A Case about an OSPF neighbor of MSR could not be established

Network Topology

Null

he original MSR3011 router has a normal relationship with the OSPF neighbor of CS equipment. After replacing it with 3600, the OSPF neighbor has failed to establish and the state has been in ExStart state.

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: OSPF 103: Sending packets.                                                     

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Source address: 21.49.127.62                                                   

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Destination address: 21.49.127.61                                              

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Version 2, Type: 2, Length: 32.                                                

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Router: 1.1.1.9, Area: 0.0.0.6, Checksum: 29749.                            

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Authentication type: 00, Key(ASCII): 0 0 0 0 0 0 0 0.                          

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: MTU: 1500, Option: _O_E_,R_I_M_MS Bit:_I_M_MS_  .                              

*Dec  3 06:58:29:404 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: DD Sequence number: 95b.                                                       

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: OSPF 103: Receiving packets.                                                   

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Source address: 21.49.127.61                                                   

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Destination address: 21.49.127.62                                               

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Version 2, Type: 2, Length: 32.                                                

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Router: 2.2.2.9, Area: 0.0.0.6, Checksum: 25205.                             

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: Authentication type: 00, Key(ASCII): 0 0 0 0 0 0 0 0.                          

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: MTU: 1500, Option: _O_L_E_,R_I_M_MS Bit:_I_M_MS_.                            

*Dec  3 06:58:29:524 2020 CC-FSZ2-SL-RT1 OSPF/7/DEBUG: DD Sequence number: 1875.   

We can see that the message from the opposite CS device has an “L” set, which usually appears in the first message of DD. Therefore, it is suspected that the opposite CS device did not receive the DD message from our device, so it keeps retransmitting the OSPF DD message.

Packet capture information also shows that our device has sent DD message, but the opposite CS device replied that ICMP was unreachable, so the CS device obviously received the DD message from our device, but it filtered out the message, resulting in the neighbor establishment failure.

We checked the configuration of the CS device and found that the ARP binding was set.  After replacing the device, the DD of 3600 was discarded, so the OSPF neighbor establishment failed.

Solution

After the ARP binding to the end device is unbound, the OSPF neighbor is established normally.