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.

13 comments:

  1. Good explanation. How does the gratuitious arp work then in the "show ip dhcp conflict"?

    Any inside?

    ReplyDelete
  2. Just ran into this issue, i imagined how it worked. Great explanation, will disable the conflicts logging, even if is interesting to know that there was a problem.

    There is no timer that could automagically clear the list of bindings (simmilar to errdisable recovery cause ...) ?

    ReplyDelete
  3. Ivan, I've reading your blog for years, this is my first question. I manage a largish network with 100 sites and about 4000 Cisco devices. For the last 10 years we used a single, centralized ISC DHCP server. Recently for various reasons too involved to explain here, it has become retarded. IN desperation I have enabled dhcp on all our 100 or so 6500s. We are not logging dchp conflicts, and so far all seems OK. However, I miss the extensive logging we used to obtain with ISC. I was thinking of enabling a DHCP db agent and turning on conflict logging, but your blog post above gives me pause. I've been googling madly and can't find much info on the use of an external dhcp db server, or how to configure it.

    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

    ReplyDelete
  4. :-P :-P :-P :-P

    ReplyDelete
  5. This saved me today, thanks!

    ReplyDelete
  6. Hi Ivan,

    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

    ReplyDelete
    Replies
    1. Conflict logging works well only if you use persistent bindings (dhcp database) to preserve DHCP server state across reloads, otherwise turn it off.

      Delete
    2. I think his answer is this....apparently when the WAPs were already active with an IP and the dhcp server was rebooted, the current WAPS IPs were placed into the exclusive list (address conflict) as the DHCP server attempted to distribute and address to a WAP requesting an IP. Once in that list I beleive the dhcp server will not give out that address even to the device that may be requesting to renew it's address with its same address. Hence the dhcp pool is reduced to the point that there are not even addresses to allocate. I think the DHCP server should recognize that a device requesting to renew its ip address should be regiven that same address along with deleting the address from the excluded list. I do not remember the dhcp packet commands in detail but I thought a renewing dhcp client shared the current IP address assigned to it with the server. Too lazy to look it all up..sorry

      Delete
  7. well, nothing prevents you from adding conflict resolution interval to tell dhcp server check and clear conflicts once a day and not try to do this every time bumps into conflict over and over again:

    ip dhcp conflict resolution interval 1440

    ReplyDelete
    Replies
    1. Great feature, but it seems to be available only in 12.2SRE. Let's hope it will eventually appear in mainstream IOS releases.

      Thank you!

      Delete
  8. Easy peesy - thanks Ivan!

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.