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

2018年6月26日23:30:17

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值更小的一侧使用该命令即可。

 


  • 更新时间:2018年6月26日23:30:17 ,共 1670 字。