Why you should summarize your routes

I was once asked a question about EIGRP queries. The question was, how do you prevent an EIGRP router from being queried for a lost route? Of course I responded with just make it an EIGRP stub router. And I was correct. But then I was asked, what about the hub router...How do you mitigate queries going to the hub router? I didn't have a clue. The answer was summarization!

When you have an EIGRP hub and spoke topology, it is best practice whenever possible to make all spokes EIGRP stubs AND summarize on your hub router towards your spokes. Here's what happens if you don't do that:

Let's say we have numerous spoke routers. Now let's say one of the spokes loses connection. Eventually the EIGRP timers will expire on the hub, and the hub will remove all routes from it's topology database that were being advertised by that spoke. Next, the hub queries all other spokes for a replacement path to those lost routes. This is why we're told to use EIGRP stub on our spoke routers where possible, to prevent needless query traffic because a stub router is never queried for lost routes, and the spoke doesn't know another path anyway.

Now let's say we have a spoke that connects to another EIGRP router other than the hub. What happens when that router fails? Well the spoke will eventually notice that it's down, then it will query the hub router for another path to the down networks. Then the hub will in turn query all of its non-stub spokes and other EIGRP neigbors. This continues until all peers have responded to all queries. This is known as a route "going active". The route will stay active until all peers have responded to all requests. This is referred to as "stuck in active". This is not ideal.

This is one reason why it's recommended to summarize on our hub links. Because in the previous example, when the spoke goes to query the hub about its other EIGRP peer, instead of the hub going into a stuck in active process, it will simply respond with its own summary route. No cascading queries to deal with!

Summaries also help when any spoke router is lost. When a spoke fails, although the hub won't query any stub routers, it does still update them about the lost routes, which is pointless, unnecessary traffic. A summary also comes in handy here. With a summary in place, the hub doesn't even bother updating the other spokes about the lost routes, it doesn't have a reason to. It's already sending a summary route, so there's no point in alerting the spokes that it lost a more specific route that falls under that summary. This is another bonus to summarizing.

Not only does all this lower resource utilization, it also increases routing stability and scalability, and lessens the likelihood of the infamous EIGRP "stuck in active" scenario. Obviously this gets more important the more spokes and layers of daisy chaining you have going.

So that is why you should use stubs and summaries in EIGRP.