OSPF interface neighbors are ExStart were working

Question

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?

emnoc · Accepted Answer

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 · Answer

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

Sign up

Login with SSO

Login to the community

Login with SSO