Because IP address management is such an important corporate function, we searched for and tested several directory-enabled servers to see whether the directory features are mere frosting on the cake or whether they provide genuine, practical value. To gauge how well directories and DHCP get along, we tested the latest versions of DHCP servers from Microsoft Corp. and Novell, comparing them with the Internet Software Consortium's dhcpd, which is the watermark for traditional IP address management.

Powerful Selling Point

Despite some initial skepticism, we were sold on one crucial feature of directory-enabled DHCP solutions: True directory-managed IP address management offers fault-tolerance. The all-important lease information of a DHCP scope is kept intact even after a server gets replaced or after the DHCP service is started on another server.

Because directories by nature synchronize their copies of the directory database to each other (the replica ring), each server doesn't need to be fault-tolerant, which is a significant cost savings. Another tantalizing benefit to using a directory for IP address management is giving applications the ability to access the directory for DHCP lease information. Applications can correlate IP addresses to user and other security information. Unfortunately, we found no nonproprietary third-party application support to perform this network magic. This dearth of products is odd because several security products, including Check Point Software Technologies' FireWall-1 and Novell's BorderManager, can corroborate a user's IP number to a user name. But further investigation revealed that FireWall-1 uses a separate information store, and BorderManager, while it uses the directory as an information store, requires additional proprietary software on the client end.

While a directory can be an excellent ingredient in your network mix, it's really just an extra layer on the DHCP cake, not a whole new concoction. Network managers who are satisfied with their current DHCP solutions may not need to roll out a whole new implementation; those interested in fault-tolerance, however, might do well to investigate the one truly directory-enabled--and thus fault-tolerant--solution available.

A Helping of Fault-Tolerance

RFC 2131, Dynamic Host Configuration Protocol, hasn't been updated since March 1997. In network years, that makes it practically ancient. The obvious question one might ask is: How come the DHCP protocol itself wasn't changed to be more fault-tolerant? The answer is: It didn't need changing. The major operational problem with DHCP relates to DHCP lease information: The protocol doesn't deal with how the state of the lease information is stored. Rather, the servers handle the state information, and they need to do so in a better manner than they have in the past.

DHCP state information is a crucial--and fragile--resource. Any administrator who has lost a DHCP server drive or suffered DHCP lease database corruption can vouch for that chaos ensues.

As you can see from the graphic "Broken Leases Cause Chaos," state information is the difference between a smoothly functioning network and a network where all the users are calling the helpdesk as soon as they boot up.

When a DHCP server loses state information, client machines are still using IP addresses from the scope--which the server, having had a frontal lobotomy, doesn't know anything about. That is, workstations A and B are merrily using their previously allocated addresses with impunity, without the server's knowledge. Because the workstations are not yet in a renewing or rebinding state, they aren't sending DHCPrequest packets to the server. In short, because they're not communicating with the server at all, they have no idea the server is having a bad day, and the server knows nothing about their use of addresses in its scope.

On a live production segment that has lost its DHCP state information, IP address conflicts are inevitable. When a client asks for a lease, the server issues the first "available" lease--which, in our example, is in use by a client machine. In this environment, large-scale IP address conflicts tend to result, and users have large-scale meltdowns. It isn't pretty.

Typical DHCP fault-tolerance solutions follow the 80-20 rule (two servers on a subnet--one with 80 percent of the range, the other with 20 percent) and use a SAN (storage area network) or local RAID storage. Although these solutions can provide the required fault-tolerance, using one is a little like boosting car performance by using nuclear power--expensive and wasteful for the task at hand.