DHCP conflict logging: the true story
The on-line configuration help for the ip dhcp conflict logging configuration command (logging: Record address conflicts in a log file) is one of the more misleading texts I've found in Cisco IOS (and the CCO documentation is not much better). Here's how it actually works ...
If you have configured ip dhcp ping parameters (highly recommended), the router will ping the IP address it intends to allocate to a client before replying to the DHCP request. If the router receives ICMP Echo Reply message (response to ping), the address is obviously in use. If the DHCP conflict logging is enabled (default), the router will log the conflict with a syslog message (not in a separate log file) and put the address on the list of conflicts. The addresses on that list (displayed with show ip dhcp conflict) are not used in the future (similar to the addresses configured with the ip dhcp excluded-addresses command). To reuse a conflicting address, the network operator has to remove it from the list with the clear ip dhcp conflict address (or * for all addresses) command.
The DHCP conflict logging makes sense if the router uses persistent DHCP bindings (called DHCP database agents in Cisco IOS), otherwise any addresses allocated prior to a router reload would be reported as conflicts after the bindings are lost. If you don't use DHCP agents, it's thus best to turn off conflict logging with the no ip dhcp conflict logging configuration command. Even without conflict logging, there's no DHCP functionality loss and no chance of duplicate address allocation, as the router would still check whether an IP address is active before allocating it (and later on, it would be willing to re-check the conflicting IP address).
If you don't use DHCP database agents and you don't disable conflict logging (default setup), you'll have to clear the conflicts manually after a reload and you might potentially exhaust the DHCP pool because of a large number of blocked conflicting addresses.
Any inside?
There is no timer that could automagically clear the list of bindings (simmilar to errdisable recovery cause ...) ?
Is there a way to obtain more info about the dhcp bindings and clients without having either a single point of failure (the external db server) or worrying about the problems with conflicts you describe above?
TIA,
Steve
I'm glad I found your post as it explains a problem I had to deal with this morning. Unfortunately our department is going to be dealing with this A LOT more in the coming months so I'm hoping you can provide more info.
Our department is going to be installing and supporting WiFi for hotels around the country. One of our installs this morning had a massive failure. The site has ~50 WAPs in a /26 DHCP pool with 62 usable addresses. When the router running the DHCP server reloaded it saw those 50 WAPs using the IPs they'd been assigned and marked those IPs as conflcts. That meant when it came time for the WAPs to release/renew their leases there were only ~10 IPs available in the pool. We got a call from the site saying the whole site was down.
What I don't understand is if this is how DHCP works, how does DHCP work at all? I've never heard of this happening before anywhere I've worked and I can't believe it's because DHCP servers have never reloaded. There has to be some workaround or something... can you please provide some info on this part of it?
Thanks!
~Steve
ip dhcp conflict resolution interval 1440
Thank you!
Hi Thanks for the clarification. I have one doubt.
Client uses GARP & DAD to detect those conflicts. Client side detection is assumed better i think as it reduces load on dhcp server. Will disabling the dhcp conflict on dhcp server be useful if conflict is detected by a client ?
If you can safely assume that all clients do DAD detection, that DAD detection works well enough for your needs (false negatives can be fun to troubleshoot), and that you don't care about the longer setup time repeated DAD might cause, you're absolutely right.
Unfortunately, I don't have enough insight into what large-scale production environments are doing these days.