104协议中的asdu地址（8472协议中a0a2地址位变更）

本文描述如何排除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常見問題故障排除。

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

一旦協商好關係（具有最高路由器ID的路由器成為主要路由器），相鄰路由器就轉換為Exchange狀態。在此狀態下，路由器交換DBD資料包，這些資料包描述其整個鏈路狀態資料庫。路由器還會傳送鏈路狀態請求資料包，這些資料包從鄰居請求最新的鏈路狀態通告(LSA)。

儘管OSPF鄰居在正常OSPF鄰接建立過程中會透過Exstart/Exchange狀態進行轉換，但OSPF鄰居停滯在此狀態並不正常。下一節將說明OSPF鄰居停滯在此狀態的最常見原因。有關不同OSPF狀態的詳細資訊，請參閱瞭解OSPF鄰居狀態。

當您嘗試在Cisco路由器和其他供應商路由器之間運行OSPF時，此問題最常出現。當路由器介面的最大傳輸單元(MTU)設定不匹配時，會發生此問題。如果MTU較大的路由器向鄰居路由器傳送了一個資料包，該資料包的大小大於鄰居路由器上設定的MTU，則鄰居路由器會忽略該資料包。當此問題發生時，命令的輸出將與下圖所示的輸出類似顯示。

OSPF Neighbor

本節介紹此問題的實際重現過程。

本圖中的路由器6和路由器7透過幀中繼連線，並且路由器6配置了5條靜態路由，這些路由已重分配到OSPF中。路由器6上的串列介面的預設MTU為1500，而路由器7上的串列介面的MTU為1450。每個路由器的配置都顯示在表中（僅顯示必要的配置資訊）：

每個路由器的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資料包時，會發生此問題。請在每個路由器上使用和命令，以便檢視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 0x

路由器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 ( NEGOTIATION - ROUTER 6 IS )>>>

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

路由器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 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資料包，作為主/從協商的一部分。確定後，路由器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(作為路由器)，採用路由器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不形成鄰居時，請考慮先前提到的因素，例如物理介質和網路硬體，以便排除故障。

瞭解OSPF鄰居狀態
排除OSPF鄰居故障
思科技術支援與下載

到此这篇104协议中的asdu地址（8472协议中a0a2地址位变更）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！

上一篇： labview调用dll动态库（labview调用dll动态库使用相对路径）

下一篇：电路工作原理图（电路工作原理图和电路图一样吗）

版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/jszy-jszl/60629.html

相关文章：