Last time, we began our look at advanced OSPF topics with the configuration of backbone and non-backbone areas. In this blog post, we'll look at the creation of more specific area types.

Stubby Area

Figure 1 - OSPF Topology

It is time to make our Area 1 from Figure 1 a stubby area. This is a simple configuration change. On each device in the area, we need to set the Area 1 as stub. Here is the configuration in our network:

This will cause a reset of the adjacency (as you might guess). After this change, it is time to check the OSPF route table and the OSPF database on ORL:

Just as we would hope, the routing table is smaller now! There is no longer the detail of the external prefixes from the ASBR. Instead we have a default route automatically generated by the ABR. This default route is needed, of course, because the routers in Area 1 still need to be able to access the remote prefixes (if needed).

Now it is time to examine the OSPF database. It is exactly what we would expect to see in a stub area:

The Type 4 and the Type 5 LSAs are filtered and there is now a Type 3 for the default route.

Totally Stubby Area

If we want to be more even more efficient in this example, we can convert Area 1 to a totally stubby area. This will eliminate the Type 3 LSAs that are used to advertise the Loopback 0 on ATL and the link between ATL and ATL2. There will still be a default route advertised, of course, because now it is needed more than ever! Here is the configuration and verification:

Not So Stubby Area (NSSA)

If you need to bring in external prefixes to a stub area, you must make it a Not So Stubby Area (NSSA). This permits the external prefixes to be carried through the stub area as Type 7 LSAs. The ABR then converts them to Type 5 for propagation through the OSPF domain (potentially).

Here is the configuration in our scenario:

This should prove to be some interesting verification for sure. Let’s begin by examining the OSPF routes and the OSPF database on ORL:

We can see from the routing table that we are learning the Type 3 advertisements again from Area 0 (1.1.1.1 and 10.12.12.0). The OSPF database proves the NSSA works as advertised at this point. We can see the external prefixes brought in to Area 1 as Type 7 in the database. Let’s quickly check over on ATL to see if they appear there as Type 5 LSAs as we would expect.

Yes, the output makes sense for our understanding of how the NSSA works. The prefixes are there as Type 5s and we see this in the routing table as well.

NOTE: The NSSA area does not feature a dynamically generated default route without you configuring that feature. So, in our network above, we would not have full reachability! In order to generate the default route, simply use the following command on the ATL2 router:

Totally NSSA

Because you have mastered the Totally Stubby area at this point, I am sure you already understand what is happening with the Totally NSSA. Here, we are blocking additional LSA types from the area. These include the Type 3 LSAs. Once again, a default route is automatically generated for us.

Here is the configuration, and the resulting verifications:

Note the incredibly concise routing table (for OSPF) on the ORL router. Also note the OSPF database is exactly what we would expect.

As you can see, OSPF is excellent at automatically filtering routes through the use of special areas and LSA Types. Next time, we'll explore options for manually filtering routes in OSPF. Until then, take good care.