Octet

Besides stub routers, how do you stop EIGRP queries from travelling across the whole network?

Show the answer

Say this first

Make sure routers away from the failure do not know the exact prefix. A router that gets a query for a prefix it has no topology entry for replies "unreachable" at once and does not pass the query on. So summarization at distribution and hub routers, and route filtering, put a boundary on the query. Stubs mean the query is not sent at all. Together they keep a failure local.

Go deeper

A worked flow

DSW1 summarizes 10.20.0.0/24 to 10.20.3.0/24 to CORE1 as 10.20.0.0/22. ASW1 owns 10.20.1.0/24, and ASW1 and ASW2 are stubs.

  1. 10.20.1.0/24 goes down on ASW1. ASW1 tells DSW1.
  2. DSW1 has no other path, so the /24 goes active on DSW1.
  3. DSW1 does not query ASW2 because it is a stub.
  4. DSW1 queries CORE1. CORE1 only knows the /22, so it has no entry for the /24 and replies unreachable immediately.
  5. DSW1 goes passive with the /24 gone. The /22 stays up because other components remain.

The core and everything behind it did no work, and nothing outside the block saw a change.

The tradeoff

A summary hides detail. If one access block is dual-homed and summarized from two places, traffic can be drawn to the wrong side when a component fails there, because the summary still looks good. The summary also installs a Null0 route on the summarizing router, so traffic to unused space inside it is dropped there.

Summary metric churn

In classic mode the summary takes the metric of its best component. If that component flaps, the summary is re-advertised with a new metric, causing an update across the core. Named mode can pin the advertised value with summary-metric under topology base.

Traps

  • Saying summarization stops the query from being sent. The query is still sent to the core router; the summary makes that router answer at once.
How did you do?Book 3.4 RoutingBook 4.1 Global Internet