本檔案介紹開放最短路徑優先(OSPF)封包、最大過渡單元(MTU)、連結狀態通告(LSA)和連結狀態(LS)更新封包在思科錯誤ID CSCse01519情況下的互動。
路由器上的鏈路具有MTU。傳出資料包(如OSPF資料包)不能大於介面MTU。
請求註釋(RFC)2328文檔了OSPF協定的第2版。RFC 2328的附錄A.1以這種方式描述OSPF資料包的封裝:
OSPF直接通過Internet協定的網路層運行。因此,OSPF資料包僅通過IP報頭和本地資料鏈路報頭進行封裝。
OSPF不定義將其協定資料包分段的方法,並且在傳輸大於網路MTU的資料包時取決於IP分段。如有必要,OSPF資料包的長度最多可達65,535位元組(包括IP報頭)。 可能較大的OSPF資料包型別(資料庫描述資料包、鏈路狀態請求、鏈路狀態更新和鏈路狀態確認資料包)通常可以拆分為多個獨立的協定資料包,而不會丟失功能。建議這樣做;應儘可能避免IP分段。
LS更新資料包中可以有一個或多個LSA。一個LS更新資料包中的許多LSA稱為將LSA打包到LS更新資料包中。
資料庫說明(DBD)資料包(也在RFC 2328中指定)描述了OSPF鏈路狀態資料庫的內容:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
RFC 2328的附錄A.3.3將介面MTU描述為:
可以從關聯介面發出的最大IP資料包大小(以位元組為單位),而不進行分段。
當OSPF鄰接關係初始化時,連線到鏈路的路由器會交換其在DBD資料包中的介面MTU值。
RFC 2328第10.6節規定:
如果資料庫說明資料包中的Interface MTU欄位指示接收介面上大於路由器可以接受而不進行分段的IP資料包大小,則拒絕資料庫說明資料包。
使用debug ip ospf adj命令時,可以看到這些DBD資料包的到達。
在本示例中,兩個OSPF鄰居之間的MTU值不匹配。此路由器有MTU 1600:
OSPF: Rcv DBD from 10.100.1.2 on GigabitEthernet0/1 seq 0x2124 opt 0x52 flag 0x2
len 1452 mtu 2000 state EXSTART
OSPF: Nbr 10.100.1.2 has larger interface MTU
另一台OSPF路由器具有介面MTU 2000:
OSPF: Rcv DBD from 10.100.100.1 on GigabitEthernet0/1 seq 0x89E opt 0x52 flag 0x7
len 32 mtu 1600 state EXCHANGE
OSPF: Nbr 10.100.100.1 has smaller interface MTU
DBD資料包將連續重新傳輸,直到OSPF鄰接關係最終被斷開。
OSPF: Send DBD to 10.100.1.2 on GigabitEthernet0/1 seq 0x9E6 opt 0x52 flag 0x7
len 32
OSPF: Retransmitting DBD to 10.100.1.2 on GigabitEthernet0/1 [10]
OSPF: Send DBD to 10.100.1.2 on GigabitEthernet0/1 seq 0x9E6 opt 0x52 flag 0x7
len 32
OSPF: Retransmitting DBD to 10.100.1.2 on GigabitEthernet0/1 [11]
%OSPF-5-ADJCHG: Process 1, Nbr 10.100.1.2 on GigabitEthernet0/1 from EXSTART to
DOWN, Neighbor Down: Too many retransmissions
在Cisco錯誤ID CSCse01519之前,Cisco IOS®軟體中的OSPF會構建不大於1500位元組的OSPF資料包,而不考慮介面MTU。因此,如果介面MTU大於1500位元組,OSPF仍最多只將1500位元組打包到OSPF資料包中。這種效率有些低下,因為OSPF可以在鏈路上傳送較大的資料包並實現更大的吞吐量。
同樣,如果傳出介面的MTU小於1500位元組,OSPF程式仍會建立或壓縮1500位元組的OSPF封包,而路由器的IP堆疊會將封包分段為較小的IP封包,以適合傳出連結的MTU。這通常發生在運行OSPF的兩台路由器之間的IPSec隧道中。通道封裝位元組的額外負荷導致的MTU小於1500位元組。OSPF構建的OSPF資料包最多1500位元組,然後資料包在路由器傳輸之前被分段。這是額外的低效率。
在Cisco錯誤ID CSCse01519之後,IOS中的OSPF可以將OSPF資料包封裝為大於1500位元組。如果傳出介面的MTU大於1500位元組,就會發生這種情況。由於可以將更多資訊打包到一個更大的資料包中,因此傳輸效率更高。換句話說,如果某個OSPF路由器需要將多個外部LSA傳輸到OSPF鄰居,則在該路由器運行具有Cisco錯誤ID CSCse01519的IOS時,該路由器可以將多個外部LSA打包到一個LS更新資料包中。
思科錯誤ID CSCse01519還允許OSPF構建小於1500位元組的資料包。在某些情況下,兩個OSPF鄰居之間的MTU小於1500位元組。在上一個使用IPSec通道的範例中,OSPF傳輸小於1500位元組的OSPF封包,並避免IP分段;同樣地,大於介面MTU的LSA也會例外。
升級OSPF路由器時,可能會發現Cisco錯誤ID CSCse01519導致的OSPF MTU問題。
許多網路具有OSPF鄰居,這些鄰居通過第2層(L2)交換網路或傳輸網路連線,該網路由L2 VPN服務或同步數字階層/同步光纖網路(SDH/SONET)網路組成。這些傳輸網路的MTU設定可能與運行OSPF的路由器不同。
雖然所有路由器上的MTU設定都應該正確且應反映真實的MTU,但經常會有一些錯誤未被注意。
這是運行OSPF的兩台路由器的網路示例。路由器1(R1)和路由器2(R2)通過L2交換機連線。
在本例中,路由器的GigabitEthernet介面的MTU設定為2000。L2交換機的MTU只有1500位元組。
如果資料流量大小從不大於1500位元組,可以使用IOS而不使用思科錯誤ID CSCse01519,因為OSPF封包永遠不會大於1500位元組。例如,如果存在一個1800位元組的LSA,則R1或R2上的OSPF進程會構建一個大於1500位元組的LS更新資料包並進行傳輸,但該資料包會被路由器之間的L2交換機丟棄。
如果R2上的OSPF資料庫有足夠的網路,則本地產生的LSA非常大,因此LS更新資料包可能大於介面MTU。
假設兩台路由器都運行沒有Cisco錯誤ID CSCse01519的IOS版本。
建立OSPF鄰接關係時,請注意R1從未收到大於1500位元組的OSPF資料包,儘管介面的MTU為2000。
啟用debug ip ospf packets命令。
OSPF: rcv. v:2 t:1 l:48 rid:10.100.1.2
aid:0.0.0.0 chk:72CF aut:0 auk: from GigabitEthernet0/1
...
OSPF: rcv. v:2 t:4 l:1468 rid:10.100.1.2
aid:0.0.0.0 chk:8389 aut:0 auk: from GigabitEthernet0/1
OSPF: rcv. v:2 t:4 l:136 rid:10.100.1.2
...
在此調試輸出中,「l:1468」是OSPF資料包的長度,因此您可以看到最大的OSPF資料包是1468位元組。「t:4」表示OSPF資料包為型別4,即鏈路狀態更新資料包。RFC 2328第4.3節中的下表定義了不同的OSPF資料包型別:
類型 | 資料包名稱 | 協定功能 |
1 | Hello | 發現/維護鄰居 |
2 | 資料庫說明 | 彙總資料庫內容 |
3 | 鏈路狀態請求 | 資料庫下載 |
4 | 鏈路狀態更新 | 資料庫更新 |
5 | 鏈路狀態Ack | 泛洪確認 |
OSPF鄰接關係達到「FULL」狀態。
R1#show ip ospf neighbor gigabitEthernet 0/1
Neighbor ID Pri State Dead Time Address Interface
10.100.1.2 0 FULL/ - 00:00:34 10.1.1.2 GigabitEthernet0/1
R2#show ip ospf neighbor gigabitEthernet 0/1
Neighbor ID Pri State Dead Time Address Interface
10.100.100.1 0 FULL/ - 00:00:34 10.1.1.1 GigabitEthernet0/1
接下來,使用Cisco錯誤ID CSCse01519將R2上的IOS升級到IOS版本。
R2#show ip ospf neighbor gigabitEthernet 0/1
Neighbor ID Pri State Dead Time Address Interface
10.100.100.1 0 LOADING/ - 00:00:33 10.1.1.1 GigabitEthernet0/1
R2#show ip ospf neighbor gigabitEthernet 0/1 detail
Neighbor 10.100.100.1, interface address 10.1.1.1
In the area 0 via interface GigabitEthernet0/1
Neighbor priority is 0, State is LOADING, 5 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x12 in Hello (E-bit L-bit )
Options is 0x52 in DBD (E-bit L-bit O-bit)
LLS Options is 0x1 (LR)
Dead timer due in 00:00:39
Neighbor is up for 00:00:49
Index 1/1, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Number of retransmissions for last link state request packet 9
Poll due in 00:00:00
R2#show ip ospf neighbor gigabitEthernet 0/1 detail
Neighbor 10.100.100.1, interface address 10.1.1.1
In the area 0 via interface GigabitEthernet0/1
Neighbor priority is 0, State is LOADING, 5 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x12 in Hello (E-bit L-bit )
Options is 0x52 in DBD (E-bit L-bit O-bit)
LLS Options is 0x1 (LR)
Dead timer due in 00:00:33
Neighbor is up for 00:02:06
Index 1/1, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Number of retransmissions for last link state request packet 25
Poll due in 00:00:03
%OSPF-5-ADJCHG: Process 1, Nbr 10.100.100.1 on GigabitEthernet0/1 from LOADING
to DOWN, Neighbor Down: Too many retransmissions
OSPF鄰接關係停滯在「LOADING」狀態,未達到「FULL」狀態。在OSPF達到25次重傳的限制之前會進行重傳。OSPF嘗試再次建立鄰接關係,相同的問題再次出現,環路無休止地繼續。
因此,R2上的升級發現了一個以前隱藏的問題:底層MTU小於OSPF路由器使用的MTU。
交換器將MTU變更為2000時,會順利傳輸大於1500位元組(「l:1980」)的OSPF封包。
R1#
OSPF: rcv. v:2 t:3 l:1980 rid:10.100.1.2
aid:0.0.0.0 chk:AC5B aut:0 auk: from GigabitEthernet0/1
若要檢查基本MTU問題,請一律對大小等於MTU和DF(不分段)位集的OSPF鄰居IP位址執行ping。
為了發現底層MTU的值,請執行ping並掃描大小。對輸出中的感歎號(!)進行計數以確定正確的MTU。在本範例中,ping指令的最後一次回應回覆大小為1500位元組。
R2#ping
Protocol [ip]:
Target IP address: 10.1.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: yes
Sweep min size [36]: 1460
Sweep max size [18024]: 1540
Sweep interval [1]:
Type escape sequence to abort.
Sending 81, [1460..1540]-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.............................
...........
Success rate is 49 percent (40/81), round-trip min/avg/max = 1/1/4 ms