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.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

18 Responses to “EIGRP Query Scoping”

  1. Jochen Bartl says:

    Great post. I can also recommend the following talks on this topic, which I’ve watched on the Cisco Live Virtual website yesterday:

    BRKRST-2330 – EIGRP Design and Deployment
    BRKRST-3330 – The Care and Feeding of an EIGRP Network

    best regards


  2. John Spaulding says:

    Aweomse!! Thanks

  3. ricecs says:

    One more situation, when queried route has no other neighbor to query. The extreme example is like following

    / \

    If R1 lost link to, what would be the sequence for R1, R2, R3?

    • R1 will send queries to both R2 and R3. If the query reaches R2 first, it will futher propagate it to R3. Symmetrically, if the query reaches R3 first, it will propagate to R2. After this both R2 and R3 will respond to R1 and the query process stops.

  4. Nish says:

    This is a valuable post…

    It would be great if you could illustrate the 4 types of “query stopping” with some diagrams please…more like your other posts…

  5. CCIE2be says:

    Great post , just a quick question re : “query stops once the queried router cannot find the exact match for the requested subnet in its topology table.”

    Is it topo table or route table ? A route could be in topo table with infinite metric and still not be in route table .

    • It is the EIGRP topology table.

      • Like Athony said it is the topology table. The reason is simple – query process is diffusing computation. Every new router involve searches for alternative path if the one it used previously failed as a result of the query. Among alternative are of course the Loop Free Alternatives found in the topology table using feasibility condition. I’m going to write up a post that describes the actual working mechanics of EIGRP, as many people seems to be confused with that one.

  6. Ian says:

    Thanks Petr…

    Like Nish, I too would love to see a detailed diagram example of these scenarios, as some of the sample CCIE R&S written questions could be a little tricky regarding this topic!!

  7. Vineet says:

    Can we change the distance when doing summarization on an interface?

  8. choywy says:

    Like to comment on Post no. 4 above by Petr Lapukhov.

    From my understand, EIGRP queries do not have the concept of arrive first/second/third..etc

    I believe in this scenario, R1 will send query to R2 and R3. R2 and R3 receive the queries and send another query to EACH OTHER.

    And all the queries send by R1/R2/R3 will get a reply from the other end.

    Is my understanding correct? Thanks..

  9. [...] EIGRP Query ScopingA short summary on EIGRP query scoping, which is they key to EIGRP scalability [...]

  10. joota/ccnp says:

    general concept of querry stop querry messages


  11. Vinicius Arcanjo says:

    Petr, I’d like to thank you for this AWESOME article. It’s very clear and goes direct to the point!

    Thank you!

  12. Srijana says:

    Thanks a lot.. valuable article and which cannot be found in Books.

  13. mark heuz says:

    I think,
    It is especially effective in “start” network designs, such as hub-and-spoke networks.

    should be,
    It is especially effective in “star” network designs, such as hub-and-spoke networks.


Leave a Reply


CCIE Bloggers