如何诊治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)算法，链路规划越简单，路径预期就越清晰。如在大部分的中小型城域网设计中，网络层次少，层次之间采用主备双链路进行保护，路径非主即备。对于这种网络，只要维护好网络拓扑图，就可以满足故障处理的需要。

对于大型、复杂的网络，管理员通过物理链路的分布，已无法快