BGP aggregation shrinks the routing table

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

Aggregation can replace several more-specific advertisements with one covering prefix. It reduces downstream table entries only where the specifics are actually suppressed and no alternative peer supplies them. The components need not fill the whole summary: advertising a sparse block also attracts traffic for its holes. Aggregation therefore combines a scaling decision with a reachability and ownership decision.

What aggregation actually buys

A peer receiving three component prefixes plus their summary has four routes, not one. In FRR, aggregate-address 10.1.0.0/16 summary-only suppresses advertisements of the covered more-specifics. It does not delete those routes from the aggregator’s own BGP table. FRR requires at least one contributing more-specific in that BGP table; having only an unrelated routing-table entry is insufficient.

A stable summary can hide changes to individual contributors from downstream peers. That benefit is conditional: losing the last contributor, changing aggregate attributes, or changing export policy can still generate updates. Suppression does not repair the failed customer path. It changes what other networks learn about the failure, while the aggregator must continue diagnosing its internal components.

The covering route is also broader than the sum of a few listed subnets. Before announcing it, verify authority for the whole range and the intended aggregate origin. Address alignment and a short table are insufficient evidence of permission. A provider may legitimately aggregate customer space under its allocation; different component origins do not automatically make aggregation unauthorized.

Preserve a clear origin

FRR’s suppress-map selects which more-specifics to suppress. Its as-set option concerns a different dimension: representing AS information from component paths. An AS_SET is an unordered set, not a list of only the customers’ origin numbers. Under the historical RFC 4271 path-length calculation, a set counts as one, regardless of its members.

RFC 9774 now deprecates AS_SET and AS_CONFED_SET. Unless explicitly configured otherwise during transition, speakers must not advertise them and must treat received routes containing them as withdrawn. Choose an unambiguous authorized aggregate origin and appropriate ROAs instead of treating AS_SET as a routine aggregation fix. An origin filter does not automatically accept an aggregate merely because a router generated it.

When it breaks

For ordinary destination-based lookup in a selected forwarding table, the longest installed matching prefix wins. A valid /24 therefore beats its covering /16, regardless of their relative BGP local preferences. First, however, each route must pass policy, next-hop resolution, and installation. BGP selection among paths for one prefix and forwarding lookup across different prefixes are separate decisions.

If one component disappears, only destinations that lose their usable route fall back to the summary; healthy components can keep forwarding. One customer’s withdrawal does not inherently blackhole every address covered by the aggregate. At the aggregating router, a discard route for unmatched summary destinations prevents traffic from following a default route back upstream and forming a loop.

Discard behavior and diagnostic messages depend on the platform and configuration. Neither silence nor ICMP delivery is universal. Removing the summary also does not necessarily mean no route: another covering prefix or a default can remain. Check the actual forwarding table and counters rather than declaring the summary dishonest solely because a specific prefix is absent.

Containment is schematic, not proportional address space. The lookup model preserves the healthy component and sends unmatched summary destinations to discard. It does not validate BGP sessions, origin policy or convergence, and was not rerun.

Check it quickly

Run this self-contained Python 3 model with assertions enabled. It creates no sockets and changes no router configuration. Two customer routes share a covering discard entry. The deliberately small model isolates longest-prefix matching and the scope of a component withdrawal; it does not implement BGP sessions, policy, or convergence.

from ipaddress import ip_address, ip_network

routes = {
 ip_network("10.1.0.0/16"): "discard",
 ip_network("10.1.4.0/24"): "customer-a",
 ip_network("10.1.7.0/24"): "customer-b",
}
def lookup(address):
 matches = [prefix for prefix in routes if ip_address(address) in prefix]
 if not matches:
 return "no-route"
 return routes[max(matches, key=lambda prefix: prefix.prefixlen)]

assert lookup("10.1.4.9") == "customer-a"
assert lookup("10.1.7.9") == "customer-b"
del routes[ip_network("10.1.4.0/24")]
assert lookup("10.1.4.9") == "discard"
assert lookup("10.1.7.9") == "customer-b"
print("withdraw A: A=discard, B=customer-b")
del routes[ip_network("10.1.0.0/16")]
assert lookup("10.1.4.9") == "no-route"
assert lookup("10.1.7.9") == "customer-b"
print("withdraw summary: A=no-route, B=customer-b")

The first output shows customer A falling into the discard route while customer B remains reachable through its own entry. After deleting the summary, A reports no route because this fixture intentionally has no default. B still resolves independently. Add a default entry as a follow-on exercise and observe how the no-route result changes.

On an authorized lab router, separately inspect received, selected, advertised, and installed routes before and after withdrawing a contributor. Confirm whether the summary survives and whether its attributes change. Router integration and forwarding behavior require that real exercise; the Python assertions establish only the stated lookup model.

Sources