OSPF：MTU不一致导致的邻接关系问题

ZDNET网络频道 12月17日 综合消息：本博文将为您详细介绍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值更小的一侧使用该命令即可。