1、PON 廣播風暴的排查和網絡優化方法編號：版本：V1.0編 制： 審 核： 批 準： All rights reserved版權所有 侵權必究( for internal use only)（ 僅供內部使用）PON 廣播域過大的排查和網絡優化方法V1.0 內部公開 第 2 頁 共 11 頁2文檔修訂記錄文檔修訂記錄日期日期DateDate修訂版本修訂版本RevisionRevision VersionVersion修改修改章節章節SecSec No.No. 修改描述修改描述ChangeChange DescriptionDescription作者作者AuthorAuthorPON 廣播域過大的

2、排查和網絡優化方法V1.0 內部公開 第 3 頁 共 11 頁3目目 錄錄1概述.42廣播風暴的產生和危害.52.1廣播域的概念 .52.2廣播風暴的產生 .52.3二層環路的危害 .52.4ONU 的幾種環路以及檢測機制.62.4.1端口自環 .72.4.2端口內環 .72.4.3ONU 外環.73廣播風暴的定位.83.1識別網絡中的廣播風暴 .83.2了解業務 VLAN 規劃.83.3流量統計排查 .83.4環路排查 .83.5抓包排查 .94廣播風暴的優化措施.115附件.11PON 廣播域過大的排查和網絡優化方法V1.0 內部公開 第 4 頁 共 11 頁41概述概述本文檔主要針對 P

3、ON 接入網的特點，用于指導廣電運營商客戶因廣播風暴問題進行網絡優化；或我司在例行廣電行業客戶巡檢過程中，通過此文檔幫助巡檢同事盡快發現客戶網絡規劃問題，進一步幫助客戶優化整改網絡。近年來我司 PON 產品在廣電市場應用過程中，發現其 PON 網絡以及上層匯聚層因早期規劃不合理，導致廣播域過大，一旦網絡中產生環路或者存在異常攻擊源等情況導致業務大面積中斷或嚴重丟包；如果廣播域過大的問題得不到及時優化改善，隨著 PON 接入網規模逐漸擴大，問題會越來越突出；PON 廣播域過大的排查和網絡優化方法V1.0 內部公開 第 5 頁 共 11 頁52廣播風暴的產生和危害廣播風暴的產生和危害2.1廣播域的

4、概念廣播是一種信息的傳播方式，指網絡中的某一設備同時向網絡中所有的其它設備發送數據，這個數據所能廣播到的范圍即為廣播域(Broadcast Domain)；通常在二層網絡中每個VLAN 都是一個廣播域；2.2廣播風暴的產生廣播風暴（broadcast storm）簡單的講是指當廣播數據充斥網絡無法處理，并占用大量網絡帶寬，導致網絡性能下降，正常業務不能運行，甚至徹底癱瘓，這就發生了“廣播風暴”。廣播風暴的表現特征：如果廣電用戶的寬帶和互動點播業務突然出現大面積的短時間中斷、寬帶測速帶寬嚴重不達標、ping 寬帶撥號獲取到的網關或 ping 機頂盒的網關時延過大（達到幾十、幾百毫秒）甚至 pin

5、g 的過程中嚴重丟包；可能產生的原因主要包含兩大類：一是由于網絡拓撲的規劃和設計不合理導致廣播域過大，二是物理連接錯誤或者配置錯誤導致執行二層環路；2.3二層環路的危害1、 MAC 地址表不穩定（MAC 地址漂移） ；還是主機 X 發送數據幀給路由器 Y，路由器的 MAC 地址表還沒有被交換機學習到，數據幀沿鏈路發送到交換 A 和交換機 B 的端口 0,那么交換機 A 和交換機 B 都將主機 X 的 MAC地址記錄在 port0。因為是通過 port0 收到的數據幀，所以會通過兩個交換機的 port1 向外泛洪，交叉來到相互交換機的 port1 口，又認為主機 X 的 MAC 地址所對應的端口

6、是port1,即從交換機 A 發出來的數據幀來到了交換機 B 的 port1 端口。然后交換機 B 收到后又通過 Port0 口再次泛洪，依次類推，數據幀在環路里重復執行上述過程，交換機 A 和交換機 B 重復的在 port1 以及 port0 上不斷的學習主機 X 的 MAC 地址，造成 MAC 地址表的不穩定。2、 數據幀被多重復制；主機 X 準備發一個單播幀給路由器 Y，數據報發出后，發現有兩條路可以到達路由器Y，一個是直接發過去，還有一條就是通過交換機 A 轉給交換機 B，然后再交給路由器 Y，此時路由器 Y 就收到了兩位一模一樣的數據幀。PON 廣播域過大的排查和網絡優化方法V1.0

7、 內部公開 第 6 頁 共 11 頁63、 廣播風暴；二層數據幀的格式中，沒有類似于三層 IP 報頭中 TTL 機制，所以數據幀在網絡中將被無限次數的傳遞，從面造成了廣播風暴，如果是單播的數據還要好一些，如果是廣播或者組播數據在這樣一個環路網絡中傳遞則廣播風暴更加明顯綜上所述，由于 PON 接入網的設備都是二層設備，數據幀的轉發原理和特點和交換機是相同的。2.4ONU 的幾種環路以及檢測機制ONU 使用私有協議 0 x0898 以廣播方式發送環路檢測報文，檢測報文中攜帶以下幾種信息，并作為幾種環路的判斷依據：源 MAC 為 CPU 的 MAC、交換端口 ID 等； PON 廣播域過大的排查和網

8、絡優化方法V1.0 內部公開 第 7 頁 共 11 頁72.4.1端口自環端口自環當 ONU 的某個 UNI 口收到的環路檢測報文中，源源 MAC 是自己的是自己的 CPU MAC 且報文且報文中的端口中的端口 ID 等于自己的端口等于自己的端口 ID，那么就判斷為端口自環并 down 掉此端口；OLT三三層層交交換換機機InternetPOSONU接入交換機2.4.2端口內環端口內環當 ONU 的某個 UNI 口收到的環路檢測報文中，源源 MAC 是自己的是自己的 CPU MAC 但報文但報文中的端口中的端口 ID 不等于自己的端口不等于自己的端口 ID，那么就判斷為端口內環，并 down

9、掉端口 ID 最小的端口；OLT三三層層交交換換機機InternetPOSONU2.4.3ONU 外環外環當 ONU 的某個 UNI 口收到的環路檢測報文中，源源 MAC 不是自己的不是自己的 CPU MAC 那么PON 廣播域過大的排查和網絡優化方法V1.0 內部公開 第 8 頁 共 11 頁8就判斷為端口外環，并 down 掉兩臺 ONU 中那個端口 ID 最小的端口；OLTOLT三三層層交交換換機機InternetPOSPOSONUONUONUor3 3廣播風暴的定位廣播風暴的定位3.1了解全網拓撲、VLAN 規劃以及用戶規模根據目前我司對各地廣電客戶的了解，很少有廣電客戶能基于用戶細分

10、業務 VLAN，更多的是基于 PON、基于整臺 OLT 劃分 VLAN，甚至還存在基于機房劃分 VLAN；如安徽蚌埠廣電同一機房的不同 OLT 劃分在同一 VLAN 域內，其廣播域的范圍可想而知；通常客戶業務 VLAN 劃分的范圍大小與故障影響程度成正比關系；在巡檢過程中或遇到實際故障時，首先要獲取客戶的全網拓撲，了解我司 OLT 的上層網絡如何規劃的；還要了解每種業務的用戶數量，單臺 OLT 用戶數量最多能達到多少，根據用戶數量已經上層拓撲我們可以估算出廣播域有多大，廣播流量有多大，那種一旦出故障的影響范圍也可相應推斷得出；如果在巡檢時客戶反饋網絡處于建設初期，用戶數量較少，但是經了解發現其

11、 VLAN規劃不合理，廣播域過大；我們要計算推斷當用戶數量發展到何種規模時是會觸發廣播域的問題，提早告知用戶，警示其潛在的風險；同樣在巡檢或處理故障時，可通過巡檢工具以及網管告警，將客戶網絡存在的其他問題一網掃盡，全部展示給客戶，今早發現問題盡早解決問題；3.2流量統計排查自下而上的分別排查 ONU 的上聯口、OLT 的 PON 口、OLT 上聯口的流量統計，我司PON 產品支持流量統計分類，分為單播、組播、廣播三類流量單獨統計；通過命令查看上述幾個節點的廣播流量如果增長非常快，如每秒幾百個或者上千個數據包，那么可以進一步的印證產生了廣播風暴；3.3排查環路環路導致的廣播風暴，在環路解除之前網

12、絡中的廣播風暴會一直持續下去；如果環路發生在 OLT 的上聯網絡（包括因上聯交換機未做端口隔離來自其他 OLT 的環路） ，此時可以根據某個特定業務中斷的 PC 或機頂盒 MAC 在 OLT 上反復 trace 或 search；會發現特定的 MAC 會不固定的漂移到上聯口或者 PON 側端口；RAISECOM(fttx)#trace mac-address 006B.8E1E.E413PON 廣播域過大的排查和網絡優化方法V1.0 內部公開 第 9 頁 共 11 頁91.Tracing OLT :Find specified MAC from PON 1/1,dynamic2.Tracing

13、 PON 1/1 :Find specified MAC from ONU 17,dynamic3.Tracing ONU 1/1/17 :Find specified MAC from UNI 3,dynamicRAISECOM #search mac-address 006B.8E1E.E413Mac Address Port vp Vlan Flags -006B.8E1E.E413 1 0 807 Hit如果環路發生在 ONU 側，由于 ONU 默認檢測到環路會立即 down 掉發生環路端口，那么廣播風暴能夠很快的消失；但是人為關閉 ONU 的環路檢測功能，一旦 ONU 側發生了環路那

14、么廣播風暴就會洪范到上層網絡；所以排查環路時還要確認下所有 ONU 的環路配置以及是否有環路記錄；1.x 命令：RAISECOM#show interface onu loopback-port PORT ID State/Time Source Port-1/3/14/4 down/infinite 12.x 命令RAISECOM#show epon-onu loopback-port PORT ID State/Time Source Port-2/2/1/1 down/infinite 13.4抓包排查在巡檢或處理故障時，最直接有效的定位廣播風暴問題就是抓包，通過抓包不僅能發現廣播風暴問

15、題還能直中要害找到故障根源；當處理故障時如網絡中有異常的主機發送大量的廣播報文可能會表現為偶爾網絡中斷偶爾恢復正常的狀態；此時抓包必須在出現故障時刻抓包才能抓到最有價值的信息。如在出差巡檢期間，為了發現廣播風暴問題，需要挑選業務容量最多的 OLT 在業務高峰期如晚上的 18 點至 21 點之間進行抓包；如果條件允許請同時鏡像抓取 ONU 上聯口的數據包和 OLT 上聯口的數據包；如下圖：OLT三三層層交交換換機機InternetPOSONUGEPC 1PC 2UplinkSet Top BoxSet Top BoxPON 廣播域過大的排查和網絡優化方法V1.0 內部公開 第 10 頁 共 11

16、 頁10以江蘇大豐廣電寬帶業務頻繁中斷的故障為例進行抓包分析：1、在等待故障復現時，同步 ONU 下掛 PC 寬帶撥號上網后一直進行 ping 上聯網關；出現故障時 PC 也出現 ping 不通網關，在抓包中過濾出 ARP 和 ICMP 報文，找到 PC ping網關不通的時間節點，可以在報文中明顯看到在抓包開始后的 145.43 秒這個時間點業務就完全不通的，剩下的全是 ARP 報文。在抓包中顯示大量的 ARP 報文的主要來自兩個主機，其中一個 MAC 地址為：00:0E:C6:C0:5F:FF，在 OLT 上追蹤 MAC 確認來自上聯網絡，進一步在匯聚交換機找到目的主機為 EOC 廠家的兩

17、臺網管服務器。隨后從路通 EOC 廠家方面得到印證他們的網管服務器為了探測 EOC 局端會周期性做對整個子網做 ARP 掃描，在故障瞬時突發 ARP 報文達到每秒近 2k 個 arp；在 5508A 上不升級版本，不改變其他配置，只是把發 arp 掃描的兩個網管服務器 MAC 過濾掉后觀察數個小時一直未再出故障； 如下圖：紅色曲線是 ARP 流量，黑色是總流量，在抓包開始的 120s 左右突然出現瞬時 ARP 流量峰值，近 2000 個包/SPON 廣播域過大的排查和網絡優化方法V1.0 內部公開 第 11 頁 共 11 頁11 4廣播風暴的優化措施廣播風暴的優化措施1、 首先細分業務 VLAN，在 OLT 上至少保證每 PON 口每業務 VLAN,最理想的情況下采用靈活 QINQ 的方式達到 PSPUPV(每業務每用戶每 VLAN)的效果；2、 打開匯聚交換機的端口隔離、不隨意關閉 PON 口隔離、不隨意關閉 ONU 之間的 P2P隔離；3、 OLT 全局不創建無用業務 VLAN，OLT 的每個 PON 只讓實際存在業務的 VLAN 通過；ONU上聯口修改為 trunk 模式并只讓 ONU 下面實際存在的業務 VL