OSPF Neighbor Adjacency States: From Down To Full

Like BGP neighbor adjacency states, OSPF has its own too. OSPF neighbor adjacency is not a bit straightforward. You might be expecting it should be in “FULL” state for the neighbor adjacency to be established, but you shouldn’t be assuming that it needs to stop at this state at all times.

OSPF IN DOWN STATE

Hello packets are very important parameters in establishing adjacency in any routing protocol not only in OSPF. Now, if no hello packets have been received from the neighbor and the dead timer interval has expired, OSPF is in DOWN state. The first OSPF neighbor state is “DOWN” state. It usually happens on Non-Broadcast MultiAccess (NBMA) networks and Non-Broadcast Point-to-Multipoint networks where neighbor is manually configured.

OSPF IN ATTEMPT STATE

“ATTEMPT” state only exist on NBMA networks. The router is sending Hello packets but these are not received by its peer.

OSPF IN INIT STATE

This is the same with the “CONNECT” state of BGP. When OSPF is in INIT state, that means that the router sees the Hello packets from the neighbor but the two way communication is not yet established. The receiving router should list its own router ID to acknowledge that it has a received a valid Hello packet.

It is not good to see a neighbor that stays on “INIT” state for a long time. There are many reasons why OSPF neighbor adjacency is stuck in “INIT” state.

• It can be a configuration/mismatch on the following parameters like Hello/Dead Timers, network mask, and Area ID.
• It can be an authentication issue. When authentication is used, make sure that authentication type and authentication key matches on both ends.
• For some reason, an access-list for OSPF multicast address 224.0.0.5 is being denied, this also causes the router to stay in “INIT” state. This address plays an important role in the two-way communication because this is the destination address of Hello packets.
• If you are configuring static frame-relay and/or dialer map and you forgot the “broadcast” keyword, it would also be an issue and make you stuck in this state. The use of the “broadcast” keyword is required if broadcast and multicast traffic is to be sent over the specified DLCI.
• Finally, it can be a Cisco bug (Cisco bug ID CSCdj01682). Try to issue “show ip ospf interface” command and check the “Neighbor Count” and “Adjacent Neighbor Count.” If the “Adjacent Neighbor Count” is higher than the “Neighbor Count” then it could be a bug.

OSPF IN 2WAY STATE

At this stage, two-way communication has been established. The router has seen its own router ID in the neighbor field of the neighbor’s packet. Do not be alarm if your routers are in “2WAY” state. In a multiaccess segments where DR and BDR are present, all DROTHERS (Not DR/Not BDR) will stay in “2WAY” state. This is normal and expected behavior as those routers will synchronize their database with DR and/or BDR only.

When there is no issue, the router checks if it is already listed as neighbor in its peer. If it is, it resets the dead timer and neighbor relationship is already formed. If not, it goes to “EXSTART/EXCHANGE” state.

OSPF IN EXSTART STATE

This is the state when the bidirectional communication has been established and in multiaccess segments, where DR and BDR election is completed, the routers enter the “EXSTART” state and start the Master/Slave relationship. In a Master/Slave relationship, it is determined by highest priority and/or router ID.

OSPF IN EXCHANGE STATE

Once the Master/Slave relationship is negotiated, the Master starts the exchange of Database Descriptor. After Master sends its DBD, the Slave sends its own DBD. If no issue occurs, it goes to “LOADING” state. However, if OSPF is stuck in “EXSTART/EXCHANGE” state the main reason is a mismatched MTU. It usually occurs when connecting a Cisco router to non-Cisco router.

A router with the higher MTU continues to accept the DBD packet of the router with the lower MTU. It will be stuck in “EXCHANGE” state. On the other hand, the router with the lower MTU will stay in “EXSTART” state. It will discard the DBD packets and will continue to retransmit the initial DBD

OSPF IN LOADING STATE

Once DBDs are acknowledged and reviewed, it now goes to “LOADING” state. OSPF stuck in “LOADING” state and generates OSPF-4-BADLSA error message is not normal. This means that LSA being exchanged is corrupted. Contact Cisco TAC support.

OSPF IN FULL STATE

IN “FULL” state, neighbors have formed and they have now the same Link State Database (LSDB).