Why Are OSPF Type 5 LSAs Flooded?

I recently saw a great question on Reddit, on why Type-5 (AS-external) LSAs are flooded, in comparison to Type-3 (Summary) that are regenerated at the ABR. To investigate this, we’ll use the following simple topology where R2 and R3 are ABRs:

OSPF Behavior Type-3 LSAs

Let’s see how OSPF handles Summary LSAs. Let’s first look at Area 1, where R4 is advertising 169.254.0.0/24 into it. This can be seen in the LSDB of R2:

R2#show ip ospf data router 203.0.113.4

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

                Router Link States (Area 1)

  LS age: 74
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 203.0.113.4
  Advertising Router: 203.0.113.4
  LS Seq Number: 80000009
  Checksum: 0x1DF0
  Length: 84
  Number of Links: 5

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

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

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

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

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

Notice the Link State ID and Advertising Router that are both 203.0.113.4 (R4).

Now let’s look at the Summary LSA from the perspective of R1:

R1#show ip ospf data summary 169.254.0.0 

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

                Summary Net Link States (Area 0)

  LS age: 256
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 169.254.0.0 (summary Network Number)
  Advertising Router: 203.0.113.2
  LS Seq Number: 80000001
  Checksum: 0xBB97
  Length: 28
  Network Mask: /24
        MTID: 0         Metric: 2 

  LS age: 256
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 169.254.0.0 (summary Network Number)
  Advertising Router: 203.0.113.3
  LS Seq Number: 80000001
  Checksum: 0xB59C
  Length: 28
  Network Mask: /24
        MTID: 0         Metric: 2 

Notice that the Advertising Router is now 203.0.113.2 (R2) and 203.0.113.3 (R3), the two ABRs. As you know, OSPF is a hierarchical routing protocol where the Type-1 and Type-2 LSAs are only flooded within an area. Those are then summarized into Type-3 LSAs by the ABRs. Summary as in topology, not prefix. The flooding scope for Type-1 and Type-2 LSAs are not domain wide, just area wide.

OSPF Behavior Type-5 LSAs

Now, for Type-5 LSAs, the story is different. These are flooded domain wide. Let’s look at a Type-5 LSA on R1:

R1#show ip ospf data ex 169.254.1.0

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

                Type-5 AS External Link States

  LS age: 43
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 169.254.1.0 (External Network Number )
  Advertising Router: 203.0.113.4
  LS Seq Number: 80000001
  Checksum: 0xEEC6
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

Note that the Advertising Router is 203.0.113.4 (R4). This LSA has been flooded, rather than advertised by the ABR. Why is that?

To find the answer to this question, we go to John Moy’s (author of RFC 2328) book OSPF – Anatomy of an Internet Routing Protocol:

How is external routing information conveyed across area borders in OSPF? One way this could have been done in OSPF was to reoriginate the AS-external-LSAs at area borders, just as OSPF does with summary-LSAs for inter-area routes. However, this would have been expensive in terms of database size. When there are multiple area border routers for a given area, multiple AS-external-LSAs would be originated for each original AS-external-LSA: one origination per area border router. And within the area border routers, the situation would have been even worse, with each area border router holding a slightly different version of each AS-external-LSA for each attached area.

So OSPF takes a different tack, simply flooding AS-external-LSAs across area borders.

The reason for flooding them is to minimize the size of the LSDB, and the amount of work for ABRs. Remember, this was back when CPU capacity was very limited. Why treat External LSAs differently than Summary LSAs? The expectation is that you would have many more external than internal routes. While you may only have tens of hundreds internal routes, you could have thousands or tens of thousands external routes. There was a time when it wasn’t uncommong to redistribute routes you had learned from BGP, such as internet prefixes, into your IGP. While this was never a great design, it certainly worked better when the internet was 10k routes rather than a million routes.

What If We Didn’t Flood Type-5 LSAs?

Let’s take a closer look at how things would have been if we didn’t flood External LSAs domain wide. Let’s start with the first claim on the number of LSAs that would get flooded into an area. If the ABRs would have regenerated Type-5 LSAs, then the number of LSAs flooded into an area would have been number of Type-5 LSAs x number of ABRs:

The original 1000 Type-5 LSAs have been doubled, as there are two ABRs. Also keep in mind that the ABRs need to modify the content of the LSA. This is more work than simply flooding it. Additionally, the LSDB size of the ABRs grows rapidly as the 1000 Type-5 LSAs that originated in Area 1, becomes 2000 in Area 0, it would originate 1000 on its own, and receive 1000 from the other ABR.

Compare this to how Type-5 LSAs are really handled below:

The number of LSAs in the LSDB is the same for all the routers. There are two Type-4 LSAs needed to reach the ASBR, but the original 1000 Type-5 LSAs remain the same number and is not a factor of the number of ABRs. The LSDB is both smaller on the backbone router, as well as the ABRs.

Returning to our fictional scenario, imagine that the ABRs were attached to more areas. If Type-5 LSAs weren’t flooded, the LSDB would grow additionally on the ABRs based on the number of areas:

I removed one ABR to simplify the diagram a bit. In this scenario, the ABR is connected to four non-backbone areas (Area 1-4), hence the total number of LSAs grow to 9000:

• 1000 in Area 1 where they originated.
• 1000 in Area 2.
• 1000 in Area 2 from the other ABR.
• 1000 in Area 3.
• 1000 in Area 3 from the other ABR.
• 1000 in Area 4.
• 1000 in Area 4 from the other ABR.
• 1000 in Area 0.
• 1000 in Area 0 from the other ABR.

The original 1000 Type-5 LSAs have turned into 9000 on the ABRs as it would have to keep copies per area, and also receives the other ABRs copies. Not very efficient!

It makes sense to flood Type-5 LSAs domain wide as the expectation is that they are larger in volume than prefixes internal to the AS.

Other Considerations

Beyond the size of the LSDB, the type Type-5 and Type-4 LSAs also provide the following:

• Optimal routing towards external destinations.
• Ability to inject routes towards non-OSPF speakers.
• Route server functionality.

Let’s focus on the first use case.

Optimal Routing Towards External Destinations

To find the cost towards external destination, the following is performed:

• Find the Type-5 LSA for the prefix.
• Get the metric of the Type-5 LSA.
• Get the Advertising Router of the Type-5 LSA.
• Find the Type-4 LSA that matches Advertising Router of the Type-5 LSA.
• Get the metric of the Type-4 LSA.
• Get the Advertising Router of the Type-4 LSA.
• Find the Type-1 LSA that matches Advertising Router of the Type-4 LSA.
• Get the metric of the Type-1 LSA.
• Add all metrics.

Let’s go through all of these steps. The Type-5 has a metric of 20:

R1#show ip ospf data ex 169.254.1.0

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

                Type-5 AS External Link States

  LS age: 426
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 169.254.1.0 (External Network Number )
  Advertising Router: 203.0.113.4
  LS Seq Number: 80000054
  Checksum: 0x481A
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

The Type-4 has a metric of 1:

R1#show ip ospf data asbr-summary 203.0.113.4

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

                Summary ASB Link States (Area 0)

  LS age: 268
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 203.0.113.4 (AS Boundary Router address)
  Advertising Router: 203.0.113.2
  LS Seq Number: 80000054
  Checksum: 0x2D3A
  Length: 28
  Network Mask: /0
        MTID: 0         Metric: 1 

  LS age: 56
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 203.0.113.4 (AS Boundary Router address)
  Advertising Router: 203.0.113.3
  LS Seq Number: 80000054
  Checksum: 0x273F
  Length: 28
  Network Mask: /0
        MTID: 0         Metric: 1 

The metric to reach the ABR is also 1:

R1#show ip ospf data router 203.0.113.2

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

                Router Link States (Area 0)

  LS age: 1048
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 203.0.113.2
  Advertising Router: 203.0.113.2
  LS Seq Number: 80000056
  Checksum: 0x6724
  Length: 48
  Area Border Router
  Number of Links: 2

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

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

This means that the metric is 20, plus a forward metric of 2:

R1#show ip route 169.254.1.0                 
Routing entry for 169.254.1.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 192.0.2.6 on GigabitEthernet0/1, 1d22h ago
  Routing Descriptor Blocks:
    192.0.2.6, from 203.0.113.4, 1d22h ago, via GigabitEthernet0/1
      Route metric is 20, traffic share count is 1
  * 192.0.2.2, from 203.0.113.4, 1d22h ago, via GigabitEthernet0/0
      Route metric is 20, traffic share count is 1

What’s important to understand here is that the ABRs advertise their cost to reach the ASBR via the Type-4 LSA. They know the cost based on link-state information in the area, via Type-1/Type-2 LSA for the ASBR. This is visualized below:

Now let’s see what would happen if we had treated Type-5 as Type-3. Noticed that I changed the cost of one of the links:

In this scenario, the ABRs regenerate the Type-5 and send it into Area 0 with a metric of 20. As there is no Type-4 in this scenario, the cost to reach the ASBR is hidden. Instead, only the cost of reaching the ABR would be taken into consideration. RT02 and RT03 would be equally good then, even though RT03 has a much higher cost towards RT04. We would have suboptimal routing towards external destinations! This is shown below:

It would in theory of course be possible to change how metric is calculated for Type-5, by including the cost to the ASBR in the metric of the reoriginated Type-5 LSA, but this would require a change to the protocol itself.

Let’s summarize.

Summary

The way OSPF floods Type-5 LSAs is different to Type-3. This is related to optimizing the size of the LSDB, something that was very important when OSPF was designed due to low amounts of memory and limited CPUs. Type-5 LSAs are flooded domain wide and the Type-4 LSA is used to find the shortest path to the ASBR, something that provides optimal routing to external destinations. If Type-5 LSAs were instead regenerated at the ABR, then there could potentially be suboptimal routing as the cost to the ASBR would be hidden. It would be possible to change this behavior, by including also the cost to the ASBR in the Type-5 LSA, but this would require modifying OSPF. With how Type-5 LSAs are flooded, the size of the LSDB is minimized. This is particularly apparent when using multiple ABRs and/or having multiple attached areas on the ABRs.