Troubleshooting DHCP Issues
- Brad Wegner Sr
- Feb 25, 2022
- 2 min read
Let's work through a few DHCP Issues I've witnessed over the years. All of these issues I have encountered in my work in WiFi or Unified Communications.
DHCP Address Exhaustion- This is pretty common, especially with Guest Networks. Do you have enough address space to cover the total amount of users at a given time? Do you know what the dwell time is for the clients on your network? Are you using default expiration periods? If clients are only going to be on the network for 1 hour, (or perhaps even 8-10 hours) before moving on, why use the default lease time of 7 days?
DHCP Broadcast Issues- DHCP clients send their (Discover) requests to FF:FF:FF:FF:FF:FF/255.255.255.255 marked with a unique transaction ID (xid) as described in the standard. If this needs to cross an L3 boundary, you'll need to configure a BOOTP relay agent. (In Cisco shops we typically call this an "ip-helper" as that's the command you'd use on the L3 interface). This BOOTP relay agent takes the information in the Broadcast packet and creates a new unicast packet and send it to the DHCP server(s) configured using the information configured on the L3 interface.
Sometimes you may need to verify with another team that they have not "moved" DHCP services to new infrastructure without notice, this change could take a few days to notice due to the fact that clients can continue using DHCP long after the servers are unavailable depending on the particular implementation.
DHCP Configuration Issues- APs, Phones, and other devices can implement a neat trick where they will pull down their boot image from a TFTP Server specified in a specially crafted DHCP Inform message. This allows you to specify for a particular VLAN such as a Voice VLAN which CUCM Server my IP Phone should connect to, or which WLC my AP should connect to. If you are employing these options in your DHCP environment ( I recommend you do) then you should be mindful of whom you'll need to communicate with when upgrading to a new Cluster, or when you're provisioning a new Controller.
*The IANA has a great list of information here citing the IETF standards
DHCP HA Issues- In my experience I have run across some issues where a pair of DHCP Servers setup so as to support each-other in a highly-available manner fail to successfully offer responses to clients. The database that resides on the two devices do not synchronize and the result is that both show client entries (stale entries in my experience) and can no longer replicate. In the M$ world I have seen this corrected by reboots, re-syncing time between devices, forcing replication, and rebuilding scopes.
In the top of the article is a hyperlink to the IETF Standard. If you haven't started reading the actual standards, I recommend you do. They are a great way to dig deeper.
If you have any more to add to the list, please comment and help build the information base!

Comments