OSPF – External routes Part 3: Type 7’s in single NSSA area.
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:
Topology for single area type 7 scenario
On R3, we have a loopback interface that will act as our external route:
R3#sh ip int b | beg Lo Loopback0 100.100.100.100 YES NVRAM up up
Lets check out the relevant information in R3’s OSPF database:
R3#sh ip os data nssa OSPF Router with ID (3.3.3.3) (Process ID 1) Type-7 AS External Link States (Area 1) LS age: 752 Options: (No TOS-capability, Type 7/5 translation, DC) LS Type: AS External Link Link State ID: 100.100.100.0 (External Network Number ) Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x316C Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 172.16.0.3 External Route Tag: 0
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:
R2#sh ip os data nssa OSPF Router with ID (2.2.2.2) (Process ID 1) Type-7 AS External Link States (Area 1) Routing Bit Set on this LSA LS age: 1571 Options: (No TOS-capability, Type 7/5 translation, DC) LS Type: AS External Link Link State ID: 100.100.100.0 (External Network Number ) Advertising Router: 3.3.3.3 LS Seq Number: 80000002 Checksum: 0x2F6D Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 172.16.0.3 External Route Tag: 0
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:
R2#sh ip os data OSPF Router with ID (2.2.2.2) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 1658 0x80000003 0x00F3CA 2 2.2.2.2 2.2.2.2 1642 0x80000003 0x009C1A 2 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 172.16.0.0 2.2.2.2 1642 0x80000002 0x0048EE Router Link States (Area 1) Link ID ADV Router Age Seq# Checksum Link count 2.2.2.2 2.2.2.2 1642 0x80000003 0x0019E8 2 3.3.3.3 3.3.3.3 1651 0x80000003 0x00B548 2 Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 192.168.0.0 2.2.2.2 1642 0x80000002 0x00C1C2 Type-7 AS External Link States (Area 1) Link ID ADV Router Age Seq# Checksum Tag 100.100.100.0 3.3.3.3 1651 0x80000002 0x002F6D 0 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 100.100.100.0 2.2.2.2 1642 0x80000002 0x00E1C8 0
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:
R2#sh ip os data ex OSPF Router with ID (2.2.2.2) (Process ID 1) Type-5 AS External Link States LS age: 1753 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 100.100.100.0 (External Network Number ) Advertising Router: 2.2.2.2 LS Seq Number: 80000002 Checksum: 0xE1C8 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 172.16.0.3 External Route Tag: 0
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:
R1#sh ip os data ex OSPF Router with ID (1.1.1.1) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 1856 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 100.100.100.0 (External Network Number ) Advertising Router: 2.2.2.2 LS Seq Number: 80000002 Checksum: 0xE1C8 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 172.16.0.3 External Route Tag: 0
And the route in more detail on R1:
R1#sh ip ro 100.100.100.0 255.255.255.0 Routing entry for 100.100.100.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128 Last update from 192.168.0.2 on Serial0/0, 01:04:42 ago Routing Descriptor Blocks: * 192.168.0.2, from 2.2.2.2, 01:04:42 ago, via Serial0/0 Route metric is 20, traffic share count is 1
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:
R1#sh ip os bor OSPF Process 1 internal Routing Table Codes: i - Intra-area route, I - Inter-area route i 2.2.2.2 [64] via 192.168.0.2, Serial0/0, ABR/ASBR, Area 0, SPF 2
And on R2:
R2#sh ip os border-routers OSPF Process 1 internal Routing Table Codes: i - Intra-area route, I - Inter-area route i 3.3.3.3 [64] via 172.16.0.3, Serial0/1, ASBR, Area 1, SPF 4
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:
R1#sh ip ro | incl 172.16.0.0 172.16.0.0/24 is subnetted, 1 subnets O IA 172.16.0.0 [110/128] via 192.168.0.2, 01:14:57, Serial0/0
Because of this we have the external route present in our routing table:
R1#sh ip ro | incl 100.100.100.0 O E2 100.100.100.0 [110/20] via 192.168.0.2, 01:15:37, Serial0/0
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:
R2(config-router)#area 1 range 172.16.0.0 255.255.255.0 not-advertise
Lets check the effects on R1:
R1#sh ip ro | incl 172.16.0.0 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:
R1#sh ip os dat | beg Type-5 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 100.100.100.0 2.2.2.2 810 0x80000003 0x00DFC9 0
Good, we have it in there. Lets verify our assumption that the external route is no longer present in the routing table:
R1#sh ip ro | incl 100.100.100.0 R1#
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!