OSPF故障定位没思路？照这篇抄就行

　　免费领取试听课程材料，私信回复”学习“即可领取”

　　OSPF邻居关系

　　无法建立定位

　　01 确认配置及底层情况是否能转发报文

　　确认配置是否都正确。

　　检查接口是否都UP。

　　两台设备能否ping通？要求带源地址ping直连接口。

　　两端设备MTU是否一致？

　　02 检查报文是否发送接收正常？

　　display ospf cumulative查看收包和发包数量：

　　

　　03 隐藏模式打开

　　隐藏模式打开enableospf-lsa-dbg后。

　　display ospfinterface <接口名>查看接口收包和发包数量(V3R3及以后的版本)。

　　

　　如果长时间处于init，基本上是没有发出hello包或没有收到hello包。

　　如果长时间处于Exstart和Exchange状态，检查ping大包能否ping通？

　　DD报文一般会填满MTU，如1500能填到1492。

　　04 debug逐层排查

　　上述简单检查都OK的话，需要debug来逐层排查了。

　　如果一端处于Init状态，一端没有显示状态，在两端debughello报文：

　　<Quidway>debugging ospf packet hello

　　如果一端处于Exstart状态，一端处于Exchange状态，在两端debugdd报文：

　　<Quidway>debugging ospf packet dd

　　如果一端处于Loading状态，一端处于其它状态，在两端debugrequeset 和update报文。

　　<Quidway>debugging ospf packetrequest

　　<Quidway>debugging ospf packet update

　　除hello以外其他报文可能比较长，建议用brief看报文头部

　　debug ip packet acl IP报文比较多，建议使用acl过滤。

　　02

　　OSPF邻居振荡定位

　　01 邻居振荡日志，关注邻居状态下降的日志

　　查找日志文件，关键字：NBR_CHG_DOWN、NBR_CHG_E(V3R2)、NBR_CHANGE_E(V3R3)。

　　举例：

　　Aug 28 2010 10:27:32 RTA %%01OSPF/3/NBR_CHG_DOWN(l): Neighbor event:neighbor statechanged to Down. (ProcessId=1,NeighborAddress=11.11.11.2, NeighborEvent=KillNbr, NeighborPreviousState=Full, NeighborCurrentState=Down)

　　由于接口DOWN导致主动断开邻居。

　　Aug 28 2010 10:31:29 RTA %%01OSPF/3/NBR_CHG_DOWN(l): Neighbor event:neighbor statechanged to Down. (ProcessId=1,NeighborAddress=11.11.11.2, NeighborEvent=InactivityTimer,NeighborPreviousState=Full,NeighborCurrentState=Down)

　　由于超时导致断开邻居。

　　Aug 28 2010 10:34:51 RTA %%01OSPF/6/NBR_CHANGE_E(l): Neighbor changes event: neighborstatus changed. (ProcessId=1,NeighborAddress=11.11.11.2, NeighborEvent=1-Way,NeighborPreviousState=Full, NeighborCurrentState=Init)

　　对端断开邻居后触发重建，在未收到本端Hello前发送1-way hello，导致本端触发1-way事件。

　　Aug 28 2010 10:38:52 RTA %%01OSPF/6/NBR_CHANGE_E(l): Neighbor changes event: neighborstatus changed. (Process ID=1, Neighbor address=11.11.11.2, Neighbor event=SeqNumberMismatch, Neighbor previous state=Full,Neighbor current state=ExStart)

　　对端断开邻居后触发重建，在收到本端Hello后发送dd报文，导致本端触发SeqNumberMismatch事件。

　　02 最常见的原因：超时断连

　　现网使用中，最常见的OSPF邻居振荡的原因是超时断连。

　　也就是说，OSPF在dead timer间隔内没有收到一个Hello报文，出现该情况有如下可能性：

　　1、有丢包现象，导致OSPF hello报文无法上送；

　　2、CPU高，导致路由任务无法获得调度，报文无法发送和接受。

　　因此，出现超时断连的现象，除了要查看日志、诊断日志外，还需要查看底层丢包计数。

　　另外，在现网中，经常有用户提出疑问，为什么只有邻居DOWN的日志，没有邻居UP的日志？

　　首先明确，邻居DOWN和UP都是记录日志的，但一般巡检或用户查看的时候都是displaylogbuffer查看。

　　Aug 28 2010 10:31:29 RTA %%01OSPF/3/NBR_CHG_DOWN(l):Neighbor event:neighbor state changed to Down. (ProcessId=1, NeighborAddress=11.11.11.2, NeighborEvent=InactivityTimer,NeighborPreviousState=Full, NeighborCurrentState=Down)

　　OSPF邻居Down的日志级别比较高是Error级别的，在logbuffer中记录。

　　Aug 28 2010 10:33:41 RTA %%01OSPF/6/NBR_CHANGE_E(l):Neighbor changes event: neighbor status changed. (ProcessId=1,NeighborAddress=11.11.11.2, NeighborEvent=HelloReceived,NeighborPreviousState=Down, NeighborCurrentState=Init)

　　OSPF邻居状态改变日志级别是Info级别的，在日志中有记录，但不会记录在logbuffer中。

　　logbuffer中的日志并不是全部的日志，logbuffer设计的初衷就是使用户便于查看用户关注的信息。

　　在不对其配置的默认情况下，logbuffer中记录的使warning（4）级别 以及以上的日志信息。

　　可以使用该命令查看对logbuffer的设置情况。

　　<Quidway>display channel

　　…

　　channel number:4, channel name:logbuffer

　　MODU_ID NAME ENABLE LOG_LEVEL ENABLE TRAP_LEVEL ENABLE DEBUG_LEVEL

　　ffff0000 default Y warning N debugging N debugging

　　03

　　OSPF Router ID

　　冲突故障定位

　　现网中时常会出现OSPFRouter ID配置冲突的问题。

　　由于Router ID是标识OSPF设备的重要依据，一旦冲突会导致OSPF的LSA频繁的老化和产生，进而导致网络不稳定。

　　01 区域内Router id冲突判断方法

　　如下拓扑：

　　

　　RTA、RTB和RTC、RTD在区域0建立OSPF邻居关系，RTA和RTC的router id都是1.1.1.1，发生了冲突。

　　判断方法：

　　1、在任意一台路由器上每隔一秒输入display ospf lsdb，查看是否有Router LSA的Age字段频繁变化，同时查看Sequence字段是否增加的很快。

　　

　　上例中router id为1.1.1.1的Router LSA Age频繁变化，Sequenc增加得也很快。

　　每隔一秒在RTB上输入display ospf routing，可以看到有路由在振荡，如果区域内路由频繁振荡，在没有邻居振荡的情况下，可以判断为RouterID冲突。

　　

　　02 区域间RouterID冲突判断方法

　　有如下拓扑：

　　

　　如上图所示，其中RTA和RTC的Router ID是冲突的，但RTA和RTC不在同一个区域。

　　判断方法：

　　在任意一台路由器上每隔一秒输入display ospf lsdb。

　　如果发现大量的AS External LSA频繁刷新，且都来自于某一台路由器，可以初步推测出不同区域的Router ID存在冲突。

　　

　　总的来说，在现网中，RouterID配置冲突的现象时有发生。

　　如果掌握了一些常用的判断方法，可以比较方便的找到问题的原因，然后逐个排查，找出冲突的RouterID。

　　解决办法：

　　更改冲突的RouterID后通过reset ospf process可以修正该配置错误。(需要注意的是，reset ospf process会导致邻居重新建立，业务会有中断)。

　　示例：

　　

　　04

　　OSPF 接口IP地址

　　冲突故障定位

　　有如下拓扑：

　　

　　01 DR与非DR冲突

　　RTA上IP地址为112.1.1.2的接口状态为DR，RTC上IP地址为112.1.1.2的接口状态不是DR，这两个接口的IP地址发生了冲突。

　　判断方法：

　　在RTC上每隔一秒输入display ospf lsdb，发现冲突网段的Network LSA的Age一直为3600或者偶尔没有这条LSA，而且Sequence字段增加很快。

　　

　　在其他路由器上每隔一秒输入displayospf lsdb，发现冲突网段Network LSA的Age不断在3600和其他较小值之间切换，而且Sequence字段增加很快。

　　02 两个DR IP地址冲突

　　RTA上IP地址为112.1.1.2的接口状态为DR，RTC上IP地址为112.1.1.2的接口状态也为DR，这两个接口的IP地址发生了冲突。

　　判断方法：

　　在任一台路由器上每隔一秒输入displayospf lsdb。

　　会发现存在两个LinkState Id为112.1.1.2的Network LSA，并且这两个LSA的Age字段一直都很小，Sequence字段增加比较快。

　　

　　总的来说，在现网中，IP地址配置冲突的现象时有发生。

　　如果掌握了一些常用的判断方法，可以比较方便的找到问题的原因，然后逐个排查。

　　找出冲突的IP地址，更改冲突的IP地址后就可以修正该配置错误。

　　03 区域内IP地址冲突设备判断方法

　　一、DR与非DR冲突时：

　　首先根据这条振荡Network LSA(具体判断方法见上)的LinkStateID可以知道冲突的IP地址。

　　然后根据AdvRouter找到其中的一台设备进而定位出是哪个接口。

　　注意，与其冲突的设备只能够通过网络IP地址规划找到，很难通过OSPF自身携带的信息找到冲突设备。

　　如上例中，可以首先判断出冲突的IP地址为112.1.1.2。

　　其中一台冲突设备的Router ID为1.1.1.1，与其冲突的另外一台设备（3.3.3.3）无法通过OSPF自身携带的信息找到。

　　二、DR与DR冲突时：

　　可以根据这两个LinkState Id相同的Network LSA(具体判断方法见上)的LinkState Id和AdvRouter判断出是哪台设备的哪个接口IP地址冲突了。

　　如上例中，很容易定位出是RouterId为3.3.3.3和1.1.1.1的两台设备上存在IP地址冲突的接口。

　　然后在根据LinkState Id(112.1.1.2---冲突IP地址)很容易就找到对应的接口。

　　05

　　OSPF 链路接口

　　频繁振荡故障定位

　　01 接口振荡

　　实际应用中，由于接口振荡导致CPU高的问题也经常出现，接口振荡，会导致Router LSA频繁产生。

　　按照协议RFC2328， Router LSA改变，会触发完全路由计算，频繁的路由计算导致CPU会一直比较高。

　　这类问题的排查还是需要从LSA着手。

　　存在如下拓扑：

　　

　　Router-A和Router-B建立OSPF邻居关系。

　　Router-B上一个接口2.2.2.2/24在OSPF中使能，并频繁up/down，在Router-A和Router-B上都会进行频繁路由计算，导致CPU高。

　　判断方法：

　　一、在任意一台设备上每隔一秒输入display ospf lsdb。

　　查看是否存在Age一直很小的Router LSA，而且Sequence number增加很快：

　　

　　二、在任意一台设备上输入display ospf brief。

　　查看完全路由计算的次数增长是否很快：

　　

　　如果存在上述两种情况都符合，在结合日志，可以快速找到频繁振荡的接口。

　　02 LSA振荡

　　LSA振荡导致OSPF路由频繁计算，导致CPU高的场景排查起来比较困难，需要找到该LSA的发布路由器，然后再从源头控制这些振荡的LSA，排查如下：

　　一、输入display iprouting-table verbose命令。

　　找到频繁振荡的路由：

　　

　　如上表所示，如果该路由频繁振荡，其Age值很小，基本上是秒级的。

　　二、输入displayospf lsdb命令。

　　查看该LSA的产生源。

　　

　　如上表所示，找到该LSA的产生源是Router id为2.2.2.2的设备，需要登录到这台设备上查看频繁产生该LSA的具体原因。

　　总的来说，由于OSPF路由计算导致CPU高的问题，排查方法重要是查看LSA的变化，根据LSA的变化找到导致振荡的原因，最终解决问题。

　　06

　　OSPF无法计算

　　路由故障定位

　　01 故障概述

　　PE-CE间，OSPF与BGP间路由相互学习和发布，有可能导致路由环路问题。

　　OSPF VPN特性专门针对这种情况提供了解决方案。

　　

　　一、VPN场景中PE通过引入私网BGP路由通过OSPF向CE发布。

　　如图所示，PE1和PE2将BGP发送过来的远端路由10.1.1.1/32通过OSPF发布给CE1。

　　CE1产生了目的地址为10.1.1.1/32的路由，下一跳分别指向PE1和PE2。

　　二、PE1收到了PE2发布的路由，产生了一条10.1.1.1/32的OSPF路由，下一跳指向CE1。

　　三、同理PE2收到了PE1发布的路由，也产生一条10.1.1.1/32的OSPF路由，下一跳指向CE1。

　　四、如上过程所描述的，到达目的地址10.1.1.1/32的路由，CE1-->PE1,PE2-->CE1，一个环路就产生了。

　　五、由于OSPF路由的优先级高于BGP路由，所以PE1和PE2上的BGP路由会被OSPF路由所替代。

　　没有了BGP路由，PE1和PE2也不会在向CE1发布路由。同时PE1和PE2也学不到对方发布的路由，刚才产生的OSPF路由也被撤消了。

　　此时没有了OSPF路由，BGP路由又被优选了。又开始重复刚才的循环。这会导致路由震荡。

　　为此，OSPF使用DN-Bit和Router-tag防止环路：

　　

　　02 DN-Bit抑制

　　

　　如上图所示，PE1和MCE设备都绑定了VPN，属于私网进程，在PE1上引入BGP路由，产生了LSA，但MCE设备上却没有计算出来路由。

　　判断方法如下：

　　一、在MCE上输入display ospf lsdb ase<Link id>查看该LSA是否带DN-Bit:

　　

　　二、在MCE上输入displaycurrent-configuration configuration ospf查看OSPF进程是否绑定了VPN：

　　

　　如果绑定了VPN，由于前面所述，由于DN-Bit的抑制，即使有LSA，路由也无法计算出来。

　　三、解决办法

　　如果该设备不承担PE角色，在MCE上输入vpn-instance-capabilitysimple即可取消环路检查。

　　03 Route Tag一致

　　

　　同样如上图所示，PE1和MCE设备都绑定了VPN，属于私网进程。

　　在PE1上引入BGP路由，产生了LSA，但MCE设备上却没有计算出来路由。

　　判断方法如下：

　　一、在MCE上输入displayospf lsdb ase <Link id>查看该LSA的Route Tag值:

　　

　　二、在MCE上输入displayospf brief命令查看OSPF本地Tag值是否和收到的LSATag值是否一致：

　　

　　如果LSA的RouteTag和本地Tag一致，由于防止环路的需要，该LSA无法计算出路由。

　　三、解决办法

　　如果该设备不承担PE角色，在MCE上输入vpn-instance-capabilitysimple即可取消环路检查。

　　另外，更改本地Route Tag值，和LSA的Tag值不一致也可以解决该问题。

　　举报/反馈