What Is Route Aggregation? Supernetting and CIDR Explained

Route aggregation — also called supernetting or summarization — is the practice of combining multiple contiguous, more-specific IP prefixes into a single, shorter prefix that covers all of them. Instead of advertising four separate /24 routes to the internet, a network that owns a contiguous /22 can advertise just that one /22. The global BGP routing table stays smaller, convergence is faster, and the underlying topology detail is hidden from networks that don't need to know it.

CIDR and the Problem It Solved

Before Classless Inter-Domain Routing (CIDR, RFC 4632, 1993), the internet used classful addressing: class A (/8), class B (/16), and class C (/24) blocks. A mid-sized organization needing 300 addresses was forced to take an entire class B (/16 — 65,536 addresses) because class C (/24 — 256 addresses) was too small. The routing table carried one entry per allocation regardless of size, and the number of class B entries was growing at a rate that threatened to exhaust both address space and router memory simultaneously.

CIDR solved both problems. It allows any prefix length from /0 to /32 (IPv4) or /0 to /128 (IPv6), and it allows hierarchical aggregation: an ISP that holds a /16 can advertise just that /16 to the internet while internally subdividing it into /24s for customers. The internet sees one route; the internal routing table carries the detail.

Binary Example: Aggregating Four /24s into a /22

Suppose a network holds these four /24 prefixes:

The first two octets (192.0) are identical across all four. Looking at the third octet in binary: 0, 1, 2, 3 — the first 6 bits are all 000000 and only the last 2 bits vary (00, 01, 10, 11). So the common prefix is the first 22 bits: 192.0.0-3.x collapsed to 192.0.0.0/22 (mask 255.255.252.0). A single /22 advertisement covers all four /24s with one routing table entry instead of four.

This works because the four /24s are contiguous and start on a /22 boundary (192.0.0.0 is divisible by 4 in the third octet). Aggregation only produces a valid supernet when the constituent blocks are aligned — you cannot aggregate 192.0.1.0/24 and 192.0.3.0/24 alone into a /23 because 192.0.2.0/24 would also be covered but is not yours.

Why Aggregation Keeps the Global Table Viable

The global BGP routing table (the default-free zone, or DFZ) today carries over one million IPv4 routes and over 230,000 IPv6 routes. Without aggregation, every ISP would need to advertise every individual /24 they have ever allocated to a customer, and every customer would announce every small block they own. The table would be many times larger, requiring far more memory and processing on every router in the DFZ.

ISPs that aggregate well contribute to internet health. An ISP with a /16 that announces a single /16 instead of 256 individual /24s saves 255 entries from every routing table on the planet. At the scale of hundreds of major ISPs each holding multiple large blocks, this effect is enormous.

ATOMIC_AGGREGATE and AGGREGATOR Attributes

When a router advertises an aggregate that suppresses more-specific routes, it must attach the ATOMIC_AGGREGATE attribute (RFC 4271, section 5.1.6) to signal that path information may have been lost. Specifically: if the aggregate was formed by combining routes with different AS paths, the downstream receiver cannot reconstruct the full set of ASes that contributed to the aggregate. ATOMIC_AGGREGATE is a well-known discretionary attribute — routers must not de-aggregate the route once they see it, and they should propagate the attribute.

The AGGREGATOR attribute is optional and transitive. It carries the ASN and IP address of the router that performed the aggregation. This is informational — it tells downstream networks which AS created the aggregate, which is useful for debugging but has no effect on routing decisions.

A related concept is AS_SET: when aggregating routes that arrived via different AS paths, a router can form an AS_SET containing all contributing ASes, preserving loop-detection information at the cost of creating an unusual path structure. AS_SETs are increasingly avoided in modern practice because they complicate RPKI validation and path analysis, and RFC 6472 discourages their use.

Why Deaggregation Happens Anyway

Despite the benefits of aggregation, operators routinely announce both an aggregate and its constituent more-specifics simultaneously. The main reasons:

Traffic engineering — Announcing the /22 aggregate to both upstreams while announcing specific /24s only to the preferred upstream creates a longest-prefix-match preference. Remote networks route to the /24 via the preferred upstream (more specific wins) and fall back to the /22 via the other upstream only if the /24 becomes unavailable. This is a cleaner mechanism than prepending.

Anti-hijack /24 announcements — A network holding a /22 that only announces the aggregate is vulnerable: a hijacker can announce a /24 within that /22, and remote networks will prefer the more-specific hijacker route (longest prefix match) over the legitimate /22. To prevent this, many operators announce every /24 they own, ensuring that their own announcement of the /24 is in the table and can be protected by RPKI. See BGP hijacking and RPKI.

Multihoming granularity — A multihomed enterprise with a /22 may want different upstreams to carry traffic for different parts of the address space. Announcing specific /24s to different upstreams achieves this, at the cost of adding more-specifics to the global table.

Max-Prefix Limits

To protect against table explosion from a misconfigured or malicious peer, BGP implementations support max-prefix limits: a session-level configuration that tears down (or alerts on) a BGP session if the number of received prefixes exceeds a threshold. For example, a small enterprise router receiving a full table from a transit provider would set a max-prefix limit of 1,200,000 for IPv4; if the provider accidentally leaks an enormous number of prefixes (as in several high-profile route leak incidents), the session drops before the router's memory is exhausted.

Max-prefix limits are also used in the other direction: a provider limits how many prefixes a customer can advertise. An enterprise with a /22 PI block has no legitimate reason to announce 255 /24s from it — the provider's limit (say, 10) prevents such deaggregation spam and keeps downstream tables clean.

Table Growth Consequences

The global routing table has grown steadily since the early 1990s. The primary drivers of growth are:

• New ASes joining the internet, each bringing their prefixes
• Deaggregation for traffic engineering and hijack protection
• IPv4 address exhaustion driving fragmented allocations from RIRs
• IPv6 uptake adding a parallel table

Table growth matters because routers store routes in TCAM (Ternary Content-Addressable Memory) for fast lookup. TCAM is expensive and limited in capacity. When the table exceeds available TCAM, routers either crash, fall back to slower software lookup, or start dropping prefixes. The famous "512K day" on August 12, 2014 illustrated this dramatically: older Cisco 7600 and 6500 series routers shipped with TCAM sized for 512,000 routes. When the IPv4 table crossed that threshold, these routers overflowed their TCAM and began dropping traffic or crashing, causing widespread outages for networks still running that hardware. The event forced rapid hardware upgrades across many ISPs.

Proper aggregation is one of the few levers the operator community has to slow table growth without limiting reachability. Organizations like the RIPE NCC and ARIN track aggregation efficiency and encourage ISPs to aggregate wherever possible.

Aggregation in Practice

On Cisco IOS, the aggregate-address command in BGP creates a summary route and optionally suppresses the more-specifics:

router bgp 64500
 aggregate-address 192.0.2.0 255.255.252.0 summary-only

The summary-only keyword suppresses advertisement of the constituent /24s to peers (they still exist in the local RIB). Without summary-only, both the aggregate and the more-specifics are advertised simultaneously — useful for the traffic engineering scenarios described above.

IPv6 Aggregation

IPv6 was designed with the expectation of hierarchical aggregation. RIRs assign large blocks to ISPs (typically /32 or larger), ISPs delegate /48s to customers. In theory, an ISP with a /32 should announce a single /32 to the global table while routing thousands of customer /48s internally. In practice, customer multihoming and traffic engineering push IPv6 operators toward announcing more-specifics as well, but the IPv6 table remains structurally more aggregated than IPv4 on a per-address basis.

The minimum prefix length accepted by most networks for IPv6 is /48. A /48 represents 65,536 /64 subnets — more than sufficient for any enterprise deployment. Announcing longer prefixes (e.g., /56 or /64) for traffic engineering is possible but risks filtering by networks that enforce the /48 minimum.

Aggregate Stability and Route Flap Dampening

A well-designed aggregate contributes to routing stability. If a more-specific /24 within a /22 aggregate flaps (goes up and down repeatedly), the upstream network still has a valid path to the /22 — traffic can still reach the other three /24s within the aggregate. Route flap dampening (RFC 2439) was historically used to suppress unstable routes, though it is now considered harmful for convergence time and is disabled by most networks. Aggregates naturally reduce the blast radius of flapping more-specifics.

RPKI and Aggregated Prefixes

When you aggregate prefixes and announce the supernet, you must create an RPKI ROA for the aggregate. If your ROA only covers a /24 but you announce a /22, RPKI validators will mark the /22 announcement as RPKI Unknown (no ROA covers it) — not invalid, but without positive authorization. Networks enforcing strict RPKI policies may prefer the known-good route from a competitor over your Unknown aggregate.

The solution is to create a ROA for the /22 aggregate. If you also announce the constituent /24s for traffic engineering, each of those also needs a ROA (or your /22 ROA must specify a max-length of /24). Getting this right requires coordinating your ROA registrations with your announcement strategy. See RPKI for the mechanics of ROA creation and validation. BGP hijacking explains why RPKI matters in the context of protecting your aggregates.

Longest-Prefix Match and Aggregation

The fundamental rule governing how aggregation interacts with routing decisions is longest-prefix match: when a router has multiple routes that cover a destination, it uses the most specific (longest) matching prefix. A /24 beats a /22 beats a /16 beats a /0 default route. This is why deaggregation for traffic engineering works — announcing a /24 to one upstream and a /22 to both causes traffic to the /24 addresses to arrive via the specific upstream (it wins on prefix length), while traffic to the other addresses in the /22 arrives via either upstream.

Longest-prefix match also explains the anti-hijack use of /24 announcements: if you only announce a /20 aggregate, a hijacker announcing a /24 from within that /20 wins for those addresses. Announcing the /24s yourself ensures your announcement is equally specific and can be protected with a ROA.

Aggregation and the IRR

When you aggregate and announce a supernet, your Internet Routing Registry entries must reflect what you actually announce. If you register route objects only for the constituent /24s but announce the /22 aggregate, IRR-based prefix filters at your upstreams and IXPs may reject the /22 (it has no matching route object). Register a route object for every prefix you announce, including aggregates. AS-SET objects should recursively enumerate all ASes whose routes you carry — important for transit providers building accurate filters for their own upstreams.

Practical Aggregation Hygiene

Best practices for network operators managing aggregation:

• Announce the aggregate (summary-only) to most peers, but also announce individual /24s to provide hijack protection and more-specific traffic engineering levers.
• Create RPKI ROAs for every prefix you announce — aggregate and more-specifics. Set max-length correctly: if you only plan to announce the /22, set max-length /22; if you also announce /24s from it, set max-length /24.
• Register route objects in the IRR for every announced prefix. Keep them updated when address assignments change.
• Periodically audit your announcements against your IRR registrations and RPKI ROAs using tools like RIPE NCC's RPKI validator or BGPalerter.
• Document your aggregation policy in your network's internal runbooks — future operators need to know which more-specifics are intentional (traffic engineering) vs which represent address space that has been returned and should no longer be advertised.
• Be aware of max-prefix limits your upstreams may impose. If you announce more prefixes than their configured limit allows, the session will be torn down. A /22 with summary-only costs one slot; announcing all constituent /24s costs four.

Related reading: network prefixes, subnets, route leaks, the default-free zone, RPKI, BGP multihoming, IRR, and BGP AS paths.

Well-behaved aggregation is a shared responsibility across the internet operator community. Every network that cleanly aggregates its address space reduces table size for every router in the DFZ. The collective benefit is significant: better router performance, lower hardware costs, faster convergence, and a more stable global routing system for everyone. It is one of the few concrete actions any network operator can take today that directly improves conditions for every other network on the internet.

Explore It Live

• AS3356 (Lumen) — a large transit AS; compare the aggregates it originates vs the more-specifics it propagates from customers
• 192.0.2.0 — example documentation prefix; look up real prefixes you know to observe aggregation in practice
• AS6939 (Hurricane Electric) — observe a network with a large, well-aggregated IPv6 address space

Use the BGP looking glass to compare prefix lengths for any network — shorter prefixes indicate aggregation.

When you see a /22 or /20 alongside constituent /24s from the same originating AS, you are observing a network that announces both aggregate and more-specifics simultaneously — a deliberate strategy balancing table hygiene against traffic engineering and hijack resilience.