目錄

簡介

必要條件

需求

採用元件

慣例

背景資訊

Exstart狀態

交換狀態

鄰居停滯在Exstart/Exchange狀態

解決方案

相關資訊

簡介

本文說明如何排解開放最短路徑優先(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 命令顯示的輸出類似於下圖所示。

通過幀中繼連線路由器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的輸出為：

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

2. Router 7調試輸出：

<<<OSPF NOT ENABLED ON ROUTER7 YET>>>

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

4. Router 7調試輸出：

<<<OSPF NOT ENABLED ON ROUTER7 YET>>>

5. 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

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

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

8. 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

9. 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

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

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

12. 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

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

14. 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資料包，嘗試確認這些資料包，並一直保持交換狀態。

由於路由器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資料包。此環路會無限期地持續下去，這可以防止任一路由器轉變為exstart/exchange狀態。

解決方案

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

附註：Cisco IOS軟體版本12.0(3)引入了介面MTU不相符偵測。此檢測涉及在DBD資料包中通告介面MTU的OSPF，它符合OSPFRFC 2178（附錄G.9）。當路由器收到通告的DBD資料包的MTU大於路由器可以接收的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資料包。但是，根本原因可能是以下任何一種：

- MTU不匹配

- 單播已損壞。在Exstart狀態下，路由器將單播資料包傳送到鄰居以選擇Primary和Subordinate。除非您有點對點鏈路（在這種情況下，它會傳送組播資料包），否則這是正確的。可能的原因如下：

- 高度冗餘網路中的非同步傳輸模式(ATM)或幀中繼環境中的錯誤虛電路(VC)對映。

- MTU問題，表示路由器只能對特定長度的封包執行ping。

- 訪問清單阻止單播資料包。

- NAT在路由器上運行並轉換單播資料包。

- PRI和BRI/撥號器之間的鄰居。

- 兩台路由器具有相同的Router-ID（配置錯誤）。

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

- 序列號不匹配。

- 意外的DD序列號。

- 「I」位被意外設定。

- 選項欄位與DBD資料包中收到的最後一個選項欄位不同。

- BadLSReq

- 鄰居在交換過程中傳送無法識別的LSA。

- 鄰居在無法找到的交換過程中請求了LSA。

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

相關資訊

- OSPF鄰居狀態

- OSPF鄰居問題說明

- 技術支援 - Cisco Systems