城域網與IPRAN對接異常流量問題案例

夏煒煒　肖安

摘 要 本文主要是中國聯通合肥分公司廬江縣分利用現有的IP城域網與廬江縣分的IPRAN系統對接，上聯廬江縣鄉鎮的OLT設備。對接開通后由于OLT設備接入用戶的MAC地址數量很大導致IPRAN設備與城域網交換機對接端口存在不明的異常流量。維護人員分別從實地測試、理論分析、網絡規劃、配置優化整等角度入手，最終成功的解決異常流量問題。

關鍵詞 IPRAN OLT IP城域網 ARP廣播 二層VPN VPLS

中圖分類號：TN914 文獻標識碼：A

1故障現象

2017年1月底，廬江一VPLS模型下所有的OLT收到IPRAN傳輸側發送大量的冗余流量，高峰時冗余流量近300～400M，且各站點發生在同一時段，并隨著業務量的變化而變化，實際各OLT（下掛寬帶業務）用戶量并不大，傳輸側接收普遍才幾兆（此為實際流量），因此大量的冗余流量擠占OLT帶寬資源，高峰時候約站占其帶寬80～90%，同時大量冗余流量也對IPRAN環網的線路寬帶造成一定程度擁塞，造成隱患，因此需要查出此流量源頭并解決。

2網絡結構（見圖1）

3故障處理過程

3.1接到故障申告后，我方立即配合排查，首先排查該E-TREE上傳輸設備發送與接收流量，經查確實存在IPRAN收發流量嚴重不對稱現象，IPRAN上發送流量遠大于接收流量（如圖1所示），其余葉節點也是如此。

3.2排查該VPLS模型中各葉節點的MAC地址容量是否配置規范，經排查配置正常，其中IPRAN設備MAC地址容量為1024，640設備MAC地址容量255符合要求。

3.3因各葉節點流量在同一時段達到峰值，懷疑該VPLS組內存在環路情況，于是仔細檢查數據配置未發現數據配置方面存在環回，現場人員也未發現有物理連接存在環路現象。

3.4為了查出異常流量源頭，局方申請夜間割接排障工單，依次做如下操作進行測試。

（1）當晚依次在傳輸側對該VPLS組各葉節點的激光器進行關閉，此時OLT專業收到不我們的發送流量，但是查詢IPRAN各葉節點仍有大量的發送流量，未查明原因。

（2）OLT側工程師在其網管上對該VPLS組各成員端口關閉（僅留下一個測試），傳輸側發現各節點還是存在較大的發送流量，且隨著業務量的增加其余站點流量同步增加，感覺流量被復制一番，最終排查未果。

3.5為了徹底查出流量源頭，在用戶的配合下去現場（廬江白湖）抓包，通過鏡像端口抓包，根據抓包結果分析報文，經研發及局方相關專業人員分析得知白湖640站點下行發送至OLT的報文中有其它各節點OLT下的用戶IP地址，因此證實了我們之前的判斷，即各節點的流量存在廣播復制，和故障現象吻合。由于該VPLS組葉節點過多（27條），我司研發人員建議將現網中心局（廬江營業廳匯聚）的MAC地址容量由1024改成65535，更改完成后，查看網管發送流量與接收流量基本一致，至此，問題得到解決（見圖3）。

4故障原因分析

因現網采用E-TREE模型，E-TREE模型屬于VPLS的一種，VPLS的原理就是以MAC尋址轉發的二層VPN技術，現網E-TREE中心局MAC地址容量為默認值1024，由于其葉節點過多，現網的實際用戶數量遠大于此值，導致大量用戶MAC未學習到，從而產生了異常流量廣播，造成流量擁塞，將此值更改為等于或超過實際用戶數量的數值時此問題即可解決。

5規避方案

根據現網實際用戶數量，合理部署MAC地址容量，規避此問題。當MAC地址多余65536的最大承載量時可以拆分IPRAN與城域網的對接端口。

參考文獻

[1] TCP/IP詳解[M].機械工業出版社

[2] MPLS/VPN 網絡架構[M].人民郵電出版社

[3] 陳雪非，黃河.MPLS VPN關鍵技術研究[J].李蓬.計算機工程與設計.endprint