How do summarisation and stub routing bound EIGRP's query domain, and why does a bounded query domain make DUAL more stable?

## What the query domain is When an EIGRP router loses its successor for a prefix and has no feasible successor, the route goes **active** and the router sends a `QUERY` to its neighbours. Each neighbour that cannot answer from its own state goes active too and queries further. The routers reached in this way form the **query domain** for that failure, and the router that started it cannot finish until every one of them has replied. RFC 7868 says this scope can be controlled: DUAL can limit where diffusion ends by "hiding reachability information through aggregation (summarization), filtering, or other means", creating failure domains inside one autonomous system. ## The mechanism that ends a query Two rules in RFC 7868 do the work: - A router informed of a change for a destination it has no reachability information for is **not required to go active** or join the computation. - When a `QUERY` arrives for a route that is not in the router's topology table, it **replies with an infinite metric** at once. So a query travels only through routers that hold the **specific prefix**. Wherever that prefix is unknown, the query ends in one exchange. ## Summarisation Suppose a distribution router owns `10.20.0.0/24` through `10.20.15.0/24` and advertises only the summary `10.20.0.0/16` toward the core. The core routers hold the summary, not the `/24`s. 1. `10.20.5.0/24` fails behind the distribution router. 2. The distribution router holds the specific prefix and has no feasible successor, so it goes active and queries its neighbours. 3. The core routers have no entry for `10.20.5.0/24`. Each replies at once with an infinite metric and queries no one. 4. The computation is over after one round trip, however large the core is. Points to keep straight: - The **summarising router still goes active** for the specific prefix; summarisation limits who it must wait for, not whether it queries. - The summary normally stays advertised while any part of it remains, so the core keeps sending traffic for the failed `/24` toward the summary, where it is dropped. That is the ordinary cost of summarising. - **Filtering** routes out of advertisements has the same effect on queries, for the same reason. ## Stub routing Stub routing is **not part of RFC 7868**; it is a feature of the implementations that offer it, and its exact options vary. The idea: - A router at the edge, such as a branch router with one or two uplinks, announces to its neighbours that it is a **stub**: it offers no transit path between other parts of the network. - Its neighbours therefore **do not send it queries**. A stub never offers itself as a transit path, so asking it would only add one more reply to wait for. - A stub router typically also limits what it advertises to its own routes rather than passing on routes learned from other neighbours. On a hub with hundreds of branch sites, this turns every failure at the hub from hundreds of outstanding replies into a handful. | Technique | In RFC 7868? | Where it applies | What it stops | |---|---|---|---| | Summarisation | yes, as hiding reachability | at a boundary router | queries for specific prefixes beyond the boundary | | Route filtering | yes, as hiding reachability | wherever routes are advertised | queries for the filtered prefixes | | Stub routing | no, an implementation feature | edge routers that offer no transit | all queries to those routers | The danger with stub routing is misuse: mark a router that really is a transit path as a stub, and paths through it disappear from its neighbours' view. ## Why a smaller domain is more stable 1. **Fewer replies to wait for.** Convergence for an active route is set by the slowest reply in the domain; fewer routers means a shorter wait. 2. **Less risk of stuck-in-active.** Every extra router is another chance of a lost packet, a busy processor or a long chain behind it. Bounding the domain is the standard prevention. 3. **Smaller failure domains.** A fault in one region costs routers elsewhere a single instant reply rather than their own active computations. 4. **Less work per failure.** Fewer queries and replies cross the network, and fewer routers spend processing time on a change that does not affect their forwarding. The summary arithmetic, which prefixes a summary can cover exactly, is a matter of address aggregation rather than of DUAL; what DUAL cares about is only that routers beyond the boundary do not know the specific prefix.