Unleashing the Power of DHCP
Although the Dynamic Host Configuration Protocol (DHCP) was introduced only seven years ago, it has already become one of the IETF's most resounding success stories. DHCP is supported in most networking devices and software—from ISDN routers to firewalls to every mainstream operating system on the market—and networks of all sizes are using DHCP to help manage their infrastructure equipment. Simply put, the technology has reached a point of ubiquity, with a level of vendor support and end-user deployment matched by only a handful of other protocols.
But despite a broad level of support for the protocol, surprisingly few DHCP installations go beyond its most basic features. Most DHCP products and their users treat it as if it were nothing more than an advanced address-assignment protocol, and few users truly leverage the host configuration aspects that define DHCP's true power.
Much of the blame for this can be laid at the feet of vendors, but users who are willing to invest some sweat equity in their installations can get high levels of reward for their efforts. What follows are some techniques to increase your network automation and reap those management rewards.
Read the Book!
Reading The DHCP Handbook: Understanding, Deploying, and Managing Automated Configuration Services (Ralph Droms and Ted Lemon, Macmillan Technical Publishing, 1999) is the greatest favor you can do for yourself if you're serious about exploiting DHCP fully. It takes only a few days to get through the material, and if you can practice on throwaway machines, you'll be a DHCP master in no time.
Although at 500 pages The DHCP Handbook is too large to be a handbook, it is an excellent reference for the mechanics of the DHCP protocol and has many solid working examples.
Use Those Options
Most organizations use DHCP only for minimal stack configuration, limiting the configuration information to an IP address, subnet mask, default router and possibly some DNS or NetBIOS settings. However, the true power of DHCP is found in its broad capabilities as a complete system-configuration protocol. When fully leveraged, DHCP lets you define a variety of system-specific aspects, including directory-services information for LDAP, NDS and NIS (Network Information Services) servers and context, the NTP (Network Time Protocol) servers the system should use, default Web and mail servers, and more.
Making full use of this extended configuration data can be difficult for two related reasons: First, the DHCP client has to be able to accept this data. Second, this data has to be stored somewhere that the supporting applications can access it. Because many DHCP clients are not easily extended to request or accept this data, users look to external configuration mechanisms for this service.
Unfortunately, there isn't much in the way of standardized configuration services either, so you end up using many services together (such as LDAP- or NDS-centric schema in conjunction with SLP multicasts and operating system-specific "user profiles"), or you end up using none of them.
Many of the corporate-focused operating systems actually are entirely capable of requesting and storing extended DHCP options and their data. For example, the DHCP clients that are bundled with Caldera Systems' OpenLinux, Digital Equipment Corp.'s Unix and Sun Microsystems' Solaris operating systems can completely configure a system—including its host name, available routes and application- and directory-specific settings—simply by providing the data via standardized DHCP options.
Microsoft's Windows NT and Windows 2000 are more difficult to coerce, but it's possible to use DHCP options to configure a system if you're willing to do some work. With those two operating systems, the built-in DHCP client uses registry entries from the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCP\Parameters\Options branch to decide which options to request during the initialization procedure and tells the client where to store received option data.
Using an external registry-reading tool, you can parse and stuff this data back into systemwide configuration files via scripts, if needed. For example, this process could be used to tell Windows NT to request the default SMTP mail server (standard option 69) during the DHCP lease-negotiation process, and then have the system login scripts read the resulting data from the registry and put it into a mail client's configuration files. Although this can be difficult, it is definitely a step forward in overall systems management.
Alas, not all operating systems are even this friendly. Versions of Windows from the 9x family are not extensible at all and require either that application developers bind to the DHCP client's UDP (User Datagram Protocol) socket to intercept extended-option data or that the applications perform their own DHCP lease renewals to obtain extended-lease data. This is how Novell's NetWare client gets NDS data from DHCP, for example.
Another option is to consider using a special-purpose DHCP client, such as Network Telesystems' Shadow IPclient, which is specifically designed to provide extended-option management as part of an overall client-management service.
Optimize Lease Duration Times
One of the most common DHCP administration questions is, "What setting should I give my lease times?" As with most things networking, the answer is, "It depends," with the primary decision criteria being the desired frequency at which your clients update their configuration data.
If you're using DHCP only for randomized address assignments, having longer lease times will result in greater levels of stability. For example, if you use lease duration times of one month or longer, then a temporary server outage is not likely to affect your normal operations all that much. However, if you're using DHCP for a variety of system-configuration options (such as default DNS servers and static routes), you will want to have shorter lease times so that changes to the network are recognized quickly by the DHCP clients. In this case, having lease times that are longer than a day or two can be problematic because clients that obtain a new lease just before a critical infrastructure change is made will not recognize this change until the lease expires or gets renewed.
For dynamic environments, there are two common lease-duration strategies. The first calls for leases to be renewed halfway through a working day (such as having them expire every eight hours, which will cause them to be renewed after four hours). Another strategy is to set the lease duration to a multiple of two and a half times the working day (that is, 20 hours for an eight-hour working day), causing the leases to completely expire overnight and thus be renegotiated every morning. The former strategy works well on networks that keep their machines running all of the time, while the latter strategy works well on networks where systems are powered down or otherwise removed from the network at night.
Be forewarned, however, that both strategies expose the network to problems if the DHCP server goes down or is on a remote network that is subject to outages. If the DHCP clients are getting their lease data from a remote DHCP server that's on the other side of a WAN link that's even minimally prone to failure, chances are good that short lease times will result in at least a few failed lease renewals.
Don't Forget Static Leases
Most organizations that use DHCP for dynamic addressing limit its use to PCs and other "dynamic" systems. Only a few organizations use it for managing "static" systems, such as print servers, mail servers and other hosts that need fixed configurations. For those organizations that use DHCP only for dynamic address assignments, this is understandable. But for those organizations looking to leverage DHCP's power as a true host-configuration protocol, this is unfortunate, because having the ability to centrally manage network settings on static hosts is just as powerful as it is with dynamic systems.
For example, as was described above, DHCP can be used to completely configure many Unix-based systems, including their specific host names, their routing tables and so forth. The advantage of using DHCP for managing these kinds of systems is that you can do it from a single console, instead of having to visit each system individually every time you need to update the routing table. Although the degree of management varies, most modern infrastructure devices and operating systems support DHCP—or at least BOOTP (Bootstrap Protocol)—for some level of configuration service in this manner. Note that some systems specifically don't allow this (namely, routers are defined as exempt from DHCP configuration in the RFCs). For the most part, however, you can relieve a significant amount of your network-management burden simply by using DHCP to configure static devices.
If you choose to do this (and I encourage you do), you really should plan on defining static host-specific leases for those systems to ensure that they don't get a random address assignment. You'll probably need to do this anyway if you're setting host-specific options—such as the host name—but you should do so even if it isn't required.
If your DHCP server supports it, you may also want to assign longer lease cycles for these systems to minimize any risks incurred by temporary failure.
Plan Your DHCP Infrastructure
One of the recurring themes in this discussion is server stability. Although you don't have to worry about your DHCP servers crashing several times a day, the uncommon outage can still be extremely damaging if you start relying heavily on DHCP for general configuration data. In particular, if you use a centralized DHCP topology that relies strongly on BOOTP forwarders and WAN links, an untimely network outage can result in a global network outage.
There are a variety of ways in which you can deal with this problem. The most simple solution is to put a DHCP server into each field office so that the local clients are almost always assured of having access to a local server. Unfortunately, managing distributed DHCP servers is not always easy, requiring at worst that you have physical access to the systems or at best that you have the ability to replicate global configuration data down to each server.
Most DHCP servers fall somewhere in the middle. For example, with the DHCP server bundled into Windows NT 4.0, a network manager can use a client-side management utility to connect to each server and define settings explicitly, which allows for distributed servers. The per-server management can get tedious, however.
Conversely, many third-party solutions let configuration files include data from multiple sources (using an $include directive or something similar) or at least allow for the use of rdist (remote distribution) or another replication service to copy global configuration files to multiple servers dynamically.
Another option along the same vein is to use a DHCP server that has its own storage-distribution mechanism. For example, Microsoft encourages users of its Windows 2000 DHCP server to implement operating system-level clustering to achieve distributed fault-tolerance (a bit of overkill for heavily distributed sites, but feasible for highly centralized ones).
Similarly, Novell's DNS and DHCP service uses NDS as a storage engine for lease data, letting you replicate portions of the NDS tree to multiple servers, whether centralized or distributed.
In addition, Process Software Corp.'s IPworks includes support for the IETF's in-progress specification for a DHCP failover mechanism, which lets a backup server assign leases if a primary server becomes unavailable for any reason.
Other vendors are working on this specification, and its support will likely become more widespread as the technology progresses. Of course, this model also requires that the physical servers be distributed; otherwise, the backup systems also could be unreachable if the WAN dies.
There are many more things you can do to enhance your DHCP utilization. Integration with DNS servers is almost commonplace and is highly recommended as a method for ensuring that host names and addresses are synchronized properly, but these five items are the most important first steps to make. By committing to use DHCP for system-configuration services, you can relieve a significant portion of your current system-management requirements simply by using the bundled tools and service.
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 2000 CMP Media, Inc. Used with permission.