An IPv4 site router advertises 10.20.0.0/16 upstream to summarise its four LANs, 10.20.0.0/24 through 10.20.3.0/24; what goes wrong for the rest of that /16?
answer
- the summary attracts all of it
- exact summary is much smaller
- discard route versus default route
- someone else's more-specific disappears
basics
~20 sThe /16 attracts traffic for 65,536 addresses though only 10.20.0.0/22 exists. Unused space is dropped at the site, or loops via its default route without a discard route; others using that space lose traffic when their more-specific vanishes.
solid answer
~40 sThe exact summary is `10.20.0.0/22`; the /16 also claims 252 /24s the site does not route, and every router that accepts it sends that traffic to the site. With a discard route for the summary, as RFC 4632 requires of a router that generates an aggregate, the traffic is dropped there: a contained black hole. Without one, it falls to the site's default route, goes back upstream, comes back down via the /16, and loops until its TTL expires. Worse, if another site uses part of the /16, say `10.20.8.0/24`, its traffic is safe only while its more-specific route is present everywhere; withdraw or filter that /24 and its traffic lands at the first site and dies. Summarise exactly, and only space you own.
go deeper
Recall that a summary attracts traffic for every address it covers, not only the subnets that really exist behind the router announcing it.
Explain the two outcomes for unused space: dropped by a discard route, or looping along the default route until the TTL expires.
Show how an over-summary turns someone else's withdrawn or filtered more-specific into a black hole, why it passes testing, and how you would detect it in production.
Decide where summaries belong in the network and who owns each one, trading table size against hidden failures and the blast radius of a wrong summary.
## The scenario A site router holds four connected LANs, `10.20.0.0/24` through `10.20.3.0/24`, and a default route pointing upstream. To keep the upstream table short it advertises one summary, `10.20.0.0/16`. The exact summary of those four blocks is `10.20.0.0/22`: four /24s, 1,024 addresses, starting on a /22 boundary. The /16 is 65,536 addresses, 256 /24s, of which 252 hold nothing at this site. Advertising it says "send me everything from `10.20.0.0` to `10.20.255.255`", and every router that accepts it will. ## What happens to the unused space Traffic for an address the site does not use, such as `10.20.77.9`, follows the /16 to the site router. What happens next depends on what that router holds: 1. **With a discard route for the summary**, the packet's longest match is the discard entry and it is dropped. RFC 4632 requires exactly this: a router that generates an aggregate must discard packets that match the aggregate but none of its more-specific routes. Whether the drop is silent or answered with an ICMP Destination Unreachable is an implementation choice. 2. **Without one**, the packet's only match is the default route, so it goes back upstream. Upstream matches the /16 and sends it back down. The packet ping-pongs until its TTL reaches zero, and the router where that happens sends an ICMP Time Exceeded to the source, as RFC 1812 requires. Every such packet crosses the same link many times, so a scan of the unused space multiplies its load on that link. The loop also makes the problem easy to misread: the source receives a Time Exceeded from one of the two looping routers, which reads like a broken path rather than like a summary that is too wide. Either way the unused space is a **black hole**: advertised as reachable, attracting traffic, delivering none. Done correctly the harm is contained at one router; done carelessly it becomes a **forwarding loop**. ## When the extra space is used somewhere else The worse case is an over-summary covering addresses another part of the network really uses. Suppose a second site owns `10.20.8.0/24` and advertises it. | State of the routes upstream | Packet to 10.20.8.5 goes to | Result | |---|---|---| | `10.20.8.0/24` and `10.20.0.0/16` both present | second site, by longest match | delivered | | `/24` withdrawn after the second site's uplink fails | first site, via the /16 | dropped there | | `/24` removed by a filter that accepts only shorter prefixes | first site, via the /16 | black-holed while the second site is healthy | The first row is why over-summaries look harmless in testing: longest match hides them while every more-specific is present. The second is tolerable only by luck, since the destination was unreachable anyway, but RFC 4632 notes that it misleads diagnosis: a traceroute ends inside the summarising network rather than where the fault is. The third is a real outage, and the summary caused it. ## Failure hiding is the same mechanism Even an exact summary hides failures. If `10.20.2.0/24` goes down, `10.20.0.0/22` stays advertised, so upstream keeps sending that LAN's traffic to a router that can only discard it. If a backup path to that LAN exists through another router, upstream prefers it only when that router announces the /24 itself, which is longer than the surviving /22. Stability upstream is bought with visibility, and the summary is where you decide how much of each you want. ## How to summarise safely - **Summarise exactly**: here `10.20.0.0/22`, not the /16. - **Summarise only space you own and route.** A covering prefix wider than your blocks is acceptable when the whole range is assigned to you and its unused parts should be dropped. - **Install a discard route** for every summary you generate, so unused space is dropped once instead of looped. - **Keep overlapping more-specifics alive** through every filter between their origin and the routers that also hold your summary. - **Watch for unexpected traffic** arriving for unused parts of a summary; it is often the first sign that someone else's more-specific has vanished. - **Leave growth room aligned**, so new LANs land inside the existing summary rather than beside it. Where a routing protocol lets a router summarise, and how it is configured there, belongs to that protocol; the validity test is the same arithmetic in every case.
- Why does a missing discard route turn a black hole into a loop?Because the summarising router forwards on the longest match it holds. Without a discard entry for the summary, an unused address inside it matches only the default route, so the packet goes back upstream, where the summary sends it straight back. It bounces until its TTL expires. RFC 4632 requires the aggregate's originator to discard such packets precisely to prevent this.
- How would you notice an over-summary in production before it causes an outage?Compare what you advertise with what you actually route: any summary wider than the exact cover of its components is a candidate. Then watch for traffic arriving for unused parts of the summary, and for drops counted on its discard route. Both rise when a more-specific owned elsewhere disappears and its traffic falls into your summary.
saying these in an interview costs you the question
- A wider summary is safer because it can never leave a subnet out.
- Upstream routers drop traffic for unused space inside a summary, since they know no subnet there.
- With a default route but no discard route, the summarising router still drops unmatched packets.
- An over-summary is harmless as long as everything works in testing.
- When a subnet inside a summary fails, upstream routers reroute around it automatically.