我們有一個扁平的辦公室網路樹，建立在許多不同的 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 對連接埠。我不確定也無法測試它是否有幫助。而且感覺很像一個特別指定解決方案。