↓Skip to main content
  1. Posts/

DHCP and conflict logging

·4 mins
Tips DHCP

DHCP is something that is kind of overlooked sometimes and is treat as a given.

There was a recent DHCP issue at a customer site and I wanted to clarify my thoughts on what happened behind the scenes but I can’t say I have ever actually checked and proved that the conflict process works in the way I expected.

When a fresh DHCP client first goes live on the network it carries out a pretty standard ‘handshake’ of:

  • DHCPDISCOVER – This is broadcasted on the local LAN with a request for an address, as it doesn’t know anything about the network it is simply asking anyone who is listening for an address
  • DHCPOFFER – This is a message from a listening DHCP server with and address that can be used by the new client
  • DHCPREQUEST – This is a reply to the offer where the client takes the address that has been offered and formally requests it
  • DHCPACK – The DHCP server acknowledges the request, the client now has an address and related parameters to operate on the network

That is the CCNA view of what happens but behind the scenes there are a couple of things that are done in between the DISCOVER and the OFFER packets.

The DHCP server keeps an index of the addresses it has used and the next address that will be ditched out during a transaction.

When a new DISCOVER comes into the DHCP server it looks at its index and before it offers the address out it first ARP’s for and if successful tries to ping the address, why does it do this though?

If you were to have a device for example that had a static IP configured on it at 192.168.1.23 and .23 happened to be the next address that the server was going to allocate then without these checks it could end up giving out an address that is in use and cause an issue on the network, it ARP’s and then pings the address to make sure nobody is using it.

When a Cisco DHCP server discovers a conflict like this as default it will place it into a conflict table stating the address that was conflicting and how it came to that conclusion, this table is then used by the DHCP process to know which addresses to not even attempt to use as it has already been deemed that they are in use.

R1#sh ip dhcp conflict
IP address        Detection method   Detection time          VRF
10.10.123.2       Ping               Mar 01 2002 12:01 AM

This conflict logging can cause issues where sometimes due to a device reload it loses its DHCP bindings table, once this happens when the devices try to refresh their binding the DHCP will think there is a conflict (due to the existing machine answering the ICMP echo) and the conflict table can end up filling up pretty quickly.

If you want the conflict logging can be disabled with no ip dhcp conflict logging

It is handy to also know that even though you disable the LOGGING of the conflicts it will still go through the process of trying to find if the address is in use before offering it out.

If for whatever reason the client doesn’t respond to the ping from the DHCP server it will hand out the address (that has a conflict) as it can’t see any issues, when it does this the fist thing once the assignment is complete is the new host sends out a gratuitous ARP message with its new IP address, if it received no reply then all is good, if however it receives a reply then it indicates that there is another device on the network that is using that address.

If this happens then the client sends a DECLINE message back to the server and because the server also received the double gratuitous ARP from the previous section it puts the address in its conflict table (or not if its been disabled) and moves onto the next available address.

↑