交换机淹没应该是Unicast的数据包。

Question

我在一家大公司做网络管理员。最近，我们注意到我们的网络基础设施出现了问题。基本上，我们的网络后端位于一个用作主L3后端交换机的催化剂上，很少有Cisco交换机作为边缘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

我将永远看到其他主机之间的通信。

然而，我读到了一篇关于单播洪水的思科文章--“现象”不仅发生在我们网络中的VLAN之间，而且也发生在同一个VLAN上。在同一个VLAN (我们的VLAN跨越多个交换机)中的交换机之间传递时，会发生这种情况吗？所有的开关都由一个树干连接到催化剂上.

有什么想法吗？

谢谢。

编辑：

看来我们找到了问题的根源。

基本上，每当其中一个交换机得到一个不识别的MAC地址的帧时，它就会将其淹没到所有端口。这是正常的--事情应该是这样的。但是，在我们当前的设置中，交换机中的MAC条目应该“活”30分钟。如果一个MAC在30分钟内没有被看到，它将从交换机中删除，直到再次出现。如果一个数据包被发送到那个MAC，并且它不在表中，那么所有的端口都会被淹没，以便找到目标MAC端口(我们希望从其中一个端口得到一个答复)。

我们找到了一个目标MAC，并在交换机MAC表中寻找它。当网络被淹没时，表中没有包含MAC。我们尝试了ARPing，与MAC相关的地址-并且洪水停止了(当MAC重新出现在MAC表中)。

但是几秒钟后，MAC又从MAC桌上消失了，洪水又开始了。

洪水问题似乎源于我们交换机上MAC表的问题。似乎他们“忘记”MAC地址比他们应该快( MAC应该停留30分钟)，并淹没所有的数据包与该MAC。

Answer 1

一个快速的前传-

L3设备(路由器、主机等)维护给定IP地址和相应的MAC地址之间的映射。

CAM -在特定的交换平台中，这可能由其他名称所知，但结果是，给定的L2交换设备在给定的硬件地址和一个或多个物理交换机端口之间保持映射。

在上述情况下所发生的情况称为单播洪水。在这种情况下，即使交换机的CAM表刷新了相应的条目，路由器仍然有一个活动的ARP条目。因此，当路由器接收到给定主机的数据包时，它只是被转发到交换机，而不首先发送ARP请求( IP : MAC映射仍然被缓存)。然而，交换机不再知道将此MAC地址映射到的端口(此条目之前已过期)。如果交换机没有给定的单播MAC的CAM条目，那么它会将该MAC的数据包洪流到所有端口，直到它看到响应(即对ARP请求的响应)。

由于不明确的原因，ARP和CAM计时器在Cisco交换机上通常是完全不同的。数值有所变化，但错配继续通过最现代的Nexus设备。最佳实践是将ARP和CAM定时器设置为类似的值--最好将CAM表设置为5秒左右，比ARP长。对路由器来说，重述ARP要比交换机不得不泛滥要好。将这两个值都设置为~600秒(10分钟)通常并不太糟糕，但如果路由器上出现过多的ARP通信量，某些环境可能需要更长的时间。

Answer 2

是的，ARP广播(吐出wireshark，你就会看到“谁有废话，告诉blah。”)。

客户应该回答说：“是我！”所以，我会调查那个没有回应的客户。