排除OSPF鄰居停滯在Exstart/Exchange狀態中的故障

下載選項

PDF (431.0 KB)
在多種裝置上使用 Adobe Reader 檢視
ePub (91.4 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (106.2 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2024 年 10 月 3 日

文件 ID:13684

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本文說明如何排解開放最短路徑優先(OSPF)鄰居停滯在Exstart和Exchange狀態中的情況。

必要條件

需求

建議使用者熟悉基本OSPF操作和配置，尤其是OSPF鄰居狀態。

採用元件

本文中的資訊係根據以下軟體和硬體版本：

思科2503路由器
要在兩^台路由器上運行的Cisco IOS^®軟體版本12.2(24a)

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

背景資訊

鄰接關係形成的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。

OSPF Neighbor

本節介紹此問題的實際重現資訊。

圖中路由器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

路由器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後，由於路由器ID較高，因此路由器7被選為主要路由器。步驟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步顯示，路由器6採用路由器7的序列號，並傳送其第二個DBD資料包，其中包含其LSA的報頭，這將增加資料包的大subordinate小。但是，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不相符偵測；但是，只有在極少數情況下才需要這樣做，如下圖所示：

OSPF Turn Off MTU Mismatch Detection

上圖顯示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資料包。但是，根本原因可能是以下任何一種：

MTU不匹配
單播已損壞。在Exstart狀態下，路由器將單播資料包傳送到鄰居以選擇Primary和Subordinate。除非您有點對點鏈路（在這種情況下，它會傳送組播資料包），否則這是正確的。可能的原因如下：
- 高度冗餘網路中的非同步傳輸模式(ATM)或幀中繼環境中的錯誤虛電路(VC)對映。
- MTU問題，表示路由器只能對特定長度的封包執行ping。
- 訪問清單阻止單播資料包。
- NAT在路由器上運行並轉換單播資料包。
PRI和BRI/撥號器之間的鄰居。
兩台路由器具有相同的Router-ID（配置錯誤）。

此外，OSPF RFC 2328第10.3節還規定，將針對以下任何事件（任何事件都可能由內部軟體問題引起）啟動Exstart/Exchange進程：

序列號不匹配。
- 意外的DD序列號。
- 「I」位被意外設定。
- 選項欄位與DBD資料包中收到的最後一個選項欄位不同。
BadLSReq
- 鄰居在交換過程中傳送無法識別的LSA。
- 鄰居在無法找到的交換過程中請求了LSA。

當OSPF未形成鄰居時，請考慮前面提到的因素，例如物理介質和網路硬體，以便排除故障。

修訂	發佈日期	意見
3.0	03-Oct-2024	已刪除PII。已更新標題、替代文字和格式。
2.0	18-Sep-2023	重新認證
1.0	10-Dec-2001	初始版本

排除OSPF鄰居停滯在Exstart/Exchange狀態中的故障

下載選項

無偏見用語

關於此翻譯

目錄

簡介

必要條件

需求

採用元件

慣例

背景資訊

Exstart狀態

交換狀態

鄰居停滯在Exstart/Exchange狀態

解決方案

相關資訊

修訂記錄

由思科工程師貢獻

這份文件是否有所幫助？

讓思科協助您