Implementing & Troubleshooting OSPF Areas: Stub, NSSA, and Totally Stubby

As network architectures evolve, OSPF remains a cornerstone technology, more relevant than ever. Whether it's providing connectivity in Data Center VXLAN fabrics, supporting MPLS and Segment Routing in Service Provider networks, or ensuring efficient routing in large, complex enterprise environments, OSPF's role is undeniable.

Understanding and implementing proper OSPF design is key to: 

• Maximizing network uptime 

• Reducing network convergence time during failure scenarios

• Optimizing the critical aspects of network performance 

Today’s network engineers must possess the skills to fully leverage OSPF’s capabilities to meet the demands of modern networking environments.

In this blog, we'll explore how to implement and troubleshoot one of OSPF's most essential aspects—its ability to optimize routing through various types of stub areas. Understanding how Stub Areas, Not-So-Stubby Areas (NSSA), and Totally Stubby Areas work is key to ensuring you have the skills to design scalable, high-performance networks.

Also, be sure to check the Further Learning section at the end for links to hands-on additional resources.

Getting Started

Let's look at the topology diagram below to understand the need for these different OSPF area types.

In this topology, we have two Autonomous System Boundary Routers (ASBRs) redistributing external routes (BGP and EIGRP) into the OSPF domain. The ASBRs advertise these routes using the External LSA (LSA Type 5), which then floods throughout the OSPF domain without any changes. These types of routes can be verified below.  

As you can see above, R2 is receiving many External Routes (Type 5 LSAs). Next, we verify who the advertising router is. Below, we can see the detailed verification for the first and last routes. 

For route 10.1.1.1, the advertising router is R1, and the router ID is 10.1.1.1. For route 10.10.10.15, the advertising router is R9, and the router ID is 10.9.9.9. 

Now, let’s verify what checksum value the ASBRs set for the Type 5 LSA routes 10.1.1.1 and 10.10.10.15.

Now, to confirm that the Type 5 LSA is flooded throughout the OSPF domain without any change, we must verify the checksum value on any other router that is not the ASBR. If the checksum value is the same, it confirms that the ASBR floods Type 5 LSA throughout the OSPF domain unchanged. 

We will verify this on R2.

Since the checksum value is the same on all routers, our verification for the ASBR flooding the Type 5 LSA throughout the OSPF domain is complete.

Imagine if the ASBR advertised 50,000 Type 5 LSA routes. 50,000 Type 5 LSAs would flood the OSPF domain, affecting the network's performance. To optimize the OSPF network, you can configure an Area as a Stub Area. This Stub Area will not receive any Type 5 LSAs; instead, it receives a default Summary LSA (Type 3 LSA) route from the local ABR so that it can still reach the external networks. 

What is a Stub Area?

A Stub area is designed to reduce the size of the routing table by restricting the types of LSAs (Link-State Advertisements) that can enter the area. Specifically, a Stub area does not allow external routes (Type 5 LSAs) to enter. Instead, the area routers rely on a default route (0.0.0.0/0) to reach destinations outside of OSPF.

Stub Area Key Characteristics:

• Type 1 and Type 2 LSAs: Routers within the stub area will exchange Router (Type 1) and Network (Type 2) LSAs as normal.

• Type 3 LSAs: Summary LSAs (Type 3) are allowed for inter-area routes.

• No Type 4 LSAs: ASBR Summary LSAs (Type 4) are not generated by the ABR.

• No Type 5 LSAs: External Routes (Type 5 LSAs) are blocked. Instead, a Type 3 LSA default route (0.0.0.0/0) is injected into the area to forward traffic to external destinations.

Stub Area Restrictions:

• Area 0 cannot be configured as a Stubby Area.

• There must be no virtual-links transiting the Stubby Area.

• There must be no ASBR present in the Stubby Area.

Stub Area Use Case

• Stub areas are ideal for areas with limited resources or where external route information is not needed. For example, a branch office with only a few internal routes may use a stub area to simplify routing decisions.

Now that we have learned the basics of OSPF Stub Areas, let's deep-dive into the configuration.

Implementing and Troubleshooting OSPF Stub Area

Imagine that Area 1 is a remote branch office, and the routers there cannot handle too many LSAs. To reduce the routes from the routing table and to optimize Area 1, configure the entire Area 1 as a Stub Area. This will remove all the Type 5 LSAs from the OSPF database and the routing table. 

Important Note: a Stub flag must match between two routers for them to establish OSPF adjacency. This means that if Area 1 is configured as a Stub on R4, then R3 and R2 must also be configured as Stub for Area 1.

Let’s verify if the Stub flag needs to match. For this, we will configure Area 1 as Stub on R4 and R3, but not on R2. 

Since we did not configure R2 as a Stub for Area 1, R2 has lost its OSPF adjacency with R3 and, in turn, all the OSPF routes.

Let’s verify the reason for this by issuing a debug command.

This proves that the Stub flag must match between the routers to establish OSPF adjacency. 

Now, let’s configure R2 with the Stub flag.

Now our OSPF adjacency should be back up, and R2 will start receiving OSPF routes.

Let’s verify which LSAs the ABR has filtered out and whether OSPF Area 1 has been optimized.

As you can see in the above output, R2 and R3 are not receiving any Type 5 LSAs and Type 4 LSAs as they are being filtered out by the ABR, which is R4 for Area 1.

Does that mean R2 and R3 cannot reach or access external networks? Well, they would still be able to access the external networks because the ABR - R4 for Area 1 - advertises a Type 3 LSA default route (0.0.0.0/0) to the routers belonging to Area 1. Next let’s verify if the ABR is indeed advertising a Type 3 LSA default route.

Next, we verify the routing table and check the connectivity to the external networks from R2 or R3.

As you can see in the above output, we do not have any Type 5 LSA routes in the routing table; instead, we have a Type 3 LSA default route that will be used to reach external networks.

Let us finally check the connectivity to the external network 10.1.1.1/32, which resides behind R1, and 10.10.10.15/32, which resides behind R10.

The next type of area is called an OSPF Totally Stubby Area.

What is a Totally Stubby Area?

A Totally Stubby Area is a Cisco-proprietary OSPF area that further reduces the routing table by blocking both external routes (Type 5 LSAs) and inter-area routes (Type 3 LSAs). Only a single Type 3 LSA default route (0.0.0.0/0) is injected to handle all traffic outside the area.

Totally Stubby Area Key Characteristics:

• Type 1 and Type 2 LSAs: Routers within the stub area will exchange Router (Type 1) and Network (Type 2) LSAs as normal.

• No Type 3 LSAs: Inter-area routes are not allowed.

• No Type 4 LSAs: ASBR Summary LSAs (Type 4) are not generated by the ABR.

• No Type 5 LSAs: External routes are blocked.

• Only a Default Route (Type 3 LSA): The ABR injects only one Type 3 LSA default route (0.0.0.0/0) into the area.

Totally Stubby Area Restrictions:

• Area 0 cannot be configured as a Totally Stubby Area.

• There must be no virtual-links transiting the Totally Stubby Area.

• There must be no ASBR present in the Totally Stubby Area.

Totally Stubby Area Use Case

• Totally Stubby Areas are perfect for networks where minimal routing information is needed. For instance, a small remote site that needs to send all non-local traffic to the central network would benefit from this configuration.

Now that we have learned the basics of OSPF Totally Stubby Areas let's deep-dive into the configuration.

Implementing and Troubleshooting OSPF Totally Stubby Area

Imagine that Area 1 is a small remote site that needs to send all non-local traffic to the central site, and also because the lower-performance routers in Area 1 cannot handle a large number of LSAs. To reduce the routes from the routing table and to optimize Area 1, we will configure all the non-ABR routers in Area 1 as Stub and the ABR routers in Area 1 as Totally Stubby. This will remove all the External (Types 4 & 5) LSAs as well as all the Inter-area (Type 3) LSAs from the OSPF database & routing table. However, one Type 3 LSA default route (0.0.0.0/0) will be injected by the Area 1 ABR into the Totally Stubby Area. Even here, the stub flag must match to keep the OSPF adjacency.

Let’s configure area 1 as Totally Stubby.

Next, we verify which LSAs the ABR has filtered out and whether OSPF Area 1 has been optimized.

As you can see in the above output, R2 and R3 are not receiving any Type 5 LSAs, Type 4 LSAs, or Type 3 LSAs from the ABR, but only one Type 3 LSA —the default route.

Our next step is to verify the routing table and check the connectivity to both the external and inter-area networks from R2 or R3.

As can be seen in the above output, the routing table has been drastically reduced. The ABR blocks all External Type 4 & 5 LSAs and Inter-Area Type 3 LSAs, and it injects only one Type 3 LSA default route (0.0.0.0/0).

The next variation after OSPF Totally Stubby Areas is the  OSPF Not-So-Stubby Area (NSSA).

What is an OSPF Not-So-Stubby (NSSA)?

The Not-So-Stubby Area (NSSA) is an extension of the Stub Area concept, which is designed to allow limited external routing while still maintaining simplicity and reducing overhead. 

Like the OSPF Stub Area, the ABR belonging to the NSSA restricts External Routes (Types 4 & 5 LSAs) from being flooded into the area. 

One key difference, though, is that ASBRs are allowed within the NSSA area. When redistribution is performed within the NSSA, the ASBR generates NSSA External LSAs (Type 7 LSAs), which the ABR then translates into External LSAs (Type 5 LSAs) before they are sent on to Area 0.

Additionally, in an NSSA, the ABR does not typically inject a Type 3 LSA default route automatically into the NSSA area. This means that the routers in the NSSA will not be able to reach external routes advertised by any ASBR that resides outside of the NSSA unless a default route is explicitly originated by the NSSA ABR. 

NSSA Practical Use Cases

1. Small Branch Offices:

   • In a small branch office scenario, external connectivity might be needed to connect to external networks or a different routing protocol (e.g., BGP), but the branch doesn't need to see all the external routes in the OSPF domain. NSSA would be useful here.

2. Hybrid Environments:

   • In environments where OSPF is used internally but external connections (like the Internet or other ASes) are required, NSSA enables the controlled redistribution of external routes into OSPF while keeping the internal OSPF network optimized.

Implementing and Troubleshooting OSPF NSSA

Use the topology below to visualize and implement NSSA.

As you can see in the above diagram, we have two ASBRs (R1 and R9). These two ASBRs generate External LSA (Type 5) and flood it throughout the OSPF domain. 

If we configure Area 2 as NSSA, R9 will stop generating External LSAs (Type 5) and start generating Not-so-stubby area LSA (Type 7). This Not-so-stubby area LSA (Type 7) will be flooded only within Area 2 and will not be flooded into Area 0 by the ABR. 

Because the ASBR R1 is outside the NSSA, it will still flood External LSAs (Type 5) into Area 0. However, the ABR of Area 2 will block these External LSAs (Type 5) coming from R1 to go into Area 2.

Now the ABR of Area 2 needs to translate the Not-so-stubby area LSA (Type 7) into External LSAs (Type 5) and advertise them to Area 0 so that routers outside the NSSA can reach the redistributed routes advertised by the ASBR R9.

The ABR of Area 2 also needs to generate a default route into Area 2 so that routers within the NSSA can reach the redistributed routes advertised by the ASBR R1. This does not happen automatically and has to be explicitly configured on the ABR.

Before we configure NSSA, we will verify whether both ASBRs are generating External LSAs (Type 5). For the ASBR R1, we will use the route 10.1.1.5/32, and for the ASBR R9, we will use the route 10.10.10.15/32 for verification.

As you can see above, both ASBRs are generating External LSAs (Type 5). Now, let's configure Area 2 as an NSSA.

Now let's verify if the ASBRs are still generating External LSAs (Type 5).

Based on the above output, we can confirm that the ASBR R1, which is outside the NSSA, is still generating and flooding External LSAs (Type 5) into Area 0. 

Based on the above output, we can confirm that the ASBR R9, which is within the NSSA, has stopped generating and flooding External LSAs (Type 5).

Let's confirm if the ASBR R9 is generating a Not-so-stubby area LSA (Type 7).

Based on the above output, we can confirm that the ASBR R9, which is within the NSSA, is generating and flooding Not-so-stubby area LSA (Type 7) instead of generating and flooding External LSAs (Type 5).

Now, let's check the routing table of R9 and verify if the ABR is blocking External LSAs (Type 5) generated by R1 to be flooded into Area 2 from Area 0.

As you can see in the above output, there are no External LSA (Type 5) routes which means that the ABBR must be blocking External LSA (Type 5) to go inside Area 2 from Area 0. This means that routes within the NSSA cannot reach routes redistributed by the ASBR R1.

To fix this, the ABR must be configured explicitly to generate a default route. 

Now, let's check the routing table of R9. 

As you can see in the above output, the ABRs (R7 and R8) are generating a default route which now allows Area 2 routers to reach the redistributed routes of the ASBR R1.

Next, let's confirm if the ABR is translating the Not-so-stubby area LSA (Type 7) redistributed routes generated by the ASBR R9 into External LSA (Type 5) before flooding into Area 0.

As you can see in the above output, ABR R8 is translating the Not-so-stubby area LSA (Type 7) redistributed routes generated by the ASBR R9 into External LSA (Type 5) before flooding into Area 0. By default, OSPF only allows one ABR to translate the Not-so-stubby area LSA (Type 7) into External LSA (Type 5). In our case, it was R8 because R8 had a higher Router-ID than R7.

Now routers outside the NSSA can reach the redistributed routes generated by the ASBR R9 by using the External LSA (Type 5) database information flooded by the ABR R8.

Let's confirm this by checking the routing table of R2.

As you can see in the above output, R8 with the router-id 10.8.8.8 is advertising External LSA (Type 5). This means that R2 should be able to ping 10.10.10.15.

This finishes our verification. 

Conclusion

OSPF’s ability to optimize routing through Stub, Totally Stubby, and Not-So-Stubby Areas is essential for supporting modern network designs. By reducing unnecessary routing information and controlling LSA propagation, these area types help ensure efficient and scalable networks.

Further Learning

Understanding these OSPF area types isn’t just about theoretical knowledge—it’s about mastering the tools that will help you manage and optimize real-world networks. Take the time to practice implementing and troubleshooting these OSPF configurations to fully realize their benefits. INE offers a wide variety of hands-on OSPF labs, videos on OSPF design, configuration, & troubleshooting, and quizzes to help you reinforce your learning.

Explore my courses and more below, and commit to continuous learning to elevate your career in networking!

SkillDive Lab Collections

• OSPF Security & Filtering

• OSPF Advanced Techniques