Duplicate IP Address 0.0.0.0 on virtual (VMWare) servers attached to Nexus switches

[michael.hinz]

Hello,

We see more frequently that virtual servers with static IP addresses report duplicate IP addresses during their reboots.  In other words the server wants to use its own IP address but somehow first checks if he can use the IP and gets a response from the switch/network that the IP is already in use and therefore pops-up a dialog in the Windows (2008) GUI saying the IP is already in use.  The result is the server will not work until the NIC gets disabled/enabled while the server is running.  Then the IP does not get identified as a duplicate IP and the system works as expected.

VMWare has identified this to be an issue specific with Cisco switches and provided various tips on fixing this:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028373

Cisco has also a KB article out there about this:

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

The problem that we have with the proposed solutions is that they only apply to IOS based switches.  Nexus (NIOS) based switches don't support the proposed commands.

Has anybody experienced the same problems with VMWare systems on Nexus switches?  How did you fix this?

Thank you,

Mike

[j.rambeau]

Hi,

I am currently facing the same issue on Windows virtual machines hosted on HyperV and VMware hosts and connected to Nexus switches.

Can't find any information related to this issue on NXOS...

@Mike, did you have any luck solving this issue ?

John

[michael.hinz]

Hi John,

We don't have an official solution for this problem.  Cisco still does not support the command on the NXOS:

ip device tracking probe delay 10

We have upgraded our Nexus 5548's to a more recent software release 5.2(1)N1(7) which seems to have improved the situation but still did not completely solve it.

We then went around and implemented the above stated command on all our 3750 and 3850 switches even though the servers are not directly connected to them.  After putting the probe delay on all switches in our LAN environment we have seen a big improvement to our problem.  We are now running into this problem only in rare cases.

Hope this helps you too.

Mike

[j.rambeau]

Thank you Mike. I will look into devices such as 3750 that might cause the issue on impacted VLANs.

I will keep the post updated, if I get something interesting.

John