我在家庭networking上有一个奇怪的经历。 我们的以太网断了; ping相邻的主机是不可能的。 我检查了开关; 所有的灯都亮着，闪烁着，虽然它们是闪烁的，这有点令人担忧。 然后我注意到我的Linux机器崩溃了（对鼠标和键盘没有反应）。 我点击重置button，在那一刻networking清除。
除了我的雇主恰好在服务连续性非常重要的业务之外，这只会有学术兴趣。 关键数据通过双独立以太网LAN发送。 我们的可靠性模型假设唯一可能导致整个局域网故障的是交换机。 所以，一个单一的故障主机可以做到这一点是令人担忧的。
这个消息在思科论坛上说不可能，所以不用担心。
这份有关美国海关中断的报告听起来很相似：一张故障的以太网卡购买了他们的networking。 这是一个单一的networking，听起来像一个硬件故障，所以它不会打倒我们的双重networking。 但是我想知道：一个设备驱动程序的错误可能会把一张卡塞进一个干扰networking的状态？ 如果是这样，那么如果它是驾驶两个保税渠道，它可能会同样楔入两个。
有谁知道更多关于以太网的潜在故障模式？
编辑
我试图理解的是：单个节点在软件（例如设备驱动程序）中可以做些什么，可能会导致整个networking崩溃。 让我们假设它不是恶意软件，那么特定交换机的晦涩的错误可能不是问题。 发送帧到一个特定的主机不会这样做。 发送大量广播帧（目标FF：FF：FF：FF：FF：FF）是否会产生这种效果？ 怎么样jabber？ 这还是一个东西吗？
这只是一些可能导致你目睹的行为的事情：
一个开关循环。
恶意软件。
坏/有缺陷的网卡。
一个错误的/行为不当的网卡驱动程序。
广播风暴（通常与交换机环路相关）。
要解决您的编辑问题：广播风暴或交换机泛滥（这是两个不同的事情）可能会导致此问题。 请注意，此处有两个广播地址：FF-FF-FF-FF-FF（255.255.255.255），它是二层广播地址，与三层子网广播地址（例如192.168.1.255是192.168.1.0/24子网的第3层子网广播地址）。 第2层或第3层的广播风暴可能会导致此问题。
开关在其固件中运行代码。 有时候，这些代码是错误的，而意外的input可能会导致交换机崩溃。 所以是的，一个行为不端的主机可能会使交换机崩溃。 这不太可能，但可能会发生。
几年前（2003年也许？）我有非网pipe的Netgear交换机，每周会下降2-4次，好像他们正在经历广播风暴 – 就像你上面的描述一样。 重新启动堆栈是唯一的修复。 Netgear的支持人员表示，他们在运行IP和IPX时遇到了一个已知的问题，而且由于他们不受pipe理，所以没有任何问题需要解决。 他们没有进一步的固件升级，所以他们更换了新的pipe理型交换机，在保修期内。
至于“请列出所有可能的以太网故障模式” – 不，这是一个愚蠢的要求。 但是，对于您自己的教育，请阅读生成树循环，这是常见的用户引发的故障模式。
由于Linux盒子似乎有两个局域网接口：你能否排除它不是临时桥接这两个接口，创build一个桥接环路？
只使用两个交换机不是高可用性。 您应该在交换机上指示广播风暴和适当的监控软件。 为此，请configuration优先级较高的pipe理VLAN，以免广播风暴中断。 或者，通过物理上独立的networking链接或带外运行pipe理function。
PS到你的编辑：在一个交换networking上，唯一能把所有端口关掉的东西是广播风暴或严重拥塞。 超大帧（jabber），碎片或类似的exception只是由交换机丢弃。 来自入口端口的广播风暴可以使用该端口的带宽泛滥networking–100M端口对1Gnetworking没有太大的损害，但1G端口可以轻易地淹没所有100M出口端口。 同样，通过可以处理的上行链路发送更多数据将会降低该方向上的大部分其他stream量。
广播风暴通常是由桥环造成的。 生成树是一个很好的补救办法，也允许您添加冗余链接到您的networking。 其他的风暴可以通过边缘端口的广播限制来处理。
拥挤是一个更强硬的野兽。 硬件方法是确保所有的上传/下载端口比任何边缘端口更快。 在具有10GE上行链路的千兆交换机上，至less需要10个边缘端口才能使上行链路饱和。 另一种方法是限制边缘端口带宽，使其不能过度上行。