EIGRP is based on the concept of diffusing computations. When something changes in network topology, the routers that detect a loss of network prefix will send out EIGRP QUERY messages that propagate in circular waves similar to the ripples on water surface. Every queried router will in turn query its neighbors and so on, until all routers that knew about the prefix affected. After this, the expanding circle will start collapsing back with EIGRP REPLY messages. The maximum radius of that circle may be viewed as the query scope. From scalability standpoint, it is very important to know what conditions will limit the average query scope, as this directly impact the network stability. You may compare the "query scope" with the concept of flooding domain in OSPF or ISIS. However, in contrast with the link-state protocols, you are very flexible with chosing the query scope boundaries, which is a powerful feature of EIGRP.

There are four conditions that affect query propagation. Almost all of them are based on the fact that query stops once the queried router cannot find the exact match for the requested subnet in its topology table. After this the router responds back that the network is unknown. Based on this behavior, the following will stop query from propagation

1) Network summarization. This could be considered as one of the most effective methods of query scoping. If router A sends a summary prefix to router B, then any query from A to B with regards to the subnets encompassed by the summary route will not find the exact match in B’s topology table. Thus queries are stopped on the routers that are one-hop from point of summarization. Given the fact that EIGRP allows for introducing summarization virtually everywhere you may easily partition your network into query domains. However, one important thing here – this requires well-planned hierarchical addressing, based on the Core-Edge model. Sending a default route to isolated stub domain could be considered an extreme case of summarization and is very effective.

2) Route filtering. You may filter EIGRP routes at any point using distribute-lists, route-maps etc. As soon as a route is filtered, the next-hop router will not learn it. When a query propagates to the next-hop, it will stop and return back. The use of route filtering is probably not as popular as route summarization, but could be used in some situations when you want to reduce the overall amount of queries but want to retain some routing information. In general, using proper route summarization should be enough.

3) Stub routers. This feature is different. Instead of “deflecting” queries, it simply signals the neighbors NOT to query the given router. This means the stub router could not be used as a transit path for any network. The stub router neighbors will not query it and thus stub feature prevents queries from even being generated. It is especially effective in “start” network designs, such as hub-and-spoke networks.

4) Different EIGRP AS numbers. EIGRP processes run independently from each other, and queries from one system don’t leak into another. However, if redistribution is configured between two processes a behavior similar to query leaking is observed. Consider that router R runs EIGRP processes for AS1 and AS2 with mutual redistribution configured between the two processes. Assuming that a query from AS1 reaches R and bounces back, R is supposed to remove the route from the routing table. This in effect will trigger route removal from AS2 topology table, as redistribution is configured. Immediately after this R will originate a query into AS2, as the prefix becomes active. The query will travel across AS2 per the normal query propagation rules and eventually R will learn all replies and become passive for the prefixes. It’s even possible for R to learn the path to the lost prefix via AS2 and re-inject it back into AS1 if the network topology permits that. As per the regular query propagation rules, you may use prefix summarization when redistributing routes to limit the query scope.

The above described are four main things that may limit query scoping. If you are using different AS numbers for this purpose, make sure you configure route summarization when doing redistribution, as otherwise you may get the “leaked query” effect.

Petr Lapukhov, 4xCCIE/CCDE
About Petr Lapukhov, 4xCCIE/CCDE

Petr Lapukhov has more than 12 years of experience working with Cisco Systems products. Not only is he the only person in the world to have earned four CCIEs (Routing & Switching, Security, Service Provider, and Voice) in just two years, he also passed every exam the first time. He shares his knowledge and experience with INE’s students through our various products and programs. Petr works with all of the technologies covered within his four CCIE tracks on a daily basis, staying current with any changes in the industry. He has also received his Cisco Certified Design Expert (CCDE) certification, joining a small group of distinguished individuals who have achieved this status. Petr is a contributor to INE’s blog and our INE IEOC Community Forum. You may contact Petr Lapukhov at

Subscribe to INE Blog Updates

New Blog Posts!