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

下載選項

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

已更新: 2024 年 10 月 3 日

文件 ID:13684

無偏見用語

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

關於此翻譯

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

簡介

本文描述如何排除Open Shortest Path First (OSPF)鄰居停滯在Exstart和Exchange狀態的問題。

必要條件

需求

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

採用元件

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

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

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

慣例

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

背景資訊

形成鄰接關係的OSPF狀態包括Down、Init、2-way、Exstart、Exchange、Loading和Full。開放最短路徑優先(OSPF)鄰居停滯在Exstart/Exchange狀態的原因有很多。本文檔重點介紹導致Exstart/Exchange狀態的OSPF鄰居之間的MTU不匹配。有關如何排除OSPF故障的詳細資訊，請參閱OSPF常見問題故障排除。

Exstart狀態

在兩個OSPF相鄰路由器建立雙向通訊並完成DR/BDR選擇（在多路訪問網路中）後，路由器會轉換到Exstart狀態。在此狀態下，相鄰路由器建立主/從關係，並確定交換DBD資料包時使用的初始資料庫描述符(DBD)序列號。

交換狀態

一旦協商好Primary/Subordinate關係（具有最高路由器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的輸出為：

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

路由器7的調試輸出：
```
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
```

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

路由器7的調試輸出：
```
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
```

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

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

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

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

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

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

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

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

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

路由器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的DBD資料包對於路由器7 MTU而言太大，因此路由器7永遠不會收到來自路由器6的ACK。路由器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資料包，並嘗試確認這些資料包，同時保持交換狀態。

由於路由器7的MTU較低，因此它會忽略來自路由器6的DBD資料包和ACK，繼續重新傳輸初始DBD資料包，並保持EXSTART狀態。

在步驟9和11中，路由器7和路由器6傳送其帶有標籤0x7的第一個DBD資料包，作為主/從協商的一部分。確定Primary/Subordinate後，路由器7被選為主要路由器，因為其路由器ID較高。步驟13和14中的標誌清楚地顯示路由器7是主路由器（標誌0x7），而路由器6是從屬路由器（標誌0x2）。

在步驟10中，路由器6接收路由器7的初始DBD資料包，並將其狀態轉換為2-way。

在步驟12中，路由器7收到Router 6的初始DBD資料包並辨識MTU不匹配。（路由器7能夠辨識MTU不匹配，因為路由器6在DBD資料包的介面MTU欄位中包括其介面MTU）。路由器6的初始DBD被路由器7拒絕。路由器7重新傳輸初始DBD資料包。

第13步顯示路由器6(作為subordinate路由器)，採用路由器7的序列號並傳送其第二個DBD資料包，該資料包包含其LSA的報頭，從而增加了資料包的大小。但是，路由器7永遠不會收到此DBD資料包，因為它大於路由器7 MTU。

在步驟13之後，路由器7繼續將初始DBD資料包重新傳輸到路由器6，而路由器6繼續傳送遵循主序列號的DBD資料包。此環路會無限期地繼續，這會阻止任一路由器從exstart/exchange狀態轉換出來。

解決方案

由於此問題是由不匹配的MTU引起的，因此解決方法是將任一路由器MTU更改為與鄰居MTU匹配。

注意：Cisco IOS軟體版本12.0(3)引入了介面MTU不匹配檢測。此檢測包括OSPF在DBD資料包中通告介面MTU，這與OSPF RFC 2178附錄G.9中的內容一致。當路由器收到通告的DBD資料包時，如果該MTU大於路由器可以接收的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/撥號程式之間的鄰居。
兩個路由器具有相同的路由器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	初始版本

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

下載選項

無偏見用語

關於此翻譯

目錄

簡介

必要條件

需求

採用元件

慣例

背景資訊

Exstart狀態

交換狀態

鄰居停滯在Exstart/Exchange狀態

解決方案

相關資訊

修訂記錄

由思科工程師貢獻

這份文件是否有所幫助？

讓思科協助您