Planning for DHCP implementation - Page 2

 By Brien M. Posey
Page 2 of 2   |  Back to Page 1
Print Article


EUC with HCI: Why It Matters

Provide fault tolerance

"The best way to prevent problems caused by a failed DHCP server is to have at least two DHCP servers per subnet. "

One of the most important issues to consider when implementing DHCP is fault tolerance. Imagine for a moment that you have only one DHCP server on each subnet. If a DHCP server fails in such an environment, the entire subnet will cease to be able to access the network.

Fortunately, you can take steps to prevent such a catastrophe. First, I recommend using static IP addresses on servers. Some types of servers--such as DHCP servers, DNS servers, and primary domain controllers--require static IP addresses. However, it isn't a bad idea to use static IP addresses on member servers, as well. By doing so, you'll prevent a DNS failure from making the server unavailable to clients that may still be functioning. Plus, should the server ever have problems, static IP addresses sometimes make the troubleshooting process easier.

The best way to prevent problems caused by a failed DHCP server is to have at least two DHCP servers per subnet. That way, if one DHCP server fails, the other DHCP server can continue providing IP addresses to clients and renewing leases. A second advantage to multiple DHCP servers is that the second DHCP server will take some of the workload off the first DHCP server, thus making it function more efficiently.

Use a superscope environment

If you decide to use multiple DHCP servers on each subnet, you should implement a superscope environment to avoid problems with unwanted negative acknowledgement (NACK) messages at lease renewal time.

Unwanted NACK messages might occur when a client attaches to the network and broadcasts a request for a DHCP lease. There's no way to control which DHCP server will respond to the request first. When a DHCP server responds, a lease is granted for a limited period of time. Now, suppose that 50 percent of the lease time has expired, and it's time for the DHCP client to request a new lease. If the lease request goes to a DHCP server other than the one that originally granted the lease, the server will send the client a NACK message--thus denying renewal of the lease--because it doesn't recognize the client's IP address as part of its scope.

You get around this problem by creating a superscope. A superscope is a configuration in which each DHCP server knows about the scopes of all other DHCP servers within the subnet. Unfortunately, you can't simply add a scope onto each DHCP server without causing some serious problems--but you can add another server's scope to a DHCP server's exclude range. Anything in the exclude range will be ignored. In the situation I discussed earlier, if a server receives a lease renewal request other than the one that issued the lease, the server will see that the IP address falls within the exclude range. The server will ignore the request, thus giving other servers a chance to service it.

Be careful about using conflict detection

One major drawback to TCP/IP is that duplicate IP addresses can cause problems on your network. To get around this issue, Windows 2000 clients perform a test when a DHCP server offers them an IP address. This test pings the address to ensure it isn't already in use on the network. If the address is found to be in use, the Windows 2000 client will decline the address it has been offered.

Unfortunately, other types of clients (such as Windows 95) don't perform this test. If you have such clients, but you still want to safeguard your network, you can configure the DHCP server to perform the test for you. However, if you decide to implement server-side conflict detection, you should consider that DHCP has no way of knowing what operating system a client is running--conflict detection will be performed on every client that requests an address. This process can dramatically slow your DHCP server. Therefore, it's important to look at each subnet as a whole and determine whether server-side conflict detection will do more harm than good.

Use reservations for consistent IP addresses

Earlier, I mentioned that it's necessary to use static IP addresses on some servers, but that I recommend using a static IP address on all servers. If you want to use static IP addresses on all your servers, but you like the idea of using DHCP for consistency, you can use a reservation system to ensure that a server receives the same IP address each time it connects.

If you decide to use a client reservation, keep a couple of things in mind: First, as I mentioned, some types of servers absolutely require a static IP address--a reserved address won't work for such servers; second, be sure to include the reserved address in the exclude list of every DHCP server that could potentially service the server, except for the server where the address and reservation actually reside.

Make sure your hardware can handle DHCP

DHCP tends to be very disk-intensive. If you have a member server that's already running close to capacity, don't even think about making it into a DHCP server. Before you make any server a DHCP server, I recommend using System Monitor to ensure that the server's processor utilization, memory usage, and disk and network throughput are running at acceptable ranges. You should also make sure the server has plenty of free hard disk space. I recommend using a RAID array, because it generally performs better than a single hard disk and because it's easy to add disk space to a RAID array should your server start running low.

If a server looks like a good candidate for a DHCP server, try implementing DHCP--but have the server service a limited scope. In Windows 2000, a few new System Monitor counters directly measure DHCP's impact on the system. If it looks as though the server will continue to function well after adding DHCP, you can then begin to use a full-scale DHCP implementation.

Configure lease durations based on clients' needs

It's no secret that network clients tend to be diverse. A typical network might have normal desktop PC users, users who occasionally plug a laptop into the network, and dial-in users who access the network from remote locations. Each type of user has different needs when it comes to DHCP leases.

For example, desktop users typically work from the same physical location every day. Therefore, if you aren't running short on IP addresses, you might consider increasing the lease duration for such users. The default lease period is eight days, but you could increase it to three weeks if you wanted to. The advantage of doing so is that less DHCP-related traffic will flow across your network. Lease renewals generate traffic because a client has to request a renewal from the server, the server must respond, and then the client must tell the server whether it has decided to accept the lease. By reducing the number of times that clients must go through a lease renewal process, you can increase the efficiency of your network and decrease the load placed on your DHCP server.

On the other hand, one reason for using DHCP is that only a computer holding a lease consumes an IP address. Therefore, if IP addresses are in short supply, DHCP can help make the addresses you have go further. If you're running out of IP addresses and want to make more addresses available at any given time, one way of doing so is to shorten the lease period. This is an especially effective technique if you shorten the lease period for dial-in users who typically need a lease for no more than a couple of hours at a time. //

Brien M. Posey is an MCSE who works as a freelance writer and as the Director of Information Systems for a national chain of health care facilities. His past experience includes working as a network engineer for the Department of Defense. You can contact him via e-mail at Brien_Posey@xpressions.com. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.

This article was originally published on Apr 28, 2000
Get the Latest Scoop with Networking Update Newsletter