Troubleshooting a DHCP Server

A look at the various reasons why a DHCP server might fail to lease IP addresses and the solutions to those problems.

If you use DHCP servers to automatically configure the TCP/IP settings for workstations in your organization, a DHCP failure can lead to a major disruption in service. After all, if a workstation is not able to acquire an IP address, then it will have no way of accessing any of the resources on your private network or on the Internet. In this article, I will discuss some techniques that you can use to troubleshoot DHCP server failures.

Inappropriate Address Assignment

One very common DHCP related issue is the assignment of an unexpected IP address. For example, suppose that your DHCP server was configured with an IP address scope of 192.168.0.1 to 192.1680.50. You would expect network hosts to be assigned IP addresses in this range. Now, suppose that a workstation on your network appeared to be having problems communicating with network servers. You issue an IPCONFIG /ALL command to view the workstation’s IP address configuration. Instead of the expected address range, the workstation has been assigned an address beginning with 169.254.

So what happened? If a host on your network is unexpectedly assigned an address beginning with 169.254, you can rest assured that the address was not assigned by your DHCP server. What actually has happened, is that the workstation has failed to contact a DHCP server. When this occurs, the workstation will assign itself an IP address using a Windows feature known as Automatic Private IP Addressing (APIPA).

Microsoft built Automatic Private IP Addressing into Windows as a way of helping those who have very small networks. For example, if you were to create a small Windows network, you would not have to manually configure IP addresses even if there were no DHCP server on the network. APIPA would automatically assign a unique class B IP address to each machine on the network. This is great for small home networks but completely inappropriate for larger networks.

If a workstation resorts to using an APIPA assigned address, it is because its requests for an IP address have gone unanswered. There are several possible causes for this problem. Assuming that the other computers on the network are able to acquire an IP address from your DHCP server, you can rule out the DHCP server as the cause of the problem.

More than likely, the issue is related to the networking hardware installed in the workstation that is having the problem. For example, the Network Interface Card might be assigned an incorrect driver. Another possible cause of the problem is that the patch cable is not plugged into the Network Interface Card, or is not connected to a switch on the other end.

Of course, just because only one computer on the network is having trouble obtaining an IP address doesn’t completely rule out the server as the cause of the problem. If other workstations are successfully obtaining IP addresses, then you can be sure that the server is working properly. However, it could be that the server has run out of IP addresses that it can assign to clients. You can easily tell if this is the problem by comparing the size of the DHCP address scope to the number of devices on your network that request IP addresses from the DHCP server.

Common DHCP Server Problems

If multiple workstations are experiencing problems with leasing IP addresses, then the problem is most likely related to the DHCP server itself. If you suspect that the DHCP server is the cause of the problem, then you might start off by doing some ping tests to verify that the DHCP server is able to communicate across the network.

If the DHCP server is able to communicate with other computers on the network, then I recommend verifying that the DHCP server has an IP address that is compatible with the scope that the server is configured to assign addresses from. For example, if the DHCP server’s scope consists of addresses from 192.168.0.1 to 192.168.0.50, then the server will not actually be able to assign those addresses unless the server itself has been assigned a static address in the same subnet range, such as 192.168.0.0 or 192.168.0.51.

 If this still doesn’t solve the problem, then I recommend checking the basics. For example, you should make sure that the DHCP server is still authorized by the Active Directory to lease IP addresses. You should also check to verify that the scope is active, and that the necessary services are running on the DHCP server.

IP Address Conflicts

Another problem that I have seen on occasions involves IP address conflicts among dynamically configured addresses. When you create a DHCP scope, it is the DHCP server’s responsibility to make sure that addresses within the scope are only leased to one client at a time. If that’s the case, then how is it possible to have an IP address conflict for dynamically assigned addresses?

There are two situations that I’ve run into that can cause this problem. The first time that I ever ran into this problem, I was able to determine which PCs had been assigned at the duplicate addresses. When I checked the TCP/IP configuration on those machines, I found that one of the machine’s IP addresses had been manually configured. It’s kind of a long story, but that machine’s user was running an unauthorized application that required a static IP address. The user got tired of having to reconfigure the application every time they used it, so they took the address that had been dynamically assigned to them, and entered it as a static address.

The likelihood of this happening today is fairly slim. When a particular situation occurred, Windows 98 was the current operating system. Windows 98 lacks many of the security features that we take for granted today. A properly secured workstation running Windows XP or Windows Vista should be resistant to end user reconfigurations. Even so, I wanted to at least mention this issue because it gives you something to look for if you have trouble solving the problem.

A much more common cause of this problem is that multiple DHCP servers are in use, and those DHCP servers have overlapping scopes. If you only have a single DHCP server on your network, do not make the mistake of immediately dismissing this idea as a possible cause of your problem. In all likelihood, there is probably a rogue DHCP server that is conflicting with your primary DHCP server.

Windows 2000 Server and Windows Server 2003 are both designed in such a way to prevent rogue DHCP servers from causing problems. A DHCP server can only issue IP addresses after it has been authorized by the Active Directory. The problem is that this only applies to Windows-based DHCP servers. DHCP servers running other operating systems are free to lease IP addresses to clients without having to be authorized by the Active Directory.

So has a user really gone through the trouble of installing a rogue, Linux based DHCP server? Probably not. A much more likely explanation is that a wireless access point, or a router intended for cable or DSL Internet connections is causing your problem. Such devices almost always have DHCP server’s built in. These devices typically use a scope range of 192.168.0.x or 192.168.1.x. If this happens to be the same IP address scope that your primary DHCP server uses, then you may run into a situation in which both DHCP servers are issuing addresses from the same address pool.

Conclusion

In this article, I’ve explained that there are a number of potential causes for DHCP failures. In most cases, these failures are related to simple communications problems between the DHCP server and the workstations that are trying to lease addresses.