OSPF路由条目排错案例
OSPF路由条目排错案例
目录
硬件平台
软件版本
案例简介
故障诊断步骤
经验总结
相关命令
相关错误信息
其他相关文档
硬件平台
路由器及多层交换机
软件版本
所有
案例简介
在日常维护工作中， 我们经常会遇到路由器上出现多余路由条目或者缺少路由条目的情况。 这些情况基本上都是路由配置变化或者引入新节点拓扑变化带来的问题。 通常情况下如果我们知道有哪些新设备或者哪些设备做过路由配置变更， 就能直接找到问题点。 但对于较大型的网络， 在缺少这些信息的情况下， 就要先对问题缩小范围， 从现象特征最明显的点为突破口进行分析。 以下是一个真实案例， 为保护客户资料， 路由器输出信息是在实验环境中抓取。
故障诊断步骤
这是一个传统的三层城域网络结构， 客户发现核心路由器(R0)路由表中一个私有网段地址， 并且是自己发布的。 我们不能确定这个网络中最近发生过哪些变化。 因为现象是集中在R0， 所以我们从这台路由器入手。
无论我们的网络是选用哪种路由协议，首先我们肯定要查看路由表详细信息。
R0#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is not set
161.74.0.0/32 is subnetted, 1 subnets
O 161.74.158.10 [110/3] via 161.174.80.146, 00:44:44, FastEthernet0/0
161.130.0.0/32 is subnetted, 2 subnets
C 161.130.158.4 is directly connected, Loopback0
O 161.130.158.6 [110/2] via 161.174.80.146, 00:56:21, FastEthernet0/0
161.174.0.0/16 is variably subnetted, 6 subnets, 3 masks
C 161.174.5.0/24 is directly connected, Loopback2
L 161.174.5.1/32 is directly connected, Loopback2
C 161.174.72.0/24 is directly connected, Loopback1
L 161.174.72.1/32 is directly connected, Loopback1
C 161.174.80.144/30 is directly connected, FastEthernet0/0
L 161.174.80.145/32 is directly connected, FastEthernet0/0
161.189.0.0/30 is subnetted, 1 subnets
O 161.189.31.52 [110/2] via 161.174.80.146, 00:44:55, FastEthernet0/0
O E2 192.168.0.0/16 [110/20] via 161.174.80.146, 00:44:45, FastEthernet0/0
注意最后一条路由， 我们可以解读为192.168.0.0/16这个网络是从161.174.80.146学来的外部路由， 并且是metric-type为2的外部路由， 出接口为F0/0。 检查161.174.80.146这个地址却发现这是R0上的F0/0接口地址。
R0#sh ip route 161.174.80.146
Routing entry for 161.174.80.144/30
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via ospf 100
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1
然而， R0本地并没有任何静态路由。 难道是路由器凭空产生的一条LSA? 带着这个疑问我们进一步检查OSPF database的细节。
R0#show ip ospf database external 192.168.0.0
OSPF Router with ID (161.130.158.4) (Process ID 100)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1681
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 192.168.0.0 (External Network Number )
Advertising Router: 161.174.80.145
LS Seq Number: 80000002
Checksum: 0x748F
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
从上面的输出可以得知R0这台路由器的Router-id为161.130.158.4， 但是这条外部路由的发布者是以161.174.80.145为router-id的。 由此我们判断一定是网络中有一台路由器的router-id配置成了R0 F0/0的地址。 最终， 顺着这个接口逐跳检查路由表和OSPF数据库皆可找到出问题的设备。
经验总结
对于路由协议相关命令的输出， 接合自己的网络要知道正常预期输出结果， 找到与预期行为不同的细节， 就能分析出解决问题的线索。相关命令
show ip route show ip route x.x.x.x show ip ospf <process id> neighbor show ip ospf database external x.x.x.x
相关错误信息
无
反馈