Before we dive into the Troubleshooting of OSPF states, please refer to this Post that explains each OSPF state:

OSPF stuck in Down State

• Description OSPF Down State::

A neighbor that is discovered dynamically through the reception of HELLO packets can fall back to a Down state if it is being deleted, for example when OSPF does not receive HELLO packets from the neighbor for a period of time longer than the Dead timer interval.

Usually, neighbors that are seen in the down state were manually configured with the neighbor command. If OSPF has never received HELLO packets from the manually configured neighbor then the manually configured neighbor will be listed as down.

Note: Manually configured neighbors are always present in the OSPF neighbor table.

• Troubleshoot OSPF stuck in Down state:

– Verify that the neighbor router is up, is running, and is properly configured for OSPF on this interface.

– Test connectivity between routers with the ping and traceroute commands (no more than 1 hop).

– Check the OSPF neighbor table on the neighboring router with the show ip ospf neighbor command.

If still down, please re-check the steps mentioned in this article to Troubleshoot OSPF Neighbor not showing in show ip ospf neighbor Command.

OSPF stuck in INIT State

• Description of OSPF INIT State:

– Being in this state indicates that a router received HELLO packets from the neighbor.

– The problem here is that two-way communication has not been established. For two-way communication to be established with a neighbor, a router also must see its own Router ID in the Neighbor field of the neighbor’s HELLO packets.

To summarize, a router with a neighbor in the init state has received hello packets from the neighbor but has not seen its own Router ID in the neighbor’s hellos.

• Troubleshoot of OSPF stuck in INIT State:

– If there are any access lists defined on the neighbor’s interface, the destination IP of 224.0.0.5 (all ospf routers multicast address) must be permitted in the input access list.  You can test this with the ping command to 224.0.0.5 and confirm that responses are received from the neighboring router(s).

– Verify that Authentication is enabled correctly (or not enabled) on both sides. The router on which authentication is not enabled can process hello packets from the neighbor (which will lead OSPF to be stuck in the Init state).

OSPF stuck in 2-WAY State

• Description of OSPF 2-WAY State:

The 2-WAY state indicates that the router has established the INIT state which means that the router can see its own Router ID in the Neighbor field of the neighbor’s HELLO packet.

Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also cause a transition to a 2-WAY state.

• Troubleshoot of OSPF stuck in 2-WAY State:

In the Broadcast network type, where DR and BDR are elected, It’s normal that DROther routers establish full adjacency only with the Designated Router (DR) and the Backup Designated Router (BDR). The OSPF neighborship with the rest of the routers in the segment will stay in 2-WAY State.

Please refer to OSPF DR and BDR Election Explained [with Configuration].

But, Why Do Routers Only Form Full Adjacencies with the DR or BDR?

OSPF stuck in Exstart/Exchange State

• Description of OSPF Exstart/Exchange State:

OSPF neighbors that are in exstart or exchange state are trying to exchange DBD packets. The router and its neighbor form a Master and Slave relationship after negotiation (highest router-ID becomes the Master). Based on this relationship, The Master router determines the initial database descriptor (DBD) sequence number to use while exchanging DBD packets.

• Troubleshoot of OSPF stuck in Exstart/Exchange State:

The adjacency should continue past this state. If it does not, there is a problem with the DBD exchange, such as a maximum transmission unit (MTU) mismatch or the receipt of an unexpected DBD sequence number.

The problem occurs when the maximum transmission unit (MTU) settings for neighboring router interfaces don’t match.

If the router with the higher MTU sends a DBD packet larger than the MTU set on the neighboring router, the neighboring router ignores the DBD packet, which will lead the neighbor state remains in exstart.

You can debug OSPF adjacency to confirm that the issue is related to an MTU mismatch:

00:04:13: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
00:04:13: OSPF: 2 Way Communication to 170.170.11.7 on 
Serial2.7, state 2WAY

To fix this problem, ensure that the MTU values are the same on both ends of the OSPF Neighbor Routers Interfaces.

To overcome this issue, Starting from Cisco IOS Software 12.01(3), the ip ospf mtu-ignore interface configuration command was introduced to turn off the MTU mismatch detection.

OSPF stuck in Loading State

• Description of OSPF Loading State:

In this state, routers send link-state request packets (LSA, LSU, etc). During the adjacency, if a router receives an outdated or missing link-state advertisement (LSA), it requests that LSA by sending a link-state request packet.

• Troubleshoot of OSPF stuck in Loading State:

Neighbors that do not transition beyond this state are probably exchanging corrupted LSAs. This problem is usually accompanied by a %OSPF-4-BADLSA console message.

Thanks, That’s all.

You can also refer to this article to Troubleshoot OSPF Adjacency, from Cisco.