ccie blog

Understanding OSPF External LSA Recursion

I wanted to fully understand how routers recurse LSA’s for external routes. Since it’s probably the most complex thing in OSPF, I decided to lab it up and explain how it works using real examples. Since this topic is pretty intense, this post is not for the feint hearted. It will be long but extremely useful for understanding how OSPF works on a fundamental & CCIE level. I really enjoyed learning about this topic & it has significantly improved my understanding of OSPF. FYI I have also included how the metric is calculated at the bottom of each scenario.

I figured that external routes can be learned in 3 ways:

  • Scenario 1: From an Intra-Area ASBR
  • Scenario 2: From an Inter-Area ASBR
  • Scenario 3: From an ASBR in an NSSA, and then learned by area 0

My topology accomodates for each of these scenarios, however not all routers will be used in each scenario, so it’s actually easier than it looks to follow along. FYI, take note of the following facts:

  • R4 and R6 are doing mutual redistribution between OSPF and EIGRP
  • All router-ID’s have NOT been advertised into OSPF

Understanding LSA Recursion

Scenario 1:  Recursion of a Type 5 LSA learned from an Intra-Area ASBR

We will use just area 50 for this demonstration.

R2 and R6 share a link in area 50. Since R6 is an ASBR, it means that he will be providing R2 a type 5 LSA about the external EIGRP link 50.50.50.50/32. Let’s check the OSPF database on R2 for this external LSA.

R2#sh ip ospf database external 50.50.50.50

            OSPF Router with ID (22.22.22.22) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 968
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 50.50.50.50 (External Network Number )
  Advertising Router: 6.6.6.6
  LS Seq Number: 8000002E
  Checksum: 0xD3BE
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

We can see that the node who advertised R2 information about this link was R6 (6.6.6.6). We can also see that R6 said that his metric to reach that link is 20 (which is the default for a metric type 2 external route). Finally, we can see that the forwarding address is 0.0.0.0, which means that to reach the link 50.50.50.50 R2 must solve the shortest path to 6.6.6.6. Since R6 is in the same area as R2, it means that R2 will already have calculated the Shortest Path Tree (SPT) towards R6. And since all links in my network are point-to-point it means there will be no DR elections and therefore, R2 will be able to solve the shortest path towards the ASBR using a type 1 LSA. We can see this by looking at the type 1 LSA that R2 has created for the link towards R6.

R2#sh ip ospf da router adv-router 22.22.22.22 | b Area 50
                Router Link States (Area 50)

  LS age: 783
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 22.22.22.22
  Advertising Router: 22.22.22.22
  LS Seq Number: 80000004
  Checksum: 0x6C9D
  Length: 48
  Area Border Router
  AS Boundary Router
  Number of Links: 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 6.6.6.6
     (Link Data) Router Interface address: 10.0.26.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.26.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

From the output we can identify that R2 has a P2P connection to R6 (6.6.6.6) and the metric to reach R6 is 1. At this point R2 has now solved the shortest path to the destination. Basically any time we have completed the recursion to a type 1 LSA in the LSDB, we have solved the shortest path to the destination.

 

So to summarise how the LSA recursion works:

R2 recurses the type 5 LSA to a type 1 LSA, and then has solved the SPT to reach the external prefix.

 

End to End Metric Calculation

If we now wanted to calculate the metric of this route. It would work like this. It would be 20 (the metric that R6 has advertised to reach the link) + 1 (the cost towards the ASBR, R6) = 21. We can see this more clearly from the routing table output below. Where the metric that the ASBR knows to reach the link is 20, and the cost towards the ASBR (the forward metric) is 1.

R2#sh ip route 50.50.50.50
Routing entry for 50.50.50.50/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 10.0.26.6 on FastEthernet1/0, 00:08:19 ago
  Routing Descriptor Blocks:
  * 10.0.26.6, from 6.6.6.6, 00:08:19 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

 

Scenario 2:  Recursion of a Type 5 LSA learned from an Inter-Area ASBR

We will use Area 50 and area 0 for this scenario. We will look at how R1 recurses the type 5 LSA to reach the ASBR for the external EIGRP link 50.50.50.50/32. Let’s start by checking the type 5 LSA information in the OSPF database on R1.

R1#sh ip ospf database external 50.50.50.50

            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: 1070
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
   Link State ID: 50.50.50.50 (External Network Number )
  Advertising Router: 6.6.6.6
  LS Seq Number: 8000002F
  Checksum: 0xD1BF
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

From the output we can see that R1 has learned that the 50.50.50.50/32 link belongs to the ASBR R6 (6.6.6.6) and R6 is advertising that the cost to reach that link is 20. We can also see that the forwarding address is 0.0.0.0, which means that to reach the link 50.50.50.50/32, R2 must first solve the shortest path towards 6.6.6.6. Since this ASBR (6.6.6.6) is in a different area (R6 is in area 50), it means that the ABR (R2) will generate a type 4 asbr-summary LSA into area 0, informing routers inside area 0 of how to reach the ASBR (6.6.6.6). So the next step in LSA recursion is to look at how we reach the ASBR 6.6.6.6 via the asbr-sumamry LSA.

R1# sh ip ospf database asbr-summary 6.6.6.6

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Summary ASB Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1380
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 6.6.6.6 (AS Boundary Router address)
  Advertising Router: 22.22.22.22
  LS Seq Number: 80000003
  Checksum: 0xD5F2
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 1

  ...output omitted

The output states that the ABR, R2 (22.22.22.22), knows the shortest path to reach the ASBR via a cost of 1. So we need to solve the shortest path to R2. Since R2 is in the same area as R1, we will have already solved the shortest path towards R2 because that’s how SPF works. All routers in the same area have to have identical LSDB’s. They then run SPF on their LSDB and calculate the shortest path to all nodes in the area. So if we look at R1’s self-generated router LSAs, we should see one describing the path towards 22.22.22.22.

R1#sh ip ospf database router self-originate

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 1941
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000006
  Checksum: 0x2FE0
  Length: 72
  Area Border Router
  Number of Links: 4

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 10.0.13.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.13.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 22.22.22.22
     (Link Data) Router Interface address: 10.0.12.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    ....output omitted

The output shows that R1 knows a path to 22.22.22.22 via a P2P link with a metric of 10. At this point R1 has now solved the shortest path towards the external link 50.50.50.50/32.

 

So to summarise how the LSA recursion works:

R1 recurses the type 5 LSA to a type 4 LSA. The Type 4 LSA is then recursed to a type 1 LSA, and then R1 has solved the SPT to reach the external prefix.

 

End to End Metric Calculation

Metric = The cost that the ASBR has advertised to reach the external prefix = 20 + the cost that the ABR knows to reach the ASBR, which is 1 + the cost to reach the ABR (R2) = 10. So the total end-to-end cost is 20+1+10 = 31. When you check the routing table, it always breaks this cost into two parts for external routes. The “metric” is the cost that the ASBR advertised to reach the external prefix. And the “forward metric” is the cost to reach the ASBR. See below.

R1#sh ip route 50.50.50.50
Routing entry for 50.50.50.50/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 11
  Last update from 10.0.12.2 on FastEthernet0/0, 00:57:30 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 6.6.6.6, 00:57:30 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

 

Scenario 3:  Recursion of a Type 5 LSA learned from an ASBR located in an NSSA

We will use area 0 and the NSSA area from the topology for this scenario. We will look at how R1 recurses the type 5 LSA to reach the ASBR for the external EIGRP link 90.0.0.0/24. Let’s start by checking the type 5 LSA information in the OSPF database on R1.

R1#   sh ip ospf da ex 99.0.0.0

            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: 48
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 99.0.0.0 (External Network Number )
  Advertising Router: 22.22.22.22
  LS Seq Number: 80000003
  Checksum: 0xA30F
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.0.34.4
        External Route Tag: 0

We can see that the advertising router for this link is 22.22.22.22 (R2 only). So why did R3 not also originate a Type-5 LSA into area 0 for this router to use? It’s because when there are 2 or more ABR’s connecting an NSSA to area 0, only one router does the type 7 to type 5 LSA conversion. It’s just a fact of how OSPF operates. Which router that is depends on an election between the ABRs (the highest router-id always wins this election); so in my case this election was between R2 and R3. The winner of the election becomes the only router to do the conversion. Since R2’s RID is 22.22.22.22 and R3’s RID is 3.3.3.3, it means that R2 has the higher 32bit number and wins this election. Therefore R2 is the only router doing the type 7 to 5 translation.
What is also interesting is that the forwarding address has actually been set to a non-zero value. The forwarding address is just an IP address that the routers need to use to reach the external network. This forwarding address dictates the actual path that is taken to reach this external network 99.0.0.0. So when R1 tries to solve the shortest path towards 99.0.0.0, it actually needs to solve the shortest path tree to the forwarding address, 10.0.34.4. Since 10.0.34.4 does not belong to area 0, an inter-area lookup is performed on the type 3 LSA for the forward address. Note how this is different from the previous scenario where we did a type 4 lookup at this point. But since R1 is not trying to solve the shortest path to ASBR anymore, he’s trying to solve the shortest path to the forwarding address (which just so happens to be on the ASBR in this case). But there can be use cases where the forwarding address is not an IP address on the ASBR, so this is why we solve the path to the forward address (which may or may not be attached to the ASBR itself).  I do want to point out here, that when we have this scenario (scenario 3 specifically), we actually solve the shortest path to the route, and not the node-id.   If we were to route 10.0.34.0/24 via null 0 on R1, we would actually lose reachability to the prefix 99.0.0.0 because SPF would not be able to compute the path to reach it.  This is completely different of how normal LSA recursion works, where we solve the shortest path to the node & not the routes: and specifically, we would never need to have a route installed to a node-id.

Anyways, let’s have a look at that type 3 LSA for the forwarding address 10.0.34.4 now.

R1# sh ip ospf database summary 10.0.34.0

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1824
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.0.34.0 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 8000000A
  Checksum: 0x876A
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 10

  LS age: 1704
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.0.34.0 (summary Network Number)
  Advertising Router: 22.22.22.22
  LS Seq Number: 8000000A
  Checksum: 0xAFEB
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 20

As a quick FYI: Since the forward address 10.0.34.4 was actually part of a /24 link state identifier, we have to lookup the /24 network address (10.0.34.0) as opposed to the actual specific IP 10.0.34.4.
Anyways, you can see that we have learned the forwarding address from both R3 (3.3.3.3) and R2 (22.22.22.22), but the routing bit is only set for the route learned via R3. The routing bit means we can actually use this path for routing. You’ll notice that there is no similar statement for the path via R2 underneath, so we cannot use the path via R2. The reason why the routing bit is not set via R2 is due to the worse forwarding metric that R2 uses to reach the forward address (20 vs the path via R3 which is 10). Notice that in this case the forward metric is actually the cost to the forwarding address. This is different from the two previous scenarios where the forward metric was always the cost to reach the ASBR (as I said before, it just so happens to be that the forward address in this case is attached to the ASBR).

We now need to check the OSPF database to see how we to reach 3.3.3.3. Since this router is in the same area as R1, it means R1 already knows the shortest path to R3 via a type 1 LSA. Let’s check that now.

R1#sh ip ospf database router self-originate

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 74
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 8000000A
  Checksum: 0x27E4
  Length: 72
  Area Border Router
  Number of Links: 4

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 10.0.13.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10
  ...output omitted

The output shows that R1 knows a path to 3.3.3.3 via a P2P link with a metric of 10. And at this point now, R1 has solved the shortest path to the destination.

 

So to summarise how the LSA recursion works:

R1 recurses the type 5 LSA to a type 3 LSA. Then R1 recurses the type 3 LSA to a type 1 LSA, and then has solved the SPT to reach the external prefix.

 

End to End Metric Calculation

So the total end to end metric would be this. It would be:
Metric = advertised cost from the ASBR = 20 + the cost from the ABR to the forwarding address = 10 + the cost to the ABR = 10. Making the total end to end cost 20+10+10 = 40. And we can confirm this by looking at the routing table output below and adding the metric to the forward metric.

R1#sh ip route 99.0.0.4
Routing entry for 99.0.0.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.0.13.3 on FastEthernet0/1, 02:59:50 ago
  Routing Descriptor Blocks:
  * 10.0.13.3, from 22.22.22.22, 02:59:50 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1

1 Comment

SamerApril 22nd, 2016 at 8:13 am

i was suffering trying to understand INE video on configuring NSSA, with all explanations on Route recursion it was mess for me…..reading your blog was really great…pretty good explanation….thanks a lot.

Leave a comment

Your comment