Bgp · XB Field Notes

BGP aggregation shrinks the routing table

Fri, 08 Oct 2027 00:00:00 +0000

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.

BGP is the Internet routing table

Sun, 12 Sep 2027 00:00:00 +0000

BGP is the only protocol that stitches tens of thousands of independently operated networks into one forwarding table. It carries reachability, but what it really carries is policy: each network says which prefixes it originates, which neighbours it learned them from, and — through filters — which ones it is willing to pass on.

The tension is that this table is built on trust between parties who have no contract with each other. Nothing validates an announcement before it propagates, so a typo or a misconfigured filter is global within minutes and stays that way until a human notices.

The AS path is a loop check and a policy signal at once

On egress an eBGP speaker prepends its own AS number, and a receiver drops any update whose AS_PATH already contains its own AS. That is the entire loop-prevention mechanism, and it is why a route cannot be re-imported around a circle. iBGP does not prepend, which is why an iBGP-learned route carries the same AS_PATH as the eBGP route that brought it into the AS, and why an AS needs a full iBGP mesh or route reflectors to distribute it.

The same field does two more jobs. Operators filter on it — reject anything containing a peer’s AS, accept only routes whose path ends in a customer’s AS — and path selection compares its length. One field, three responsibilities, and they conflict: prepending to make a path less attractive also makes it look like a route your filters should reject.

Why the table is about a million prefixes

The real numbers, from the CIDR Report snapshot taken for this article: 1,080,189 IPv4 prefixes, or 597,258 if you collapse everything that can be aggregated. Amazon alone originates 18,025 prefixes, of which 15,759 are more-specifics of larger blocks. Roughly half the table is more-specifics of address space that is already announced.

That is a policy artifact, not a topology artifact. Multihoming creates a more-specific per provider, traffic engineering creates them per path, and a customer who wants their own routing decisions creates one more. Aggregation would halve the table, and nobody does it, because every one of those more-specifics is doing a job.

Path selection is a fixed order, not a distance

BGP picks a path by walking a list and stopping at the first step that breaks the tie: highest weight, then highest local preference, then locally originated, then shortest AS path, then lowest origin type, then lowest MED, then eBGP over iBGP, then lowest IGP cost to the next hop, then lowest router ID. Weight and local preference are local to one router or one AS and never travel in an update.

Running that over four candidate paths for one prefix: the decision lands on weight, because a weight of 100 beats 0 before anything else is read. Remove the weights and the decision moves to local preference. Remove local preference as well and it moves to AS-path length, where a two-AS path beats a three-AS path. The shortest path is step four of nine, which is why “BGP picks the shortest route” is not a useful statement.

When it breaks

The classic incident shape is a leaked more-specific that hijacks traffic. An unrelated AS originates 198.51.100.128/25 inside someone else’s 198.51.100.0/24, and longest-prefix-match hands it exactly half the victim’s address space — 128 of 256 addresses — with no withdrawal, no error, and the legitimate /24 still sitting in every table. It presents as partial unreachability and traffic appearing somewhere unexpected, and it is the shape documented in RFC 7908. RPKI origin validation is the mitigation, but it only answers whether an AS is allowed to originate a prefix; a ROA’s maxLength must cover the more-specific, and a forged AS path with a valid origin still validates.

The second failure is the table outgrowing the hardware. A device with 1,000,000 IPv4 FIB entries is already 80,189 prefixes short of today’s table; at 1,200,000 it fits. When a FIB fills, the router keeps the sessions up and stops installing routes — some prefixes move to software forwarding, others are dropped, and the blast radius is that unrelated destinations stop working while BGP looks perfectly healthy.

Check it quickly

Confirm what your router actually believes about a prefix:

show bgp ipv4 unicast summary
show bgp ipv4 unicast 198.51.100.0/24
show bgp ipv4 unicast 198.51.100.0/24 longer-prefixes
show ip route 198.51.100.200

The first prints the total prefix count, which is how you notice a peer dumping routes at you. The second and third together show whether a more-specific exists and who originates it — a /25 you do not recognise is the whole incident. The fourth is the verdict the forwarding engine reached, and if it disagrees with what you expected from the first three, the hijack is already live.

Sources

RFC 4271 BGP-4, the decision process and AS path loop detection, checked 2026-09-16.
RFC 6811 prefix origin validation, what RPKI validation does and does not prove, checked 2026-09-16.
RFC 7908 route leaks, the problem statement for leaked announcements, checked 2026-09-16.
CIDR Report, current IPv4 table size and per-AS more-specific counts, checked 2026-09-16.