王 凱彭 忠
1.內蒙古廣播電視網絡集團有限公司 內蒙古 呼和浩特市010010
2.內蒙古廣播電視網絡集團有限公司烏達分公司 內蒙古 烏海市016000
內蒙古廣播電視網絡集團有限公司(以下簡稱內蒙古廣電網絡)從2015年開始實施FTTH(Fiber To The Home光纖到戶)試點工程至今,形成了一張覆蓋全區盟市、旗縣、鄉蘇木、村嘎查,規模上百萬戶的數據寬帶網絡。隨著網絡建設和用戶規模的快速發展,日常故障種類和數量也不斷增多,一些類型的故障避免不了處理起來較為棘手。本文著重從比較常見、但處理起來比較困難的數據鏈路層典型故障案例進行分析,并提出相應的建議。
說到數據鏈路層,首先需要了解OSI(Open System Interconnect開放系統互連參考模型)。OSI是ISO組織在1985年定義的網絡互連模型,該標準定義了網絡互連需要用到的七層模型框架,即由底層到高層依次分別為:物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層以及應用層。每一層采用協議描述的形式來實現相應層級的功能,不同層級采用不同的協議實現不同實體相同層級的信息表達,下一層級服務于上一層級。在數據寬帶業務中,由于英特網的訪問一般需要用到網絡層以上的層級,所以數據鏈路層就成為必不可少的報文流層級。如圖1所示。
數據鏈路層由MAC(介質訪問控制子層)和LLC(邏輯鏈路控制子層)構成,接受物理層的服務并服務于網絡層,通過控制MAC地址轉發來實現不同實體在數據鏈路層的信息交互。

圖1 OSI七層模型

圖2 PON網絡結構圖
利用光纖信號傳遞過程中的能量衰耗小、速率高、不易干擾、無源靈活性高等諸多優點,FTTH成為目前最為廣泛的有線接入方式,而PON(Passive Optical Network無源光網絡)則依靠低成本、高帶寬、擴展性強、與現有以太網兼容、方便管理等優點成為FTTH有線寬帶數據業務場景中的主流數據通道接入技術。PON按照網絡分配層級分為:OLT(Optical Line Terminal光線路終端)、Splitter(分路器)、ONU/ONT(Optical Network Unit光網絡單元/Optical Network Terminal光網絡終端)三個部分。按照不同標準協議運營商一般采用EPON(Ethernet Passive Optical Network以太網無源光網絡)或者GPON(Gigabit-Capable Passive Optical Network千兆無源光網絡)的形式來實現FTTH接入。目前內蒙古廣電網絡主要采用EPON方式來實現從前端到用戶家的光配線網接入。如圖2所示。
正是因為PON設備以太網兼容這一特性,完成了以太網數據流從運營前端到用戶終端的傳輸:PON系統將從上連設備接收到的下行方向以太網數據,封裝為PON協議后,采用廣播方式經由局端的OLT設備將IP數據、語音、視頻等多種業務通過分配網絡中的無源分光器分配到所有ONU終端,在ONU終端完成PON協議解封裝后,將以太網數據送給用戶;在上行方向,通過分配網中的無源分光器將來自各個ONU反向封裝的信息采用TDMA方式耦合到同一根光纖,傳送到位于局端OLT接收端口,再由OLT還原為以太網數據。
上述網絡中,網絡設計思路是從用戶側發起的以太網數據流通過ONU、OLT、接入交換機、匯聚交換機形成的數據鏈路層通道將以太網數據流送給BRAS。BRAS將用戶撥號請求通過網絡層經由骨干路由器轉發到鑒權中心通過鑒權認證后,BRAS設備充當網絡層業務網關的角色完成DHCP動態地址分發以及向網絡層側路由器進行以太網數據流轉發,直到互聯網平臺。網絡結構示意圖如圖3所示。
某地市反饋在所屬中心機房的若干臺FTTH前端設備中的一臺設備覆蓋用戶中出現用戶寬帶故障,圖3中虛線框內的部分是本次故障出現的示意范圍,現象如下:
現象1:用戶終端采用PPPOE撥號過程用時較長,而且多次撥號后依然無法鑒權通過。
現象2:用戶終端采用PPPOE撥號過程用時較長,而且多次撥號后才能完成與后臺鑒權系統的關系建立。

圖3 網絡結構示意圖
現象3:顯示用戶終端撥號成功,在使用互聯網過程中存在“掉線”,即上網中斷,用戶終端重新發起撥號請求,回到現象1或者現象2。
現象4:顯示用戶撥號成功,但無法使用互聯網或者使用互聯網過程中存在“卡頓”,上網體驗感不好。
在了解以上現象后,通過對網絡結構的梳理,分析問題,下面列出本次故障處理采用的處理步驟:
步驟1:由下到上檢查故障用戶終端ONU、前端OLT設備以及本臺OLT設備上聯的接入交換機設備的接口光功率指標、設備運行日志,查看物理層鏈路的狀態是否正常。
理由:故障現象只發生在單臺OLT前端設備覆蓋范圍內,優先考慮物理層鏈路以及設備狀態是否穩定有異常,在日常故障處理中物理層鏈路占比較大,須優先考慮鏈路情況。
結果:用戶終端ONU、OLT前端設備、接入交換機光功率在正常閾值范圍,OLT前端設備、接入交換機無異常行為報錯,終端ONU斷電重啟以及替換測試后均故障復現,初步排除物理層鏈路異常以及設備運行異常的情況。
步驟2:根據故障用戶終端的MAC地址,查看OLT前端設備、接入交換機、匯聚交換機的MAC地址表項中有無異常。
理由:故障現象著重發生在撥號過程中,PPPOE撥號報文的成功建立需要進行兩次協議握手,協議需要在以太網廣播域中進行傳播,廣播域傳播過程需要借助數據鏈路層來實現,而觀測用戶撥號終端MAC地址在數據鏈路層中的有效性就會顯得十分必要,有效性可以通過設備MAC地址表項來進行查看,比如觀察表項中MAC地址的老化時間可以對數據鏈路層的穩定性進行初步判斷。
結果:通過對比查看用戶撥號終端MAC地址在OLT前端設備、接入交換機、匯聚交換機中的MAC地址表項,并沒有發現處在這三個節點設備的撥號終端MAC地址有異常,初步判定數據鏈路層穩定。
步驟3:查看BRAS設備上用戶PPPOE撥號狀態,判斷認證過程中有無異常情況。
理由:用戶撥號終端在進行PPPOE撥號過程中,需要與BRAS設備以及后臺鑒權中心進行協議報文交互:用戶終端發出的PPPOE撥號協議報文(兩次握手)通過ONU—OLT—接入交換機—匯聚交換機—BRAS形成的數據鏈路層通道,將攜帶封裝PPPOE協議的撥號請求送入BRAS設備,并由BRAS交由鑒權中心驗證后回復給撥號終端。所以從BRAS設備上可以查看用戶撥號請求是否到達,以進一步驗證數據鏈路通道的有效性。
結果:通過BRAS設備采集信息,發現用戶報送PPPOE撥號請求可以送達BRAS設備,但會有時延。而且從鑒權中心回復撥號終端的信息經由BRAS下發到撥號終端完成一次握手后,沒有收到撥號終端的二次握手信息。在這里會發現一些細節將故障嫌疑指向數據鏈路層,但是并不確定是鑒權中心回復信息用戶終端驗證后丟棄還是鑒權中心下發的參數存在異常。在這個階段終于發現故障的尾巴。
步驟4:查看故障用戶賬號在鑒權中心的詳細信息,判斷鑒權系統中留存賬號與正常賬號有無異常。
理由:根據步驟3得出的初步結論,從難易程度來講,首先從較為容易的第2條路進行驗證,即用戶賬號信息的有效性。從網絡結構上來說,一般情況下,越靠近網絡上層,業務流受到的不確定因素越小;反之,越靠近用戶側,網絡使用環境越復雜,不確定因素隨之就會變多。
結果:通過從鑒權中心后臺采集的用戶賬號信息,發現用戶信息并無異常,為了做到更嚴謹的驗證,從鑒權中心重新對用戶信息進行登記,并使用“刷新”后的賬號信息從用戶撥號終端進行測試,故障依舊,至此故障范圍重新縮小到匯聚交換機—接入交換機—OLT前端設備的數據鏈路層。
步驟5:根據步驟4得出的結論,由下至上詳細梳理數據鏈路層業務流,采集分析設備端口VLAN標簽。
理由:在數據鏈路層中,不同的業務流在以太網廣播域傳播過程中往往是通過VLAN標簽來進行劃分、相互識別并且相互隔離的,而我們日常查看數據鏈路層的“指標”往往只需要關注VLAN廣播范圍和MAC地址表項。在步驟2中我們著重觀察故障用戶撥號終端的MAC地址在數據鏈路層中的情況,需要放大到業務VLAN廣播域這個節點上進行觀察和分析。OLT前端設備中只設置和本設備相關的業務VLAN,所以分析的重點落在接入交換機以及匯聚交換機上面。
結果:通過梳理接入交換機各個端口設置的VLAN信息,發現交換機存在兩個端口帶有一個共同的VLAN標簽,接下來發現這兩個端口對接的業務類型均為OLT前端設備。正常情況下為了避免以太網廣播域過大而導致數據鏈路層故障報文相互影響進而不便于確定用戶側故障源,每臺OLT前端設備會采用不同的VLAN標簽來進行業務在廣播域的區分和隔離,在這里出現兩個交換機端口使用共同的VLAN標簽無疑需要將故障排查范圍擴大到兩臺設備,而通過用戶報障信息僅集中在一臺設備上,所以計劃將兩臺設備共用廣播域的情況進行分離操作,即在不采用更換VLAN標簽的情況下采用端口隔離的方式對這兩個接入交換機端口進行配置更改,而不中斷正在發生的大部分用戶上網行為。操作完成后進行測試及報障用戶回訪,故障現象消失。
面對這類數據鏈路層故障該如何避免?如何優化這類故障導致的運維人力成本和時間成本?進而如何能給用戶提供更好的寬帶使用感受呢?可以從優化網絡結構、減少數據鏈路層規模的方向去嘗試。本案例的核心并不是哪個用戶終端出現了異常情況進而影響到其他OLT前端設備用戶,因為位于用戶側的終端使用環境復雜,無法規范所有用戶的使用行為,處于數據鏈路層的設備層級過多,一旦前端設備接入較多,參數管理起來的難度就會加大,這樣故障只是時間問題,不是概率問題。如果采用前端設備(主要工作在數據鏈路層)直連BRAS(主要工作在網絡層),或者減少交換機(主要工作在數據鏈路層)的級聯,這樣一來從用戶側發出的數據流能夠經歷更少的廣播域就可以到達網絡層網關,這類數據鏈路層的故障就會比較少。
在日常網絡故障分析和處理工作中,由數據鏈路層引發的故障經常會令人頭疼不已,不僅僅是因為想方設法不斷重現故障進行觀察分析是件不容易的事情,更是因為數據鏈路層沒有網絡層路由關系那么相對“直觀”,故障線索往往會比較隱蔽。上述案例最終的正確處理方式看起來比較簡單,但是面對紛繁復雜的故障現象,需要運維人員熟悉網絡的基本原理,更需要耐心。