Route summarization can be a good thing when done correctly. By summarizing a group of specific routes into one larger summarized (aggregate) route you can greatly improve the stability of the internetwork routing protocol. When a router advertises a summary it hides link failures and instabilities behind the summary from being seen by the rest of the routers in the network receiving the summary. This hiding behavior prevents unnecessary routing protocol convergence and keeps the internetwork stable if a routing loop or flapping link is affecting a peripheral area of the network. However, as with most good things, there are trade-offs. When we use summarization we are trading network stability for routing accuracy. If done incorrectly, route summarization can prevent a network from converging properly, create black holes, and cause sub-optimal routing conditions. Configuring route summarization can get particularly tricky where there are one or more alternate paths to a summarized destination.

Here are two common mistakes when implementing route summarization with alternate paths:

  • Using alternate paths to bypass a point of summarization.</li>
  • Specfic routes leaking out of the summarized area from an alternate path.</li>

Figure 1.1 below shows case #1 where an alternate (redundant) path to a site in the network is bypassing a point of summarization.

route summarization

In Figure 1.1 above, R3 and R4 belong to the same site with a high speed (metric 1) link connecting them together and they both have subnets in the same 10.128.0.0/16 address range. The preferred method for R1 and R5 to reach the 10.128.0.0/16 subnets is to use their direct link to R3. R1 will use R2 as an alternate path, and R5 will use a lower speed direct link to R4 as its alternate path. R3 and R4 have been configured to advertise a summarized route, 10.128.0.0/16, to their neighbors R5, R1, and R2.

At this point, life is good, R1 and R5 see a single summarized route from R3 as their best path to reach the 10.128.0.0 subnets. They also receive the summary on their alternate paths, but those paths are not installed in the routing table because of the higher metric. Everything appears to be fine until the link between R3 and R4 fails. The network administrator is surprised to find that suddenly R4 has lost all connectivity. R1 and R5 can no longer reach the 10.128.200.0 /24 subnet on R4. Why is this? Why are the alternate paths not working!?

The problem is this: The alternate paths are useless because route summarization is doing exactly what it is supposed to be doing, it’s hiding link failures behind the summary. When the R3-R4 link fails, R3 does nothing, it continues to advertise its summary route to R1 and R4 as if nothing happened. The only reason R3 would ever stop advertising the summary would be if it had no specific routes left in its routing table to summarize, or if the router completely died altogether. Since R3 has its own directly connected subnet within the summary (10.128.1.0/24) it sees no reason to stop sending the 10.128.0.0/16 summary. R1 and R5 are unaware of any link failure and continue to see R3 as the best path to subnets connected to R4. Once the traffic reaches R3 it is dropped by the 10.128.0.0/16 route to interface Null0 that R3 creates when the summary is configured.

Alternate paths that bypass a point of summarization are useless in protecting link failures behind the summary. In this case, R2 is the alternate path for R1 that bypasses R3 to reach subnets that are summarized by R3. The low speed link between R5 and R4 is an alternate path that bypasses R3 to reach subnets summarized by R3. Each alternate path is useless in this scenario.

One solution to this problem would be to create two smaller unique route summaries, one unique to R3 and its subnets, and the other unique to R4 and its subnets. With unique summaries, the alternate paths would not reach subnets summarized by the router being bypassed. Figure 1.2 below shows the solution.

route summarization

In the figure above, R3 no longer summarizes the subnets on R4, rather R4 sends a unique summary of its own. When the R3-R4 link fails, R3 stops advertising the summary learned from R4 and routers R1 and R5 begin using the summary learned on the alternate paths as their best route to R4’s subnets. When configuring route summarization it is important to make sure that the more specific routes making up the summary are not advertised out of alternate paths into the rest of the network. When all paths leading out of a summarized area have not been configured for summarization, the more specific subnet advertisements will “leak” out into the network. Leaking routes can cause sub-optimal routing as shown in the diagram below. Figure 1.3 below shows case #2 where specific routes that are supposed to be summarized are leaking out alternate paths, causing sub-optimal routing.

route summarization

Summarized routes need to be advertised not only to the best paths, but the alternate paths as well. If more specific routes are allowed to leak out of alternate paths, the rest of internetwork will chose the alternate path as the best path. This is because routers use the rule of longest match when making routing decisions. In this case, if a router needs to send traffic to 10.128.1.1 and has both 10.128.0.0 /16 and 10.128.1.0 /24 routes in the routing table, it will always choose the /24 route over the /16 route because it is a more specific match. This will cause sub-optimal routing to destinations.

In the diagram above, R3 needs to send a summary to R4 as well in order to prevent R4 from receiving and advertising R3’s more specific routes to its neighbors using the less desirable alternate paths. These sub-optimal routing problems may go unnoticed initially as full connectivity will be established. Figure 1.2 above shows R3 plugging the leak by sending a summary to R4.

Route summarization is generally a good thing. When planned and configured properly it will greatly improve internetwork routing protocol stability and failure recovery performance. However, summarization needs to be considered very carefully as it can quickly create problems such as black holes, failed convergence, and sub optimal routing if misconfigured and improperly planned.