Hello everyone. Let me explain you in this short post the issues I had last week…

After a „successfully“ implementation of the new Cisco switches the customer started having issues while starting the notebook or comming back from a meeting and inserting the notebook back in to the docking station.

The client received an error message telling him there should be an IP-Address conflict with the IP 0.0.0.0. The message only offered an Okay button. If you click on it, the client got a new IP-Address and everything was fine.

Since all users were affected by this issue, a secondary effect emerged. All since all the clients were getting a new IP-Address the DHCP-Pool was empty of available addresses to assign.

So… what is the issue?

Since Windows Vista and later versions Microsoft decided to implement a mechanism in order to detect duplicated IP-Addresses in the network during the DHCP-Process.

During the acquisition of a new IP-Address through the DHCP-Server the client run-through different stages. One of them is DAD (Duplicated address detection).

In order to find out, if some other client already have the address we are ready to use, the client send an ARP-Broadcast asking if someone else already configured this address, putting 0.0.0.0 as a source and the desired IP as the destination. If a replies from the destination arrives, then it means the address is already in use.

IP Device Tracking

IP Device Tracking sends the same request in order to maintain his table up to date. The client sees the packet and assumes that his IP-Address is already in use. Therefore a DHCP Decline will be sent and a new IP-Address will be assgined.

Having a closer look at the DHCP-server we will see several entries with „BAD_ADDRESS“. This address can not be used. Having a network with hundred of users, will cause unintended DoS-Attack since at some point no IP-Addresses will be available for new clients.

A short capture of the problem in Wireshark

On some IOS versions we are able to configure globally a source interface for the requests IPDT sends.

Another way is to increase the period of check IPTD works with.

ip device tracking probe delay 15

The problem seems to be solved.

Thanks everyone and see you hopefully soon.