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

我的网工朋友大家好。

好久没聊OSPF技术了，相关基础且经典的内容，公众号陆陆续续分享过一些，趣味科普，面试考题，实验操作，都有涉及。

按照惯例，先给你整一波优质的往期内容：

《 5个超经典实验，老杨带你高效进阶OSPF 》

《 不懂OSPF，你就千万别点开这篇文章 》

《图解OSPF，看这70张图已经足够（一）》

《图解OSPF，看这70张图已经足够（二）》

今天主要想给你分享点OSPF故障的相关干货。

引起OSPF故障的原因很多，不同的问题会导致不同的故障，但你真的会排查吗？

怎么做OSPF故障定位，码住这6个实用案例。

今日文章阅读福利：《OSPF网络设计解决方案》

作为网络基础，了解它是你入门精进的第一步。私信我，备注“方案”，前30名私信的小友即可获得此份OSPF经典读物。

如果想从0到1系统学习网络，也可以和我聊聊，告知学习意向，我会为你推荐最适合你学习网络的方式。

01 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值不一致也可以解决该问题。

整理：老杨丨10年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部