数据包被无意中送出交换机

如果交换机专门用于该系统,交换机应该只向系统发送stream量。 我们似乎没有:如果我运行“tcpdump不是主机myhostname”,我可以看到许多显然是非广播(ssh,nfs)在其他主机之间传输的数据包。 我怎样才能防止这个? 我认为这可能会导致性能下降(我们有严重的NFS使用;如果它从所有的交换机端口出来,那就不好)。

交换机是三个Netgear GS748TSpipe理交换机的堆栈。 开关活动指示灯不断闪烁同步,这似乎也是错误的。

你可能没有看到我要描述的内容,那有可能是你。 我已经在几个低端和中间的Netgear和Linksys交换机上看到了你正在谈论的症状。 我见过这种“疯狂”行为的交换机已经运行了一段时间,工作正常,但是却开始把所有的端口泛滥出来。 我通常收到的电话是“networking速度慢”,随后的带宽监视通常会find一个“疯了”的交换机,通常它的活动指示灯亮起,大量“伪”stream量合法的交通,其他时间看似随机垃圾)。

我喜欢Zypher关于检查CPU利用率的build议,但是我也考虑打破“堆栈”(在这些特定的交换机上,我不知道“堆栈”是否作为一个逻辑单元运行),并testing每个交换机个别。

在过去几年里,这个问题似乎已经变得更糟了,没有名字的以太网交换机,Linksys和Netgear交换机。 我不知道是否有一些常见的芯片在我看过或者没有看到的问题开关中存在问题。 (我们build议我们的客户购买戴尔PowerConnect交换机,但他们的交换机还没有看到这些问题。)

通常情况下,交换机不应该故障回到“集线器”模式,除非你的MAC地址表超载(通常大约有8,000多个MAC地址,但是检查产品型号的详细信息)。 您可以使用以下命令检查给定Cisco交换机上的MAC地址数量:

sh mac-address-table | inc Total 

交换机根据vlan标记(如果使用它们)和mac地址做出所有决定。 如果你遇到洪水,那么你需要看看为什么交换机没有build立一个准确的MAC地址表。

你可以得到这个行为,但是如果你得到我所说的“vlan bleed”。 如果您有两个交换机端口背靠背连接,但在不同的vlan上,您可以看到这种行为。

具有多个网卡的设备也可以将vlans桥接在一起。 微软有一个“function”桥接网卡,所以你的无线和有线networking将立即桥接。

查看您的mac表中是否有多个地址不是上行链路到其他交换机的端口。 您也可以通过交换机的MAC表跟踪应该单播的设备之一的MAC地址。

在Cisco交换机上,这些命令可能会有帮助:

 sh mac-address-table | ex CPU sh mac-address-table | ex CPU|<uplink port name> 

我会检查的第一件事是交换机的负载。 如果你运行在如此高的负载下,它不能正确地切换数据包(在大多数情况下,这开始发生在80-90%的cpu负载区域),它将会失败回到有效的集线器,以及丢包的可能性。

虽然其他响应听起来更像您所描述的,但请确保您插入的端口没有设置为镜像端口 。

这种行为通常表示交换机没有在其桥接表(又名CAM表或MAC地址表)中input帧的目的MAC地址。 思科将其称为单播泛滥 。

你能提供一些有关你的拓扑结构的细节吗? 所有的“意外”stream量是发往同一个主机,还是多个主机? 你的主机是否使用绑定/分组的网卡? 入站stream量可能发送到一个MAC地址,但主机的出站stream量来自另一个NIC。

编辑:由于虚假的stream量是有限的MAC,这可能是一个好地方开始。 你可以询问交换机的桥接表(思科设备上的show mac-address-table),并查找是否存在违规目标MAC地址的条目? 另外,您能否确认交换机桥接表的超时值是什么?

我之前看到过这种情况的一种情况是在ARP超时值高于MAC地址表超时的子网上。 通常,当ARP条目超时时,发送ARP探测。 交换机会logging探测的响应,交换机会将主机的源MAC存储在其桥接表中。 当这些定时器相反时,桥接条目在ARP条目之前老化。 这意味着子网上的路由器/主机知道MAC地址拥有给定的IP,但交换机不知道该MAC连接到哪个端口。 在这种情况下,交换机会将stream量填充到该VLAN中的所有端口。

交换机是假设发送定向的stream量,但并不总是。
每台交换机都像networking上的每台主机一样维护一个ARP表。
一个简单的攻击 –
如果您必须在交换局域网中嗅探不属于您的数据包。 你所做的是产生大量假的ARP请求,并且在交换机中过载ARP表。 一旦ARP表超载,交换机将以默认的HUB模式运行。
CPU过度使用可能会导致性能下降,但我几乎可以肯定地认为,不是像这样的数据包风暴。