10-05-2010 11:20 AM - edited 03-06-2019 01:20 PM
Hello all,
I am experience the following issue: In an environment with Cisco and other vendor swithces (HP Procurve), we receive an IP conflict on the servers.
I inspect the logs from 6500s and I found out this message:
%IP-4-DUPADDR: Duplicate address x.x.x.x on Vlan1, sourced by 0000.0000.0000
I cannot figure out what is this mac with all 0's.
Could you guide me in some direction how to find out from where it appears this MAC or better what is the issue source and how to fix it.
If somebody experienced the same issue it will be great to help
UPDATE:
What I discover about the issue is that every node with IP address when receive this frame with all 0's MAC notify the IP conflict with its own IP address.
I left a sniffer in the network and I hope that it will gather something.
Thank you very much in advance!
Stenly
10-05-2010 11:34 AM
Hello Stanley,
a possible source could be a VMware machine that is not totally configured we saw these kind of messages from time to time
Hope to help
Giuseppe
10-05-2010 11:43 AM
Dear guislar,
Any idea how to find out which is the VM?
10-05-2010 11:50 AM
Dear Stenley,
I tried in the past to follow up this kind of MAC addresses but as it happens for error messages related to illegal multicast MAC addresses seen in source address position the risk is that the entry for this all 0000.0000.0000 never appears in the regular CAM table.
you can try to use the following commands as soon as you see the message
show mac address-table address 0000.0000.0000
or
show mac-address-table address 0000.0000.0000
(IOS release dependent)
but again the risk is to see nothing (the entry may be automatically filtered out of CAM table)
it shouldn't cause any real issue.
We usually have a talk with someone of the server group advising about it.
Hope to help
Giuseppe
10-05-2010 01:17 PM
Giuseppe, Stenly,
I am thinking of using the arping Linux utility - perhaps performing an explicit ARP query on the duplicate IP address and closely observing both the ARP reply contents and the frame Dest/Src MAC address in which the reply is encapsulated could help to isolate the real MAC address.
Best regards,
Peter
10-06-2010 07:21 AM
Thank you all for the relpies. I updated the case.
10-07-2010 10:47 PM
It appears, that the problem is with an unknown-vendor switch, that gives its MAC address or MAC with all 0's when there is an request to non-existing IP address (old NTP).
Thank you all again for the recommends!
Stanley
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide