ami*_*ito 5 networking cisco switch flooding unicast
我在一家大公司担任网络管理员。最近，我们注意到我们的网络基础设施存在问题。基本上，我们的网络后端位于作为主要 L3 后端交换机的 Catalyst 上，很少有 Cisco Nexus 交换机作为连接到该 Catalyst 的边缘 L2 交换机。
当我们尝试嗅探其中一台主机上的流量时，问题就会出现 - 然后我们（总是）看到其他主机之间的单播流量。
我会尝试更详细：假设我在主机 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
我将始终看到其他主机之间的流量。
然而，我读了一篇关于单播泛洪的 Cisco 文章——“现象”不仅发生在我们网络中的 VLAN 之间传递时，而且发生在同一个 VLAN 上。在同一 VLAN 中的交换机之间传递时是否可能发生这种情况（我们的 VLAN 跨越许多交换机）？所有交换机都通过中继连接到 Catalyst...
有任何想法吗？
谢谢。
编辑：
似乎我们找到了问题的根源。
基本上，每当其中一台交换机收到一个带有它无法识别的 MAC 地址的帧时，它就会将其泛洪到所有端口。这是正常的 - 事情应该如此。但是，在我们当前的设置中，交换机中的 MAC 条目应该“存活”30 分钟。如果 30 分钟内没有看到 MAC，它将从交换机中删除，直到再次看到。如果一个数据包被发送到那个 MAC 并且它不在表中 - 所有端口都将被淹没以找到目标 MAC 端口（我们希望从端口之一得到答案）。
我们找到了目标 MAC 之一并在交换机 MAC 表中查找它。当网络被淹没时，该表不包含 MAC。我们尝试对与该 MAC 相关的地址进行 ARPing - 并且洪水停止了（因为 MAC 重新出现在 MAC 表中）。
然而，几秒钟后，MAC 再次从 MAC 表中消失，洪水又开始了。
洪水问题似乎源于我们交换机上的 MAC 表问题。似乎他们“忘记”MAC 地址的速度比他们应该的要快（MAC 应该保留 30 分钟）并用该 MAC 淹没所有数据包。
快速的前传——
ARP 表 - L3 设备（路由器、主机等）维护给定 IP 地址和相应 MAC 地址之间的映射。
CAM 表 - 在特定交换机平台中，这可能有其他名称，但结果是给定的 L2 交换设备维护给定硬件地址和一个或多个物理交换机端口之间的映射。
上述情况中发生的情况称为单播泛洪。这是一种即使交换机的 CAM 表已刷新相应条目，路由器仍具有活动 ARP 条目的情况。因此，当路由器收到给定主机的数据包时，它会简单地转发到交换机，而无需先发送 ARP 请求（IP : MAC 映射仍被缓存）。然而，交换机不再知道该 MAC 地址映射到的端口（该条目之前已过期）。如果交换机没有给定单播 MAC 的 CAM 条目，那么它将将该 MAC 的数据包洪泛到所有端口，直到看到响应（即对 ARP 请求的响应）。
由于不明原因，ARP 和 CAM 计时器在 Cisco 交换机上通常有很大不同。这些值略有不同，但在最现代的 Nexus 设备中，这种不匹配现象仍然存在。最佳实践是将 ARP 和 CAM 计时器设置为相似的值 - 理想情况下，将 CAM 表设置为比 ARP 长 5 秒左右。路由器重新进行 ARP 比交换机必须进行泛洪要好。将这两个值设置为 ~600 秒（10 分钟）通常不会太糟糕，但如果在路由器上看到过多的 ARP 流量，某些环境可能需要更长的时间。