如何診治IP網絡故障
IP網絡故障定位的復雜程度，非一般運維人員所能掌握。如何讓運維人員追本溯源，了解IP故障發生的機理，掌握從現象到定位的過程，并順利排障？
IP網絡故障管理難表現為兩點：***，告警數量多，甚至是泛濫，每天告警工單數量很多，但一些告警定位后，又不需要作任何恢復動作，維護人員不堪重負。第二，故障發生卻無任何告警，只能摸索排查，定位耗時長，非常依賴人的經驗。這兩種現象給故障管理工作帶來非常大的困擾，本文將深入診斷其發生的根源，并給出相應的治理辦法。
溯源
故障告警多
告警數量多的根源與IP網絡兩個特點相關，***個特點是網絡層次多，例如一個VLL(Virtual Leased Line)業務在IP網絡上承載，要經過物理層、鏈路層、路由協議、MPLS、VLL等多層次處理，若某條物理光纖發生中斷，那么物理層、鏈路層、IP傳輸層、VLL管道層將全部受到影響，這些層次也將全部發送TRAP。第二個特點是協議關聯多，一般物理光纖的故障將引起路由協議的收斂，再引起MPLS LDP等協議的變化，這個過程中必然要發送大量的TRAP。
無告警
無告警的問題相對復雜。我們先回顧一下故障的定義，故障是產品或產品的一部分不能或將不能完成預期功能的事件或狀態，簡單地說，就是現狀不符合預期。反之，如果沒有“預期”，則不會有“故障”。實際上，正是IP網絡上的預期無法清晰定義，才導致了“無告警”現象的發生。我們從控制平面和轉發平面的原理出發，追溯無告警發生的根源。
控制平面決定源到目的地的業務路徑。在傳統的電路網絡上，管理員靜態指定主備路徑，每個業務的下一跳非主即備，預期非常清晰。而在IP網絡上，路由協議根據網絡實際情況選擇***路徑，單個路由器只知下一跳，并不掌握業務路徑。因此，當鏈路中斷產生路由收斂或者路徑計算錯誤，導致路徑發生變化時，路由器無法告警業務路徑切換。
有這樣一個網上問題：NGN語音業務中斷40多分鐘而IP承載網無任何告警，排查中發現是LSP路徑計算錯誤，其結果與ISIS路徑不一致而導致業務中斷。在這個案例里，建立LSP的協議并不掌握路徑預期，因此無法發現LSP路徑計算錯誤，也就無法發出告警通知路徑錯誤。
在轉發平面上，IP網絡不是同步網絡，其轉發機制無法定義預期，比如，業務報文要經過路由器A、B順序轉發，但是B完全不知道A是否有報文會送到，有報文送到是正常，沒有也是正常，因此當A路由器故障無法轉發報文時，B無法告警。
此類故障最常見的情況是路由器間的光纖劣化，光纖上發生了丟包，但路由器上無告警。對于這類故障的排查需要花費大量的時間，需要按照承載網的轉發路徑，逐個路由器、逐條鏈路去排查，最終才能發現是光纖故障導致丟包。
厘清IP網絡故障管理難的根源后，排障的思路和措施就比較明確了，下文將給出對告警多和無告警故障的解決之道。
排障
突出根源告警
前文提到，告警數量多的根源在于層次多、關聯多，底層故障衍生出大量高層告警。如果我們能夠突出根源告警，忽略或者抑制衍生告警，就不需要針對無效告警派單處理，從而減少工作量。
從網上問題庫中統計發現，IP網絡的故障根源大部分來自于硬件、鏈路的劣化。尤其是網絡中的鏈路，如光纖、微波等，容易受到環境影響，從而導致接口閃斷。接口反復UP/DOWN，將引發大量接口的告警，同時又引起IGP協議收斂，引發IGP反復告警，進而引發LSP的反復告警。即鏈路的告警將衍生出大量的協議告警。
針對以上情況，本文提出兩種告警優化的思路：***，在告警監控中，將告警歸類為環境、硬件、軟件、接口、鏈路管道、協議和業務等幾個類別，環境、硬件類告警的處理優先級大于協議、業務類告警。高級別告警處理恢復后，其衍生的低級別協議告警會自動恢復。這種方法簡單實用，可短期見效。第二，建設告警相關性系統，按協議、業務運行關系定義告警的衍生關系。在告警監控系統上，將衍生告警掛接在根源告警上顯示，管理員直接處理根源告警，這種方法可以比較完善地解決告警多的問題，但建設困難且周期較長。
解決“無告警故障”的關鍵在于預期和現狀的對比，我們仍從控制平面和轉發平面分別闡述。
路徑預期和檢測
盡管IP的控制平面采用了動態協議，但其運行的基礎仍然是物理鏈路和SPF(Shortest Path First)算法，鏈路規劃越簡單，路徑預期就越清晰。如在大部分的中小型城域網設計中，網絡層次少，層次之間采用主備雙鏈路進行保護，路徑非主即備。對于這種網絡，只要維護好網絡拓撲圖，就可以滿足故障處理的需要。
對于大型、復雜的網絡，管理員通過物理鏈路的分布，已無法快速識別業務路徑。在這種情況下，需要采用仿真計算的方式，將網絡上的配置、拓撲等集中到仿真軟件中，計算出業務的預期路徑。
預期建立之后，采用OSS軟件定期獲取路徑的現狀并與預期對比的方式，若不一致即發送告警，并提示管理員網絡發生了故障。中小型、簡單網絡可以采用TraceRt獲取路徑。大型、復雜網絡一般都會存在ECMP(Equal-Cost MultiPath等價多路徑)，此類情況一般可以綜合TraceRt、轉發表查詢等方式來詳細判斷業務流的路徑。另一種方式是通過分析IGP的泛洪報文，掌握路徑建立的詳細過程，根據路由算法和配置來掌握轉發路徑。
轉發預期和檢測
在轉發平面上，預期的建立和檢測非常密切，按照實現方式的不同，可以分為三種情況：非業務隨路檢測、業務隨路檢測和業務分析。
***種是非業務隨路檢測。簡單地說，就是自行定義預期，在網絡上注入OAM檢測報文。由于接收方已預先掌握了檢測報文的大小、時間間隔等特征，當收到的報文不符合自行定義的預期特征時，即是發生故障。
這種方式的優點是容易獲取和實施，網絡各層面均有OAM檢測協議可以使用，如BFD、EthOAM、ICMP Ping、MPLS OAM等，缺點是OAM檢測報文特征與業務流量特征不完全一致，可能會出現檢測未發現問題，但實際業務卻發生了問題的情況。
第二種方式是業務隨路檢測，直接對業務流進行度量，典型代表是ITU-T Y.1731標準中定義的丟包統計功能，其原理簡單地說就是“包守恒”，體現在以下的公式：
接收報文數量＝發送報文數量
具體實現上，發送方和接受方都對業務流進行計數統計，發送方定時將計數發送到接收方，由接收方進行核對，核對出錯即是故障發生。
第三種是業務分析。這種方式度量業務數據，并和預定義的標準閾值進行對比，如針對IPTV業務，采用專用硬件掛接在設備端口上，直接度量網絡上IPTV流量的vMOS值等業務指標。這種方式需要采用DPI等方式，對實際業務報文進行采樣統計或深度解析，按照業務已經定義的預期，分析其是否出現問題。該方式的優點是真實，缺點是設備部署和維護的成本高。
這三種方式不是非此即彼的關系，需要根據業務SLA目標，綜合采購、維護成本等因素進行考慮和選擇。
【編輯推薦】
