OSPF, Part 4

Let’s talk about some issues that arise when we scale an OSPF internetwork up to a large size. As usual when it comes to scalability, there are three issues involved:

  • Bandwidth
  • RAM
  • CPU

First, as the internetwork grows, there are more routers. Recall that with link-state protocols such as OSPF, every router’s LSA (Link State Advertisement) is flooded throughout the internetwork. Obviously, the more routers, the more LSAs must be flooded, which results in more LSU (Link State Update) packets, consuming more bandwidth on the links.

Second, as the LSAs are flooded, each router makes a copy of each LSA, which it keeps in its LSDB (Link State Database). Therefore, the more routers, the larger will be each router’s LSDB, and a larger LSDB requires more RAM to store it. Also, since there are a lot of prefixes, the resulting routing table will be large, requiring even more RAM.

Third, every time a router’s LSDB changes, the router runs Dijkstra’s SPF algorithm to generate its revised routing table. The larger the internetwork, the larger the LSDB, and the more frequently it’s likely to be changing. Thus, each router is running SPF more often on a larger LSDB, consuming more CPU cycles.

The bottom line is that since bandwidth, RAM, and CPU cost money (and we don’t have infinite money) there is some limit to how large an OSPF autonomous system can grow. There are two solutions to this scalability problem

    1. Limit OSPF to small internetworks (bad idea!)
    2. Modify OSPF to enhance its scalability (good idea!)

      Of the two options, the latter was used, and we call it “multi-area OSPF”. What we do is divide the OSPF autonomous system into regions called “areas”. An example of a multi-area OSPF topology is shown here:

      Here’s how it works

      A router that lies completely within an area is called an “internal router”. Internal routers, such as R1, know the entire topology for that specific area (in R1’s case it’s Area 1). Using SPF on its LSDB, R1 builds its routing table by calculating the best path from itself to any prefix within Area 1. At this point, R1 knows the best route to all prefixes within Area 1. Likewise, internal routers R3 and R5 calculate their routing tables for Area 0 and Area 2, respectively.

      A router that is attached to more than one area is called an Area Border Router (ABR), and it maintains an LSDB for each area to which it is attached. R2, for example, is an ABR which connects Area 0 and Area 1. R2 runs SPF on its Area 0 and Area 1 LSDBs, and the results go into its routing table. Thus, R2 knows the best path from itself to all prefixes within Area 0 and Area 1. In addition, R2 now advertises the prefixes that lie within Area 0 into Area 1, and vice-versa. Note that only the prefixes and their metrics are advertised, not the existence of individual routers within an area. Likewise, R4, the ABR between Area 2 into Area 0, advertises prefixes between them.

      For reasons of fault-tolerance, it’s possible that there could be two or more ABRs joining two areas. Since each ABR advertises the cost for each prefix from its perspective, the routers in the area receiving the advertisements can make optimal routing decisions about the prefixes that lie in the other area. At this point, all routers know the best route to all prefixes within the areas to which they are attached, and to the prefixes within the adjacent areas.

      Furthermore, the Area 1 prefixes that R2 is sending into Area 0 are flooded over to R4, which then floods them into Area 2. As a result, all routers in Area 2 know about the prefixes in Area 1. This happens in the opposite direction, as well, and when the flooding has completed, all routers will know about all of the prefixes within the entire OSPF autonomous system. Because it’s just the prefixes and their costs that are being advertised between areas, and not detailed topology information, this requires less bandwidth, RAM and CPU than if it were all one big OSPF area, with all routers knowing everything about the topology.

      In the next installment, we’ll continue our discussion of multi-area OSPF, including some techniques to further increase the scalability.

      Author: Al Friebe

      In this article

      Join the Conversation