本博文將為您詳細介紹MTU不一致導致的鄰接關系問題及解決方法。

1.MTU不一致 

(1)何時關注MTU

從Exstart狀態開始，OSPF進程關注來自鄰居的DD消息中的 Interface MTU 字段

(2)何時忽略DD

如果接收到的DD消息中Interface MTU值大于本地接口MTU，則忽略此DD消息

(3)MTU不一致結果

接收到DD中的 Interface MTU 與本地接口MTU不一致時，鄰接關系卡在 Exstart/Exstart 或 Exstart/Exchange 狀態

Master的常規判斷步驟

(1)We are not Slave——比較Rouer-ID

(2)We are the Master——接收到DD以本地發送Seq Number進行隱式確認

Slave的常規判斷步驟

(1)We are the Slave——比較Router-ID

正是因為以上判斷步驟的不同，導致了MTU不一致時，有了兩種情況出現

2.Exstart/Exstart

聲明：

以下描述的Master/Slave都是宏觀上正常情況下選舉的結果，更正確的描述應該為原本通過選舉應該成為Master或Slave的設備

(1)何時發生

Master發送的DD消息，其Interface MTU值更大

(2)情況描述

①Slave在確定的接口角色后，便向鄰居發送DD消息

②Master接收到來自Slave的DD消息(尚未隱式確認)，其DD中Interface MTU值小于本地接口MTU，控制臺提示如下：

Nbr 1.1.1.1 has smaller interface MTU

First DBD and we are not SLAVE

雖然控制臺有提示，但是依然讀取該消息內容，試圖確定Master/Slave

此時Master與Slave的鄰接關系為Exstart

③與此同時，Master也會向Slave發送DD消息，但由于該DD消息的Interface MTU值大于Slave本地接口值，Slave忽略此消息

控制臺提示如下：

Nbr 2.2.2.2 has larger interface MTU

由于不讀取該DD內容，實際上Slave本地甚至無法確定自己是Slave，更不會以Master發送的DD的Seq Number作為回復

此時，與Master的鄰接關系為Exstart

④Slave由于一直忽略Master發送的DD，相當于對于發送給Master的DD始終沒有收到回復，本地將重傳其First DD

⑤Master一直沒有收到帶有隱式確認的DD消息，認為發送給Slave的消息沒有得到回復，也將重傳其DD

⑥最終，兩臺設備之間卡在Exstart/Exstart狀態

3.Exstart/Exchange

(1)何時發生

Slave發送的DD消息，其Interface MTU值更大

(2)情況描述

①Master接收到來自Slave的DD消息，由于其MTU值更大，本地忽略此DD消息

由于始終忽略此DD消息，本地將重傳該DD

此時與Slave狀態為Exstart

②Slave接收到來自Master的DD消息，其MTU值更小，因此該消息有效

③通過比較Router-ID，本地確認自己是Slave，且觸發向Master發送帶有LSA頭部的DD消息，包含隱式確認

控制臺提示如下：

Nbr 2.2.2.2 has smaller interface MTU

Send DBD to 2.2.2.2 on FastEthernet0/0 seq 0x103B opt 0x52 flag 0x0 len 32

NBR Negotiation Done. We are the SLAVE

此時在Slave一側，將Master置為Exchange

④最終，兩臺設備之間卡在Exstart/Exchange狀態

注意：

DD消息默認重傳時間為5s

4.解決辦法

(1)修改接口MTU值

Router(config-if)#ip mtu

Value單位：Byte

Value取值范圍：68~1500

1500為接口默認值

(2)通過配置，忽略MTU值不一致的問題

Router(config-if)#ip ospf mtu-ignore

由于是接收到值更大的MTU時忽略DD消息，因此一般在接口MTU值更小的一側使用該命令即可。

原文鏈接：http://blog.csdn.net/blakegao/article/details/16345021