Welcome back to part 3 about OSPF and external routes.
In this post I will focus on type 7 LSA’s. These are LSA’s thats created within an NSSA area. An NSSA area is, as you may know, an area which is meant as a stub area (no type 4 and 5’s), but will still allow for external routes to be introduced in the area. Instead of having type 5’s, which is not allowed in a stub area, it is allowed to have a special type of LSA called a type 7 LSA.
Type 7 LSA’s are only used within an NSSA area. It is not flooded to the rest of the domain as type 7. Instead the ABR connecting to the NSSA will convert this type 7 to a type 5, which will then be flooded to the rest of the OSPF domain.
A note of caution here. When the ABR converts the type 7 to a type 5 LSA, the forwarding address is set to the highest interface address of the advertising router, also advertised into the NSSA natively. Sounds cryptic? 🙂 In our case the highest interface address thats advertised into the NSSA area is R3’s serial address 172.16.0.3. The forwarding address of the type 5 LSA as generated by R2 will be set to this address.
Below is the topology i will show you output from:
On R3, we have a loopback interface that will act as our external route:
Lets check out the relevant information in R3’s OSPF database:
A couple of things to note here. This is an NSSA LSA. As can be seen, the advertising router is 3.3.3.3 (R3). The forwarding address is also set to R3’s highest interface address that’s advertised into the NSSA area.
Lets check out R2 to make sure we see the same LSA here:
Good, we see the output that we wanted to. Now lets see what else exists on R2, lets dump the entire OSPF database to get a summary on whats going on:
Check out the very bottom of the output. We have a type 5 LSA present and the LSA is created by R2 (2.2.2.2). Lets get some further information on the lsa:
What we see here, is that R2 creates the type 5 LSA, but at the same time it maintains the forwarding address that R3 set originally.
Finally, lets see the same route on R1:
And the route in more detail on R1:
Pay attention to the forwarding metric and the next-hop. The forwarding metric is 128, which equals to the 2 serial links. This forwarding metric can also be verified by checking the border-routers:
On R1:
And on R2:
The cost of these two together is 128, which is whats reported by R1 in its total forwarding metric.
Lets switch gears, and check out another tidbit, or rather a rule of OSPF. In order to use the external route on R1, we need to have learned the forwarding address through either an intra or inter-area LSA.
Currently, on R1, we have learned the 172.16.0.0/24 network through an inter-area route:
Because of this we have the external route present in our routing table:
Lets try and make this NOT happen. Basically we filter out the 172.16.0.0/24 network for the entire area 0.
On R2, lets apply a filter:
Lets check the effects on R1:
So far, so good. We dont have the inter-area route to 172.16.0.0/24 anymore. To begin with, lets see if we still have the type 5 LSA in our OSPF database:
Good, we have it in there. Lets verify our assumption that the external route is no longer present in the routing table:
Nothing! So we verified that we need to have a route to the forwarding address, even though the next hop is clearly R2. Interesting, and something to keep in mind.
I hope this has been a good foundation on the use of type 7 LSA’s. Next time, we will have a bit more complex scenario set up with multiple NSSA areas. This will make life a bit more… fun? 🙂
Until next time, take care!