跟踪无效的源Mac地址

我继承了一个远程站点的支持，该站点包含一个Cisco 4500，并连接到大约2打cisco访问交换机-主要是2960s，其中有3750s和3560s。并非所有的访问交换机都直接连接到4500上-交换机之间存在菊花链连接，这显然是由于布线不足造成的。最近，我注意到4500上的错误消息，表明已接收到带有无效源mac地址的帧：

*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

连接到Te5 / 1的设备是访问交换机（Cisco 3750）。依次将其连接到其他6个访问开关。经过一番谷歌搜索，看来4500是唯一记录无效源mac地址的cisco平台。根据我的阅读，其他平台（2960、3750等）似乎可以转发这些帧，但是不要将它们记录为无效帧，也不要将条目添加到mac地址表中。我怀疑无效源Mac地址的根本原因可能是网卡故障，软件错误或vmware服务器配置错误。接入交换机上提供哪些工具来跟踪有问题的端口？

cisco switch layer2

— 用户123456
source

删除了我的帖子，没有意识到它们根本不可见。如果交换机不会将它们放在CAM中，那么我猜您最好的选择是在交换机上运行SPAN会话，但是即使那样，要找到源端口也很棘手。另一个选择是禁用未知单播，看看是否有任何中断。令我惊讶的是，沟通仍然有效。如果具有该MAC的主机在其子网之外发送了某些内容，则GW必须不得不ARP才能看到主机的MAC并封装帧，那么GW是否有任何奇怪的ARP映射？

— Daniel Dib 2013年

根据supportforums.cisco.com/docs/DOC-36000，应将这些帧放在硬件中，以便至少不影响交换机的性能。

— Daniel Dib 2013年

是的，根据该链接：“请注意，无论如何，具有无效MAC地址的数据包都将被丢弃，所有其他Cisco Catalyst交换机都将在静默中丢弃这些数据包，在4K平台中，当观察到此类事件时，它将显式生成日志记录消息。” ...但是我知道情况并非如此，因为4500抱怨帧到达Te5 / 1（这是连接到3750的端口）上。这表明3750正在转发带有无效帧的帧。无论DOC-36000怎么说，都可以使用源Mac。

— User123456 2013年

分而治之！

— generalnetworkerror 2013年

有什么答案对您有帮助吗？如果是这样，您应该接受答案，这样问题就不会永远弹出来寻找答案。或者，您可以提供并接受自己的答案。

— 罗恩·莫平

Answers:

您可以尝试使用接口和/或访问交换机上的VLAN上的MAC ACL阻止帧。通过有选择地应用这些块并检查4500上的错误消息是否消失，您可以了解流量的来源。

移动电缆以查看是否遵循4500上错误消息中提到的端口也可能有帮助，但在生产环境中可能会很棘手。

— 格本
source

通常，当我看到此消息时，它来自配置错误的VM（通常托管在用户计算机上）。根据情况和环境的不同，可能很难找到它们（在大学的CS和ECE部门大楼里见到了很多这样的建筑物，这些建筑物就像学生一样来来去去）。

您已经有了几个不错的答案，但是您可以追求的另一种选择是将以下配置添加到下游交换机（37xx，36xx，29xx）：

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

这将丢弃使用此MAC的所有流量，而不是转发该流量，并且由于它应该在硬件中完成（除非导致MAC查找在软件中完成的任何功能/问题），否则不会对性能产生负面影响。

— YLearn
source

谢谢你的建议。这将防止帧跨中继线转发到其他交换机，这是一个很大的胜利。有没有一种方法可以通过记录日志或调试命令来观察基于此配置的端口丢失帧？

— User123456 2013年

@fcorrao，不幸的是没有使用此配置。您将不得不尝试执行Gerben建议的操作，并使用MAC ACL或Dave的建议来捕获端口外的流量。但我认为，只有配置错误的设备才会受到不利影响，因此他们要么将其告知人们，要么甚至不会注意到自己。

— YLearn

在我看来，此错误并没有影响网络性能，因为您是自己发现日志消息的，而不是被用户的投诉所淹没。这使我怀疑问题出在某些当前未使用的已连接但部分配置或配置错误的软件或服务。

最好的方法可能是让这只熟睡的狗躺下，直到某些用户报告问题为止。另外，如果您有时间，可以按照@Daniel Dib的建议运行SPAN会话，并仔细检查输出，直到确定可疑的端口或设备。

— 戴夫在俄亥俄州
source