BGP · XB Field Notes

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

RFC 4271 BGP-4, defines ATOMIC_AGGREGATE, AGGREGATOR and AS_SET, checked 2026-09-16.
FRR BGP route aggregation, documents aggregate generation, component suppression and AS-set options, checked 2026-09-16.
RFC 4632 CIDR, the classless prefix and longest-match forwarding model, checked 2026-09-16.
RFC 9774: Deprecation of AS_SET, updated aggregation and origin requirements, checked 2026-10-15.

BGP is the Internet routing table

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

BGP exchanges reachability between independently operated networks, but there is no single authoritative Internet forwarding table. Each router learns a policy-filtered view, chooses routes, and attempts to install usable next hops. Two routers can legitimately select different paths to the same prefix. Understanding BGP means separating announcements, selection policy, and packet forwarding rather than treating them as one universal answer.

The AS path carries history and policy

In ordinary eBGP operation, a speaker prepends its AS number when advertising a route externally. A receiver normally excludes paths containing its own AS to avoid inter-AS loops. There are configured exceptions and protocol extensions. Inside an AS, iBGP does not normally add another AS number; its advertisement restrictions and route-reflector rules address a different loop problem.

AS_PATH is also a policy input and a selection attribute. Repeated prepending can make one route less attractive where path length matters, but cannot override another network’s higher-priority local policy. There is no general rule that prepending makes a route fail filtering. Filters must be understood in their actual operator and customer context.

LOCAL_PREF is an attribute distributed to internal BGP peers, normally not to external peers. Weight, where an implementation provides it, is router-local and is not a standard BGP path attribute. Conflating these two controls hides an important distinction: a local preference change can influence decisions across the AS, while a weight change generally affects one router.

Compare the same prefix first

A router’s best-path process compares candidate paths for the same prefix. The exact sequence depends on the implementation and configuration, including eligibility, local policy, AS-path length, MED comparison rules, and next-hop reachability. A vendor’s weight-first list is not the complete protocol definition. MED is commonly compared within the same neighboring AS, with configurable exceptions.

Forwarding then performs longest-prefix matching over the installed destination routes. A /25 and its covering /24 do not compete through the same best-path tie-break list. If both are accepted and installed, the /25 matches its half of the address range even if the /24 has a shorter AS path. Policy routing and other forwarding features require additional inspection.

Table size likewise depends on the observation point, address family, and date. Distinct prefixes, all received paths, and hardware FIB entries are different counts. Aggregation can reduce some advertisements, but multihoming and traffic engineering may require specific routes. An address-only aggregation estimate is not proof that every corresponding policy can be preserved.

When it breaks

An unauthorized origin announcement is a prefix hijack; a route leak exports learned reachability beyond its intended policy scope. They can overlap, but are not synonyms. The hypothetical /25 below illustrates lookup only: real networks may reject it through prefix-length, origin, or customer filters. An unfamiliar more-specific deserves investigation, not an immediate conclusion that an attack is live.

RPKI origin validation checks the announced prefix, authorized origin, and permitted maximum length against validated records. It does not authenticate the entire AS path or determine every export relationship. Valid-origin routes can still be leaked. Combine origin validation with appropriately scoped import and export policy, and monitor changes rather than assuming all updates propagate unchecked.

A healthy session also does not prove successful forwarding installation. Hardware exhaustion, unresolved next hops, or programming failures can leave a control-plane route unusable. Failure behavior varies by platform; software fallback is not guaranteed. Capacity planning must use the device’s actual table partitions, supported features, and installation telemetry, not a universal million-entry threshold.

Two distinct decisions: same-prefix path selection and cross-prefix forwarding lookup. The source fixture holds other conditions equal; it is not a router implementation or geographical shortest-path proof. No fixture was rerun.

Check it quickly

Run this Python 3 fixture with assertions enabled. The first half intentionally models only local preference and AS-path length, with every other selection condition held equal. The second half is an independent forwarding table. It uses documentation addresses and creates no sessions, listeners, or network announcements.

from ipaddress import ip_address, ip_network

paths = [
 {"name": "policy-first", "localpref": 200, "path": [64501, 64502, 64503]},
 {"name": "shorter", "localpref": 100, "path": [64504, 64503]},
]
def choose(candidates):
 return min(candidates, key=lambda p: (-p["localpref"], len(p["path"])))
assert choose(paths)["name"] == "policy-first"
paths[1]["localpref"] = 200
assert choose(paths)["name"] == "shorter"

routes = {ip_network("198.51.100.0/24"): "legitimate",
 ip_network("198.51.100.128/25"): "unexpected"}
def forward(address):
 matches = [p for p in routes if ip_address(address) in p]
 return routes[max(matches, key=lambda p: p.prefixlen)]
assert forward("198.51.100.20") == "legitimate"
assert forward("198.51.100.200") == "unexpected"
print("same prefix: local preference first, then path length")
print("different prefixes: lower half legitimate, upper half unexpected")

The longer path wins until local preference is equalized; then the shorter path wins. Separately, the lower address selects the legitimate /24, and the upper address selects the unexpected /25. These results explain two different decisions without claiming to implement a router. Real diagnosis must correlate received and advertised paths, selected routes, hardware installation, and permitted-client probes.

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.
FRR BGP path selection, implementation-specific selection controls and diagnostics, checked 2026-10-15.