The most basic (and perhaps most commonly known) function of DHCP is to assign IP addresses to machines within a network. Although dynamically assigning the addresses is one of the key advantages of DHCP it is not a requirement. That is, you could configure DHCP to assign specific addresses to specific machines. For example, I have done it in some networks for the servers, as well as the clients. Each machine was configured to use DHCP, but the servers needed to have static addresses. Rather than configuring the servers themselves with a particular address, we did this using DHCP. That way, should routers, DNS servers, or whatever get changed, we did not need to reconfigure the servers.

DHCP is also useful in environments where you have a people with laptops working in multiple networks, such as people who regularly work out of the home, but still come into the office. Other cases are people who visit many of your branch offices and where these offices are on different networks. If the laptop is configured to use DHCP and there is a DHCP server at each location, the laptop is automatically configured for the local network. In fact, I use it at home on my four-node network, so I don’t have to deal with configuring each machine individually (or re-configuring it).

When the DHCP server (dhcpd) starts it reads it configuration file, which defaults to /etc/dhcp.conf, but can be changed when the server is started using the -cf option. Using the configuration file, DHCP stores the list of addresses in memory for each of the subnets to which it provides services. When a DHCP client starts, it requests an address. The server looks for an available address and assigns it to the client. Should the specific client be configured a static address, then it is this address, which is returned to the client.

The assignment of the IP address to the machine is referred to as a lease. Like leases in other contexts, DHCP leases are only valid for a specific period of time. The default is one day, but you can configure it to be most any value. In addition, it is also possible for the client to request a specific lease duration. However, to prevent any machine from holding on to the lease and not letting go, you can configure the server with a maximum lease time.

Depending on your network setup, it may be necessary to limit DHCP to just a single network segment. This could be a problem if the DHCP server is sitting on both segments. However, DHCP can be configured to listen for requests on just specific network interfaces. In addition, if for some reason your system cannot determine whether a specific interface can

Obviously, the DHCP server needs a means of keeping track of the leases across reboots of either the server or the clients. This is accomplished with the dhcpd.leases files, which is typically in the /var/state/dhcp directory. After reading the dhcpd.conf file at system startup, the server reads the dhcpd.leases file and marks accordingly those systems that have active leases.

One important thing to note is that unlike other system services, dhcpd does not re-read its configuration file while it is running. Therefore, you need to restart the server by hand each time you make a change. Also, the dhcpd.leases file is not rewritten each time the server is started. Instead, the file is maintained across reboots, so that the state of each lease is saved.

Basic Server Configuration

The dhcpd.conf file is very straightforward and easy to comprehend. At the top is a header, which contains the global configuration parameters for the server itself and which is applicable to each of the supported subnets, unless specifically overridden. Following that are the configuration declarations for all subnets accessible from the server, whether they are actually provided DHCP services or not.

Configuration is done by various statements in the dhcpd.conf file, which can be either a declaration or parameter. A declaration is used to describe the topology of your network, as it is these declarations that specify for which subnets or even individual host specific configuration is valid. Parameters define the various characters, such as how to do something (which route to take), how to behave (the length a lease is valid) or basic characteristics, such as the IP address.

In its simplest form a DHCP configuration entry consists of a subnet address, the netmask and the range of IP addresses. For example, you might have something that looks like this:

subnet 10.2.0.0 netmask 255.255.0.0 { range 10.2.3.0 10.2.3.200; }

This entry applies to the Class A network 10.2.0.0. However, only addresses in a much smaller network (10.2.3.0) are available. In fact, not all of the addresses in that range are available, since the highest address is 10.2.3.200. Note that each entry is followed by a semi-colon. Hosts can also be configured individually using the host keyword, which is followed by the name of the host.

In this example, we used the hardware and fixed-address options to define the configuration for this specific host.

These have the general syntax:

option option-name option-data

What is valid as “option-data” will depend on the option you use. Some are IP addresses or hostnames; others are can be text strings or numbers, while others are simply Boolean values (true/false or on/off). Note that you actually need to include the word “option” to tell the DHCP server that what follows is an option and not a subnet declaration or something else. Keep in mind that if an option specified as a global parameter, it applies to all of the subnets. However as mentioned above, your can also override this value in one of the subnet definitions.

Table 1 gives you a list of the more common dhcpd options. However, there are several dozen more, many of which only apply to specific protocols or services such as NNTP, finger, IRC, and so forth. For a complete list of options with even more details, check out the dhcp-options man-page.

One of the host specific definitions is “hardware” which describes the specific hardware. As of this writing only the “ethernet” and “token-ring” hardware types are supported. Following the type is the physical address of the card (i.e. the MAC address). For example, you might have something like this:

host saturn { hardware ethernet 00:50:04:53:F8:D2; fixed-address 192.168.42.3: }

This example says that the machine saturn has an Ethernet card with the MAC address 00:50:04:53:F8:D2 and it to be assigned the fixed address 192.168.42.3.

Sometimes you need to specify options for a number of machines on your network without having to treat them as a separate subnet. For example, you could define a subnet for a group of machines and then apply specific options just to that subnet. However, this means that you will generally have specify all of the necessary configuration options, plus these special nodes obviously cannot have IP addresses in the same subnet as the others.

To overcome this limitation, you can group machines together using the group keyword. Then, all the options included within the group definition apply to that group. However, it is also possible to specify parameters for specifics. Like subnets, it is also to specify individual hosts with the group. For example:

group { default-lease-time 300000; option routers 192.168.42.1; host jupiter{ hardware ethernet 00:50:04:53:D5:57; default-lease-time 500000; } host saturn { hardware ethernet 00:50:04:53:F8:D2;} host uranus { hardware ethernet 00:50:04:53:32:8F;} }

In this example, we set the default lease time (how long the lease is valid) for the group to 500000 seconds (almost 6 days) and the router to be the machine 192.168.42.1. This definition applies to the three hosts listed. However, with the host jupiter we set the default lease time to a higher value, but the router definition would still apply.

Another consideration is when there are multiple networks on the same physical network segment. There are several reasons that such a configuration is necessary and the ISC DCHP provides you with the ability to configure your system accordingly. This is done by declaring a shared-network.

A shared network is basically nothing more than a container for a group of machines. One difference to the group declaration is that a shared-network declaration can contain subnets, as well as groups or individual hosts. It has the general syntax:

shared-network network-name { shared-network-specific parameters subnet { subnet-specific parameters } group { group-specific parameters } }

Note that within either the group or subnet declarations, you can specify parameters for individual hosts, just as when they are not part of a shared-network.

Although the configuration of the DHCP server is pretty straightforward, having to administer a large number of systems by editing files can become tedious. One solution I found useful is Webmin (www.webmin.com). This provides a graphical, web-based interface to a large number of system functions (including DHCP). Figure 1, shows you the primary DHCP configuration page. At the top you see three subnets which this machine managers. Here, too, you would also see any shared networks that are configured.

Underneath are any machines that are specifically configure as well as groups of machines. When you select each object, you are can configure the same options as you can be editing the files. Figure 2, shows you the configuration for a specific host.

Troubleshooting the Server

With complex DHCP configurations it is often difficult to tell which parameter applies to any given host. When trying to figure out what is happening, there are two rules of thumb. First, host or group declarations can specifically override the global definition. In addition, host declarations can override the group declarations.

Second, definitions are not necessarily applied in the order in which they appear in the dhcpd.conf file. Instead, the values are applied starting from the specific moving to the more general. That is, the server first checks for a specific host configuration, then for a group configuration, then the subnet configuration, followed by a shared-network configuration, followed by the global declarations. Configuration options are only added to and not overwritten. Therefore, the configuration for the smaller, more specific units (like hosts) overrides those of the more general units (like global parameters). So, when trouble shooting, start at the bottom, working your way up.

Perhaps the most basic troubleshooting technique is to look at the leases the server has assigned. This is done by looking at the leases file (/var/state/dhcp/dhcp.leases), which maintains the current state of all active leases. One thing to note is that this file is rewritten from time to time to keep the file from growing too large. First a temporary copy is made called and the old file is renamed dhcpd.leases~. Although fairly rare, it can happen that for some reason the server dies at this point. There is no dhcpd.leases file and thus server cannot restart. Rather than simply creating an empty dhcpd.leases file, you need to rename dhcpd.leases~ to get things to work correctly.

The contents of the dhcpd.leases file is fairly straight forward. Each lease declaration is identified with the keyword “lease” followed by the IP address and a block of configuration information within curly brackets. For example, you might have something like this:

lease 192.168.42.1 { starts 0 2000/01/30 08:02:54; ends 5 2000/02/04 08:02:54; hardware ethernet 00:50:04:53:D5:57; uid 01:00:50:04:53:D5:57; client-hostname “PC0097”; }

The starts and ends statements indicate the period when the lease is valid. Each entry is of the form:

weekday yyyy/mm/dd hh:mm:ss;

The weekday is the numerical value for the day of the week starting with 0 on Sunday, as in this case. One key aspect is that the date and time are Greenwich Mean Time and not local time.

The hardware entry is the same as from the dhcpd.conf file and list the hardware address of the card. The uid entry is unique identified for the client, using either a ASCII string client identifier supplied by the client or the hardware address preceeded by hardware type (in this example “01”).

Often times the client wants to pick its own name. There are two ways a client can do this. One is using the “Client Hostname” option, as in this example. The other is using the “Hostname” option, which is used by many operating systems, such as Windows 95. In this cases, you would have just the keyword “hostname”, which is also followed by the name of the host.

Just because the dhcpd.leases file contains a specific entry does not make it valid. One approach would be to remove any applicable entry (based on either the IP address or hardware address) and then re-start the server. If you end up with the same results, there may be a problem with the way the client is configured.

It may also be necessary to see what the server thinks it is doing as compared to looking at the client or dhcpd.leases file and guessing what the server thinks it is doing. This can be accomplished by running the dhcp server in the foreground (using the -f option) and having it output all of the error messages to stderr (using the -d option) rather than using the system logging daemon. You can then watch the server as it accepts and processes requests.

Client Configuration

Configuring the client-side is fairly straight forward, depending on your distribution. For example, if you are running a SuSE 6.3, then all you need to do is get into the network configuration portion of YAST and select the basic network configuration. Pressing F3 sets auto-IP configuration, which gives you the choice of configuring either DHCP or BOOTP. If you select DHCP, you end with something like figure 2. This makes changes to the file /etc/rc.config by setting the configuration parameters for the respective card simply to “dhcpclient”. For example, without DHCP you might have an entry like this:

IFCONFIG_0=”192.168.42.1 broadcast 192.168.42.255 netmask 255.255.255.0 up”

Once DHCP is configured the entry would look like this:

IFCONFIG_0=”dhcpclient”

Note that you could have some of the interfaces configured to use DHCP and others with static addresses. When the system boots, the /etc/rc.d/network script is called (for example, as /etc/rc.d/rc2.d/S05network). If it finds that the IFCONFIG line for the respective card equals “dhcpclient”, it simply skips the configuration of that interface, for the moment. Later in the boot process, the DHCP client script is started (for example, as /etc/rc.d/rc2.d/S05dhclient). It is here that the client then tries to get its configuration from the DHCP server.

On other systems, like Caldera or Redhat, have their own configuration tool and change the appropriate file in /etc/sysconfig/network-scripts/. For example, if you were configuring DHCP on your eth0 interface, the script ifcfg-eth0 would be changed. When done you end up with something like this:

DEVICE=eth0 IPADDR=0.0.0.0 NETMASK=255.255.255.0 NETWORK= BROADCAST=0.0.0.255 GATEWAY=none ONBOOT=yes DYNAMIC=dhcp

Find the line labeled simply DYNAMIC= and change it to DYNAMIC=dhcp.

In most cases the default client configuration is sufficient (at least, in my experience). If not, the client has it’s own configuration file: /etc/dhclient.conf. If you have more than one interface on your system with different network option, you need to group the options by interface. For example, you might have something like this:

interface eth0 { send dhcp-lease-time 3600; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name; require subnet-mask, domain-name-servers; }

The send statement tells the client to send the particular option with the specified value. These can be any of the options the server understands and are defined in detail in the dhcp-options (5) man-page.

The request statement is a list of configuration options (not the values) that the client requests that the server send. The key word is “request” as the required statement, says that the particular configuration option must be sent by a server in order for the client to accept the server’s response.

Security

At first glance, there may not seem to be much to talk about in terms of security and DHCP. However, considering the importance of DHCP, a few precautions are in order.

The first consideration is the machine itself. Although an outage of a couple of hours might be something you can deal with, any long outage means that they may be a number of machines without a valid configuration or even a valid IP address. Therefore, you need to look at what other services the machine with your DHCP server provides. Since there is very little computer power required to support DHCP, you can easily get away with smaller machines. This might be preferable to having the dhcpd running along side some other machines. On the other hand, I worked in one company where the DHCP server was also the DNS and mail server for the company.

Another issue to consider is a denial of service attack. If your DHCP server were accessible from the Internet, it would be possible for someone to gobble up all of your IP addresses, leaving nothing for your own machines. Therefore, you should block DHCP traffic through your firewalls. If your firewall is running on a Linux machine, you can use the ipfwadm program to block port 67 (the DHCP listen port) and port 68 (the DHPC transmit port).

Table 1 – Common dhcpd.conf Configuration Options and Declarations