OSPF stub areas are a special area where LSA type 5s for external routes are filtered, meaning we will never see a type 5 LSA in a stub area. This is a mechanism to shrink the Link State Database (LSDB) if the area does not need the external routes. The NSSA (That’s Not So Stubby Area) is a modification of this logic that allows us to redistribute external routes into the stub area. Since type 5s are not allowed in the stub area, the external routes are injected into the stub area using a special LSA type, type 7. The type 7 LSAs will only exist in the NSSA, they do not propagate though area border routers (ABRs). If multiple ABRs exist for the NSSA, an election takes place so that a single ABR translates the type 7s into type 5s. This article will examine NSSA and LSA 7-to-5 translations.
Demo Network
I built the network below in Cisco Modeling Labs for demonstration. R4 and R5 are IOS-XR, the rest are XE. As noted in the topology, area 5 is NSSA. Area 7 is a regular OSPF area. R2 and R3 are redistributing EIGRP into OSPF, R8 is redistributing BGP into OSPF.
Here is a link to the CML YAML file in GitHub.
NSSA Basics
BGP router R9 originates 172.31.0.0/16 and R8 redistributes this prefix into OSPF. We will start by confirming that we have a type 5 LSA for 172.31.0.0/16 in areas 7 and 0. We will then confirm that NSSA area 5 contains no type 5 LSAs.
The output below confirms that R8 originates a type 5 for 172.31.0.0/16.
We can see the same type-5 on R6 and R4. The type 5 LSA is somewhat unique in that it is propagated beyond normal area boundaries without modification.
Just as we expect, R2 has no type 5 LSAs. The first screenshot confirms that R2 is only a member of 1 area. 0 normal areas, 0 stub areas, and 1 nssa. The second screenshot confirms that R2 has no type 5 LSAs.
The outcome of this type-5 filtering is that area 5 does not have a route to 172.31.0.0/16. The default behavior for NSSA does not inject a default route from the ABR either, meaning that 172.31.0.0/16 will be unreachable from the NSSA area.
LSA Type-7
The difference between a stub and not-so-stubby area is that NSSA allows external routes to be redistributed into the stubby area. How can we have external routes without type-5s? The LSA 7 is used for this functionality. If you put a type 5 and type 7 side-by-side under a microscope, you won’t see much difference. In my opinion, type 7 is basically a hack around the “no type 5s” rule. Below are screenshots of type 5 and type 7 LSAs from the demo network. Notice how similar the LSA structure is between the two.
Let’s look at some type 7s in the CLI. On R5, we can see that both R2 and R3 are generating a type 7 for external prefix 172.17.0.0/16.
These type 7 LSAs allow routers within the NSSA to construct forwarding entries for the external routes. Type 7s are an NSSA construct, they do not leave the NSSA.
Type-7 to Type-5 Translation
If we refer to the screenshot above, we can see that the options field in the CLI contains “Type 7/5 translation” and the options field in the screenshot below, we can see that the “P” (aka propagate) bit is set. These both indicate the same thing, that the LSA is eligible for type 7 to type 5 translation at an ABR.
Only 1 NSSA ABR needs to translate type 7s to type 5s. If more than 1 NSSA ABR exists, an election takes place to determine which ABR will inject the type 5s into the backbone area. The ABR with the highest router ID wins the election. In our case, R5 is elected to be the translator. R4s RID is 0.0.0.4 and R5s is 0.0.0.5. We can confirm this by looking on R7 for the external LSA for 172.17.0.0, shown below. Note that there is only 1 type 5 for this prefix and it is advertised by R5
R4 does not originate any external LSAs because it did not win the translator election.
I powered off R5 to prove that once R4 becomes aware that R5 is down, it will start translating type 7s to type 5s.
Once R5 is restored, it preemptively takes over the translator role.
To see R4 take over the translator role, I started a packet capture on its G0/0/0/2 interface and cleared the OSPF process on R5. Once R4 realizes that it needs to take over the translator role, it originates a type 5 for the NSSA external networks, one shown below.
R5’s OSPF process quickly recovers and wins the type-7/5 translator election. R4 sends out type 5’s with the age field set to the maximum value, 3600 seconds. This causes the type 5s generated by R4 to be flushed from the LSDB.
The debug output below from R4 shows this type 5 LSA generation and LSDB flush via max age.
NSSA Default Route Injection
Remember that our NSSA area has no external type 5 routes or a default route. We saw earlier that R5 has no route to 172.31.0.0/16 or a default route to get out of the area. What if we want to maintain “no type 5s” logic of the NSSA but inject a default route to provide reachability to filtered networks?
We can configure the ABR to inject a default route into the NSSA. I’ll use R4 as an example.
Just like that, we have a default route in the NSSA area with reachability to external prefixes!
The output below confirms that the default route is injected into the NSSA via LSA-7. Notice that the “p-bit” is not set, “No Type 5/7 Translation”. This means that this LSA will not be translated into a type 5 to ensure that the default route does not leave the NSSA.
That’s all for now! I hope this helps you understand OSPF NSSAs, thanks for stopping by!