OSPF：MTU不一致导致的邻接关系问题
|
本博文将为您详细介绍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 【编辑推荐】 （编辑：淮北站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |