EIGRP Query bounding.

• July 13, 2014
• CCDE  
• Technology  
• EIGRP  
• Queries  
• Routing Protocols  

In the process of restudying EIGRP as a protocol, and more specifically as to how it converges, you can’t avoid running into the saying “Remember to bound your queries!”.

From a conceptual point of view its fairly easy to understand that the further out you ask for a prefix the longer the convergence process will take. But what really takes place when you have different tools in place to bound the query from taking place?

There are 3 different types of “Query Bounding” techniques that can be utilized:

1) Filters (fx. distribute lists).

2) Summarization

3) Stub routers.

How do they actually work to limit the query scope?

Well, the basic premise for EIGRP queries is the fact that you are asking your fellow EIGRP neighbour for an exact prefix, fx. 172.16.1.0/25. If for any reason you EIGRP neighbour does not have this in his topology table, it will simply respond right away that it doesn’t have a path to this prefix. Query stopped right there.

By using filters such as distribute lists you are removing the prefix from ever getting advertised to the neighbour and as such he will never receive it in his topology table.

Summarization is a little bit different. You are still sending a prefix, however instead of it being a specific prefix, it has now been summarized. In our example, instead of 172.16.1.0/25, it might have been summarized to 172.16.1.0/24. This means that when a query comes in for a lost route to 172.16.1.0/25, the router will again respond that its never had this route in its topology table. Again, the query has been stopped.

Last one is by using stub routers. When the EIGRP adjacency is coming up between two routers, the one thats been configured as a stub router will include this fact in its hello packets and as such the upstream router will know this fact about the adjacency. When the route to 172.16.1.0/25 is lost, the upstream router will already know not to ask the downstream router at all, because by definition its a stub.

But pay close attention, you will see a notable difference between the first two methods of bounding the query scope and the last one. With the first two, the query will still reach one router further downstream before getting replied to. With the last one, it never even propagates that far.

That means from a convergence point of view, that if possible, you are better off by using the “stub” router feature where appropriate. A good example would be toward your access routers in either a 2 or 3 level hierarchy.

Just an observation. Hope it helps!