WTF issue of the day: duplicate address for 0.0.0.0 - BAD WINDOWS BAD

[wintermute000]

http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html


http://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html#anc10


All you 802.1x, MACsec/Trustsec lovin' security types better notepad this... stat!


Broken since Vista... ROFL

[EOS]

We ran into that last year after we deployed some new Cisco Chassis' around the office.

This is the only config change we made to correct the issue -

Code Select Expand

ip device tracking probe delay 10

[deanwebb]

That, and using the Cisco supplicant, will go a long way towards fixing up those woes.

[wintermute000]

Is ip tracking only turned on with those security features or is it on by default in some newer platforms?



That is messed up behaviour though. I know strictly speaking its RFC compliant (yeah I even read some of it LOL), but c'mon, if a windows host's own NIC is currently 0.0.0.0 as its still being initialised then surely it should be smart enough to disregard the SOURCE IP address of an incoming arp probe. Its mind boggling (and  something that linux/OSX has no issues with).
Whats even more mind boggling is that a source 0.0.0.0 of the arp probe is also RFC compliant (in order to prevent ARP cache corruption if there is indeed a dupe). So basically this scenario should have been foreseen and the RFC fixed (something as simple as 'except if your current address is 0.0.0.0 because you've just fsckin rebooted').


I'll make a mental note to add that 10 second delay onto any new deployments I do, just to avoid any issues down the track if a fancy new feature is activated (flexible netflow requires this too?!?!? why the eff).