我发现了一个奇怪的问题，无法按需重现，并且对其根本原因有怀疑。
问题：整个网络间歇性地瘫痪，直到我走动并拔掉导致生成树洪水的计算机的插头。
拓扑：我有 2 台通过千兆 gbic 连接的 Cisco 非托管千兆交换机。两台交换机的千兆 gbic 端口旁边的相应端口均未占用，因此上行链路按设计运行。两台交换机都是 Cisco 的，属于同一个系列（SG100 和 SG102），因此不存在不兼容的问题。
我通过直接连接到罪魁祸首机器以及通过交换机连接的方式进行了 wireshark 捕获，两者都产生了相同的生成树洪水，导致 MAC PAUSE 帧减慢了速度，从而导致网络崩溃。
Probable culprit but unable to replicate issue "YET" is that this seems to usually occur AFTER the following occurs:
1. User undocks their laptop from their docking station and connects to WiFi
2. User is done with need for laptop away from desk and re-docks
3. User's laptop re-connects via Ethernet on the docking station
4. Sometimes crashes entire network.
由于我无法按需复制该问题，我该如何为 Wireshark 构建某种过滤器，以仅捕获类似于回声（而非 ICMP ECHO）的数据包，而这些数据包更像是导致初始风暴的重复流量，之后生成树就会发疯？
这样，我可以连续几天或几周运行捕获，直到再次发生这种情况。以下是我在 wireshark 中看到网络中断后的情况。
由于这些不是托管交换机，它们甚至不支持 STP，所以我很困惑为什么它总是以生成树流量结束。此外，源 MAC 地址在自然配置中不存在，我只在事后才知道受影响的工作站，而且它总是冻结或偶尔出现 BSOD。我已经很久没有见过这种情况发生时的 BSOD 了，但系统每次都会冻结，没有小型转储，是的，它已配置。
Other things I've already eliminated:
Cabling or cabling loop(s)
event logs - just show time loss between frozen time and reboot
no dumps when frozen
updated to Dell's latest certified drivers and BIOS
rebooted everything (again intermittent but usually after a undock, connecft to WiFi, re-dock and auto connect to ethernet pattern)
答案1
首先，需要明确的是，这不是生成树协议 (IEEE 802.1D)，而是以太网流量控制 (IEEE 802.3x，现为 IEEE 802.3-2012 的一部分)。以太网流量控制 PAUSE 帧的寻址地址与 STP 使用的地址相同，因此数据包嗅探器通常会将该地址报告为 STP 地址，即使该地址用于流量控制。
802.3x 时代的以太网流量控制有点失败。人们发现它会导致网络问题，尤其是“队头”阻塞，但为时已晚。想象一下，一台快速服务器为正常客户端和慢速客户端提供数据。慢速客户端不堪重负，向交换机发送暂停帧，现在交换机无法传送从服务器获取的所有帧，因此交换机向服务器发送暂停帧。这会阻止服务器向另一个（正常）客户端发送帧，即使服务器、交换机和客户端都有备用容量。这个慢速客户端（以及一个不太灵敏的交换机和不太灵敏的 802.3x 以太网流量控制协议）把所有人都搞砸了。
因此，一些交换机供应商故意不支持 802.3x 样式的流量控制，或者即使支持，也只允许交换机接受传入的 PAUSE 帧，但从不发送它们。如果您的交换机完全可管理，并且具有流量控制的配置设置，请确保将它们配置为从不发送 PAUSE 帧。
事实上，考虑到您看到 PAUSE 帧泛滥，如果您完全禁用流量控制，您的网络可能会更好。配置您的交换机和客户端以禁用流量控制。
此外，请保持以太网驱动程序为最新版本，并考虑清除网络中任何已知会在主机崩溃时向网络发送 PAUSE 帧的以太网 NIC 型号。