IPv4 address duplication, sourced by MAC 0000.0000.0000

[stanibarb]

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

[Giuseppe Larosa]

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

[stanibarb]

Dear guislar,

Any idea how to find out which is the VM?

[Giuseppe Larosa]

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

[Peter Paluch]

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

[stanibarb]

Thank you all for the relpies. I updated the case.

[stanibarb]

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