9.5. DHCPBootstrap Protocol (BOOTP) was the first comprehensive configuration protocol. It provides all of the information commonly used to configure TCP/IP, from the client's IP address to what print server the client should use. BOOTP was simple and effective; so effective, in fact, that it became the basis for Dynamic Host Configuration Protocol (DHCP). DHCP operates over the same UDP ports, 67 and 68, as BOOTP. It provides all of the services of BOOTP as well as some important extensions. Dynamic Host Configuration Protocol provides three important features:
In this section we configure a DHCP server that supports BOOTP clients, performs dynamic address allocation, and provides a wide range of configuration parameters for its clients. Several implementations of DHCP are available for Unix systems. Some are commercial packages and some run on a specific version of Unix. We use the Internet Software Consortium (ISC) Dynamic Host Configuration Protocol Daemon (dhcpd). It is freely available over the Internet and runs on a wide variety of Unix systems, including both our Linux and Solaris sample systems. (See Appendix D, "A dhcpd Reference" for information on downloading and compiling dhcpd.) If you use different DHCP server software, it will have different configuration commands, but it will probably perform the same basic functions. 9.5.1. dhcpd.confdhcpd reads its configuration from the /etc/dhcpd.conf file. The configuration file contains the instructions that tell the server what subnets and hosts it services and what configuration information it should provide them. dhcpd.conf is an ASCII text file that is similar to a C language source file. The easiest way to learn about the dhcpd.conf file is to look at a sample: # Define global values that apply to all systems. default-lease-time 86400; max-lease-time 604800; get-lease-hostnames true; option subnet-mask 255.255.255.0; option domain-name "wrotethebook.com"; option domain-name-servers 172.16.12.1, 172.16.3.5; option lpr-servers 172.16.12.1; option interface-mtu 1500; # Identify the subnet served, the options related # to the subnet, and the range of addresses that # are available for dynamic allocation. subnet 172.16.3.0 netmask 255.255.255.0 { option routers 172.16.3.25; option broadcast-address 172.16.3.255; range 172.16.3.50 172.16.3.250; } subnet 172.16.12.0 netmask 255.255.255.0 { option routers 172.16.12.1; option broadcast-address 172.16.12.255; range 172.16.12.64 172.16.12.192; range 172.16.12.200 172.16.12.250; } # Identify each BOOTP client with a host statement group { use-host-decl-names true; host 24seven { hardware ethernet 00:80:c7:aa:a8:04; fixed-address 172.16.3.4; } host rodent { hardware ethernet 08:80:20:01:59:c3; fixed-address 172.16.12.2; } host ring { hardware ethernet 00:00:c0:a1:5e:10; fixed-address 172.16.3.16; } } This sample configuration file defines a server that is connecting to and serving two separate subnets. It assigns IP addresses dynamically to the DHCP clients on each subnet and supports a few BOOTP clients. All of the lines that begin with a sharp sign (#) are comments. The first few real configuration lines in the file specify a set of parameters and options that apply to all of the subnets and clients served. The first three lines are parameters, which provide direction to the server. All three of the sample parameters define some aspect of how dhcpd should handle dynamic address assignments.
The configuration file uses a few more parameters that will be explained as we go. For a complete list of all DHCP parameters, see Appendix D, "A dhcpd Reference". The next four lines are options. The options all start with the keyword option. The keyword is followed by the name of the option and the value assigned to the option. Options define configuration values that are used by the client. The meanings of the sample options are easy to deduce. The option names are very descriptive. We are providing the clients with the subnet mask, domain name, domain name server addresses, and print server address. These values are similar to those that could have been provided with the old BOOTP service. DHCP, however, can do more than BOOTP. For sake of illustration, we also define the maximum transmission unit (MTU). The sample interface-mtu option tells the client that the MTU is 1500 bytes. In this case, the option is not needed because 1500 bytes is the default for Ethernet. However, it illustrates the point that DHCP can provide a very complete set of configuration information. The subnet statements define the networks that dhcpd serves. The identity of each network is determined from the address and the address mask, both of which are required by the subnet statement. dhcpd provides configuration services only to clients that are attached to one of these networks. There must be a subnet statement for every subnet to which the server physically connects, even if some subnets do not contain any clients. dhcpd requires the subnet information to complete its startup. The options and parameters defined in a subnet statement apply only to the subnet and its clients. The meanings of the sample options are clear. They tell the clients what router and what broadcast address to use. The range parameter is more interesting, as it goes to the heart of one of DHCP's key features. The range parameter defines the scope of addresses that are available for dynamic address allocation. It always occurs in association with a subnet statement, and the range of addresses must fall within the address space of the subnet. The scope of the range parameter is defined by the two addresses it contains. The first address is the lowest address that can be automatically assigned, and the second is the highest address that can be assigned. The first range parameter in the example identifies a contiguous group of addresses from 172.16.12.50 to 172.16.12.250 that are available for dynamic assignment. Notice that the second subnet statement has two range parameters. This creates two separate groups of dynamic addresses. The reason for this might be that some addresses were already manually assigned before the DHCP server was installed. Regardless of the reason, the point is that we can define a noncontiguous dynamic address space with multiple range statements. If a range parameter is defined in a subnet statement, any DHCP client on the subnet that requests an address is granted one as long as addresses are available. If a range parameter is not defined, dynamic addressing is not enabled. To provide automatic address assignment for BOOTP clients, add the dynamic-bootp argument to the range parameter. For example: range dynamic-bootp 172.16.8.10 172.16.8.50; By default, BOOTP clients are assigned permanent addresses. It is possible to override this default behavior with either the dynamic-bootp-lease-cutoff or the dynamic-bootp-lease-length parameter. However, BOOTP clients do not understand address leases and do not know that they should renew an address. Therefore the dynamic-bootp-lease-cutoff and the dynamic-bootp-lease-length parameters are used only in special circumstances. If you're interested in these parameters, see Appendix D, "A dhcpd Reference". Each BOOTP client should have an associated host statement that is used to assign the client configuration parameters and options. It can be used to manually assign the client a permanent, fixed address. The sample configuration file ends with three host statements: one for 24seven, one for rodent, and one for ring. Each host statement contains a hardware parameter that defines the type of network hardware (ethernet) and the physical network address (e.g., 08:80:20:01:59:c3) used by the client. The hardware parameter is required in host statements for BOOTP clients. The Ethernet address is used by dhcpd to identify the BOOTP client. DHCP clients can also have associated host statements. For DHCP clients, the hardware parameter is optional because a DHCP client can be identified by the dhcp-client-identifier option. However, it is simpler for a DHCP client connected via Ethernet to be identified by its Ethernet address. A wide variety of parameters and options can be defined in the host statement. For example, adding to each host statement an option similar to the following assigns each client a hostname: option host-name 24seven; It is often easier, however, to define options and parameters at a higher level. Global options apply to all systems. Subnet options apply to every client on the subnet, but the options defined inside a host statement apply to only a single host. The host-name option shown above would need to be repeated with a different hostname in every host statement. An easier way to define a parameter or option for a group of hosts is to use a group statement. A group statement groups together any other statements. The sole purpose of the group statement is to apply parameters and options to all members of the group. That is exactly what we do in the example. The group statement groups all of the host statements together. The use-host-decl-names parameter in the group statement applies to every host in the group. This particular parameter tells dhcpd to assign each client the hostname that is declared on the host statement associated with that client, which makes the host-name option unnecessary for this configuration. Given the sample dhcpd.conf file shown earlier, when dhcpd receives a request packet from a client with the Ethernet address 08:80:20:01:59:c3, it sends that client:
The client receives all global values, all subnet values, and all host values that are appropriate. Clearly, DHCP can provide a complete configuration. Your DHCP configuration, though larger in the number of systems supported, probably is simpler than the example. Some commands appear in the sample primarily for the purpose of illustration. The biggest difference is that most sites do not serve more than one subnet with a single configuration server. Servers are normally placed on each subnet. This reduces the burden on the server, particularly the burden that can be caused by a network-wide power outage. It eliminates the need to move boot packets through routers. Also, the fact that addresses are assigned at the subnet level makes placing the assigning system at the subnet level as well somehow more logical. DHCP servers are not the only servers that work best when located close to the clients. In the next section we look at how to keep distributed servers updated. Copyright © 2002 O'Reilly & Associates. All rights reserved. |
|