本博文将为您详细介绍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
