我们有一个扁平的办公网络树，它建立在许多不同的 ProCurve L2 和 L3 GigE 交换机上，跨越大约 300 个端口。今天我发现网络中的某个设备在短时间内导致过多的广播，导致大多数 100Mbps 链路饱和，从而影响某些服务（例如 VoIP）。该设备连接到 ProCurve 3500yl 交换机，该交换机是网络的根交换机，因此风暴通过根交换机蔓延到网络的其余部分。
问：有没有办法将问题局部化并避免风暴通过根交换机蔓延？
以下是与我的情况有关的更多细节，因为我可能问了一个错误的问题，而最好的解决方案可能在别处。
引发风暴的设备本身是 ProCurve 3400cl (J4905A) PoE 交换机，其固件版本已过时，M.10.76为 2009 年版。我知道它很旧了，周末会更新最新的。
3400cl 连接到一个会间歇性长时间断电的电源。断电后恢复供电时，设备需要大约 5 分钟才能启动。此时，流量会流经设备，而设备及其链路尚未完全设置好。在此期间，它会向网络发送各种难以捕获的不良流量，但这会在通过 SNMP 收集的统计数据中留下一个峰值。
在此期间，我看到High collision or drop rate. See help.
网络上许多 100Mbps 端口上的消息。
3400cl 通过两个物理 GigE 链路连接到 3500yl。3400cl 运行 RSTP，而 3500yl 配置了 MSTP 生成树协议。在正常运行期间，3400cl 上的 RSTP 禁用其中一个链路，而另一个链路正在转发。
当 3400cl 重新启动时，我可以在 3500yl 的日志中看到以下消息
14:05:03 ... port 37 is now off-line
14:05:04 ... port 38 is now off-line
14:05:51 ... port 37 is blocked by STP
14:05:51 ... port 38 is blocked by STP
14:05:54 ... port 37 is now on-line
14:05:54 ... port 38 is now on-line
然后我看到High collision or drop rate连接到 3500yl 的 100Mbps 端口和连接到它的低级交换机。
14:07:11 ... port NN-High collision or drop rate. See help.
VoIP 用户也遇到了中断。
我唯一能尝试的直接措施是设置broadcast-limit 53500yl 对端口。我不确定，也无法测试它是否有用。而且感觉非常像一个特别指定解决方案。