如何透過 Nebula Switch 排除群播和廣播風暴
Zyxel Employee
如何尋找並解決廣播與群播風暴
廣播或群播風暴，是造成區域網路效能低下甚至完全癱瘓的常見原因之一。當大量的廣播/群播封包在網路中不斷循環，會迅速耗盡所有設備的處理能力與網路頻寬。
本文將作為一份完整的指南，從「了解風暴」、「尋找來源」到「解決問題」，引導您系統性地找出網路中的問題點，並恢復網路的正常運作。
版本資訊
本篇教學的截圖與操作，基於 Nebula Control Center 19.00 版本。
文章大綱
第一章 : 功能簡介
- 1.1 什麼是群播和廣播風暴？
- 1.2 群播和廣播風暴從何而來？
- 1.3 如何知道網路是否存在群播/廣播風暴
第二章 : 如何尋找群播/廣播風暴來源
- 2.1 尋找風暴 - 交換器事件日誌
- 2.2 尋找風暴 - 端口鏡像
- 2.3 尋找風暴 - Wireshark
第三章 : 如何解決群播和廣播風暴
- 3.1 啟用風暴控制
- 3.2 啟用 IGMP Snooping（僅針對群播風暴）
- 3.3 解決故障設備行為
第一章 : 功能簡介
1.1 什麼是廣播與群播風暴？
「廣播/群播風暴」是指當一個區域網路 (LAN) 中，被大量、密集的廣播 (Broadcast) 或群播 (Multicast) 封包所淹沒，導致網路效能急遽下降甚至完全癱瘓的現象。
這些封包會不斷地被交換器複製並轉發到所有連接埠，迅速耗盡網路頻寬與交換器、防火牆等設備的處理器資源，最終造成正常使用者的連線緩慢或中斷。
1.2 風暴從何而來？(常見原因)
廣播與群播封包本身是網路正常運作所需的一部分，但它們會演變成「風暴」，通常源於以下兩種情況：
- 網路迴圈 (Network Loop)這是最常見的原因。當交換器之間不慎被連接成一個封閉的環路（例如：一條網路線的兩端插在同一台交換器上），廣播封包會在這個環路中被永無止境地複製與轉發，數量呈指數級增長，瞬間癱瘓網路。
- 設備故障或行為異常某台網路設備（如網卡、印表機、IP 攝影機）因硬體故障或驅動程式問題，開始無預警地對網路發送大量的廣播或群播封包。
1.3 如何判斷是否存在風暴？
當風暴發生時，您通常會觀察到以下現象：
- 網路全面或局部癱瘓：網路速度變得極度緩慢、延遲暴增，甚至完全無法連線。
- 交換器燈號異常狂閃：所有連接埠的燈號，或整個交換器的燈號，以極高的頻率不停閃爍。
- CPU 使用率飆高：防火牆或核心交換器的 CPU 使用率異常地接近 100%。
- 事件日誌出現警告：Nebula 交換器或防火牆的事件日誌中，會出現關於「廣播/群播風暴」或「迴圈偵測」的警告紀錄。
背景知識：廣播與群播封包是什麼？
廣播 (Broadcast) 封包一對多的通訊方式，將封包發送給同一個廣播域內的所有設備。它主要用於設備探索，例如
ARP請求或DHCPDiscover 封包。群播 (Multicast) 封包一對多的通訊方式，但只將封包發送給有加入特定「群組」的設備。常用於 IP 影像串流，例如 Apple TV、Chromecast 或 IPTV 服務，其使用的 IP 位址範圍為
224.0.0.0到239.255.255.255。
第二章 : 如何定位群播/廣播風暴
定位風暴來源的過程，就像偵探辦案，需要由大到小，逐步縮小範圍。Nebula 平台提供了多種工具，讓您能快速找到問題的根源。
2.1 尋找風暴 - 交換器事件日誌
這是最簡單、最快速的方法，通常能解決大部分的問題。
- 前往事件日誌導覽至 【全站點 > 監控 > 交換器 > 事件日誌】。
- 分析日誌篩選「風暴控制」相關的事件。日誌會明確指出在哪一台交換器 (
Switch) 的哪一個連接埠 (Port) 上偵測到風暴。- 範例：日誌顯示
SW1的Port 23和SW2的Port 10出現群播風暴。
- 範例：日誌顯示
3. 判斷來源路徑
- 如果發生風暴的埠是上行鏈路埠 (Uplink)（如
SW1的Port 23），代表風暴是從其他交換器傳來的，來源不在這台交換器上。
- 如果發生風暴的埠是終端設備連接埠 (Access Port)（如
SW2的Port 10），那這個埠所連接的設備，極可能就是風暴的來源。
4. 鎖定來源設備 (MAC 位址)
進入被標示為來源的交換器（SW2）的詳情頁，點擊對應的連接埠（Port 10），查看其 MAC 位址表。表中的 MAC 位址，就是產生風暴的設備。
5. 識別與處理
- 識別設備：您可以利用
MAC Address Lookup等網站，透過 MAC 位址查詢設備的製造商。 - 處理設備：找到實體設備後，可對其進行斷電、更新韌體或聯絡原廠等後續處理。
現在我們已經找到了風暴的來源，接下來需要找出該設備製造這些群播風暴的原因。這可以通過調查設備來完成，或者我們可以致電該產品相關技術人員。
使用埠鏡像 (Port Mirroring) 搭配 Wireshark 進行深度分析
在某些情況下（例如，日誌被大量洗掉，或您想分析風暴的封包內容），就需要使用更進階的工具。
核心概念：此方法是將有問題的交換器埠的流量，完整地「複製」一份到另一個埠，然後用連接在該埠上的電腦，透過 Wireshark 軟體來進行即時的封包分析。
2.2 尋找風暴 - 端口鏡像
在 Nebula 上設定埠鏡像，將來源埠（您懷疑有問題的埠）的流量，鏡像到一個未使用的目的埠。
- 詳細設定方法請參考：Nebula 診斷工具 - 埠鏡像和封包擷取
2.3 尋找風暴 - Wireshark
將您的電腦用網路線連接到該目的埠，並開啟 Wireshark，選擇對應的網卡開始擷取封包。
- 設定過濾器，在 Wireshark 的顯示過濾器中，輸入 broadcast or multicast 來篩選出廣播與群播封包。
分析流量 :
- 判斷風暴：正常情況下，這類封包不應頻繁出現。若您看到封包以極高頻率（例如，每秒超過數十個）不斷刷新，即代表存在風暴。
- 尋找來源：點選任一可疑封包，在下方的詳細資料中，找到「Src: (來源)」欄位，其後的 MAC 位址就是發送該封包的設備。
找出 IP 位址 (可選) : 找到來源 MAC 位址後，您可以使用 Advanced IP Scanner 等區域網路掃描工具，來找出該設備對應的 IP 位址，方便進一步管理。
第三章 : 如何解決群播和廣播風暴
現在我們已經找到了群播或廣播風暴的源頭，當然，我們需要解決它。解決群播/廣播風暴的主要方法有四種：
- 確認網絡中是否存在迴圈並消除迴圈 - 群播/廣播風暴隨後就會消失
- 啟用風暴控制 - 限制每秒通過端口發送的群播和廣播封包的數量，以便在風暴封包發生之前將其丟棄
- 啟用 IGMP 偵聽（僅適用於群播風暴）- 控制和引導群播流量僅發送到請求它們的設備，避免將流量送給不需要的設備
- 斷開設備與網路的連接或聯繫供應商以查看該設備發生了什麼情況，因為用群播/廣播封包淹沒網路是不正常的
3.1 啟用風暴控制
3.1.1 本地管理模式
前往【Advanced Application -> Broadcast Storm Control】然後配置群播/廣播風暴所在的端口：
在需要的端口上啟用風暴控制，並從每秒 50 個封包的值開始，如果仍然遇到風暴，則減少到 30 個。
建議在只有連接一台裝置的端口上面啟用設定，若端口串接 HUB ，無法確認設備數量，因此也無法準確限制。
3.1.2 Nebula 管理模式
前往 整個站點 > Devices > 交換器，將群播/廣播風暴所在的端口設置風暴控制
在需要的端口上啟用風暴控制，並從每秒 50 個封包的值開始，如果仍然遇到風暴，則減少到 30 個。
建議在只有連接一台裝置的端口上面啟用設定，若端口串接 HUB ，無法確認設備數量，因此也無法準確限制。
3.2 啟用 IGMP Snooping（僅針對群播風暴）
IGMP 監聽是一個很大的主題，我們不會在這邊深入討論它的理論。簡單來說，只要開啟功能，Switch 就能監聽 Multicast 流量，將豐包只傳送給需要的裝置。您可以在下面找到配置此功能的位置。
3.2.1 Nebula 管理模式
前往【整個站點 > 設定 > 交換器 > IGMP進階設定】啟用該頁面最上方的「IGMP snooping」，完成記得點選「Save」。
3.2.2 本地管理模式
前往【Advanced Application > Multicast > IPv4 Multicast > IGMP Snooping】勾選 「Active」，點選「Apply」，最後記得點擊右上角「Save」保存設定檔。
請注意！如果沒有點擊「Save」，交換器重啟設定將遺失。
了解更多 IG Snooping 設定可以參考此篇文章 : How to configure IGMP Snooping for multicast clients in the same LAN
3.3 解決故障設備行為
如果持續發生的群播/廣播風暴正在影響您的網絡，您需要立刻中斷設備與網路的連接。
您還可以聯繫引起風暴的設備的製造商（供應商）技術人員，找出引起風暴的原因，並嘗試由設備製造商（供應商）技術人員解決。
