Before we move on to more advanced topics, we'll wrap up this OSPF Basics series in Part 3. Here we'll examine LSA types, area types, and virtual links.

OSPF LSA Types

Link State Advertisements (LSA) are the lifeblood of an OSPF network. The flooding of these updates (and the requests for this information) allow the OSPF network to create a map of the network. This occurs with a little help from Dijkstra’s Shortest Path First Algorithm. 

Not all OSPF LSAs are created equal. Here is a look at each:

The Router (Type 1) LSA - We begin with what many call the “fundamental” or “building block” Link State Advertisement. The Type 1 LSA (also known as the Router LSA) is flooded within an area. It describes the interfaces of the local router that are participating in OSPF and the neighbors the local OSPF speaker has established.

The Network (Type 2) LSA - Remember how OSPF functions on an Ethernet (broadcast) segment. It elects a Designated Router (DR) and Backup Designated Router (BDR) in order to reduce the number of adjacencies that must be formed and the chaos that would result from a full mesh of these relationships. The Type 2 LSA is sent by the Designated Router into the local area. This LSA describes all of the routers that are attached to that Ethernet segment. 

The Summary (Type 3) LSA - Recall that your Type 1 and Type 2 LSAs are sent within an area. We call these intra-area LSAs. Now it is time for the first of our inter-area LSAs. The Summary (Type 3) LSA is used for advertising prefixes learned from the Type 1 and Type 2 LSAs into a different area. The Area Border Router (ABR) is the OSPF device that separates areas and it is this device that advertises the Type 3 LSA.

Examine the OSPF topology shown in Figure 1 below.

Figure 1: A Sample Multi-Area OSPF Topology

The Area 1 ABR would send the Type 3 LSAs into Area 0. The ABR joining Area 0 and Area 2 would send these Type 3 LSAs into Area 2 to provide full reachability in the OSPF domain. The Type 3 LSAs remain Type 3 LSAs during this journey, it is just OSPF costs and advertising router details that change in the advertisements. Notice also that in this example we are describing a multi-area OSPF design that is not using any special area types like Stub or Totally Stubby areas.

The ASBR Summary (Type4) LSA – There is a special router role in OSPF called the Autonomous System Boundary Router (ASBR). It is the job of this router to bring in external prefix information from another routing domain. In order to inform routers in different areas about the existence of this special router, the Type 4 LSA is used. This Summary LSA provides the router ID of the ASBR. So once again, the Area Border Router is responsible for shooting this information into the next area and we have another example of an inter-area LSA.

The External (Type 5) LSA - So the ASBR is the device that is bringing in prefixes from other routing domains. The Type 4 LSA describes this device. But what LSA is used for the actual prefixes that are coming in from the other domain? Yes, it is the Type 5 LSA. The OSPF ASBR creates these LSAs and they are sent to the Area Border Routers for dissemination into the other areas. Remember, this might change if we are using special area types.

The NSSA External (Type 7) LSA - Remember that in OPSF there is a VERY special area type called a Not So Stubby Area (NSSA). This area can act stub, but it can also bring in external prefixes from an ASBR. These prefixes are sent as Type 7 LSAs. When an ABR gets these Type 7 LSAs, it sends them alone in to the other areas as a Type 5 LSA. So, the Type 7 designation is just for that very special NSSA area functionality. 

Other LSA Types - Are there other LSA types? The short answer is YES. But we do not often encounter these. For example, a Type 6 LSA is used for Multicast OSPF and that technology never really caught on, allowing Protocol Independent Multicast to win out. For completion’s sake, here is a complete listing of all of the possible LSA types:

• LSA Type 1: Router LSA
• LSA Type 2: Network LSA
• LSA Type 3: Summary LSA
• LSA Type 4: Summary ASBR LSA
• LSA Type 5: Autonomous system external LSA
• LSA Type 6: Multicast OSPF LSA
• LSA Type 7: Not-so-stubby area LSA
• LSA Type 8: External attribute LSA for BGP
• LSA Types 9, 10, and 11: “Opaque” LSA types used for application-specific purposes

OSPF LSA Types and Area Types

One of the reasons that you should master the different LSA types is the fact that it can help you fully understand the potential importance of a multi-area design, especially one that might include special areas. A key to the importance of special area types in OSPF is the fact that they initiate the automatic filtering of certain LSAs from certain areas. 

For example, think about Area 1 attached to the backbone area of Area 0. There are Type 1 LSAs flooding in this Area 1. If we have broadcast segments, we also have Type 2 LSAs circulating in the area. The Area Border Router is sending LSA Type 3s into the backbone to summarize the prefix information from Area 1.

This ABR is also taking in this information from the backbone for other areas that might exist. If there is an ASBR out there in the domain somewhere, our Area 1 will receive Type 4 and Type 5 LSAs in order to know the location of this ASBR and the prefixes it is sharing with us. Note that this is the potential for a lot of information being shared between areas. This is precisely why we have special area types!

OSPF LSAs and the Stub Area

What is it that we want to accomplish with a stub area? We do not want to hear about those prefixes that are external to our OSPF domain. Remember what those were? Sure, they are the Type 5 LSAs. In fact, we do not even want to hear about those Type 4 LSAs that are used to call out the ASBR in the network. So the stub area is full of Type 1, Type 2, and Type 3 LSAs. In fact, how would this area get to one of those external prefixes if it needed to? We typically use a very special Type 3 LSA for this. This LSA represents the default route (0.0.0.0/0). It is this handy route that allows devices in this area to get to all of those externals. In fact, it is this router that is used to get to any prefix not specifically defined in the Routing Information Base (RIB).

OSPF LSAs and the Totally Stubby Area

With this area, we want very little inside it from an LSA perspective.  With this area, it makes sense that we are blocking those Type 4 and Type 5 once again, but now we are even blocking the Type 3 LSAsthat are describing prefix information from other areas WITHIN our OSPF domain. There needs to be one big exception, however. We need a Type 3 LSA for a default route so we can actually get to other prefixes in our domain.

OSPF LSAs and the Not So Stubby Area and the Totally Not So Stubby Area

Remember, the Not So Stubby Area needs to have those Type 7 LSAs. These Type 7 LSAs permit the proliferation of those external prefixes that are entering your OSPF domain thanks to this NSSA area you created. Obviously, this area also has the Type 1, Type 2, and Type 3 inside it. Type 4 and Type 5 will be blocked from entering this area as you would expect. You can also create a Totally Not So Stubby Area by restricting Type 3s from this area.

Virtual Links

You might recall from our earlier discussion of OSPF that all areas in an OSPF autonomous system must be physically connected to the backbone area (Area 0). Where this is not possible, you can use a virtual link to connect to the backbone through a non-backbone area. 

Keep the following facts in mind about your virtual links:

• They should never be considered a design goal in your networks. They are a temporary “fix” for a violation of the rules of OSPF.
• You can also use virtual links to connect two parts of a partitioned backbone through a non-backbone area.
• The area through which you configure the virtual link, known as a transit area, must have full routing information.
• The transit area cannot be a stub area. 

You create the virtual link with a single command in OSPF configuration mode:

This command creates a virtual link through area 1 with a remote OSPF device with Router ID 3.3.3.3. You configure that remote OSPF device with a virtual-link command as well. For example, if our local OSPF device is at Router ID 1.1.1.1, the appropriate remote command would be:

NOTE: A virtual link is just one patch for a broken OSPF implementation. You could also use a GRE tunnel to patch the OSPF topology.

That wraps up our look at basic OSPF concepts. In the upcoming series of blog posts, we'll begin examining advanced topics and configuration. Until then, take good care.