9.5.1 dhcpd.conf

dhcpd 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 I find more readable than the bootptab 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 "nuts.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 acorn {         hardware ethernet 00:80:c7:aa:a8:04;         fixed-address 172.16.3.4;     }     host peanut {         hardware ethernet 08:80:20:01:59:c3;         fixed-address 172.16.12.2;     }     host hickory {         hardware ethernet 00:00:c0:a1:5e:10;         fixed-address 172.16.3.16;     } }

This sample configuration file is similar to the example used above for bootptab . It 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 real configuration line defines a parameter for the server.

We begin the dhcpd.conf file with 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.

default-lease-time

Tells the server how many seconds long a default address lease should be. The client can request that the address be leased for a specific period of time. If it does, it is assigned the address for that period of time, given some restrictions. Frequently, clients do not request a specific lifetime for an address lease. When that happens, the default-lease-time is used. In the example, the default lease is set to one day (86400 seconds).

max-lease-time

Sets the upper limit for how long an address can be leased. Regardless of the length of time requested by the client, this is the longest address lease that dhcpd will grant. The life of the lease is specified in seconds. In the example, it is one week.

get-lease-hostname

Directs dhcpd to provide a hostname to each client that is assigned a dynamic address. Further, the hostname is to be obtained from DNS. This parameter is a Boolean. If it is set to false, which is the default, the client receives an address but no hostname. Looking up the hostname for every possible dynamic address adds substantial time to the startup. Set this to "false". Only set this to true if the server handles a very small number of dynamic addresses.

We will use a few more parameters in this configuration. All of the parameters are documented in Appendix D .

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 meaning of the sample options is easy to deduce. The option names are very descriptive. We are providing the clients with the subnet mask, domain name, domain server addresses, and print server address. These values parallel those in the bootptab example shown earlier in this chapter.

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 will serve. 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 meaning of the sample options is clear. They tell the clients what router to use 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 address 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 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 they do not know that they should renew an address. Therefore the dynamic-bootp-lease-cutoff and the dynamic-bootp-lease-length parameters are only used in special circumstances. If you're interested in these parameters, see Appendix D .

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 acorn , one for peanut , and one for hickory . 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 one assigns each client a hostname:

option host-name acorn;

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 of a host statement only apply to 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 in the sample configuration 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 hostname option unnecessary for this configuration.

Given the sample dhcpd.conf file shown earlier, when dhcpd receives a BOOTREQUEST packet from a client with the Ethernet address 08:80:20:01:59:c3, it sends that client:

• The address 172.16.12.2

• The hostname peanut

• The default router address 172.16.12.1

• The broadcast address 172.16.12.255

• The subnet mask 255.255.255.0

• The domain name nuts.com

• The domain name server addresses 172.16.12.1 and 172.16.3.5

• The print server address 172.16.12.1

• The MTU for an Ethernet interface

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 system that does that assignment at the subnet level seem somehow more logical. In the next section we look at how to keep distributed servers updated.