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).

It is very easy to understand Stub Area if you are going to configure and apply it in the laboratory. A few years ago, what I did is just memorize the concepts of OSPF Stub Area. But after being away from the Academy for so long, my own brain failed to store my memories about it. As we all know the brain is flexible in storing lots of lots information about what you’ve learned, experienced, your everyday life since birth, and so on. However, it is not a reliable storage most especially if you are not doing it every day (And it is not that quite memorable enough to be remembered).

One day, I was asked by an Erudite about the Stub Area.

“What is that again?” I asked my brain.

My brain whispered, “Uhm… I don’t know… I think there is nothing special on it.”

“What on bits-and-bytes!”

Analyzing the routing table and the result after configuration will help you understand the Stub area better than reading it a hundred times.

Assuming that you have configured the interfaces and the OSPF adjacencies are established on each router, let us configure Aedes router and Anopheles router as part of the Stub Area:

Aedes#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Aedes(config)#router ospf 3
Aedes(config-router)#area 20 stub
Aedes(config-router)#end


Anopheles#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Anopheles(config)#router ospf 2
Anopheles(config-router)#area 20 stub
Anopheles(config-router)#end
Anopheles#

Easy?

Now, this is the fun part. Let’s take a look at the routing tables of each router before and after we configure Aedes and Anopheles routers as stub.

The output above is captured from Culex. Culex’ neighborship with Anopheles is still up. The loopback network address of Anopheles, 192.168.2.0 (appearing as “O“), is learned by Culex through the directly connected interface address 192.168.12.2 of Anopheles.  Aedes network 192.168.3.0 and the 192.168.23.0 network configured between Aedes and Anopheles appeared as “O IA” before and after Aedes and Anopheles are configured as Stub Area. Therefore, since Culex is in Area 0 and not configured as part of Stub Area, it’s routing table did not change after I configured Aedes and Anopheles router as part of Stub network.

The same goes with its database:

Router Link State (LSA Type 1) shows router IDs of Culex and Anopheles, while the Summary Net (LSA Type 3) shows the 192.168.3.0 and 192.168.23.0 network being generated and advertised by Anopheles.

If you are thinking that there are some changes on the Anopheles router, we’ll there is none on the routing table and OSPF adjacencies.

Before and after screenshot shows that Anopheles is still converged with Culex and Anopheles and the routing table still shows that there are 3 directly connected links and 2 OSPF neighbors (192.168.1.0 and 192.168.3.0).

However, the Anopheles database has changed. The Summary Net Link States(LSA Type 3) now shows the default route 0.0.0.0 being advertised to the Aedes router.

Looking at the Aedes router, though the neighborship is still the same, its routing table is changed after it was configured as part of Stub Area network. A Type 3 LSA is injected into the area by Anopheles to act as a default route. This allows Aedes to connect to other routers outside the stub area.

Lastly, what did you notice on the database of each router? Aren’t they the same?

Anopheles, since it is the ABR, has the database of both Area 0 and Area 20. It has the same database with Culex in Area 0 and same database with Aedes in Area 23. We, therefore, conclude, that it is true that OSPF maintains the same database in each area. Amazing, right?