網絡迴路造成廣播風暴如何找出源頭？

迴路如何令網絡瞬間癱瘓

以太網交換機收到未知目的位址的訊框時，會把訊框複製並向除來源連接埠外的所有連接埠轉發。當網絡出現迴路（Loop），即交換機之間存在兩條或以上的有效路徑，同一訊框便會在迴路上不斷被複製轉發，且每個複製品又會被其他路徑再一次複製，廣播與未知單播訊框的數量以指數方式膨脹。短時間內交換機的轉發引擎、背板頻寬與記憶體全部被填滿，正常流量無法處理，整個網絡陷入癱瘓，此現象即「廣播風暴」（Broadcast Storm）。

廣播訊框（Broadcast Frame）的目標位址是 ff:ff:ff:ff:ff:ff，理論上每次連線建立（DHCP 請求、ARP 查詢）都自然產生，本身屬正常機制；其殺傷力全部來自迴路讓它們無限自我複製。因此問題的根源不在廣播本身，而在迴路。層二（L2）以太網的訊框結構與轉發規則，可參考 IEEE 802.3 標準及本站〈廣播與衝突網域〉一文。

出現迴路時的典型徵狀

迴路造成的風暴徵狀非常典型，與硬件故障或病毒攻擊不同，幾乎可以一眼辨認：

實務上最可靠的驗證方式，是逐一拔除交換機的對外 Uplink 或用戶連接埠，觀察指示燈是否停止閃爍。若拔除某一條線後風暴停止，該條線路便是迴路的關鍵一環。網絡工程師處理這類問題時會先保留現場、記錄每個連接埠的狀態再逐段測試，避免拔錯線導致無法還原。

用連接埠統計鎖定源頭

1. 先斷開與上層交換機的 Uplink——若整個網絡癱瘓，優先處理最外層的擴散鏈路，令風暴影響範圍止於局部，再逐段排查。
2. 登入可網管交換機查看連接埠統計——在管理介面或透過 CLI 檢視各埠的接收與傳送訊框計數器。迴路鏈上，相關埠的廣播訊框計數會在短時間內急升，是最直接的線索。
3. 留意「交叉電纜接錯線」——把同一交換機的兩個埠以網線直接接駁（例如當作備線預留、或把牆身面板兩端插在同一台機），是最常見的迴路成因。拔除這類線後問題即時消失。
4. 檢查交換機之間的冗餘連接——兩台交換機之間同時接了兩條線、或經牆身面板間接形成第二路徑，都會構成迴路。
5. 從最可疑的線逐條拔除測試——每拔一條觀察 10 至 15 秒，確認風暴是否停止；找出源頭後，以正確的網絡設計取代臨時接線。

完成後應記錄各連接埠的最終接線，把「哪些埠接哪部設備」整理成文件。缺乏文件記錄的網絡，迴路往往在未來的擴充或搬線時再次出現。網絡文件的重要性可參考本站〈網絡配置備份與自動化〉一文。

迴路的常見實際成因

迴路絕大多數不是刻意建立的，而是日常操作無意造成：

以香港的情況而言，商廈與工廈租戶換手頻繁，舊租戶的網線、電訊商的固網數據線與新網絡並存，是迴路的高發環境。裝修期間臨時拉線、辦公室搬位後「方便起見」多留一條線，日後接駁時形成迴路，是實務上最常遇到的成因。

STP 與 Loop Protection 的角色

生成樹協定（Spanning Tree Protocol，STP）由 IEEE 802.1D 定義，其作用是在層二網絡中自動偵測冗餘路徑，並以阻塞（Blocking）狀態停用其中一條，確保任何時刻都只有一條有效路徑，從機制上防止迴路。其後發展的 Rapid STP（802.1w）把收斂時間大幅縮短。另一項常用的防護是 Loop Protection（迴路保護），當交換機在指定埠上偵測到重複的協定資料單元（PDU），便自動關閉該埠。

但兩者都無法取代人工查線，原因如下：第一，STP 預設狀態未必在所有交換機上啟用，而多數中小型非網管交換機根本不具備 STP；第二，STP 只處理交換機之間的鏈路，同一台交換機兩個埠被網線直接互接的「單機迴路」，很多型號無法完全攔截；第三，風暴一旦成形，交換機 CPU 被拖垮，STP 協定訊息自身也無法及時處理。因此即使網絡配備 STP，風暴仍可能發生。

工程實務上的建議是：在可網管交換機啟用 STP 與 Loop Protection，同時把實體接線管理妥當——迴路的最終防線是清晰的線路記錄與審慎的接線紀律，而非單靠協定。交換機的選購考慮可參考本站〈網絡交換機是什麼？〉一文。

常見問題

權威參考來源

• IEEE 802.1D：Spanning Tree Protocol
• 維基百科：Broadcast radiation
• 維基百科：Broadcast storm
• 維基百科：Spanning Tree Protocol
• IEEE 802.3：Ethernet standard

相關技術主題