OSPF路由條目排錯案例 文檔下載：無注：此文檔為中文原創，故無英文版目錄硬件平臺軟件版本 案例簡介故障診斷步驟經驗總結相關命令硬件平臺路由器及多層交換機軟件版本所有 案例簡介在日常維護工作中， 我們經常會遇到路由器上出現多余路由條目或者缺少路由條目的情況。 這些情況基本上都是路由配置變化或者引入新節點拓撲變化帶來的問題。 通常情況下如果我們知道有哪些新設備或者哪些設備做過路由配置變更， 就能直接找到問題點。 但對于較大型的網絡， 在缺少這些信息的情況下， 就要先對問題縮小范圍， 從現象特征最明顯的點為突破口進行分析。 以下是一個真實案例， 為保護客戶資料， 路由器輸出信息是在實驗環境中抓取。 故障診斷步驟這是一個傳統的三層城域網絡結構， 客戶發現核心路由器(R0)路由表中一個私有網段地址， 并且是自己發布的。 我們不能確定這個網絡中最近發生過哪些變化。 因為現象是集中在R0， 所以我們從這臺路由器入手。 無論我們的網絡是選用哪種路由協議，首先我們肯定要查看路由表詳細信息。 R0#sh ip routeCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODR, P - periodic downloaded static route, + - replicated routeGateway of last resort is not set161.74.0.0/32 is subnetted, 1 subnetsO 161.74.158.10 110/3 via 161.174.80.146, 00:44:44, FastEthernet0/0161.130.0.0/32 is subnetted, 2 subnetsC 161.130.158.4 is directly connected, Loopback0O 161.130.158.6 110/2 via 161.174.80.146, 00:56:21, FastEthernet0/0161.174.0.0/16 is variably subnetted, 6 subnets, 3 masksC 161.174.5.0/24 is directly connected, Loopback2L 161.174.5.1/32 is directly connected, Loopback2C 161.174.72.0/24 is directly connected, Loopback1L 161.174.72.1/32 is directly connected, Loopback1C 161.174.80.144/30 is directly connected, FastEthernet0/0L 161.174.80.145/32 is directly connected, FastEthernet0/0161.189.0.0/30 is subnetted, 1 subnetsO 161.189.31.52 110/2 via 161.174.80.146, 00:44:55, FastEthernet0/0O 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.146Routing entry for 161.174.80.144/30Known via connected, distance 0, metric 0 (connected, via interface)Redistributing via ospf 100Routing 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數據庫皆可找到出問題的設備。經驗總結對于路由協議