城域網未知組播分析和優化

（中國電信股份有限公司無錫分公司，無錫 214000）

1 引言

電信城域網目前綜合承載寬帶，IPTV，語音業務。隨著網絡規模的增大，網絡內未知組播報文的數量隨之增多，達到一定程度后，就會對網絡帶寬，設備負載產生壓力，進而影響業務質量。研究未知組播的成因，實施對應的網絡優化勢在必行。

2 未知組播及其危害

城域網設備，例如交換機在處理單播報文時，每轉發一個數據幀，就會進行相應的源MAC地址學習，從而學習到一個單播轉發表項。而組播轉發表項則不同，它是通過一些三層或二層的組播協議獲得的。城域網常用的二層組播協議有IGMP（Internet Group Management Protocol，因特網組管理協議）。

在組播轉發流程中，設備使用CPU分析IGMP報文，形成組播轉發表下發給ASIC （Application Specific Integrated Circuits，專用集成電路）芯片，芯片根據轉發表轉發組播報文。命中組播轉發表的報文，稱為已知組播，沒有命中的報文，稱為未知組播。

對于未知組播，設備根據自身設計，在物理端口層面將報文丟棄或者泛洪。同時報文被抄送至CPU，交給上層協議處理。當未知組播報文到達一定速率，就會超過CPU處理能力或觸發CPU保護機制，導致部分正常業務的IGMP報文被丟棄。

IGMP報文被部分丟棄后，正常組播表項有幾率得不到刷新被老化，對應流量成為未知組播。此時，若設備在物理端口層面的轉發策略為丟棄，則IPTV業務表現為流量中斷；若策略為泛洪，則報文會被轉發至該網絡廣播域下除源端口以外其他所有端口，可能導致用戶側端口擁塞，甚至觸發相鄰網絡設備的CPU丟包，影響范圍進一步擴大。

3 城域網未知組播的來源

3.1 非法組播

當設備開啟可控組播功能，配置了組播節目列表之后，所收到報文中的組播目的地址不在列表范圍內，該組播即為非法組播。設備不會為非法組播建立組播轉發表項，而是根據自身設計，丟棄，泛洪或者限速泛洪。

非法組播一般有兩個來源：

（1）終端內置協議：例如，開啟了IPv6協議棧的電信家庭網關，會向IPv6組播目的地址FF02：：16發送MLDv2（Multicast Listener Discover，組播偵聽發現協議）報文。

TP-LINK，華為，NETGEAR，小米，REALTEK等廠家的路由器或智能終端，會向IPv4組播目的地址239.X.X.X，224.X.X.X等發送IGMPv2，IGMPv3報文。在城域網匯聚交換機（下掛約2.5萬終端）CPU側抓包，1分鐘內可以收到此類終端發出的729個IPv4組播報文，包含322個IPv4組播組。

（2）惡意組播攻擊：終端沒有組播業務需求，卻向外發送過量組播報文的行為，稱為惡意組播攻擊。終端可以利用某些設備對未知組播的“泛洪”處理動作，在不具備合法接入IP的情況下，向網絡發送大量惡意組播報文，惡意報文又被設備沿廣播樹泛洪至整個網絡，進而造成網絡中CPU性能瓶頸節點下的組播轉發出現異常。惡意組播源不僅可以存在于IPTV業務VLAN（Virtual Local Area Network，虛擬局域網）中，也可存在于專線、寬帶，語音等任意業務的任意VLAN內。

以W市某次攻擊事件為例，惡意終端原有專線業務已拆機，網關IP等三層業務數據已刪除，但接入光路和端口VLAN仍然保留。攻擊者利用城域網的IGMP報文處理機制，直接構造大量虛假IGMP請求報文發送給上聯，速率約0.35kp/s。經過專線交換機泛洪后，造成匯聚交換機CPU處理IGMP報文時大量丟包，進而影響了該匯聚交換機下所有組播業務。攻擊時，匯聚交換機CPU報文統計如圖1所示，IGMP報文轉發比例被降低到了9.8%。

圖1 匯聚交換機IGMP報文丟包

3.2 組播轉發表規格過小

交換機和路由器的組播轉發表通常由組播組、源端口、目的端口、VLAN組成[1]。當組播轉發表規格過小，設備實際承載的組播數量超過了組播轉發表最大條目數量，超出的組播組流量就會成為未知組播。

在目前城域網匯聚層和接入層中的交換機通常工作在IGMP snooping模式，往往不配置組播節目列表或不具備可控組播能力，此時組播轉發表規格過小成為未知組播的潛在來源因素。

3.3 CPU報文處理丟包

CPU若存在丟包，IGMP報文得不到及時處理，會使得組播轉發表項得不到正確刷新[2]。根據IGMP協議機制，若兩個周期的IGMP通用組查詢被丟棄，再過一個IGMP最大查詢響應時間，設備上所有組播表項都將老化，原先合法的組播將成為未知組播。若兩個周期的特定組響應報文被丟棄，再過一個最大查詢響應時間，設備上特定組播組表項都將老化，流量成為未知組播。

CPU丟包和未知組播的形成之間互為因果：CPU丟包幾率導致未知組播產生，另一方面未知組播會被抄送CPU處理，加劇CPU丟包。

城域網內設備和終端CPU丟包的原因主要有：

（1）未知組播：以之前提到的MLDv2協議報文為例：網絡未優化前，在W市某局家庭網關PON口抓包，終端從上聯口收到了同一匯聚交換機下其他家庭網關的大量MLDv2報文，速率約1.5kp/s。該速率觸發了家庭網關的CPU保護機制，造成IPTV業務的IGMP報文隨機性丟包，最終導致組播類視頻斷流。

（2）針對設備CPU的惡意攻擊：有些協議需要設備CPU處理，例如ICMP，IGMP，TELNET，廣播等。攻擊者利用此機制，向設備發送過量協議報文，從而影響CPU正常工作。

W市某次網管服務器中毒，網管向接入網OLT（Optical Line Terminal，光線路終端）發送ICMP報文，報文速率0.5kp/s。導致該OLT主控板CPU異常，峰值利用率達到73%，遠高于相同負載的同類型OLT，峰值時間與該OLT下IPTV業務卡頓時間相近。在OLT上臨時配置ACL（Access Control List，訪問控制列表）禁止網管服務器訪問，后期重裝服務器操作系統后，IPTV業務恢復正常。

（3）網絡環路：通常為用戶將網線接在了同一臺ONU（Optical Network Unit，光網絡單元）的兩個口上導致。上聯設備發送的廣播包進入環路后形成廣播風暴，耗盡二層設備CPU資源。

4 網絡優化措施

提高設備硬件規格，網絡優化是應對未知組播的兩個主要措施。而網絡優化可以在不增加硬件成本，不影響現有業務的前提下，促進網絡的平穩發展，是運營商的較優選擇。

網絡優化中，保留并處理業務相關的協議報文，隔離或丟棄不相關協議報文，做好網絡安全防護工作，是方案的基本原則。

W市城域網優化方案如下：

（1）配置合法組播前綴列表：針對組播轉發表規格大小問題，業務控制層設備可以配置合法組播前綴列表，接入層設備開啟IGMP proxy功能[3]并使能合法組播前綴列表。配置后，設備只學習包含在前綴列表范圍內的IGMP報文并形成組播轉發表項。

（2）匯聚層和接入層開啟二層隔離：傳統的二層網絡，VLAN和VLAN之間相互隔離，但同一個VLAN內的終端仍然屬于同一個廣播域，存在廣播/組播風暴隱患。匯聚層和接入層配置二層隔離后，同一個VLAN內廣播以及未知組播僅向二層設備上聯口轉發，下聯設備和終端之間二層隔離，不再收到其他終端發出的的廣播和組播報文。

例：針對跨OLT泛洪，匯聚交換機開啟下聯口隔離。注意上聯端口不能配置隔離，避免路由器接收不到用戶側正常的廣播和組播報文；針對跨PON口和VLAN內泛洪，OLT開啟PON口隔離和VLAN內隔離。隔離效果如圖2所示：

圖2 二層隔離效果

（3）接入層開啟未知組播丟棄：未知組播處理方式為“泛洪”的二層接入設備，可以開啟未知組播丟棄。配置后，設備將丟棄未知組播報文，不再上送CPU，也不向其他端口轉發。

（4）統籌規劃CPU報文分類限速和出口報文分類限速：針對僅本地處理的報文：設備開啟CPU保護功能，對ASIC芯片上送CPU的報文分類并限速，優先保證網絡管理和重要業務報文的處理。

針對除本地處理外繼續向網絡泛洪的報文：首先，可信ONU或者交換機利用QoS為報文著色分類；其次，各層次設備依據QoS標記，部署出口報文分類限速；底層設備限速適當嚴格，把攻擊流量隔離在靠近用戶側。

（5）周期巡檢，積極應對：采集統計CPU報文處理信息，形成維護基準，開展針對設備CPU的周期性檢測和異常處理。設備主控板和業務板的CPU都需要處理

5 結束語

網絡優化是一項長期性，周期性的系統工作。隨著城域網終端規模的增長和業務融合的發展，需要維護人員不斷調整網絡結構，優化網絡流量，解決網絡質量瓶頸，使得用戶體驗得到較大提升，為運營商業務戰略和國家通信事業提供有力支撐。