如何诊治IP网络故障[1]

  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网络故障管理难的根源后，排障的思路和措施就比较明确了，下文将给出华为针对告警多和无告警故障的解决之道。

[1]  [2]  [3]