Dynamic Host Configuration Protocol (DHCP)
Manually configuring IP addresses for a handful of systems is a fairly simple task. However, manually configuring IP addresses for an entire department, building, or enterprise of heterogeneous systems can be daunting and prone to errors! The Dynamic Host Configuration Protocol (DHCP) can assist with these tasks. A DHCP client machine can be configured to obtain its IP address automatically. When the DHCP client software is started, it broadcasts a request onto the network for an IP address. If all goes well, a DHCP server on the network will respond, issuing an address and other necessary information to complete the client’s network configuration.
DHCP is also useful for configuring mobile or transient machines. Users who travel from place to place can connect their machines to the local (wired or wireless) network and obtain an appropriate address for their location.
This chapter covers the process of configuring a DHCP server and client. It includes obtaining and installing the necessary software and then walks through the process of creating a configuration file for it. At the end of the chapter, we’ll step through a complete sample configuration.
NOTE DHCP is a standard. Thus, any operating system or device that conforms to or implements to this standard should, theoretically, be able to interoperate with a Linux-based DHCP server or client. So, for example, Microsoft Windows client systems can be configured to use DHCP and can contact a Linux-based DHCP server to get their IP addresses. The Windows clients will not necessarily know or care that their IP configuration information is being provided by a Linux server!
The Mechanics of DHCP
When a client is configured to obtain its address from the network, it asks for an address in the form of a DHCP request. A DHCP server listens for client requests. Once a request is received, it checks its local database and issues an appropriate response. The response can include any combination of an IP address, name servers, network mask, default gateway, and so on. The client accepts the response from the server and configures its local settings accordingly.
The DHCP server maintains a list of addresses it can issue. Each address is issued with an associated lease, which dictates how long a client is allowed to use the address before it must contact the server to renew the lease. When the lease expires, the client is not expected to use the address any more. As such, the DHCP server assumes that the address has become available and can be put it back in the server’s pool of addresses.
The implementation of the Linux DHCP server includes several key features common to many other DHCP server implementations. The server can be configured to issue any free address from a pool of addresses or to issue a specific address to a specific machine. In addition to serving DHCP requests, the Linux DHCP server can service Bootstrap Protocol (BOOTP) requests.
The DHCP Server
Dynamic Host Configuration Protocol Daemon (dhcpd), the DHCP server, is responsible for serving IP addresses and other relevant information in response to client requests. Since DHCP is a broadcast-based protocol, a server will usually have to be present on each subnet for which DHCP service is to be provided.
Installing DHCP Software via RPM
The Internet Systems Consortium (ISC) DHCP server is the de facto DHCP implementation for Linux distributions. It is also available in most Linux distributions’ software repositories in a prepackaged/binary format.
In this section, we run through the process of installing the ISC DHCP software on Red Hat–like Linux distros. On Linux systems running Fedora, Red Hat Enterprise Linux (RHEL), or CentOS, the ISC DHCP software is separated into two different packages:
• dhcp-client*.rpm The dhcp-client package provides the ISC DHCP client daemon.
• dhcp-server*.rpm The dhcp-server package provides the ISC DHCP server service.
On most Linux distributions, you will most likely already have the DHCP client-side software automatically installed during the original operating system installation. We can check to see what is already installed on our sample Fedora system by typing the following:
From the sample output, you can see that the client-side package is already installed.
To set up the DHCP server on a Fedora-based distro, we need to install the necessary package. We will use
dnf to download and install the software automatically:
Once this command completes successfully, we should have the necessary software installed.
Installing DHCP Software via APT in Ubuntu
On our Ubuntu server, we’ll use
dpkg to query the local software database for the DHCP client software:
From the sample output, we can see that the DHCP client package is already installed.
To install the DHCP server software on an Ubuntu distro, type the following:
Once this command completes, you should have the necessary DHCP server software installed. The DHCP server service will also be automatically started for you after installation.
Configuring the DHCP Server
The primary configuration file of the ISC DHCP server is dhcpd.conf, and most distros store the file under the /etc/dhcp/ directory. Here are the main highlights of the configuration file:
• A set of declarations to describe the networks, hosts, or groups attached to the system and possibly the range of addresses that can be issued to each respective entity. Multiple declarations can be used to describe multiple groups of clients. Declarations can also be nested in one another when multiple concepts are needed to describe a set of clients or hosts.
• A set of parameters that describes the overall behavior of the server. Parameters can be global or local to a set of declarations.
NOTE Because every site may have a unique network with unique addresses, every site must be set up with its own configuration file. If this is the first time you are dealing with DHCP, you might want to start with the sample configuration file presented toward the end of this chapter and modify it to match your network’s characteristics.
Like most configuration files in Linux, the file is ASCII text and can be modified using your favorite text editor. The general structure of the configuration file is as follows:
Each new declaration block applies to a set of clients. Different parameters can be applied to each block of the declaration.
You might want to group different clients for various reasons, such as organizational requirements, network layout, and administrative domains. To assist with grouping these clients, you can make use of certain declarations. We discuss these in the following sections.
group Individually listing parameters and declarations for each host again and again can make the configuration file difficult to manage. The group declaration allows you to apply a set of parameters and declarations to a list of clients, shared networks, or subnets. The syntax for the group declaration is as follows:
label is a user-defined name for identifying the group. The
parameters block contains a list of parameters that are applied to the group. The
subdeclarations are used in case a further level of granularity is needed to describe any additional clients that might be a member of the current declaration. Ignore the
parameters field for now. It will be covered in the upcoming section “Parameters.”
host declaration is used to apply a set of parameters and declarations to a particular host in addition to the parameters specified for the group. This is commonly used for fixed address booting or for the BOOTP clients. The syntax for a
host declaration is as follows:
label is the user-defined name for the host group. The
subdeclarations are as described in the
shared-network declaration groups a set of addresses of members of the same physical network. This allows parameters and declarations to be grouped for administrative purposes. Here’s the syntax:
label is the user-defined name for the shared network. The
subdeclarations are as described in the
subnet declaration is used to apply a set of parameters and/or declarations to a set of addresses that match the description of this declaration. Here’s the syntax:
subnet-number is the network that you want to declare as being the source of IP addresses to be given to individual hosts. The
netmask is the netmask (see Chapter 12 for more details on netmasks) for the subnet. The
subdeclarations are as described in the
range declaration specifies the range of addresses that are valid to issue to clients. The syntax is as follows:
dynamic-bootp keyword is used to alert the server that the following range of addresses is for the BOOTP protocol. The
starting-address and optional
ending-address fields are the actual addresses of the start and end blocks of IP addresses. The blocks are assumed to be consecutive and in the same subnet of addresses.
We introduced this concept earlier in the chapter. Turning on these parameters will alter the behavior of the server for the relevant group of clients. We’ll discuss these parameters in this section.
authoritative The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a user unknowingly installs a DHCP server without fully understanding how to configure it, it does not send incorrect DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network. This parameter’s syntax is as follows:
default-lease-time This specifies the default length of time (in seconds) for which IP address leases will be allocated to clients if the clients did not request any specific duration. Here is the parameter’s syntax:
filename In some applications/environments, the DHCP client may need to know the name of a file to use to boot. This is often combined with
next-server to retrieve a remote file for installation configuration or diskless booting. This parameter’s syntax is as follows:
fixed-address or fixed-address6 This parameter is only applicable under the
host declaration. It specifies the set of addresses (IPv4 or IPv6) assignable to the client. This parameter’s syntax is as follows:
get-lease-hostnames If this parameter is set to
true, the server will resolve all addresses in the declaration scope and use that for the
hostname option. This parameter’s syntax is as follows:
hardware For a BOOTP client to be recognized, its network hardware address must be declared using a
hardware clause in the
host statement. This parameter’s syntax is as follows:
hardware-type must be the name of a physical hardware interface type. Currently, only the Ethernet and Token Ring types are recognized. The
hardware-address (sometimes referred to as the media access control, or MAC, address) is the physical address of the interface, typically a set of hexadecimal octets delimited by colons. The
hardware statement can also be used for DHCP clients.
max-lease-time A client has the option to request the duration of the lease. The request is granted as long as the lease time doesn’t exceed the number of seconds specified by this option. Otherwise, the client is granted a lease to the maximum of the number of seconds specified here. Here is the syntax:
next-server statement is used to specify the host address of the server from which the initial boot file (specified in the
filename statement) is to be loaded. This syntax is as follows:
server-name is a numeric IP address or a domain name.
server-identifier Part of the DHCP response is the address for the server. On multi-homed systems, the DHCP server issues the address of the first interface. Unfortunately, this interface may not be reachable by all clients of a server or declaration scope. In those rare instances, this parameter can be used to send the IP address of the proper interface that the client should communicate to the server. The value specified must be an IP address for the DHCP server, and it must be reachable by all clients served by a particular scope. This parameter’s syntax is as follows:
server-name statement can be used to inform the client of the name of the server from which it is booting. This parameter is sometimes useful for remote clients or network install applications. This parameter’s syntax is as follows:
Name should be the name that will be provided to the client.
use-lease-addr-for-default-route Some network configurations use a technique known as Proxy ARP so that a host can keep track of other hosts that are outside its subnet. If your network is configured to support Proxy ARP, you’ll want to configure your client to use itself as a default route. This will force it to use ARP (Address Resolution Protocol) to find all remote (off-the-subnet) addresses.
This parameter’s syntax is as follows:
use-lease-addr-for-default-route command should be used with caution. Not every client can be configured to use its own interface as a default route.
Currently, the DHCP server supports more than 60 options. Here is the general syntax of an option:
Table 29-1 summarizes the most commonly used DHCP options.
Table 29-1 Common dhcpd.conf Options
A Sample dhcpd.conf File
The following is an example of a simple DHCP configuration file:
In this example, note the following:
• A single subnet is defined. The DHCP clients are instructed to use 192.168.222.1 as their default router (gateway address) and 255.255.255.0 as their subnet mask.
• A lease time of 21,600 seconds is set, but if the clients request a longer lease, they may be granted one that can last as long as 43,200 seconds.
• The range of IP addresses issued starts at 192.168.222.25 and can go as high as 192.168.222.49. The machine with a MAC address of 00:80:c6:f6:72:00 will always get assigned the IP address 192.168.222.50.
To set up your DHCP server with the sample configuration file, all you need to do is create/edit a file named /etc/dhcp/dhcpd.conf and populate the file with the entries in our sample file.
We’ve thoughtfully (we’re nice like that!) bundled working copies of the configuration file(s) used in this chapter at the following URL to save you some typing:
To follow along using this bundle, just download the file (
wget <preceding URL>), extract its contents (decompress it using
tar xvJf chapter-29.tar.xz), and copy the file(s) to the proper directories on your local system.
CAUTION It is of paramount importance that you make sure your DHCP server has at least one network interface configured with an IP address that belongs to the same network as the network defined in the subnet declaration of the dhcpd.conf file. This means, for example, that you shouldn’t have a subnet declaration that reads
subnet 192.168.222.0 netmask 255.255.255.0 while your DHCP server has a single network interface (such as ens0) with an IP address of 172.16.0.10.
You should also ensure that the IP address of the DHCP server is excluded from the network range of issued/leased IP addresses specified in the
range declaration. The DHCP server in our example should have a static IP address that lies in the range 192.168.222.1 to 192.168.222.24. If you ignore this warning, the dhcpd service will fail to start with errors similar to any of these:
Starting and Stopping dhcpd
On systemd-enabled Linux distros, you can use the
systemctl utility to query the status of the dhcpd daemon and to manage the service.
Begin by checking if the service is running:
If the output shows that the service is not running (inactive, dead, and so on), use the
start option with the
systemctl utility to start the service:
If you’ve made some dhcpd.conf configuration changes and you want the running dhcpd server instance to include/implement your changes, you can restart the service by running the following:
To stop the dhcpd service, type this:
General dhcpd Runtime Behavior
Once it’s started, the daemon patiently waits for client requests to arrive prior to performing any processing. When a request is processed and an address is issued, the daemon keeps track of the address in a file called dhcpd.leases. On Fedora, RHEL, and CentOS systems, this file is stored in the /var/lib/dhcpd/ directory.
On Debian-based distros, such as Ubuntu, the client leases are instead stored under the /var/lib/dhcp/ directory.
The DHCP Client Daemon
The ISC DHCP client daemon (named dhclient), included with many popular Linux distributions, is the software component used to talk to a DHCP server described in the previous sections. If invoked, dhclient will attempt to obtain an address from an available DHCP server and then configure its networking configuration accordingly.
Configuring the DHCP Client
The client is typically run from the startup files, but it can also be run manually. It’s normally started prior to other services/processes that are dependent on the availability of a functional/configured network stack.
As hinted, the client can be manually invoked from the command line any time after startup. The client daemon can be started without additional options, but it will attempt to obtain a lease on all interfaces configured on the system.
Here is how to start the client from the command line in its most basic form:
NOTE On most Linux distros, various mechanisms (such as Scripts, NetworkManager, Netplan, systemd-networkd, and so on) exist to help set up the system automatically as a DHCP client between each system reboot so that you won’t need to manually run the dhclient daemon each time the system needs an IP address. See Chapter 13 to learn more.
Optionally, the client daemon can be started with additional flags that slightly modify the behavior of the application. For example, you can optionally specify the interface (such as eth0) for which an address lease should be requested.
Some of the options for
dhclient are described in Table 29-2. The full syntax of the
dhclient command is shown here:
Table 29-2 dhclient Command-Line Options
DHCP is a useful mechanism for dynamically configuring the addresses for large groups of machines or mobile devices. Since DHCP is an open and standards-based protocol, the architecture and platform of the server and the client are normally irrelevant.
A Linux server running the popular and highly configurable dhcpd server software can service DHCP requests.
Client-side software also exists to easily configure the networking stack of a Linux-based machine as a DHCP client on the network. This client daemon has a number of options that make it able to speak to a variety of DHCP servers.