home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam    

Book HomeTCP/IP Network AdministrationSearch this book

9.5. DHCP

Bootstrap 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:

Backward compatibility with Bootstrap Protocol

A DHCP server can support BOOTP clients. Properly configured, a DHCP server can support all of your clients.

Full configurations

A DHCP server provides a complete set of TCP/IP configuration parameters. (See Appendix D, "A dhcpd Reference" for a full list.) The network administrator can handle the entire configuration for the users.

Dynamic address assignments

A DHCP server can provide permanent addresses manually, permanent addresses automatically, and temporary addresses dynamically. The network administrator can tailor the type of address to the needs of the network and the client system.

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.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 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; 
option domain-name "wrotethebook.com"; 
option domain-name-servers,; 
option lpr-servers; 
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 netmask { 
    option routers; 
    option broadcast-address; 
subnet netmask { 
    option routers; 
    option broadcast-address; 
# Identify each BOOTP client with a host statement 
group { 
    use-host-decl-names true; 
    host 24seven { 
        hardware ethernet 00:80:c7:aa:a8:04; 
    host rodent { 
        hardware ethernet 08:80:20:01:59:c3; 
    host ring { 
        hardware ethernet 00:00:c0:a1:5e:10; 

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.


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).


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 here, it is one week.


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. Set it to true only if the server handles a very small number of dynamic addresses.

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 to 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;

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 address

  • The hostname rodent

  • The default router address

  • The broadcast address

  • The subnet mask

  • The domain name wrotethebook.com

  • The domain name server addresses and

  • The print server address

  • 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 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.

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.