我是一家大公司的networkingpipe理员。 最近我们注意到了我们networking基础设施的一个问题。 基本上，我们的networking后端位于作为主要L3后端交换机的Catalyst上，作为边缘L2交换机的几个Cisco Nexus交换机连接到该Catalyst。
这个问题出现在我们试图嗅探我们的一台主机上的stream量时 – 我们（ 总是 ）看到其他主机之间的单播stream量。
我会尽量做得更细致：假设我在主机10.0.0.1上，使用MAC MAC ，我运行命令 –
tcpdump -i eth0 ether host not MAC and host not 10.0.0.1 and not broadcast and not multicast
我会经常看到其他主机之间的stream量。
然而，我读了一篇关于单播泛滥的思科文章 – 这个“现象”不仅发生在我们networking中的VLAN之间，而且也发生在同一个VLAN上。 在同一个VLAN中的交换机之间通过（我们的VLAN跨越多个交换机），是否有可能发生？ 所有交换机都通过一条中继线连接到Catalyst …
有任何想法吗？
谢谢。
编辑：
我们似乎发现了我们问题的根源。
基本上，每当其中一台交换机得到一个MAC地址的帧，它不能识别 – 它将其洪泛到所有的端口。 这是正常的 – 事情应该走的方式。 但是，在我们目前的设置中，交换机中的MAC条目应该“活”30分钟。 如果30分钟内没有看到MAC，它将从交换机上删除，直到再次看到。 如果一个数据包被发送到该MAC并且它不在表中 – 所有的端口将被洪泛以find目的MAC端口（我们希望从其中一个端口得到答案）。
我们find了一个目的MAC，并在交换机的MAC表中查找。 当networking被淹没时，该表不包含MAC。 我们试着对与MAC相关的地址进行ARPparsing，并且洪水停止（MAC重新出现在MAC表中）。
然而，几秒钟后，MAC又从MAC表中消失，洪水再次开始。
看起来洪水问题是由交换机MAC表问题引起的。 看起来他们似乎“忘记”MAC地址比他们应该快（MAC应该停留30分钟）并且用该MAC洪泛所有数据包。
一个快速的前传 –
ARP表 – L3设备（路由器，主机等）维护给定的IP地址和相应的MAC地址之间的映射。
CAM表 – 在特定的交换机平台上可以被其他名称所知，但是结果是给定的L2交换设备在给定的硬件地址和一个或多个物理交换机端口之间保持映射。
上述情况发生的情况称为单播泛滥。 即使交换机的CAM表已经刷新了相应的条目，路由器仍然具有实时ARP条目。 因此，当路由器收到给定主机的数据包时，只需将其转发给交换机，而不必先发送ARP请求（IP：MAC映射仍被高速caching）。 但是，交换机不再知道该MAC地址映射到的端口（该条目早已老化）。 如果交换机对于给定的单播MAC没有CAM条目，则它将该MAC的分组泛洪到所有端口，直到它看到响应（即对ARP请求的响应）。
由于模糊原因，思科交换机上的ARP和CAM定时器通常非常不同。 这些值有所不同，但通过最现代的Nexus设备仍然存在不匹配。 最佳做法是将ARP和CAM定时器设置为相似的值 – 理想情况下CAM表设置为比ARP长5秒左右。 重新ARP的路由器比交换机不得不淹没更好。 将这两个值设置为大约600秒（10分钟）通常不会太差，但是如果在路由器上看到过多的ARP通信，则某些环境可能需要更长的时间。
是的，ARP广播（抛出wireshark，你会看到“谁是等等等等，告诉等等。”）。
客户应该回应“这就是我！” 所以，我会调查没有回应的客户。