MTU设置不正确导致OSPF邻居不能建立

ospf的配置过程可能不小心会忽略掉这个问题，因为不同厂家默认的Mtu值可能是不一样的，在应用时使用默认值就会出现下属情况

故障现象：
         OSPF邻居关系无法正常建立，OSPF的状态机一直处理Exstart和Down之间来回跳转。

debug信息：

3:24:29: OSPF: Nbr 192.168.4.12 on Vlan2 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
3:24:29: OSPF: Nbr 192.168.4.11 on Vlan2 from LOADING to FULL, Loading Done
3:24:30: OSPF:  Nbr 192.168.4.12on Vlan2 from DOWN to DOWN, Neighbor Down: Ignore timer expired
3:24:30: OSPF:  Nbr 192.168.4.12on Vlan2 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
3:24:30: OSPF:  Nbr 192.168.4.11 on Vlan2 from LOADING to FULL, Loading Done
3:24:30: OSPF: Nbr 192.168.4.12 on Vlan2 from DOWN to DOWN, Neighbor Down: Ignore timer expired

处理步骤：

－、先熟悉一下OSPF邻居建立的几个步骤：
1、down未连接状态
2、init 初始状态
3、Two-way状态 设备出现在对端设备发送的路由信息中，就进入two－way状态
4、exstart 确定主从关系，即谁先发送dbd报文
5、exchang 在主设备的带领下开始交换dbd报文
6、loading 请求更详细的信息
7、full 建立邻接关系

二、从日志信息中可以看出，OSPF邻居关系建立的步骤是从1到4步后再无法进行下去了，只能又重新1步开始了。因为能进行到第4步，所以可以排除OSPF链路出现DOWN的问题了。由于在第4步就无法建立下去了，也就是说DBD包协商不成功。在Exstart阶段进行DBD包协商主从关系时会比较MTU值，如果两边DBD报文中的MTU参数相互之间不符合将会协商不成功。在DBD报文中进行MTU的比较的原因主要是由于DBD报文的内容比较大，如果两边的MTU值不一致的话很可能会造成DBD包丢弃，所以会在Exstart过程中增加MTU的协商过程。所以对OSPF邻居关系的端口MTU一致性进行检查。

三、经检查发现OSPF两侧设备的MTU值确实不一致，由于对端路由器/交换机上还有一些MPLS VPN的业务，为保证业务的正常对所有端口的MTU的进行了调整，而出问题的那个端口是不承载MPLS VPN业务的，本来不应该对MTU值进行更改。由于两侧MTU的不一致引起了OSPF邻居关系的震荡。由于DBD进行MTU参数比较只是在OSPF的Exstart阶段进行的，如果OSPF邻居关系一直处于Full的状态时更改MTU并不会中断OSPF邻居关系，只有在OSPF邻居关系重建时才会出现以上的问题。而且一直会出现OSPF的振荡。

 如果细心查看的话会发现debug的信息下有mtu值的显示

03:25:44: OSPF: Rcv DBD from 192.168.4.12 on Vlan1 seq 0x3099 opt 0x2 flag 0x3 len 72 mtu 1500 state EXCHANGE

 

处理结果：

        由于设备两端的端口的MTU值不同，造成OSPF的exstart协商无法通过，只要把两端设备端口的MTU值设置成一致就可以了。

 

 

 

-----------------------------------------------------------------------

http://mandyc.blog.51cto.com/1230448/379839