The time has arrived to tackle some of the more advanced (and interesting) features of the Open Shortest Path First routing protocol. We begin by examining the configuration and verification of the different OSPF areas. This is an exercise that is not only fun, but it can really cement the knowledge down of how these areas function and why they exist.

OSPF LSA Types

Areas are a fundamental concept of OSPF. It is what makes the routing protocol, hierarchical, as we like to say.

There is a core backbone area (Area 0) that connects to normal, non-backbone areas. The backbone might also connect to special area types we will examine in detail in this chapter. This hierarchical nature of the design helps ensure the protocol is very scalable. We can easily reduce or eliminate unnecessary routing traffic flows and communications between areas if needed. Database sizes are also contained using this approach.

The Backbone and the Non-Backbone Areas

To review a bit from our previous blog posts, Figure 1 shows a simple multi-area network. Here I will configure this network using my personal favorite configuration approach, the interface-level configuration command ip ospf. Example 1 shows the configuration of all three devices.

Figure 1: A backbone and non-backbone area

Example 1: Configuring the Backbone and Non-Backbone Areas

Notice the simplicity of this configuration even though we are running a fairly complex routing protocol. The Area Border Router (ABR) is ATL2 with one interface in the backbone and one in the non-backbone area. 

Notice also how we get some “bonus” verification free of charge. As we are configuring the interfaces, we can see OSPF adjacencies forming between the devices. This saves us from needing to verify these “manually” with the following command:

An interesting verification for us here is to check for the prefix of 1.1.1.0/24 from the ATL device (as well as the remote link between ATL and ATL2). We check for this on ORL to verify the multi-area configuration of OSPF. Since this is a “normal” area, all LSAs should be permitted in the area and we should see the prefix appear as an inter-area OSPF route.

While not often required in troubleshooting, we can examine the OSPF database in order to see the different types of LSAs in place.

The router link state entries are the Type 1 LSAs. These are the endpoints in our local area of 1. The net link state entries are the Type 2 LSAs. Here we see the router ID of the Designated Router. Finally, the summary net link states are the Type 3 LSAs. These are the prefixes the ABR sends into our area. Sure enough, they are the loopback (1.1.1.0) and the remote network (10.12.12.0).

NOTE: The loopback interface is advertised as a host route of 32-bit. To change this, you can just use the command ip ospf network point-to-point under the loopback interface. This changes the network type from the loopback type for OSPF and causes the mask to advertise as it is configured.

Now it is time to add to the story here. Let’s configure some external prefixes and inject them into the OSPF domain. This is simple thanks to loopback interfaces. We will create some on the ATL router, run EIGRP on them, and then redistribute them into OSPF.

Now we have even more interesting verifications on the ORL device. First, the routing table:

Notice how the remote prefixes are listed as E2 routes. This is the default of Type 2 external OSPF routes. It means that the metric is unchanged as the prefix flows from the ASBR (Autonomous System Boundary Router) to the internal OSPF speaker. You can change the type to Type 1 if you desire when you are performing resitrubution. 

Perhaps of more interest is the OSPF database:

Notice now we pick up the Type 4 LSA (summary ASB link state) which is the router ID (1.1.1.1) of the ASBR (ATL). We also get the Type 5 LSAs that are the external prefixes.

That's going to wrap up the first part of our advanced OSPF blog series. Next time, we'll take a look at creating stubby areas, totally stubby areas, not so stubby areas (NSSA), and totally NSSA. Until then, take good care.