Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If you’re planning on upgrading to Windows 2000, Microsoft recommends using TCP/IP as the default protocol and implementing TCP/IP through Dynamic Host Configuration Protocol (DHCP). However, before you install DHCP on your network, you must consider some serious configuration issues. In this article, I’ll discuss some of these issues. As I do, I’ll provide you with information on how best to implement DHCP to avoid performance and security problems on your network.
Some background
If you’ve been using TCP/IP for any time at all, you’re no doubt familiar with DHCP. If not, here’s a brief explanation: DHCP is a TCP/IP service that you can use to set network clients’ TCP/IP configurations automatically as they attach to the network. This configuration is done by providing the DHCP server with one or more scopes. A scope is nothing more than a range of IP addresses that may be assigned to clients on a temporary basis. The length of time that a client is allowed to use an IP address from a DHCP server is called the client’s lease period.
As you can see, DHCP eliminates the need to manually configure each client; it also helps to prevent duplicate IP addresses and can help to conserve IP addresses when they’re in short supply. However, for DHCP to function correctly and efficiently on large networks, proper planning is essential. If it is set up improperly, DHCP can cause headaches. The following sections discuss some of the issues you need to consider before installing DHCP.
As I mentioned earlier, DHCP automatically configures clients for TCP/IP at the time the clients attach to the network. Obviously, this process doesn’t happen by magic. Getting DHCP to configure a client for use on a network requires several messages to be passed back and forth across the network. Although these messages tend to be small, if many clients are attempting to get an IP address at the same time, the excessive traffic created can bog down the network.
One way of dealing with this problem is to limit each DHCP server to servicing only one specific subnet. By doing so, you’ll isolate each subnet’s DHCP-related traffic and prevent it from flowing onto the rest of the network.
Of course, everyone is on a budget these days, and DHCP servers cost money. If you lack the funding to implement all those individual DHCP servers, it’s possible to make a single DHCP server service multiple subnets. However, you must first consider some issues beyond network traffic. The biggest issue involves your routers. DHCP servers function through the use of broadcasts; therefore, before a DHCP server can service multiple subnets, the routers that connect those subnets must be configured as BOOTP and DHCP relay agents.
If your routers don’t support BOOTP and DHCP, you’re not out of luck just yet. If you have at least one Windows 2000 server or Windows NT 4.0 Server in each subnet, you can configure those servers to act as DHCP and BOOTP relay agents. Should you decide to use relay agents, keep in mind that it’s often necessary to increase the default amount of time that relay agents wait before sending relay messages to servers.
As you can see, setting up a DHCP server to service multiple subnets can be a pain to configure. Doing so also has a negative impact on network performance. I recommend always limiting a DHCP server to servicing its own subnet unless absolutely necessary.
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.
