13

I have inherited support of a remote site which contains a Cisco 4500 and is connected to ~2 dozen cisco access switches - primarily 2960s with a couple of 3750s and 3560s. Not all access switches are directly connected to the 4500 - there is some daisy chaining of switches which was apparently done as a result of inadequate cabling. Recently i've noticed serror messages on the 4500 which indicate frames have been received with an invalid source mac address:

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

The device connected to Te5/1 is an access switch (Cisco 3750). It in turn is connected to 6 other access switches. After a bit of googling it appears the 4500 is the only cisco platform which logs invalid source mac addresses. From my reading, other platforms (2960, 3750, etc) seem to forward the frames along but don't log them as invalid, nor do they add an entry to the mac address-table. I suspect the root cause of the invalid source mac addresses could be a faulty nic, a software bug or perhaps a misconfigured vmware server. What tools are available on the access switches to track down the offending port?

Improve this question
5
  • 1
    Deleted my post, didn't realize that they weren't visible at all. If the switch won't put them in CAM then I guess your best bet is to run SPAN session on switches but even then it would be tricky to find the source port. Another option would be to disable unknown unicast and see if anything breaks. I'm surprised that communication works though. If a host with that MAC sends something outside it subnets the GW would have to ARP to see the MAC of the host and encapsulate the frame, does the GW have any weird ARP mappings?
    – Daniel Dib
    Commented Sep 11, 2013 at 7:16
  • 2
    According to supportforums.cisco.com/docs/DOC-36000 these frames should be dropped in HW so at least it shouldn't affect performance of the switches.
    – Daniel Dib
    Commented Sep 11, 2013 at 7:20
  • 1
    Yes, according to that link: "Please note that packets with invalid MAC address will be dropped anyway, all other Cisco Catalyst switches are silently dropping these packets in HW, 4k platform is explicitly generating logging message when such event is observed." ...but I know this can't really be the case since the 4500 is complaining about frames that are arriving on Te5/1 which is the port connected to the 3750. This would indicate the 3750 is forwarding the frames w/ the invalid source mac despite what DOC-36000 says.
    – User123456
    Commented Sep 11, 2013 at 10:20
  • Divide & Conquer!
    – generalnetworkerror
    Commented Sep 12, 2013 at 8:12
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin ♦
    Commented Aug 8, 2017 at 14:40

3 Answers 3

Reset to default
4

You could try if the frames can be blocked using a MAC ACL on interfaces and/or on vlans on the access switches. By applying the blocks selectively and checking if the error messages on the 4500 disappear or not, you can home in on the source of the traffic.

Moving cables around to see if the port mentioned in the error message on the 4500 follows could also help, but might prove tricky in a production environment.

Improve this answer
0
7

Generally when I have seen this, it comes from a poorly configured VM (often hosted on a user machine). Depending on the situation and environment, they can be difficult to track down (saw a lot of these at a University in the CS and ECE department buildings which moved and came/went as students did).

You have a couple great answers already, but another option you can pursue is to add the following config to the downstream switches (37xx, 36xx, 29xx):

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

This will drop any traffic with this MAC rather than forward it on and since it should be done in hardware (barring any features/problems that cause MAC lookups to be done in software), it shouldn't have a negative impact on performance.

Improve this answer
2
  • Thank you for this suggestion. This will prevent the frames from being forwarded across the trunks to other switches which is a big win. Is there a way through logging or debug commands to observe a port dropping frames based on this configuration?
    – User123456
    Commented Sep 13, 2013 at 13:49
  • @fcorrao, unfortunately not with this configuration. You would have to try doing what Gerben suggested and use a MAC ACL or Dave's suggestion of capturing traffic off the ports. But my take on it is that only the misconfigured device will be adversely affected, so either they will make it known or they won't even notice themselves.
    – YLearn
    Commented Sep 13, 2013 at 14:36
0

It appears to me that this error is not affecting network performance, as you discovered the log messages on your own, rather than your being inundated with user complaints. This leads me to suspect that the issue lies with some connected, but partially configured or misconfigured software or service that is not currently in use.

Your best course may be to let this sleeping dog lie, until such time as some user reports a problem. Alternatively, if you have the time to spare, you can run SPAN sessions as @Daniel Dib suggested, and give the output close scrutiny until you determine a suspect port or device.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.