VMware Cloud Community
Vandalay
Enthusiast
Enthusiast

Invalid Source MAC address 00:00:00:00:00:00

My network shop has informed me that on several occasions the switch port connected to two of my 7 ESX 3 servers has reported Invalid Source MAC address 00:00:00:00:00:00. It appears to not be constant and comes and goes.

Exact message from CISCO:

2140: Aug 17 02:08:23: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: Packet received with invalid source MAC address (00:00:00:00:00:00) on port Fa6/22 in vlan 8

Servers seem to be fine, I don't see any problems. I can't say for sure but it may occur during a clone or VMotion.

Anyone seen this before?

Reply
0 Kudos
23 Replies
mprigge
Enthusiast
Enthusiast

This may not be apropos at all, but I remember seeing this problem a year or two ago with some HP servers I was working on. Had nothing to do with ESX whatsoever (but was a Linux issue - if the COS is the problem, that might mean something). It was a result of using the TG3 (tigon) driver on the NCxxxx HP gig NICs that were in the box. I can't remember whether it was old ROM or a newer driver that corrected the problem, but that may be something to consider. We noticed when the machines couldn't get to the internet (firewall dropped the traffic as invalid). Otherwise they worked fine. Sometimes a reboot would correct the problem - it's been a while though.

Like I said - I doubt that's your problem, but I thought I'd throw it out there.

Reply
0 Kudos
thickclouds
Enthusiast
Enthusiast

Anyone find out more on this?

Charlie Gautreaux vExpert http://www.thickclouds.com
Reply
0 Kudos
Vandalay
Enthusiast
Enthusiast

cpfcg, are you having the same issue?

I haven't gotten any resolution on it. One of these days I'll open a ticket.

Reply
0 Kudos
thickclouds
Enthusiast
Enthusiast

Our issue was VST. Not sure if it matters but VST over COS and IOS seemed to be the bad combo. Can anyone else confirm this?

Charlie Gautreaux vExpert http://www.thickclouds.com
Reply
0 Kudos
lefravi
Contributor
Contributor

When I had this issue, the time of the alert was exactly the same as the time I changed a virtual machine connection from an "internal only virtual switch" to a virtual switch connected to the LAN (while VM was up).

Does this situation match with the behaviour you've encountered ?

Reply
0 Kudos
lefravi
Contributor
Contributor

After further testing, this behavior is reproduced when you modify the network connection of a virtual machine from an "Internal Only" virtual switch to a virtual switch connected to a to a physical switch while it's the VM is running.

Reply
0 Kudos
amorey
Contributor
Contributor

We found that Vista machines generate this MAC address.

See http://www.microsoft.com/technet/community/columns/cableguy/cg0506.mspx#ENKAC

on how to disable it.

Reply
0 Kudos
mcraig88
Contributor
Contributor

We are also running into this, any resolution?

Reply
0 Kudos
johnnyfixit
Contributor
Contributor

We too are seeing this. It appears to be the RARP packet used to let the switch know where the mac is, though it was my understanding this was only supposed to happen on a reboot or live transfer. It seems like it spews out a schwack of "proper" rarp packets, then begins to mangle the source mac. In addition to 00:00:00:00:00:00 I also occasionally see 60:60:00:0c:29:29 which you can see has the vmware vendor id in the wrong place.

Vandalay
Enthusiast
Enthusiast

Hadn't looked at this in a while but happy to find someone else that has seent he same issue. Did you come to any conclusions or find a way to fix it?

Reply
0 Kudos
tristanbob
Contributor
Contributor

We are seeing ton of these messages on our switches, ever since we deployed VMware. Please reply if you know why this is happening and how it can be remedied.

Tristan Rhodes

Reply
0 Kudos
GuillaumeARRQ
Contributor
Contributor

We currently experience the same problem. I'll investigate the issue and report any finding ...

Reply
0 Kudos
garybrown
Enthusiast
Enthusiast

Seeing the problem too - have raised an SR - will let you know what we get from that....

Reply
0 Kudos
davegrant
Contributor
Contributor

Reply
0 Kudos
garybrown
Enthusiast
Enthusiast

That's what I'm hoping - installed the patch this morning and will monitor.

Reply
0 Kudos
tristanbob
Contributor
Contributor

Is anyone else seeing strange behavior with their switches who log this error?

We are seeing some switches actings as if they were hubs, and the only error message we see is this "%C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET:" error. I am not sure what would cause this other than flooding the CAM table, which is not happening.

Please respond if you are also seeing this behavior.

Tristan

Reply
0 Kudos
xiandow84
Contributor
Contributor

hei guys! few days ago ,i met this problem.such as:*Dec 1 10:45:26: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 337 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Gi6/12 in vlan 2 then i find help in cisco.com ,i thought i have reasons for this:

The switch filter frames with a source MAC address of 00-00-00-00-00-00, which is an invalid source MAC, from the CAM table. This is an example of the syslog error output when this occurs:

%SYS-4-P2_WARN: 1/Filtering MAC address 00-00-00-00-00-00 on port 2/48 from host tableThese messages are informational and tell you that a frame that has a source MAC address of 00-00-00-00-00-00 is found, and the switch will never add that to the CAM table. However, the switch will forward traffic sourced from an all-zero MAC address.

The workaround is to identify the end station that generates frames with an all-zero source MAC address. Typically, one of these devices transmits such frames:

A traffic generator, such as Spirent SmartBits

Certain types of servers, such as load-balancing IBM WebSphere servers

A misconfigured router or end station, such as a device that transmits all-zeros broadcasts

A faulty NIC

while i found i was the 2ed cause as it said! anybody meet this quetion it may help you ! thanks!

Reply
0 Kudos
tristanbob
Contributor
Contributor

xiandow84 - Thanks for the post. Can you post the link to the document you found on Cisco.com? That explains why I thought the switches were acting like hubs, this MAC address could not be learned by the CAM table.

How did you fix the problem? It looks like you discovered that it was "Certain types of servers, such as load-balancing IBM WebSphere servers". What types of servers did you find? Are you running VMware ESX? How did you fix this problem?

Thanks,

Tristan

Reply
0 Kudos
xiandow84
Contributor
Contributor

Hi,I am glad to hear from you! I found it in google which title is"Catalyst 6500/6000 Switches ARP or CAM Table Issues " there is a troubleshooting issues about "Switch Filter All-Zero MAC Addresses from the CAM Table" .while my server type is ibm x3650 ,we use both for terminalsevers by load-balancing . the switch must have filtered this kind of traffic for safety..here is the link =http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00807347ab.shtml#zero

在2007-12-04,tristanbob <communities-emailer@vmware.com> 写道:

,

A new message was posted in the thread "Invalid Source MAC address 00:00:00:00:00:00":

http://communities.vmware.com/message/810532

Author : tristanbob

Profile : http://communities.vmware.com/people/tristanbob

Message:

Reply
0 Kudos