Aggregation replaces a set of adjacent prefixes with one covering announcement, so every peer downstream stores one entry instead of dozens and stops processing updates for each component. The table gets smaller, and the churn of a flapping edge stops propagating outward.

The tension is that a summary is a claim about reachability. Once the covering prefix is in the table, the forwarding engine acts on it for addresses whose component routes are gone, so a smaller table is bought with a blurrier failure signal.

What aggregation actually buys

A peer receiving 10.1.4.0/24, 10.1.7.0/24, 10.1.9.0/24 and a covering 10.1.0.0/16 stores four entries. Configure aggregate-address 10.1.0.0/16 summary-only and the peer stores one. Suppression happens on egress: the more-specifics stay in the aggregator’s own table and keep forwarding its own traffic, they are simply not advertised. FRR is strict about this — a more-specific must exist in the BGP table, not merely in the RIB, before the aggregate is originated at all.

The second prize is churn. Every flap of a component is an update the peer must parse, select and reinstall. Behind a summary those updates stop at the aggregator, so a customer network oscillating twice a minute costs the rest of the internet nothing. On a flapping edge that is the property wanted.

summary-only, suppress-map and as-set

summary-only suppresses every longer prefix to every neighbour. suppress-map suppresses only the more-specifics a route map matches, for “summarise this block but keep that one exception”. as-set changes what the path looks like: instead of collapsing components into the aggregator’s own AS, it emits an AS_SET of the real origin ASes.

as-set preserves loop detection but damages everything else. An AS_SET lengthens the path for AS-path comparison, gives origin validation nothing to check, and is being deprecated — FRR ships bgp reject-as-sets to drop such routes both ways. The genuinely dangerous configuration is aggregating across different origins at all. Folding 10.1.4.0/24 from AS64501 and 10.1.7.0/24 from AS64502 into one 10.1.0.0/16 originated by AS64500 tells every peer that AS64500 originates the whole block. A neighbour filtering on origin now accepts a prefix it should not, and one filtering on AS path no longer sees the customers. Detail is destroyed, not compressed.

Longest prefix match is the only forwarding rule

BGP decides reachability; the FIB decides forwarding, and the FIB has one rule — longest mask wins. The aggregate is never preferred or depreferenced, and the more-specific wins whenever it exists. Replaying this over a built table: with both present, a packet to 10.1.4.9 matches 10.1.4.0/24 via AS_PATH 64500 64501. Withdraw that /24 while the aggregate survives and the same packet matches 10.1.0.0/16, with no change whatsoever to the aggregate. Withdraw the aggregate as well and the packet finally becomes “no route, ICMP unreachable”.

That is why announcing an aggregate without its more-specifics changes the forwarding path, not merely the table size. The summary is a standing promise and the FIB enforces it. It cuts the other way too: a more-specific is a traffic magnet, so whatever you announce more specifically receives that traffic no matter what the covering prefix claims.

When it breaks

The classic failure is a summary advertised while a more-specific has been withdrawn somewhere else. The aggregate outlives its component, so traffic for the dead block is drawn to the aggregator and dropped inside it — a blackhole with no ICMP, no withdrawal to notice, no counter at the edge. In the replay, 10.1.4.9 moves from the /24 to the /16 and is silently discarded. It presents as “some destinations in the /16 are unreachable and everything else is fine”, which sends the investigation to the wrong layer.

The second failure is the flap that opens a temporary blackhole. Withdraw a component, re-announce it two seconds later, and for those two seconds every packet in that range matches the aggregate and dies. Blast radius scales with how much address space sits behind the summary: summarise fifty thousand customer addresses behind one /16 and one customer’s flap blacks out all fifty thousand. Mitigate by not summarising across origins, by keeping the more-specifics advertised and paying for the entries, or by using an unreachable-prefix announcement so the withdrawal propagates a discard instead of silence.

Check it quickly

Confirm the aggregate and its components still agree:

show bgp ipv4 unicast 10.1.0.0/16 longer-prefixes
show bgp ipv4 unicast 10.1.4.0/24
show bgp ipv4 unicast 10.1.0.0/16
show ip route 10.1.4.9

The first lists every component under the summary; the second proves the suspect one is still there. The third is where a lost origin shows up as AS_SET or a bare aggregator AS, and the fourth shows what the FIB will really match — if it prints the /16 for an address whose /24 you expected, the component is gone and the aggregate is lying.

Sources

  • RFC 4271 BGP-4, defines ATOMIC_AGGREGATE, AGGREGATOR and AS_SET, checked 2026-09-16.
  • FRR BGP route aggregation, documents aggregate-address, summary-only, suppress-map, as-set and unreachable-prefix announcement, checked 2026-09-16.
  • RFC 4632 CIDR, the classless prefix and longest-match forwarding model, checked 2026-09-16.