OSPF Part 11 – Summarization Options

Continuing with our discussion of OSPF summarization options, refer to the figure below…

When we left off, we had reduced the number of Type-5 LSAs being injected into the OSPF cloud from two hundred to two, a summary route from each ASBR. But what if the prefixes that lie within the RIP or EIGRP clouds cannot be easily summarized (a situation which occurs all too often in real life)? In that case, instead of one large summary block, we could configure the ASBRs with multiple smaller summary blocks, by using multiple OSPF “summary-address” commands. The resulting Type-5 LSAs would then flood through Area 0 and into Area 1, but this is better than having every router know about each individual external prefix.

Notice that to reach any external prefix, R5 must send the packet towards Area 0. We can take advantage of this by configuring Area 1 as an OSPF “stub” area.  To do this, we use the OSPF “area stub” command on all routers connected to the area (including any ABRs). If we do, each ABR will inject a default route into Area 1, and no Type-5 LSAs are injected.

Remember that the stub area flag is contained within OSPF hello packets, and it is an option on which neighbors must agree, so it’s important that the “stub” feature be configured on all routers connected to the stub area. In the case of Area 1, this would be R3 and R4 (the ABRs), as well as R5 (an internal router).

At this point, the best paths from R5’s perspective are:

  • Subnet A via R3 (cost = 3)
  • Subnet B via R3 (cost = 3)
  • Subnet C via R4 (cost = 3)
  • Subnet D via R4 (cost = 3)
  • RIP and EIGRP clouds via defaults from R3 and R4 (cost = 1)

Since R5’s routing table now contains one default (with two next hops) instead of two summary routes, we’ve just saved some more RAM on R5. So what’s not to like? Next time we’ll find out!

Now let’s suppose that R5 wants to get a packet to the RIP cloud. Since R5 is receiving the default route from both R3 and R4, if the metrics are the same (which they would be unless we change them), R5 will load-share traffic for the RIP cloud between R3 and R4. In other words, half of the packets bound for the RIP cloud from R3 will take the sub-optimal path via R4. Likewise, since R5 will load-share packets for the EIGRP cloud between R3 and R4, half of those packets would take the sub-optimal path via R3.

Next time, we’ll look at what can happen if Area 1 is made “totally stubby”.

Author: Al Friebe

In this article

Join the Conversation