簡介
本文說明如何排解開放最短路徑優先(OSPF)鄰居停滯在Exstart和Exchange狀態中的情況。
必要條件
需求
建議使用者熟悉基本OSPF操作和配置,尤其是OSPF鄰居狀態。
採用元件
本文中的資訊係根據以下軟體和硬體版本:
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
慣例
如需文件慣例的詳細資訊,請參閱思科技術提示慣例。
背景資訊
鄰接關係形成的OSPF狀態包括Down、Init、雙向、Exstart、Exchange、Loading和Full。開放最短路徑優先(OSPF)鄰居停滯在Exstart/Exchange狀態的原因可能很多,本文檔重點介紹導致Exstart/Exchange狀態的OSPF鄰居之間的MTU不匹配。有關如何排除OSPF故障的詳細資訊,請參閱排除OSPF常見問題。
Exstart狀態
在兩台OSPF相鄰路由器建立雙向通訊並完成DR/BDR選舉後(在多路訪問網路中),路由器會轉換到Exstart狀態。在此狀態下,相鄰路由器建立主/從關係,並確定交換DBD資料包時使用的初始資料庫描述符(DBD)序列號。
交換狀態
一旦 Primary/Subordinate
關係已經協商(具有最高Router-ID的路由器成為主路由器),相鄰路由器會轉換到Exchange狀態。在此狀態下,路由器交換DBD資料包,這些資料包描述其整個鏈路狀態資料庫。路由器還會傳送鏈路狀態請求資料包,該資料包請求鄰居提供最新的鏈路狀態通告(LSA)。
儘管OSPF鄰居在正常的OSPF鄰接構建過程中通過Exstart/Exchange狀態進行轉換,但OSPF鄰居停滯在此狀態是不正常的。下一節將介紹OSPF鄰居陷入此狀態的最常見原因。請參閱瞭解OSPF鄰居狀態以瞭解有關不同OSPF狀態的詳細資訊。
鄰居停滯在Exstart/Exchange狀態
當您嘗試在Cisco路由器和其他供應商路由器之間運行OSPF時,該問題最常出現。當的最大傳輸單位(MTU)設定為 neighboring
路由器介面不匹配。如果MTU較高的路由器所傳送的封包大於相鄰路由器上設定的MTU,則相鄰路由器會忽略該封包。出現此問題時,會顯示 show ip ospf neighbor
命令顯示的輸出類似於下圖所示。
通過幀中繼連線路由器6和Router7
本節介紹此問題的實際重現資訊。
圖中路由器6和路由器7通過幀中繼連線,路由器6配置了5條靜態路由,這些路由已重分佈到OSPF中。路由器6上的串列介面的預設MTU為1500,而路由器7上的串列介面的MTU為1450。表中顯示了每台路由器的配置(僅顯示必要的配置資訊):
路由器6配置 |
路由器7配置 |
interface Serial2
!--- MTU is set to its default value of 1500.
no ip address
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
ip address 10.170.10.6 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 101
!
router ospf 7
redistribute static subnets
network 10.170.10.0 0.0.0.255 area 0
!
ip route 192.168.0.10 255.255.255.0 Null0
ip route 192.168.10.10 255.255.255.0 Null0
ip route 192.168.10.0 255.255.255.0 Null0
ip route 192.168.37.10 255.255.255.0 Null0
ip route 192.168.38.10 255.255.255.0 Null0 |
interface Serial0
mtu 1450
no ip address
no ip directed-broadcast
encapsulation frame-relay
frame-relay lmi-type ANSI
!
interface Serial0.6 point-to-point
ip address 172.16.7.11 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 110
!
router ospf 7
network 172.16.11.6 0.0.0.255 area 0 |
每台路由器的show ip ospf neighbor命令輸出為:
router-6#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.16.7.11 1 EXCHANGE/ - 00:00:36 172.16.7.11 Serial2.7
router-6#
router-7#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.170.10.6 1 EXSTART/ - 00:00:33 10.170.10.6 Serial0.6
router-7#
當路由器6在交換狀態下傳送大於1450位元組(路由器7的MTU)的DBD資料包時,便會出現此問題。使用 debug ip packet
和 debug ip ospf adj
命令檢視OSPF鄰接過程。步驟1到14中Router 6和7的輸出為:
-
Router 6調試輸出:
<<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on
Serial2.7 is dead
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on
Serial2.7 is dead, state DOWN
-
Router 7調試輸出:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
-
Router 6調試輸出:
<<<ROUTER 6 SENDING HELLOS>>>
00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5
(Serial2.7), len 64, sending broad/multicast, proto=89
00:04:03: IP: s=10.170.10.6 (local), d=224.0.0.5
(Serial2.7), Len 64, sending broad/multicast, proto=89
-
Router 7調試輸出:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
-
Router 7調試輸出:
<<<OSPF ENABLED ON ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
00:17:44: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 64, sending broad/multicast, proto=89
00:17:44: OSPF: Build router LSA for area 0,
router ID 172.16.7.11, seq 0x80000001
-
Router 6調試輸出:
<<<RECEIVE HELLO FROM ROUTER7>>>
00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 64, rcvd 0, proto=89
00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from
Serial2.7 172.16.7.11
00:04:04: OSPF: End of hello processing
-
Router 6調試輸出:
<<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5
(Serial2.7), Len 68, sending broad/multicast, proto=89
-
Router 7調試輸出:
<<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from
Serial0.6 10.170.10.6
00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on
Serial0.6, state 2WAY
-
Router 7調試輸出:
<<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6
seq 0x13FD opt 0x2 flag 0x7 Len 32
00:17:53: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:17:53: OSPF: End of hello processing
-
Router 6調試輸出:
<<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on
Serial2.7, state 2WAY
-
Router 6調試輸出:
<<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE
NEGOTIATION - ROUTER 6 IS SUBORDINATE
)>>>
00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7
seq 0xE44 opt 0x2 flag 0x7 Len 32
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7),
Len 52, sending broad/multicast, proto=89
00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE
-
Router 7調試輸出:
<<<RECEIVE ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6
seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU
-
Router 6調試輸出:
<<<SINCE ROUTER 6 IS SUBORDINATE
SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>
00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7),
Len 1492, sending broad/multicast, proto=89
-
Router 7調試輸出:
<<<NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT>>>
00:17:54: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 68, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF:
Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]
此時,路由器6繼續嘗試確認來自路由器7的初始DBD資料包。
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 172.16.7.11 area 0 from
Serial2.7 172.16.7.11
00:04:13: OSPF: End of hello processing
00:04:18: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE
00:04:18: OSPF: Send DBD to 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=10.170.10.6 (local), d=224.0.0.5
(Serial2.7), Len 1492, sending broad/multicast, proto=89
00:04:23: IP: s=10.170.10.6 (local), d=224.0.0.5
(Serial2.7), Len 68, sending broad/multicast, proto=89
00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE
路由器7從不從路由器6獲取ACK,因為路由器7的DBD資料包對於路由器7 MTU來說太大。路由器7重複重新傳輸DBD資料包。
0:17:58: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF:
Retransmitting DBD to 10.170.10.6 on Serial0.6 [2]
00:18:03: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 10.170.10.6 area 0 from
Serial0.6 10.170.10.6
00:18:03: OSPF: End of hello processing
00:18:04: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 68, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF:
Retransmitting DBD to 10.170.10.6 on Serial0.6 [3]
00:18:08: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#
由於路由器6的MTU較高,因此它繼續接受來自路由器7的DBD資料包,嘗試確認這些資料包,並一直保持為EXCHANGE狀態。
由於路由器7的MTU較低,因此它會忽略來自路由器6的DBD資料包以及ACK,繼續重新傳輸初始DBD資料包,並一直處於EXSTART狀態。
在步驟9和11中,路由器7和路由器6傳送其帶有標誌0x7的第一個DBD資料包,作為主/從協商的一部分。之後 Primary/Subordinate
確定,由於路由器7的Router-ID較高,因此它被選為主要路由器。步驟13和14中的標誌清楚地顯示,路由器7為主路由器(標誌0x7),而路由器6為從屬路由器(標誌0x2)。
在步驟10中,路由器6收到Router 7的初始DBD資料包並將其狀態轉換為2-way。
在步驟12中,路由器7收到Router 6的初始DBD封包並識別MTU不相符。(路由器7能夠識別MTU不匹配,因為路由器6在DBD資料包的介面MTU欄位中包括其介面MTU)。路由器6的初始DBD被路由器7拒絕。路由器7重新傳輸初始DBD資料包。
步驟13顯示Router6, subordinate
,採用Router 7的序列號,並傳送其第二個包含其LSA報頭的DBD資料包,這將增加資料包的大小。但是,Router 7從來不會收到此DBD封包,因為它大於Router 7 MTU。
在步驟13之後,路由器7繼續將初始DBD資料包重新傳輸到路由器6,而路由器6繼續傳送遵循主序列號的DBD資料包。此環路會無限期地持續下去,這可以防止任一路由器轉換出啟動/交換狀態。
解決方案
由於問題是由不匹配的MTU導致的,因此解決方法是更改任一路由器MTU以匹配鄰居MTU。
註:Cisco IOS軟體版本12.0(3)引入了介面MTU不匹配檢測。此檢測涉及在DBD資料包中通告介面MTU的OSPF,它符合OSPF RFC 2178附錄G.9。當路由器收到通告的DBD資料包大於路由器可接收的MTU時,路由器會忽略DBD資料包,且鄰居狀態仍處於Exstart狀態。這可以防止鄰接關係的形成。要解決此問題,請確保鏈路兩端的MTU相同。
在Cisco IOS軟體12.01(3)中,還引入了ip ospf mtu-ignore介面組態指令來關閉MTU不相符偵測;但是,這僅在極少數情況下需要,如下圖所示:
光纖分散式資料介面(FDDI)連線埠
上圖顯示Cisco Catalyst 5000上的光纖分散式資料介面(FDDI)連線埠,其中路由交換器模組(RSM)連線到路由器2的FDDI介面。RSM上的虛擬LAN(VLAN)是一個虛擬乙太網路介面,MTU為1500,而路由器2上的FDDI介面的MTU為4500。當封包在交換器的FDDI連線埠上收到時,它會前往背板,並在交換器本身內發生FDDI到乙太網路轉換/分段。這是一個有效的設定,但是通過MTU不匹配檢測功能,路由器和RSM之間沒有形成OSPF鄰接關係。由於FDDI和乙太網路MTU不同,因此此ip ospf mtu-ignore指令在RSM的VLAN介面上很有用,可停止MTU不相符的OSPF偵測,並形成鄰接關係。
必須注意的是,MTU不匹配(雖然最常見)不是OSPF鄰居停滯在Exstart/Exchange狀態的唯一原因。此問題最常見的原因是無法成功交換DBD資料包。但是,根本原因可能是以下任何一種:
此外,OSPF RFC 2328第10.3節還規定,將針對以下任何事件(任何事件都可能由內部軟體問題引起)啟動Exstart/Exchange進程:
-
序列號不匹配。
-
BadLSReq
-
鄰居在交換過程中傳送無法識別的LSA。
-
鄰居在無法找到的交換過程中請求了LSA。
當OSPF未形成鄰居時,請考慮前面提到的因素,例如物理介質和網路硬體,以便排除故障。
相關資訊