1、OSPFv2诊断思路

1)首先检查本地设备OSPF的基本配置正确与否

OSPF协议是否运行,是否已具备正确的ROuter-ID,这些信息可以通过Show ip ospf查看。注意整个网络内的ROuter-ID应该是唯一的。

检查设备是否配置接口属于某个特定的区域,OSPF正常运行需配置已UP的接口并定义于特定区域,使用命令S8610(config-rOuter)# Network address wild-mask area area-id, 配置接口属于特定的区域,通过Show ip ospf Interface Interface-name来确认是否配置成功。

2)与邻居设备的交互关系是否正确

通过Show ip ospf Neighbor 可以查看邻居关系是否异常,通常情况下,邻居应处于FULL状态,对于NBMA和广播网络中,DROther之间为2-Way状态。

下面为通常的检查步骤:

a.检查物理连接及下层协议正确性;OSPF协议的报文收发需要下层协议支持,报文的收发通过单播和多播两种形式来实现的,因此可通过Ping 程序或者打开报文收发开关(Debug ip ospf packet)来确定下层协议是否运行正常,报文收发是否正常。

b.检查设备双方的接口配置是否一致,,在下层协议的正确性情况下,我们还需要保证试图建立邻居关系的双方接口的配置是否正确,这包括:网路地址和掩码是否一致,接口所属区域一致,HelloInterval,ROuterDeadInterval配置一致,区域认证方式和接口认证方式及密码是否一致。不一致的参数会导致,邻居无法建立邻居关系。通过打开Debug ip ospf packet开关,可以显示详细的异常事件,有助于定位异常原因。

c.设备双方区域属性是否一致;如某台设备上区域A配置为Stub,而另一台区域A为普通区域,则导致双方在区域A无法正常建立邻居关系。

d.在广播网络和NBMA网络中,至少配置一台设备的该接口的Priority大于1;因为在NBMA网络和广播网络中,需要选举DR,而只有Priority大于1的设备才有能力参与选举,因此必须满足该条件,否则网络中的设备将无法正常运行。在接口模式下执行命令ip ospf priority num 配置接口的优先级。

3)区域规划是否正确

下面是常见的区域规划注意事项:

a.当一个自治系统存在多个区域时,应保证存在骨干区域,且其他区域均与骨干区域物理相连或逻辑相连,同时骨干区域自身应该是连通的;

b.不同设备的对应的区域属性应该一致,如区域认证方式,是否为Stub区域,不一致性会导致OSPF运行异常

 

2、OSPFv3诊断思路

1)确认是否可以Ping同对端

2)确认邻居是否正确

查看邻居状态是否已经达到FULL状态,关联命令:Show ipv6 ospf Neighbor,如果邻居无法进入FULL状态,根据如下配置进行检查

a.观察接口命令配置是否正确,确认接口是否参与正确OSPFv3进程

关联命令:Show running-config IFNAME

b.观察OSPF接口信息是否正确,要注意接口地址掩码/Hello/dead/area-id等参数

关联命令:Show ipv6 ospf Interface

3)观察是否正确接收到邻居发来的报文

关联命令:

Debug ipv6 packet

Debug ipv6 raw-socket

Debug ipv6 ospf packet

4)观察导致邻居不稳定的事件

关联命令:Debug ipv6 ospf nfsm

5)如果邻居正确,但路由表项同期望的不一致

a.观察LSA信息是否正确,观察对应的LSA是否正确,sequence-number是否异常的变化;关联命令:Show ipv6 ospf database [ls-type]

b.观察本设备是否有到达通告该LSA的设备;关联命令:Show ipv6 ospf topology

c.观察是SPF计算是否正确关联命令:Show ipv6 ospf多次查询,观察SPF计算次数是否增加。关联命令:Debug ipv6 ospf rOute [spf|ia|ase]

 

3、OSPF邻居关系异常故障排查---OSPF邻居列表为空

   导致OSPF邻居表为空最常见的原因一般是配置错误或缺少配置。如果邻居表为空,将不能继续形成OSPF邻居关系。

   最常见的引起这个问题的可能原因如下:

1)在接口上没有启动OSPF

2)网络第1或第2层故障

3)这个接口在OSPF中被定义为被动的。

4)一个访问列表在两边阻止OSPF hello分组

5)在一条广播链路上存在一对子网号/掩码不匹配

6)hello间隔/死亡间隔不匹配

7)验证类型(纯文本或者MD5)不匹配

8)验证密码不匹配

9)区域ID不匹配

10)stub/transmit/NSSA区域类型不匹配

11)一个OSPF邻接体存在有第二IP地址

12)一个OSPF邻接体存在于一个异步接口上

13)在NBMA(帧中继、X.25、SMDS等等)上没有定义网络类型或邻居

14)在两边的Frame-relay map/dialer map语句中缺少关键字broadcast

 

4、OSPF邻居关系异常故障排查---OSPF邻居停滞于ATTEMPT状态

这个问题仅会出现在定义了neighbor语句的NBMA网络中有效。停滞于ATTEMPT表示一个路由器试图通过发送它的hello分组联络一个邻居但是没有收到任何回应。ATTEMPT状态本身并不是一个问题,因为它是在NBMA模式中一个路由器要通过的一个普通状态;但是,如果一个路由器在这个状态停滞很长一段时间,就表明出现了问题。

    这个问题最常见的可能原因如下:

1)错误配置了neighbor语句

2)在NBMA中单播中断了

 

5、OSPF邻居关系异常故障排查---OSPF邻居停滞于INIT状态

当一个路由器从邻居收到一个OSPF hello分组的时候,它在hello分组中包含进邻居的路由器ID并发送这个hello分组。如果它不包含邻居的路由器ID,那么邻居将停滞于INIT状态,这表明出现了一个问题。路由器收到的第一个分组将使路由器进入INIT状态。这并不是问题,但是如果路由器在这个状态停留很长一段时间,就表明出现了问题。它表示邻居路由器没有看到由这个路由器发送的hello分组----那也就是为什么它没能包括这个路由器的路由器ID在它自己的hello分组中的原因。

    这个问题最常见的可能原因如下:

1)访问列表在某一方向阻塞了OSPF hello分组

2)组播功能在某一方向被破坏了

3)验证只在一边可用(启用了验证,路由器将拒绝所有非验证分组)

4)在某一边的frame-relay map/dialer map语句中缺少broadcast关键字

5)hello分组在某一边的第2层丢失了

 

6、OSPF邻居关系异常故障排查---OSPF邻居停滞于2-way状态

OSPF邻居停滞于2-way状态

原因:在所有路由器上都配置了优先级0

如果一个以太网段中所有的路由器都配置了优先级0,那么这个网段上将无法进行DR、BDR的选择,因此也就会卡在2-way状态,无法进入下一个状态。

 

7、OSPF邻居关系异常故障排查---OSPF邻居停滞于EXSTART/EXCHANGE状态

这在OSPF邻接体过程中是一个重要的状态。在这个状态中,路由器选择了一个主设备和一个从设备还有一个初始序列号。整个的数据库也在这个状态下交换。如果一个邻居停滞于EXSTART/EXCHANGE状态持续很长一段时间,那就表明出了问题。

    引起这个问题最常见的可能原因如下:

1)不匹配的接口MTU

2)在邻居上有重复的路由器ID(在交换DBD前,会先发送一个DBD分组来选举一个主设备和从设备,路由器ID大的用户成为主设备)

3)不能用超过一定大小的MTU去ping通(DBD大小超过中间链路的MTU导致被丢弃,导致DBD不断重传)

4)由于下列原因单播连接损坏了

  a、在帧中继/ATM交换机中错误的VC/DLCI映射

  b、访问列表阻止单播

  c、对单播进行了NAT转换

 

8、OSPF邻居关系异常故障排查---OSPF邻居停滞于LOADING状态

当一个邻居停滞于LOADING状态时,本地路由器已经向邻居发送了一个链路状态请求分组去请求一个过期或丢失的LSA,并且等待从它的邻居来的一个路由更新分组。如果邻居没有回答或邻居的回答没有到达本地路由器,那么路由器将停滞于LOADING状态。

    这个问题最常见的可能原因如下:

1)不匹配的MTU

2)损坏的链路状态请求分组

 

9、BGP重发布路由到OSPF的场景中,重发布的网络中包含相同路由前缀但掩码不同的路由时,在特定操作下,有概率导致OSPF网络中的这些相同前缀的路由丢失

问题描述:

BGP重发布路由到OSPF的场景中,重发布的网络中包含相同路由前缀但掩码不同的路由时,在特定操作下,可能导致OSPF网络中的这些相同前缀的路由丢失

历史某个时刻,用户在网络中同时配置了相同前缀不同掩码的网段,比如同时出现了192.168.1.0/24与192.168.1.0/30(其他类似的都有可能,这里结合本次故障举例说明)。

然后又删除了192.168.1.0/30,这种状态一直维持到网络中负责通告192.168.1.0/24的相关设备发生重启,就会通告下联设备删除与添加路由,这个过程中BGP不会有问题,

可是通过BGP分发到OSPF,OSPF再通告给邻居时就会出现LSA在数据库中可是路由却没计算出来的故障。

金融行业中需要重点关注(涉及BGP和OSPF重发布的应用中重点关注)

 

重复步骤:

重现步骤与分析:

例如: BGP网络57---OSPF网络--86---OSPF网络--86 的拓扑

57重分发BGP路由到OSPF,变化过程如下(用户中间配置了小网段,然后又删了,机器又升级重启了):

 57(生成方)                       86(接收方)

(1) LSA 192.168.1.0/24            LSA 192.168.1.0/24  路由 192.168.1.0/24

(2) 用户在192网段那边进行操作,配置了小网段

    LSA 192.168.1.0/25            LSA 192.168.1.0/25  路由 192.168.1.0/25

        192.168.1.1/24                    LSA 192.168.1.1/24  路由 192.168.1.0/24

(3) 用户删除配置的小网段(只要历史上某个时刻有过这个操作,就残留下面这个,就算后面刷新也不会变)            

    LSA 192.168.1.1/24            LSA 192.168.1.1/24  路由 192.168.1.0/24

(4) 用户升级重启(BGP删除添加路由,从而通告OSPF删除添加路由,从LOG看BGP的删除添加是很快速的,导致ospf感知到部分的变化)

    LSA 192.168.1.1/24 MAXAGE     LSA 192.168.1.1/24 MAXAGE ----〉 触发计算,由于是MAXAGE就会删除路由(这里是延时删除操作)

    LSA 192.168.1.0/24            LSA 192.168.1.0/24        ----〉 触发计算,新添加 Route : 1.0/24

LSA 192.168.1.1/24 MAXAGE ----〉延时删除操作触发计算,查询到192.168.1.0/24的路由结构,由于宣告者和类型与LSA                           

192.168.1.0/24的宣告者和类型是相同的,重新计算 192.168.1.0/24的逻辑就进不去而无法重算,然后走计算192.168.1.1/24的逻辑,由于是MAXAGE就删除192.168.1.0/24的路由

    LSA 192.168.1.0/24刷新        LSA 192.168.1.0刷新       ----〉与之前的LSA数据库中lsa相同,就无限计算不出来了,clear ip ospf ase才能重新算出来

在BGP网络中做网段变更或设备重启的动作,则有可能导致 OSPF网络中设备丢失部分路由。

 

故障影响:

此类相同前缀的OSPF路由丢失,导致部分网段不通。

 

规避方法:

当故障发生时,可以通过Clear ip os ase命令将没计算出来的路由重新计算出来,并且不影响当前已生成的其他路由。

 

解决方法:

升级版本到解决问题的版本

3760E  10.4(3)未解决、10.4(3)p1,10.4(3b1b19)、10.4(3b19)p2 均已解决。

5750    10.4(3)未解决、10.4(3)p1、10.4(3)p4均已解决

5750E    10.4(2T53)未解决、10.4(3b16)、10.4(3b16)p1均已解决

6200   10.4(3b3)未解决、10.4(3b3)p1、10.4(5b2)均已解决

S76  10.2(5)未解决、10.2(5)p2(已解决)

S78  10.4(2b2)未解决、10.4(2b2)p4(已解决)

S86  10.4(3)未解决、10.4(3b7)p1、10.4(3b17)均已解决

S12000  10.4(3)未解决、10.4(3b3)未解决、10.4(3b17)已解决

 

10、OSPF路由信息丢失类故障信息收集方法

1)静态收集信息

show running-config

show logging

show ip ospf

show ip ospf neighbor

show ip ospf interface

show ip ospf border-routers

show ip ospf spf

show ip ospf route count

show ip ospf route

show ip ospf database database-summary

show ip ospf database

show ip ospf database router

show ip ospf database network

show ip ospf database summary

show ip ospf database asbr-summary

show ip ospf database external

show ip ospf database nssa-external

show ip route count

show ip route

show memory protocols

2)收集动态信息

a、打开debug ip ospf route ase

   执行clear ip ospf ase  (注意:该命令是隐藏命令)

   undebug all关闭调试开关

b、show ip route查看路由是否已经有了,若还是没有,继续第3步;否则结束信息收集;

c、 打开debug ip ospf route spf

   在其中一个启用OSPF的接口下配置:ip ospf cost 99

   等待10s

   恢复配置:no ip ospf cost (若原来有配置cost,这时候恢复为ip ospf cost xxx,其中xxx为原来配置的值)

   undebug all关闭调试开关

d、 show ip route查看路由是否已经有了,若还是没有,继续第5步;否则结束信息收集;

e、 执行clear ip ospf process

f、 show ip route查看路由是否已经有了,正常此时应该有了。

   万一还没有,重新收集一遍上述静态信息,结束信息收集

 

11、S5750S或S5750-A交换机路由条目多的时候可能导致某些网段不通

客户现场故障:

O E2 10.152.0.0/26 [110/1] via 10.151.195.137, 00:04:51, VLAN 851

这个路由条目有,但是呢这台交换机下联的PC无法ping通10.152.0.0/26网段的视频服务器,如果在这台交换机上添加一条这个网段的静态路由,下联PC访问视频服务器就没有问题,然后把这个静态路由删了,这台PC下联的用户依然能访问这个网段,但是重新cle ospf进程故障又出现(cle ip ospf pr)。不是所有网段都不通,目前发现了这个网段。

路由条目如下:

SXXZ2_VC_CS_01#sh ip route count

--------- route info ----------

the num of active route: 1727

 

故障原因及解决方案:

5750A/5750S的指标

路由表容量  V4  512,  (5750-A属于农行专项产品,在其他行业或客户并无销售)

ACE容量     768

MAC地址表容量   8K

由于S5750-A路由硬件网络路由容量只有512,当该设备的网络环境中超过路由容量时会导致部分路由转发不通。

现场如果需要在该网络环境中使用,建议更换路由容量满足的设备或采用减少路由表项学习规避。

 

12、OSPF的network命令发布不了某个SVI接口的地址

OSPF network 发布路由的条件是需要该接口是up状态的,需通过show interface status确认SVI口状态是否是UP的

 

13、OSPF数据库中有5类LSA表项,但是却没有安装进路由表中;   

OSPF的5类LSA中,FA的地址有2种情况:

1)在OSPF引入外部路由时,若产生的Type 5 LSA的FA地址为0.0.0.0,则其他路由器在计算到达该外部网络时,将考虑如何到达ASBR(即产生该Type 5 LSA的路由器),来计算出外部路由的下一跳地址。

2)在OSPF引入外部路由时,若产生的Type 5 LSA的FA地址不为0,则其他路由器在计算到达该外部网络时,将考虑如何到达该FA地址,来计算出外部路由的下一跳地址。

若同时满足以下三个条件,则产生的Type 5 LSA,其FA地址不为0,则该FA地址等于该引入的外部路由的下一跳地址

1)引入的这条外部路由,其对应的出接口启用了OSPF;

2)引入的这条外部路由,其对应的出接口未设置为passive-interface;

3)引入的这条外部路由,其对应的出接口的OSPF网络类型为broadcast;

注:如果FA非0,那么优选到FA地址 metric最短的路径,而且到FA的路由必须OSPF域内域间,否则忽略该表项;

综上所述,若某条5类LSA没有放进路由表中,有2种确认方法:

(1)show ip route | in x.x.x.x (FA地址) ,看该FA地址对应的路由是否从域内域间学过到;若都不是,则这条5类LSA不会放进路由表;

(2)ASBR上,相应的出接口是否关闭OSPF;