DHCP – BAD_ADDRESS entries caused by IP Device Tracking

Microsoft Windows has a feature that detects IP conflicts.  A Cisco switch can effectively turn that feature into a DoS attack on your DHCP server.  That’s pretty neat.

A subnet full of BAD_ADDRESS entries??  Way past cool!!  Notice that the “Unique ID” is just a reverse hex of the IP.

Wireshark shows us the action:

Here we can see see the Cisco ARP message (packet 15) that triggers the  Windows client to throw out a DHCP Decline message.  This is the IP device tracking feature trying to populate its table.  When the Windows client sees the Cisco device’s ARP message, it assumes another device is trying to utilize that IP.

The fix?

Delay the probe by a number of seconds.  This may need to be more, depending on how long your clients take handle their duplicate IP detection process.  Many factors can affect this process, including authentication or authorization (dot1x) settings.

delay the probe:

 Older device syntax:
ip device tracking probe delay 15
 SISF-based device tracking syntax:
device-tracking policy reachable-lifetime 15

additionally modify the source IP:

Older device syntax:
ip device tracking probe use-svi
newer device syntax:
ip device tracking probe auto-source fallback 0.0.0.250 255.255.254.0 override
even newer device syntax:
device-tracking tracking auto-source fallback 0.0.0.250 255.255.254.0 override

Wireshark now shows us the completed DHCP process with no issues:

You can see the Cisco device now waits longer to send its ARP message (packet 15).  I set the delay at only 2 seconds for this demonstration.

Leave a Reply

Your email address will not be published. Required fields are marked *