OSPF故障排查总结.docx
OSPF故障排查总结OSPF故障排查总结 我们都知道OSPF邻居建立过程一般有7个步骤(当然这里忽略了down的状态),每一步在邻居协商的时候都在做不同的事情。如果在邻居建立过程，卡在中间某一步不往下面继续协商，那一定说明了有问题存在。下面就是总结了停滞在每一步可能遇到的问题。 首先来看看OSPF问题处理的流程和思路： 关于OSPF邻居的各个状态要处理的事情，这里还是再来做一个澄清： Down：这是OSPF建立交互关系的初始化状态，表示在一定时间之内没有接收到从某一相邻路由器发送来的信息。在非广播性的网络环境内，OSPF路由器还可能对处于Down状态的路由器发送Hello数据包。 Attempt：该状态仅在NBMA环境，例如帧中继、X.25或ATM环境中有效，表示在一定时间内没有接收到某一相邻路由器的信息，但是OSPF路由器仍必须通过以一个较低的频率向该相邻路由器发送Hello数据包来保持联系。 Init：在该状态时，OSPF路由器已经接收到相邻路由器发送来的Hello数据包，但自身的IP地址并没有出现在该Hello数据包内，也就是说，双方的双向通信还没有建立起来。 2-Way：这个状态可以说是建立交互方式真正的开始步骤。在这个状态，路由器看到自身已经处于相邻路由器的Hello数据包内，双向通信已经建立。指定路由器及备份指定路由器的选择正是在这个状态完成的。在这个状态，OSPF路由器还可以根据其中的一个路由器是否指定路由器或是根据链路是否点对点或虚拟链路来决定是否建立交互关系。 Exstart：这个状态是建立交互状态的第一个步骤。在这个状态，路由器要决定用于数据交换的初始的数据库描述数据包的序列号，以保证路由器得到的永远是最新的链路状态信息。同时，在这个状态路由器还必须决定路由器之间的主备关系，处于主控地位的路由器会向处于备份地位的路由器请求链路状态信息。 Exchange：在这个状态，路由器向相邻的OSPF路由器发送数据库描述数据包来交换链路状态信息，每一个数据包都有一个数据包序列号。在这个状态，路由器还有可能向相邻路由器发送链路状态请求数据包来请求其相应数据。从这个状态开始，我们说OSPF处于Flood状态。 Loading：在loading状态，OSPF路由器会就其发现的相邻路由器的新的链路状态数据及自身的已经过期的数据向相邻路由器提出请求，并等待相邻路由器的回答。 Full：这是两个OSPF路由器建立交互关系的最后一个状态，在这时，建立起交互关系的路由器之间已经完成了数据库同步的工作，它们的链路状态数据库已经一致。 前面是说明OSPF邻居在各种不同的状态所要处理的事情，那么如果当邻居的状态老是停留在某一个状态而一直不能转换到下一个状态的时候，那么这个时候就有必要进行一次故障排查了。 OSPF邻居状态停滞在INIT阶段： 可能是其中的某一段用ACL访问列表阻止了OSPF hello 分组. 组播功能在某一边不能正常传输。 邻居验证通不过。 在broadcast network不论是DR,BDR,DRother,大家发送hello packet的时候目标地址都是AllSPFRouter(224.0.0.5),这也就是为什么需要查看hello报文是否能双向传输的关键是组播。或者是否是ACL将224.0.0.5的组播地址给deny掉了。 OSPF邻居状态停滞在2-Way阶段： 查看是否两边的路由器接口下面都配置了命令：Router(config-if-fastethernet0)#ip ospf priority 0 这里涉及到一个知识点，我们都知道，在广播网络中，需要进行选举DR或者BDR,那么选举的原则就是: 当选举DR/BDR的时候要比较hello包中的优先级#ip ospf cost priority 0255），优先级最高的为DR，次高的为BDR.不作修改默认端口上的优先级都为1，在优先级相同的情况下比较Router ID，RID最高者为DR，次高者为BDR，当你把相应端口优先级设为0时，OSPF路由器将不能再成为DR/BDR，只能为DROTHER. 而关键的问题就在于在广播网络中，必须要选举DR和BDR.如果DR和BDR产生不了，自然就会停留在该阶段. 下面有一些关于debug时候得到的信息可以作为参考： *Sep 6 20:07:20.755: OSPF: Neighbor change Event on interface FastEthernet0/0 *Sep 6 20:07:20.759: OSPF: DR/BDR election on FastEthernet0/0 *Sep 6 20:07:20.759: OSPF: Elect BDR 0.0.0.0 *Sep 6 20:07:20.759: OSPF: Elect DR 0.0.0.0 *Sep 6 20:07:20.763: DR: none BDR: none *Sep 6 20:07:20.791: OSPF: Interface FastEthernet0/0 going Up *Sep 6 20:07:20.791: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 12.1.1.1 *Sep 6 20:07:21.251: OSPF: Build router LSA for area 0, router ID 12.1.1.1, seq 0x80000001 *Sep 6 20:07:22.307: OSPF: Rcv hello from 23.1.1.2 area 0 from FastEthernet0/0 12.1.1.2 *Sep 6 20:07:22.311: OSPF: 2 Way Communication to 23.1.1.2 on FastEthernet0/0, state 2WAY *Sep 6 20:07:22.311: OSPF: End of hello processing OSPF邻居停滞在Exstart或者是Exchange状态： 不匹配的接口MTU. 这个问题很多时候都会爆发出来，两边接口的MTU不匹配会造成邻居不能full起来。因为在这两个阶段，RFC定义的有一项必要的工作就是比较两边的MTU是否匹配。如果不匹配就不能进入到下面的环节. 要解决这个问题，可以在两边都设置一样的接口MTU,或者在两边的接口下面配置忽略接口MTU： Router(config-if-fastethernet0)#ip ospf mtu-ignore 在邻居路由器上有重复的Router-ID. 不能用超过一定大小的MTU去ping通对端.-该问题多出现在链路上面。 单播不能双向通讯。 在PRI/BRI拨号接口之间的网络类型为P2P网络类型. OSPF邻居停滞在Loading状态： 还是MTU的问题，同上.
