某局点使用MSR V7 和其他厂家路由器对接ospf 状态持续卡在exchange问题处理经验案例

无

某局点之前使用V5 的MSR和对端其他设备对接ospf使用正常，但是后期扩容，需要将V7 MSR替换掉V5的MSR 设备，但是替换之后，发现ospf 状态异常，状态一直卡在exchange状态，对比V5和V7的配置，并无发现任何异常，指导收集V5的debug ospf 和V7 的debug ospf 对比。

刚开始对比v5和v7debug发现两边的option 字段不同，发现我们V5和V7路由器在协商报文的时候一个option有带了一个o一个没有带。o位，用来表明始发路由器支持Opaque LSA，怀疑第三方厂家对接的时候可能由于对方厂家不支持携带该字段，导致无法协商成功，指导客户在ospf进程下配置undo opaque-capability 后发现还是无法建立起来，说明不是这个问题，后续再让客户在V7侧抓包查看。

//V5 debug 信息

*Mar 19 20:09:20:661 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: OSPF 203: SEND Packet.
*Mar 19 20:09:20:662 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: Source Address: 22.169.x.x
*Mar 19 20:09:20:662 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: Destination Address: 224.0.0.5
*Mar 19 20:09:20:663 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: Ver# 2, Type: 1, Length: 44.
*Mar 19 20:09:20:663 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: Router: 20.1.x.x, Area: 0.0.0.200, Checksum: 46455.
*Mar 19 20:09:20:663 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: AuType: 00, Key(ascii): 0 0 0 0 0 0 0 0.
*Mar 19 20:09:20:664 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: Net Mask: 255.255.255.224, Hello Int: 10, Option: _E_.
*Mar 19 20:09:20:664 2019 KZX-LANZHOU-R1 RM/6/RMDEBUG: Rtr Priority: 1, Dead Int: 40, DR: 22.169.x.x, BDR: 0.0.0.0.

//V7 debug 信息

*Jan  1 09:03:52:668 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: OSPF 203: Receiving packets.                                                   
*Jan  1 09:03:52:668 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: Source address: 21.169.x.x                                                
*Jan  1 09:03:52:668 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: Destination address: 224.0.0.5                                                 
*Jan  1 09:03:52:668 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: Version 2, Type: 2, Length: 32.                                                
*Jan  1 09:03:52:668 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: Router: 20.1.x.x, Area: 0.0.0.200, Checksum: 22119.                          
*Jan  1 09:03:52:668 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: Authentication type: 00, Key(ASCII): 0 0 0 0 0 0 0 0.                          
*Jan  1 09:03:52:669 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: MTU: 1500, Option: _O_E_, R_I_M_MS Bit: _I_M_MS_.                              
*Jan  1 09:03:52:669 2011 KZX-LANZHOU-R1 OSPF/7/DEBUG: DD Sequence number: 48e9132.                 

通过抓包查看发现两边发送DD报文的方式不一样，V7 使用单播方式发送，但是对端使用组播方式发送，P2P口上使用单播发送DD能够解决“单播不通时OSPF邻居仍能full、导致有路由却转发不通”的问题，在产品主流的分支版本上都已经调整为单播方式了。大多友商设备也是使用单播方式发送DD报文了。

现场替换V7设备后，MSR DD报文都是单播发送的，对端的DD是组播发送的。MSR可以发送第2个DD报文，但是对端一直在重复发送DD的第1个报文，MSR可以兼容对端，对端却出现了无法兼容本端的报文。

所以建议客户协调对面设备更改为单播方式发送，问题解决。