故障案例——OSPF邻居都Full，为啥还不通呢？
故障现象
1、分支点的路由器R2与R1 建议OSPF邻接关系，在OSPF 区域1 内，状态均为Full，但R2无法ping 通 4.4.4.4等OSPF路由，而R3没问题。
2、该场景只有R2、R3 的登录权限，其他均无登录权限查看。
网络拓扑
配置思路
- 1、搭好拓扑图，连接好线；
- 2、标注IP信息、router id；
- 3、启动设备，配置好设备名、router-id，每个设备直连IP信息。
- 4、配置各个设备的loopback接口、物理接口ip地址。
- 5、配置OSPF路由协议。
关键配置
R1（注：为了重现故障现象，R1某一个接口配置先不展示）
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 14.1.1.1 0.0.0.0
area 0.0.0.1
network 12.1.1.1 0.0.0.0
area 0.0.0.2
network 13.1.1.1 0.0.0.0
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
R2
ospf 1
area 0.0.0.1
network 2.2.2.2 0.0.0.0
network 12.1.1.2 0.0.0.0
- 1
- 2
- 3
- 4
R3
ospf 1
area 0.0.0.2
network 3.3.3.3 0.0.0.0
network 13.1.1.3 0.0.0.0
- 1
- 2
- 3
- 4
R4
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 14.1.1.4 0.0.0.0
- 1
- 2
- 3
- 4
检查邻居状态：
R1与R2、 R3、R4邻居状态均为Full状态（邻接）。
故障重现及分析
接下来，故障重现：该场景是我们没有R1核心的登录权限。
在R2上去ping 4.4.4.4：
邻居也正常：
到R3上 ping 4.4.4.4 看看：
结果，R3是可以ping通4.4.4.4的。
再R2上看看路由表，我们都知道，如果不能ping通，就先看看路由表有没有相关路由。
从R2的路由表，可知，没有任何OSPF路由。
这说明一下现象：即R2与R1 OSPF邻居建立OK，只是路由层面出了问题。
这时，我们需要想办法排查路由层面的。
我们可以通过抓包或debug，分析看看。
先用debug看看，在R2开启debug相关命令。（友情提示：在生产网中，请谨慎开启debug）
<R2>terminal monitor
Info: Current terminal monitor is on.
<R2>
<R2>terminal debugging
Info: Current terminal debugging is on.
<R2>
<R2>debugging ospf packet brief
- 1
- 2
- 3
- 4
- 5
- 6
- 7
等待一会儿，看到屏幕有一些debug信息，就可以先关掉debug了
<R2>undo debug all
Info: All possible debugging has been turned off
<R2>
- 1
- 2
- 3
现在我们来看看debug信息：
看到R2发送了一个hello包，DR 优先级是1，自己是DR，即12.1.1.2
也看到了R2收了一个Hello包，对端发过来的，不过DR和BDR居然均0.0.0.0
由此可知，R2发出来的Hello包是有携带DR和BDR的，R1发过来的Hello包 DR和BDR字段是全0。设备默认OSPF网络类型是broadcast，需要选举DR和BDR，而R1没有DR和BDR，说明R1的G0/0/0接口网络类型，肯定不是broadcast。
我们知道，邻居正常，如果网络类型不一致，会导致OSPF计算路由时，出错，无法计算正确的拓扑。
所以，接下来解决办法：把R2的G0/0/0接口也修改一下网络类型。
[R2]int g0/0/0
[R2-GigabitEthernet0/0/0]ospf network-type p2p
- 1
- 2
现在，我们在R4上ping 4.4.4.4看看：
可以通的原因是：ospf可以正确计算路由，学习到OSPF路由了。
文章来源: libai.blog.csdn.net，作者：李白你好，版权归原作者所有，如需转载，请联系作者。
原文链接：libai.blog.csdn.net/article/details/122777530
- 点赞
- 收藏
- 关注作者
评论（0）