OSPF：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>

Value单位：Byte

Value取值范围：68~1500

1500为接口默认值

（2）通过配置，忽略MTU值不一致的问题

Router（config-if）#ip ospf mtu-ignore

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

本文出自 “Thely” 博客，请务必保留此出处http://thely.blog.51cto.com/2695427/1016294