Content

| 5.7 |  | Troubleshooting OSPF |
| 5.7.2 |  | OSPF state issues |

Routers being neighbors does not guarantee an exchange of link state updates. Neighbor routers must form adjacencies in order for this to happen. Interface type plays a major role in how the adjacencies are formed. For example, neighbors on point-to-point links always become adjacent.

Once a router decides to form an adjacency with a neighbor, it starts by exchanging a full copy of its link state database. The neighbor follows suit. After passing through several neighbor states, the routers will become adjacent. 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.