故障案例——OSPF邻居都Full，为啥还不通呢？

Posted 2022-02-16 李白你好

《网络￥安全联盟站》-李白

• • 故障现象
  • 网络拓扑
  • • 配置思路
    • 关键配置
  • 故障重现及分析

故障现象

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 

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 

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 

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 

检查邻居状态：
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

等待一会儿，看到屏幕有一些debug信息，就可以先关掉debug了

<R2>undo debug all
Info: All possible debugging has been turned off
<R2>

现在我们来看看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

现在，我们在R4上ping 4.4.4.4看看：

可以通的原因是：ospf可以正确计算路由，学习到OSPF路由了。