Networking

Get IT Done: Additional ways to identify and prevent DHCP failures

Learn additional ways to prevent DHCP from failing


Your DHCP server can be the lifeblood of your network. A failure at this level can cause office-wide downtime, which puts even more pressure on you to quickly correct the situation. But there are many ways that DHCP services can fail, so it's often difficult to pinpoint the problem and fix it fast. I've compiled a few more tips on the causes of DHCP failures and how to correct them to help you repair failures now and prevent problems down the road.

More about DHCP failures
In the Daily Drill Down “Troubleshooting Windows 2000 DHCP servers,” I explained many different types of DHCP failures and gave tips on troubleshooting them. Here, I will add to that list with even more types of failures and how to correct them on your servers.

Running out of IP addresses
Perhaps one of the most common causes of DHCP server failure isn’t really a failure at all. All sorts of problems can result when a DHCP server runs out of addresses to lease. Without additional addresses to lease, users who boot up their workstations won’t be able to access the network. Users who have already connected to the network may lose connectivity—along with important work—if their lease expires and they can’t renew it. However, there are several things you can do to ensure that plenty of leases will be available.

Depending on your individual DHCP implementation, you can decrease the lease time to force the systems to request a new lease more frequently. I should mention, though, that decreasing the duration of a DHCP lease increases the workload on the DHCP server since clients have to renew IP address leases more frequently. Therefore, if your server is already overworked, then decreasing the lease time probably isn’t the best solution to your problems.

When you decrease the lease time, systems that have been turned off won’t hold a lease for as long of a time, which frees up the address for another system to use. The same theory holds true for dial-up clients. In some situations, a DHCP server can continue to view an IP address as being in use even after a dial-up client has disconnected. Some systems release IP address leases as soon as a system disconnects or goes offline, while others hold the address until the lease expires.

Another solution to the problem of running out of IP addresses is to create some bogus addresses for your clients to use. I'm sure you've been warned of the dangers of simply making up IP addresses; however, in some situations, making up IP addresses is a very viable option. Remember, the only time a system’s IP address really matters is when a DNS server maps the address to a specific application, such as a Web server or an e-mail server, or when the address is designed to identify a specific computer. However, the simple fact that you’re using DHCP in the first place means that the majority of your machines are probably address independent. This means that the PC will be functional regardless of what IP address it uses, so long as the IP address is valid and uses a similar subnet structure to ones used by the other machines.

The real problem with making up IP addresses is that when you do, there’s a good chance the address you’ve created is already owned by someone else and is used on a Web server somewhere else in the world. Therefore, the trick is to make sure that the legitimate owner of the address that you’ve chosen, or rather the range of addresses that you’ve chosen, is never put in a position where your use of the address interferes with his or her use of the same address. The trick to doing this is to make the addresses invisible to the outside world.

Your IP addresses may already be invisible outside the firewall because most firewalls and proxy servers use a single, legitimate IP address to communicate with the outside world. Any time a PC on your network needs to communicate with the outside world, the request is passed to the gateway server, or the server that’s acting as a firewall or a proxy server. The gateway server then receives the request and uses its own IP address to forward the request to the outside world. When the requested information is retrieved, it arrives at the gateway PC, which passes the information to the client who originally requested it. What makes this operation great is that all communications with the outside world appear to be coming from one single legitimate IP address. Therefore, any illegitimate IP addresses you might use are never exposed to the outside world.

The real problem could occur when one of your clients needs to access a Web site whose IP address happens to be the same as one of the internal addresses you’re using. In such a situation, the client would usually connect to the machine that exists on the local network rather than to the Web server on the Internet. In reality, the chances of duplicating addresses with Web sites anyone in your office would ever actually visit are slim to none.

If you’re still worried about the possibility of this happening, you can always research to see who owns the address. For example, the address range I’ve chosen for my personal network corresponds to an address range used by the military. Since there’s very little chance that I’d ever need to access military systems, this address range seemed like, and so far has been, a safe choice.

Of course, if you want to make sure you don’t have your server room taken over by a bunch of Marines, you can also use one of the sets of private, reserved IP addresses. These addresses, shown in Table A, are reserved for private use only and don’t exist on the Internet. You can safely use them on your network without having to encounter any conflicts at all.

Table A
Address Block Netmask Class
10.x.x.x 255.255.255.0 A
176.16.0.0/12 –176.31.255.255 255.255.0.0 B
192.168.0.0 – 192.168.255.0 255.255.255.0 C
You can use these private IP addresses.

You can also use address reservations to combat the problem of running out of addresses. Address reservations is a technique by which your DHCP servers reserve a specific address for a specific PC. For example, most of the time, you would use a static IP address on your servers. You can either hard code the desired IP address into your servers or implement a DHCP reservation for those servers. This technique doesn’t work for all servers, as some servers require a hard-coded IP address. However, the reservation technique isn’t just for servers. If your clients must have network access at all times, you can reserve addresses for them. By reserving an address, the clients are guaranteed IP addresses at any time.

Overlapping IP addresses
When you have multiple DHCP servers, if you don’t carefully sequence the TCP/IP numbers they can offer, you can sometimes run into accidental address duplication—that is, duplication by another DHCP server. DHCP servers each contain scopes of addresses that they can assign to clients. All of the combined scopes make up a super scope.

This organizational layout protects your network from address duplication. However, some types of DHCP servers don’t check the network for the existence of other DHCP servers, let alone check the address range with which the other servers are working. Therefore, if you find IP addresses are being duplicated, check your DHCP servers to make sure each server contains a unique scope.

Mismatched addresses
Much more common in larger organizations, mismatched IP addresses can also cause DHCP failures. An IP address is composed of a network number followed by a computer number. A subnet mask differentiates between the two numbers. For example, a subnet mask of 255.255.0.0 tells Windows that the first two numbers compose the network number, while the last two numbers are the computer number.

The problem occurs when IP addresses with different subnet masks are used on the same network segment. For example, suppose that you had one DHCP server assigning IP addresses that fell into the 255.255.0.0 format, while another DHCP server was assigning addresses in the 255.255.255.0 format. According to books I’ve read, the client PCs should still be able to communicate with each other. However, my own personal experience has shown me that unless the two address formats exist on two different segments, the PCs in question will have trouble communicating.

In the few times that I’ve seen such an arrangement, the machines with the 255.255.0.0 address format were able to communicate with other PCs using the 255.255.0.0 format but not with the machines using the 255.255.255.0 format. The reverse was also true. The machines with the 255.255.255.0 address format were able to communicate with other machines using the 255.255.255.0 format but not with the machines using the 255.255.0.0 address format.

To avoid possible communications problems between machines with such mismatched addresses, make sure all your DHCP scopes conform to a common subnet mask format.

Rogue DHCP servers
Prior to the release of Windows 2000, it was actually possible for a hacker to place his or her own DHCP server onto a network and cause some serious chaos. An unauthorized DHCP server can duplicate IP addresses or assign clients invalid addresses with information that won't connect them to the Internet or other network resources.

Fortunately, Windows 2000 protects against this. When you install DHCP services on a Windows 2000 server, Windows requires you to specifically authorize the new DHCP server to service the network.

Service failure
When using Windows NT or Windows 2000 as the operating system on your DHCP servers and a DHCP failure occurs, it’s important to remember that DHCP is service based. One of the first things you should check in such a situation is whether or not the DHCP service is still running. In some situations, correcting the problem may be as simple as restarting the service.

Conclusion
Your DHCP servers are a very important part of your network, and having a problem at the DHCP level can cause considerable user downtime. Once you know some of the major causes of DHCP failures, you’ll have an easier time recovering from the failure or preventing another such failure later.

Editor's Picks