Alternate Use Of
DHCP

We desired some tool to make deployment of new equipment as simple as possible. We wanted:

• no need to power up the new item on before deploying it
• no need to find out the new equipment's MAC address
• no need to change any configuration file anywhere on the network
• no need to keep track of network items such as gateway, subnet mask, root domain name, DNS servers, NTP (time) servers, or WINS servers
• no need to keep track of used vs. available IPaddresses
• ability to use IPaddresses for permissions
• ability to configure printer IPaddresses into computers with confidence they would never change
• support "guest" devices
• support all infrastructure devices that expect DHCP service

DHCP's design focus was apparently the slightly different problems of a) sharing the scarce resource of IPaddresses, and/or b) allowing a foreign device to temporarily insert itself into the network as a guest easily. (Support of "guest" devices is actually on our list of our needs, but it's only one of many items rather than the main focus.)

We found that we could reconfigure DHCP to serve our purposes perfectly. We use the ISC DHCP server daemon running under Linux. It happens that we initially used version 3.0.1 (from ftp.isc.org) on both primary and secondary servers, and later upgraded the primary server to use version 3.0.5. We use the daemon software exactly as supplied; all our tweaks are to the configuration (and surrounding scripts and cron jobs); we made no changes to the `dhcpd` code (in fact we didn't even compile it, rather we relied on pre-built packages).

Address Reuse

One of our requirements was that the IPaddress of devices (computers, printers, etc.) never change. In its typical configuration, DHCP has a strong preference (further aided by some logic in Windows) for devices to reuse the same IPaddress. But it does not guarantee it. And there's no configuration option to force 100% address reuse.

We however made DHCP always assign the same IPaddress to a device anyway, simply by configuring a very very long lease time. Typically the lease time is measured in hours or days. We set the lease time to three years (min-lease-time, default-lease-time, and max-lease-time all 94608000)! Even if a device --such as a printer-- is powered off over an entire summer vacation, when it's turned back on in the fall it will again receive the very same IPaddress. This is particularly important where printers use a TCP-style port, so each computer is linked to a particular printer by the printer's IPaddress.

In order to remember all these associations between MAC address and IPaddress for such a long time in our environment, our DHCP daemon needs some kind of database. The only existing function that's anything like the database we need is the file where the information about the current leases persists from one invocation of the DHCP daemon to the next (/var/lib/dhcp/dhcpd.leases). Typically this file is fairly small and contains only relatively transient information.

We treat this file as a database. In our environment it contains an entry for every device that's ever existed on the network, so it's much larger than is typical. To force the file to be no larger than necessary (and reasonably up to date), we use a `cron` job to stop then restart the DHCP daemon every day.

For us it's very important to keep this file intact. If our DHCP daemon were started without this file, it would behave in undesired ways. So we have several different backup mechanisms. The net result is there are three or four backup copies of this file at all times (not counting the copies in current use by the DHCP daemons), and two or three of them are on entirely separate machines.

High Availability

Because our operation relies so heavily on it, we want DHCP service to always be immediately available on our network. We want it to be available even if some piece of computer hardware or network hardware fails and even if there's a power hit. Of course the first thing we did is connect our DHCP servers to an Uninteruptable Power Supply (UPS) which is in turn connected to emergency power. Even so, the only way to get the high availability we desire is to in effect implement some sort of "hot backup".

The difficulty of deploying very high availability DHCP has been one of DHCP's main drawbacks for a long time. Previously, the best one could do was divide the network, configure two DHCP servers to each serve half the network, then manually change the configurations as necessary in response to failures. If one DHCP server failed, the other --since it was already running-- could be reconfigured quickly to temporarily serve the entire network. This was not completely automatic however; it still required a bit of manual intervention.

Recent versions of the DHCP daemon include the capability to have two overlapping DHCP daemons active at the same time without making any conflicting address assignments. With this capability, the secondary DHCP server can take over automatically if the primary DHCP server fails. However the new feature was not easily available to us at the time, was apparently somewhat difficult to configure at the time, and still required manual intervention to restore backup operation after a fault was fixed.

So we figured out another way to provide very high availability. Our method relied on two assumptions that were true in our environment: i) IPaddresses never change, and ii) very little new equipment arrives on the network most of the time. Our method would probably not work in other environments where one or both of these assumptions was not the case.

Our backup DHCP server has a slightly different configuration, and it uses a very recent copy of the lease database from the primary server. It delays responding for five seconds (min-secs 5), its lease time is only one hour (lease time 3600), and it's "non authoritative". So normally all requests are handled by the primary ("authoritative") server since the delay always makes the backup server's response come in second and so always be discarded. But if the primary server fails, the backup server's (late) response is the only response and so is accepted and used.

Since the backup DHCP server is working off the lease database copied from the primary DHCP server less than a day ago, it virtually always assigns exactly the same addresses the primary would have. And even in the rare cases where this isn't so, every client will switch back to the primary DHCP server soon. They'll switch back because address assignments made by the backup DHCP server are only good for a short period of time, forcing clients to re-request DHCP service again soon. When clients re-request DHCP service, if the primary has been fixed it will respond and its response will get to the client first. (And since address leases assigned by the backup server are so transitory, it doesn't matter if they're not completely recorded and propagated back to the primary DHCP server nor if they're changed by the primary DHCP server.)

Brittleness

The main problem with this alternate/unintended use of DHCP is it's "brittle". In other words it's easy to accidentally mess things up and hard to put them back right again. It's a little like living with a Ming vase on your nightstand.

If the DHCP server is ever started with the wrong leases file (or a corrupt leases file, or no leases file at all), or if a "rogue" DHCP server is ever active on the network, client computers may change their IPaddress, and it may be difficult to go back to the status quo ante.