我的网工朋友大家好。
好久没聊OSPF技术了，相关基础且经典的内容，公众号陆陆续续分享过一些，趣味科普，面试考题，实验操作，都有涉及。
按照惯例，先给你整一波优质的往期内容：
今天主要想给你分享点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 debugging03 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年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部
标签：LSA,这篇,故障,冲突,IP地址,Router,OSPF,路由 From： https://blog.51cto.com/u_15281548/6570189