The benefits of DHCP are compounded when you are using Linux as its OS. In this Daily Drill Down, I will go through the steps of configuring a Linux server to work as a DHCP server.

Fear not—it’s actually quite simple.

The ins and outs of DHCP
The Dynamic Host Configuration Protocol (DHCP) is nothing new to many Linux users. Most people have a DHCP client installed on their computers so they can connect to the Internet via cable or DSL modems. This allows them to have a dynamically assigned IP address every time they connect to their ISP, usually just by booting the system if they have a dedicated cable or DSL connection. This is an easy way for ISPs to hand out semi-permanent IP addresses to their clients without giving everyone a real static IP address. In fact, if you leave your computer on most of the time, you may end up with the same IP address for a very long time since it works on an IP address lease/renewal basis.

However, DHCP is far more versatile than this usage might imply. It can be used in any corporate environment where laptops come and go and computers are turned on and off or are changed around on a semi-regular basis. For most system administrators, dealing with network changes, IP address changes, and so forth, is one of their most time-consuming tasks. Fortunately, DHCP allows most system administrators to deal with a large networked environment with a greater degree of ease.

DHCP was designed to provide all possible TCP/IP configuration parameters to client computers using the client/server model. Because it includes every configuration option defined in the Requirements for Internet Hosts RFC, there is no need for a system administrator to configure TCP/IP on a user’s desktop. It is all done by the interaction between the DHCP client and the DHCP server.

IP leasing
How DHCP handles IP address leasing is quite simple. A DHCP client initiates a conversation with the server, and the server leases an IP address to the client for a configurable period of time. When the time expires, the client must either renew the lease or return the address to the server so that it can be assigned to another system. There is no need to create a custom configuration for each client since the server is responsible for the address assignments. This also allows you to make efficient use of IP addresses. If someone is out of the office for a week, their valuable IP address (which might be needed by someone bringing a laptop into the office for a day) is not wasted.

The only requirement is that the DHCP server must use a static IP address. This is because clients need to know which system to connect to, and if the server is also using a dynamic IP address, it won’t know where to connect to get the information it needs to configure TCP/IP on the client system. Also, DNS knows nothing about addresses that are assigned through DHCP, which means that remote computers cannot look up the address of a system that received its IP address via DHCP. There is an ongoing project, however, to implement a dynamic DNS that will allow DHCP servers to update the DNS database information to reflect dynamic IP address assignments and changes. Since this poses a slight security risk, the work on dynamic DNS is slow and careful. But, in the meantime, DHCP works well enough for most network configurations and will help minimize the amount of time any system administrator spends working on individual client computers.

To install the DHCP server, you need dhcpd. You can obtain it via the source code from or install the package that came with your Linux distribution. For Red Hat 6.2 users, this is dhcp_2.0_5.i386.rpm, which you can find on your installation CD. The latest stable version of dhcpd is 2.0.

Installing dhcpd
Once you have the source tarball or the RPM/DEB package for your distribution, install it. For RPM/DEB package users, this process is simple and straightforward. To install from the source code, untar the source code and enter the dhcp_2.0 subdirectory, then type:
make install

If you have a previous version of DHCP installed on your system, be sure to remove it prior to running make install so that you do not mix man pages, configuration files, or binaries.

Configuring dhcpd
The configuration file for your DHCP server is the /etc/dhcpd.conf file. This file contains numerous configuration commands that operate the server and provide configuration information to the clients.

A DHCP server can provide service to individual hosts through static address assignments (useful for servers) or to an entire subnet of hosts through dynamic address assignments. The configuration file uses host and subnet statements that identify the client systems.

The following is an example of a host statement:
host ns {
 hardware ethernet 12:34:56:78:AB:CD;

This statement defines the host name, Ethernet address, and IP address of the client. Using this statement, any time the client with the matching Ethernet address connects to the server, the server will return the defined host name and the defined static IP address.

The following is an example of a subnet statement:
subnet netmask {

This statement defines the network we are providing DHCP service for, in this case It also says that the IP addresses it is allowed to lease are from to The range clause defines the low and high values of the IP addresses the DHCP server is allowed to lease. It must always be used within a subnet statement, and the range defined must be within the address space of the defined subnet.

dhcpd configuration options
There are many configuration options available to you in the /etc/dhcpd.conf file. All of these options can be specified within a host or subnet statement or within a group statement. The group statement can be used to supply configuration options to a group of host or subnet statements. Also, you can use options outside of group, subnet, or host statements if you wish to apply those options to every single system and network you define. Because of this flexibility, you can completely tailor your configuration to your specific needs.

The first statements you should be concerned with are the allow and deny statements. These statements control how dhcpd handles client requests. The three allow/deny statements are as follows:

  • booting—This statement is used within a host statement to allow or deny the specific host from obtaining any configuration information from the DHCP server. By default, hosts are allowed booting.
  • bootp—This statement is used to tell the server whether or not it should act as both a BootP and DHCP server or just a DHCP server. By default, BootP clients are allowed, so you need only one server to handle both DHCP and BootP requests.
  • unknown_clients—This statement controls whether dhcpd will allow or deny clients for which it does not have specific host entries. By default, this is allowed, as denying this feature takes away about 90 percent of the reason why anyone would want to use a DHCP server.

For example, to deny booting, you would use:
deny booting;

There are also many other configuration options that control the server and the DHCP protocol. The more commonly used options are as follows:

  • boot_unknown_clients [true|false]—If the value is false, only clients that have a host statement are assigned an address. The default is true.
  • default_lease_time [seconds]—This option defines the length of time, in seconds, for an IP address lease if the client does not request a specific lease length.
  • dynamic_bootp_lease_cutoff [date]—This option defines a termination date for addresses assigned to BootP clients. By default, BootP clients are assigned a permanent address.
  • dynamic_bootp_lease_length [seconds]—This option defines the length of time in seconds for an IP address lease for BootP clients. Note, however, that BootP clients do not renew address leases, so a client that does not boot and contact the server often enough will lose its lease.
  • fixed_address [address[,address…]]—This option assigns a permanent IP address to a host as part of a host statement. More than one address can be assigned for a client that boots on more than one subnet.
  • get_lease_hostnames [true|false]—If the value is true, dhcpd will perform a reverse lookup for every dynamically assigned address and send to the client the host name it gets from DNS. However, this can add a lot of extra overhead for servers on larger networks. By default, this value is false, and no reverse lookups are done.
  • hardware ethernet [address]—This option defines the client’s Ethernet address within a host statement. The DHCP server uses the Ethernet address to map host information to a specific client. For BootP clients, this is the only way dhcpd can map the information; however, DHCP clients can use other values in addition to the Ethernet address to identify themselves to the server. To obtain the Ethernet address of a Linux client, run ifconfig and check the Hwaddr field.
  • max_lease_time [seconds]—This option defines the maximum length, in seconds, of a lease length. This is the maximum lease length a client may receive regardless of what it requests.
  • range [dynamic_bootp] [low address] [high address]—This option defines the range of IP addresses available for the server to dynamically assign. The argument [dynamic_bootp] tells dhcpd to assign dynamic IP addresses to BootP clients as well as DHCP clients. By default, BootP clients are not assigned dynamic IP addresses because BootP was not designed for it.
  • server_identifier [address]—This option defines the IP address of the server that is sent to clients. By default, the address of the server’s network interface is used, so this should be used only if the server presents an incorrect address for some reason.
  • server_name [“name”]—This option defines the host name of the server.
  • use_host_dec1_name [true|false— This option defines whether the server will send the name provided on the host statement to the client as its host name.
  • use_lease_addr_for_default_route [true|false]—This option sends the client its own address as the default route instead of sending the true default route.

The previous statements deal with how the server operates; however, there are more configuration options available for client operation. Some of the more common options are as follows:

  • option broadcast_address [address]—Defines the broadcast address.
  • option domain_name [“domain”]—Defines the domain name.
  • option domain_name_servers [address_list]—Lists the addresses of the DNS name servers.
  • option finger_server [address_list]—Lists the finger servers available to the client. Finger servers are typically used on sites that block finger traffic at the firewall.
  • option host_name [“name”]—Defines the client’s host name.
  • option nis_domain [“name”]—Defines the name of the local NIS (Network Information Services) domain.
  • option nis_servers [address_list]—Lists the addresses of the NIS servers.
  • option nntp_server [address_list]—Lists the addresses of the NNTP servers the client is to use.
  • option ntp_servers [address_list]—Lists the addresses of the NTP (Network Time Protocol) servers the client is to use.
  • option pop_server [address_list]—Lists the addresses of the POP3 servers the client is to use.
  • option routers [address_list]—Defines the default router.
  • option smtp_server [address_list]—Lists the addresses of the SMTP servers the client is to use.
  • option subnet_mask [mask]—Defines the subnet mask. If this option is undefined, the network mask from the subnet statement is used.
  • option time_offset [value]—Defines the offset from Coordinated Universal Time of your time zone (i.e., _5 would mean Eastern Standard Time).
  • option www_server [address_list]—Lists the addresses of the Web servers available to the client. Typically, this would be used to define proxy Web servers the client is to use.

There are many more configurable client options than those listed, but these are the ones most commonly used. For a full list of available options, please read the man pages for dhcpd.conf and dhcp_options.

A sample dhcpd.conf file
The layout of the /etc/dhcpd.conf file is similar to the layout of configuration files for BIND in that it uses a programming-like system of specifying statements. Each group, subnet, and host statement must be enclosed within curly brackets, and every statement must end with a semicolon. You can also include comments in your configuration file by preceding the comment with a hash symbol. An example /etc/dhcpd.conf file follows:
# Define global values
max_lease_time 604800;
default_lease_time 86400;
option subnet_mask;
option domain “”;
option domain_name_servers,;
option pop_server;
option smtp_server;

# Define dynamic address range for the subnet
subnet netmask {
 option routers;
 option broadcast_address;

# Host statements for clients with static IP addresses
group {
 use_host_dec1_names true;
host ns {
hardware ethernet 12:34:56:78:AB:CD;
host router {
 hardware ethernet 00:80:C7:A1:10:5C;
 fixed address;

This example first defines some global properties, like the maximum lease time of one week and the default lease time of one day. The subnet mask is defined as well as the domain name, the two DNS servers, and the POP3 and SMTP servers (both of which are the same machine).

Next, we define a group with the option to use the host names as defined in the enclosed host statements. Then, we define the host statements for two computers, ns, and router. As you can see, the ns computer acts as a DNS server as well as a POP3 and an SMTP server.

Configuration problems
There are a few stumbling blocks you may encounter after your DHCP server is configured and running. Primarily, if you provide DHCP services to Microsoft Windows clients, you may encounter problems with the limited broadcast address. If Windows clients do not see DHCP messages from the server while other clients, such as Linux clients, do, you may need to define a specific route for the limited broadcast address on your Linux server. To do so, add the following to your /etc/hosts file: lim_broad

Then, add a route for the limited broadcast address by using this command:
route add _host lim_broad dev eth0

To make this a more permanent change, add the previous command to your /etc/rc.d/rc.local file. For Red Hat and Caldera users, the above commands have been added for you in the stock DHCP init script, /etc/rc.d/init.d/dhcpd.

If you have problems running dhcpd on multiple network interfaces, you most likely have an older kernel. Be sure you are using a kernel version of 2.0.31 or higher.

If you get a Protocol Not Configured error, be sure that your kernel was compiled with the CONFIG_PACKET and CONF_FILTER options turned on.

Setting up a DHCP server is not too terribly difficult. The initial configuration may take some time, but the benefits in the long run include ease of configuration across the network, easier IP address management, and considerable time savings. Because of the versatile nature of the DHCP server software, it even makes sense in an environment of sole static IP usage where the configuration options are often the same. If similar TCP/IP settings are used, using a DHCP server precludes the need to configure every computer individually. In short, a DHCP server makes sense even if you don’t use dynamic IP addresses. With the ability to handle BootP clients on top of DHCP clients, dhcpd is an extremely effective and useful tool in any network environment.

Vincent Danen, a native Canadian in Edmonton, Alberta, has been computing since the age of 10, and he’s been using Linux for nearly two years. Prior to that, he used OS/2 exclusively for approximately four years. Vincent is a firm believer in the philosophy behind the Linux “revolution,” and heattempts to contribute to the Linux causein as many ways as possible—from his FreezerBurn Web site to building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from BrainBench.He hopes to tackle the RHCE once it can be taken in Canada.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.