OSPF interface neighbors are ExStart were working

[journeyman]

A previously working OSPF area now has issues. Troubleshooting using this KB article but stuck now.

FGT1 is an ABR with multiple OSPF areas. Area 0.0.0.3 has 2 neighbors (FGT2 and FGT3) and 3 interfaces - the primary link and two ipsec tunnels (one each neighbor).

Routing on the primary link has failed. This is the only problem - all other areas are OK, and the ipsec backups within this area are also OK.

Ping is OK to both neighbors' primary interface IP. Also it is possible to ssh* to FGT2 and FGT3. Heavily summarised diagnostic output as follows

FGT1 # get router info ospf neighbor

FGT1 # <FGT2> ExStart/Backup

FGT1 # <FGT3> ExStart/DROther

FGT1 # get router info ospf status

FGT1 # Area 0.0.0.3

FGT1 # Number of interfaces is 3

FGT1 # Number of neighbors is 2

FGT1 # get router info ospf interface

FGT1 # My-Interface is up

FGT1 # Neighbor Count is 2, Adjacent neighbor count is 0 <<< I guess this is a problemFGT2 and FGT3

FGT2 # get router info ospf neighbor

FGT2 # <FGT1> Exchange/DR

FGT2 # <FGT3> Full/DROther

FGT3 # get router info ospf neighbor

FGT3 # <FGT1> Exchange/DR

FGT3 # <FGT2> Full/Backup

Hello, Dead, Wait and retransmit times match (all default).

The output of diagnose ip router ospf / diagnose debug is a bit beyond me, but interesting bits incude:

NFSM DD inactivity timer expire

NFSM ExStart (AdjOK?)

NFSM DD Retransmit timer expire

RECV[LS-Upd] Neighbor state is less than Exchange* ssh working up to a point. Of note is that the ssh session to FGT2 and FGT3 (primary interface) will hang on the command get router info ospf interface (MTU issue?).

The primary interface is a complicated beast. There's MPLS, E1, microwave radio... however similar infrastructure is also present on other areas / interfaces that are working.

My suspicion is something to do with the infrastructure of the primary interface, this under investigation but nothing found yet.

What conclusion can be drawn from the adjacent neighbor count = 0 above?

Any suggested for further diagnostics or other thoughts?

[journeyman]

There is a possibility that MTU changes were made on the MPLS. Can't confirm until tomorrow.

[emnoc · Accepted solution]

Set the ospf mtu-ignore and move on. You can always validate MTU sizes and mismatch by

1: conducting  packet capture of the 2 ospf neighbors in exStart ( MTU is shown in the packet )

2:  execute-ping with the DF bit set

e.g

 execute ping-options df-bit yes /B]

than conduct pings across the  area 3 link between the 2 neighbors, slowly increase the payload size till the pings drops off.

e.g

 execute ping-options data-size 1460

[journeyman]

Confirmed someone made some "experimental" changes. The changes have been backed out and a convincing case made to cease unmanaged experiments.

Next step is a design process in which we participate instead of fault finding a broken service after the fact.

Thanks for pointing out ospf-interface mtu settings. There are however some other devices in the path which may not be so adaptable.

[emnoc]

FYI will you ignore the mtu in the OSPF datagram, you have nothing to adapt to. The field and this parameter in the OSPF hello packet is ignored. The field is  always present regardless,  but it's ignored by all ospf-speakers that have it ignored

[journeyman]

Thanks again. We also lost access to managed switches so MTU changes are a bigger problem than getting OSPF to work.