Network Nirvana

Configuring your network requires a ton of tedious work, unless you take advantage of the Dynamic Host Configuration Protocol.

Troubleshooting the Server

With complex DHCP configurations, it is often difficult to tell which parameter applies to any given host, but remember two things: First, host or group declarations can specifically override the global definition, and 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. The values are applied starting from the specific and 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 para-meters). When you are troubleshooting DHCP, always start at the bottom and work 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 and the old file is renamed dhcpd.leases~. Although it is rare, sometimes the server dies at this point. When this happens, there is no dhcpd. leases file and the server cannot restart. Rather than simply creating an empty dhcpd. leases file, you’ll need to rename the old dhcpd.leases~ file back to dhcpd.leases.

The contents of the dhcpd.leases file is fairly straightforward. Each lease declaration is identified with the keyword lease followed by the IP address and a block of configuration information within curly brackets. You might have something like this:

lease  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. The date and time are Greenwich Mean Time, not local time.

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

Client Configuration

How you configure the client side depends on your distribution. For example, if you are running 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 (the Bootstrap Protocol). If you select DHCP, changes will be made to the /etc/rc.config file by setting the configuration parameters for the respective card to ” dhcpclient”. For example, without DHCP you might have an entry like this:

IFCONFIG_0 = "    broadcast    netmask up"

Once DHCP is configured, the entry would look something 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 will skip the configuration of that interface. Later in the boot process, the DHCP client script is started (for example, as /etc/rc.d/rc2.d/ S05dhclient). Now the client will try to get its configuration from the DHCP server.

Other systems, like Caldera or Red Hat, have their own configuration tool and change the appropriate file in /etc/sysconfig/network-scripts/. For example, if you wanted to configure DHCP on your eth0 interface under Red Hat, the filename ifcfg-eth0 would be changed. When done you would end up with something like this:


In most cases the default client configuration is sufficient (at least, in my experience). If not, the client has its own configuration file: /etc/dhclient.conf. If you have more than one interface on your system with different network options, 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; they 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 require statement says that the particular configuration option must be sent by a server in order for the client to accept the server’s response.

Securing Things

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 there 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 alongside 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. So make sure that you block DHCP traffic through your firewalls. If your firewall is running on a Linux machine, you can use the ipfwadm (which is called netfilter in its latest incarnation) program to block port 67 (the DHCP listen port) and port 68 (the DHPC transmit port).

Comments are closed.