The following is a list of the different states that OSPF can be stuck in
and some of the possible causes.
OSPF Stuck in ATTEMPT
This problem is only valid for NMBA
networks in which neighbor statements have been defined. Stuck in ATTEMPT means
that a router is trying to contact a neighbor by sending its Hello, but it has
not received a response. The output of show ip ospf
neighbor indicates this problem exists.

The most
common possible causes of the problem are:
- Misconfigured neighbor statement
- Unicast connectivity is broken on NBMA, which could be due to a wrong DLCI,
an access list, or NAT translating the unicast.
OSPF Stuck in INIT
The INIT state indicates that a router
sees hello packets from the neighbor, but two-way communication has not been
established. A Cisco router includes the router IDs of all neighbors in the
INIT (or higher) state in the neighbor field of its hello packets. 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 hello packets coming from the neighbor
router. The output of the show ip ospf neighbor command
indicates that the router is stuck in INIT.

The most common possible causes of this problem are:
- An access list on one side is blocking OSPF Hellos.
- Multicast capabilities are broken on one side (switch problem).
- Authentication is enabled on only one side.
- The frame-relay map/dialer map statement on one side is missing the
broadcast keyword.
- Hellos are getting lost on one side at Layer 2.
OSPF Stuck in 2-WAY
The 2-WAY state is an indication that
the router has seen its own Router ID in the neighbor field of the neighbor
hello packet. The reception of a Database Descriptor (DBD) packet from a
neighbor in the INIT state will also cause a transition to 2-way state. The
OSPF neighbor 2-WAY state is not a cause for concern.
On networks that
require a DR/BDR election to take place, if all routers are configured with
priority 0, there will be no election process. All routers will remain in 2-WAY
state, as the show ip ospf neighbor command will indicate.
The solution is
to make sure at least one router has an ip ospf priority of at least 1.
OSPF Stuck in EXSTART/EXCHANGE
OSPF neighbors that are in EXSTART
or EXCHANGE state are in the process of trying to exchange DBD packets. The
router and its neighbor form a master/slave relationship. The adjacency should
continue past this state. If it does not, there is a problem with the DBD
exchange, such as MTU mismatch, or the receipt of an unexpected DBD sequence
number.
The most common possible causes of this problem are:
- Mismatched interface MTU.
- Duplicate Router IDs on neighbors.
- Inability to ping across with more than certain MTU size.
- Broken unicast connectivity, which could be due to a wrong DLCI, an access
list, or NAT translating the unicast.
The debug ip ospf adj command can help diagnose
these problems, as shown in Figure
, which indicates
an MTU interface mismatch.
OSPF Stuck in LOADING
In the LOADING state, routers send
link-state request packets. 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. Neighbors that do not transition beyond
this state are most likely exchanging corrupted LSAs. This problem is usually
accompanied by a "%OSPF-4-BADLSA" console message. Since this is not
a common problem, it is recommend that the network administrator contacts the
Cisco TAC.
If a neighbor does not reply or a neighbor reply never
reaches the local router, the router will also be stuck in the LOADING state.
The most common possible causes of the problem are:
- Mismatched MTU
- Corrupted link-state request packet
The output of show ip ospf neighbor indicates that
the R2 neighbor is stuck in LOADING.
The
debug ip ospf adj command can help diagnose these problems.
Command output can indicate an MTU interface mismatch.
Command output
can also indicate a possible problem due to packet corruption.
