Supernetting is subnetting run backwards: it shortens a prefix so that one route covers several blocks. Announcing that shorter prefix in place of the longer ones is route aggregation, and (RFC) 4271 defines it for : "Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised" (RFC 4271, section 9.2.2.2). Its other name is summarisation (RFC 1518, section 4). You meet it wherever one autonomous system (AS) passes routes to another. By the end you can test whether blocks merge, tell exact from covering aggregates, read BGP's aggregate attributes and recognise how aggregation fails.

Where the word came from

In November 1991 the Internet Engineering Task Force () created the ROAD (Routing and Addressing) group to study the growth of routing (RFC 4632, section 2). The Internet Engineering Steering Group (IESG) later recorded the approach the BGP working groups took that month: "The principal approach was to perform route aggregation by using address masks in BGP to do 'supernetting' (rather than 'subnetting')" (RFC 1380, section 3.2).

RFC 1338 of June 1992, Supernetting: an Address Assignment and Aggregation Strategy, gave each provider blocks of Class C network numbers (RFC 1338, section 2.2), aligned from the start: "Each block must fall on bit boundaries" (section 8). RFC 1519 put the name Classless Inter-Domain Routing () on the same strategy in September 1993 (RFC 1519, section 1), and RFC 4632, Best Current Practice (BCP) 122, replaced it in August 2006. In its words, prefixes "may be defined to describe any power of two-sized block of between one and 2^32 end system addresses" (RFC 4632, section 3.1). The classes are in How IPv4 addresses work, and how one RFC replaces another in The RFC series.

The alignment rule, in binary

A prefix is the leftmost bits that a bitwise AND of address and mask leaves (RFC 1518, section 4), and in the address that names a prefix every bit after it is zero (RFC 4632, section 3.1). Hence the rule: blocks equal one prefix exactly when their union is one unbroken run of 2^k addresses whose first address ends in k zero bits, and the prefix length is then 32 - k. Two equal blocks of 2^m addresses merge when they are adjacent and the lower one starts on a multiple of 2^(m+1). Three equal blocks never do, because three times a power of two is not a power of two. The notation itself is in CIDR notation explained.

Two pairs of /26 blocks, in binary as computed with Python's ipaddress module on 2026-10-18:

192.0.2.0/26       11000000.00000000.00000010.00000000
192.0.2.64/26      11000000.00000000.00000010.01000000
192.0.2.0/25       11000000.00000000.00000010.00000000

192.0.2.64/26      11000000.00000000.00000010.01000000
192.0.2.128/26     11000000.00000000.00000010.10000000

The first pair shares 25 bits and differs only in bit 26, so together it is exactly 192.0.2.0/25. The second pair touches, yet differs already in bit 25: a /25 starts only at .0 or .128, so the smallest block holding both is 192.0.2.0/24, which also takes in .0/26 and .192/26. Adjacency is not enough; alignment decides. The same boundaries cut blocks in Subnetting basics and in splitting a block into unequal subnets, and a site given one contiguous power-of-two block can be aggregated into a single prefix (RFC 4632, section 4.1).

Exact aggregation or a covering supernet

For 192.0.2.0/26 and 192.0.2.128/26 there are two answers. The exact aggregate, the fewest prefixes covering exactly the inputs, is the two blocks, since the gap stops any merge. The covering supernet, the smallest single block holding both, is 192.0.2.0/24, and it claims 128 addresses nobody listed, .64/26 and .192/26. Gaps like these are in Subnet overlaps and gaps.

A covering aggregate is normal when the space is yours. In RFC 4632's example a provider called PA holds the 524,288 addresses of 10.24.0.0/13, connects six sites using 36 /24s between them, and announces the whole block (RFC 4632, sections 6.1 and 6.2). That is its right: a routing domain holding prefixes "has sole responsibility for aggregation of those prefixes" (section 5.4). Rule #2 is the price: the aggregating router "must discard packets that match the aggregate route, but not any of the more-specific routes", so that unreachable parts cannot loop (section 5.1), usually through a discard or null route (section 5.2). Aggregates are also steadier: a dynamic one is withdrawn only when all its components are unreachable (section 5.4). The saving is downstream: aggregation does not shrink the aggregating router's own table (Juniper Networks, Configuring Route Aggregation). Summarising inside one network is in Route summarization.

How BGP marks an aggregate

BGP sends each prefix as Network Layer Reachability Information (NLRI), a <length, prefix> pair (RFC 4271, section 4.3), so an aggregate is a shorter prefix with new attributes. A speaker that accepts a less and a more specific route installs both, or aggregates them if they share a NEXT_HOP, and if it aggregates it "SHOULD either include all ASes used to form the aggregate in an AS_SET, or add the ATOMIC_AGGREGATE attribute to the route" (section 9.1.4). The attributes:

Routes with different Multi-Exit Discriminator () values must not be aggregated (RFC 4271, section 9.2.2.2). What the aggregate loses is precision: packets may cross ASes its AS_PATH does not list (section 9.1.4). More on the protocol is in BGP: how the internet decides where traffic goes.

AS_SET, deprecated in May 2025

RFC 9774 (May 2025) updates RFC 4271: unless an operator configures otherwise, speakers "MUST NOT advertise BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs" and must treat a received one as a withdrawal (RFC 9774, section 3) of every route it carries (RFC 7606, section 2). AS_SETs were often used wrongly, most often holding a single AS, and Route Origin Validation over the Resource Public Key Infrastructure (-ROV) never treats them as Valid (RFC 9774, sections 1 and 4). BCP 172 had already recommended, in 2011, that operators not generate new announcements with AS_SETs (RFC 6472, section 3). The replacement keeps the markers and drops the set: "In consistent brief aggregation, the AGGREGATOR and ATOMIC_AGGREGATE Path Attributes are included, but the AS_PATH does not have AS_SET or AS_CONFED_SET path segment types" (section 6.1). Loops are avoided by policy instead: "An aggregate prefix SHOULD NOT be announced to the contributing ASes" (section 6.2). In the RFC's example AS 64505 aggregates four /24s, from AS 64501 to 64504, into a /22 and holds this entry (appendix A):

p/22 AS_PATH "" AGGREGATOR 64505 ATOMIC_AGGREGATE

How aggregation fails

Every failure here turns on one rule: "Routers must use the most specific matching route (the longest matching network prefix) when forwarding traffic" (RFC 1812, section 2.2.5.2). One router's side of it is in Static routes, longest prefix match and administrative distance.

Holes and loops. A multihomed destination cannot be summarised, and a customer that changes provider without renumbering punches a hole in the old aggregate, which the new provider's longer announcement fills (RFC 4632, sections 4.1 and 5.1). If that more-specific disappears, traffic follows the aggregate, is discarded by its advertiser, and traceroute blames that network instead (section 5.1). Without a discard route, a network that loses part of its own aggregate follows its provider's less specific route back up and the packet loops (section 5.2); the BGP specification does not discuss installing that route (RFC 9774, appendix C).

Leaks. "The leaked internal prefixes are often more-specific prefixes subsumed by an already announced, less-specific prefix" (RFC 7908, section 3.6). On 12 August 2014 AS701 and AS705 leaked more than 20,000 of them (section 3.6). Seen from AS 131072 the table went well past 512,000 entries, and 512K is a default number of IPv4 entries for a high-speed lookup cache in some equipment's fine print (Geoff Huston, What's So Special about 512?).

Hijacks. "Traffic can be hijacked by advertising a prefix for a given destination that is more specific than the aggregate that is normally advertised for that destination" (RFC 4632, section 12). On 24 February 2008 Pakistan Telecom (AS17557) made an unauthorised announcement of 208.65.153.0/24, inside YouTube's 208.65.152.0/22, and the longer prefix won wherever it spread (RIPE Network Coordination Centre case study). The wider weakness is in BGP: the trust fall the whole internet is standing on.

Proxy aggregation. A provider may aggregate the routes it receives from another without explicit agreement; other networks then see an inconsistent view of the original routes, which is why RFC 4632 asks for extreme caution (RFC 4632, section 5.4).

Defences. Prefix length is the first filter: "IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted in the Internet" (RFC 7454, section 6.1.3), and a limit on the routes accepted from each peer is recommended (section 8). A Route Origin Authorization (ROA) should be minimal, listing only prefixes the AS actually originates (RFC 9319, section 5).

What it did to the routing table

Aggregation slowed the growth of the global table; it never made the table small. RFC 4632 calls it essential all the same: "aggregation is the only tool available for making routing scale in the global Internet" (RFC 4632, section 10). The counts measure different things, so each is labelled:

WhenMeasureCount
1992Default-free table (RFC 1338, section 3.3.2)about 4,700
March 1994Table as CIDR arrived (Huston, CIDR Report)20,000 down to 18,000 in a couple of weeks
January 2026Prefixes, and more-specifics among them, seen from AS 131072 (Huston, BGP in 2025)1,050,000; 544,000
18 October 2026Prefixes, and the count if aggregated (The CIDR Report)1,085,532; 602,076

"The routing table has continued to grow, largely as a result of the advertisement of more specifics" (Geoff Huston, BGP in 2025). The CIDR Report's aggregated figure also aggregates across holes, address space nobody advertises, which is exactly a covering supernet (The CIDR Report). The report is produced daily (Geoff Huston, The Why and What of the CIDR Report).

How to see it

The CIDR / Subnet Calculator has a Supernet mode that shows both answers, the Minimal covering set and the Single supernet, and the extra addresses the supernet adds when there are any. Its results for three inputs, summarised, as computed with its own code on 2026-10-18:

192.0.2.0/26, 192.0.2.64/26
  Minimal covering set: 192.0.2.0/25    Single supernet: 192.0.2.0/25    (no note)
192.0.2.64/26, 192.0.2.128/26
  Minimal covering set: 192.0.2.64/26, 192.0.2.128/26    Single supernet: 192.0.2.0/24    128 extra
198.51.100.0/26, 198.51.100.64/26, 198.51.100.128/26
  Minimal covering set: 198.51.100.0/25, 198.51.100.128/26    Single supernet: 198.51.100.0/24    64 extra

It masks host bits silently; its Overlap / gap mode lists the holes inside a scope. The Python playground has the standard ipaddress module (Python documentation, ipaddress): collapse_addresses() gives the exact aggregate, summarize_address_range() the prefixes for a range, and supernet() the parent block, which says which block contains a network, not whether two merge. Unlike the calculator, it refuses host bits. Output as recorded (abridged):

>>> from ipaddress import ip_network, ip_address, collapse_addresses, summarize_address_range
>>> list(collapse_addresses([ip_network('192.0.2.0/26'), ip_network('192.0.2.64/26')]))
[IPv4Network('192.0.2.0/25')]
>>> list(collapse_addresses([ip_network('192.0.2.64/26'), ip_network('192.0.2.128/26')]))
[IPv4Network('192.0.2.64/26'), IPv4Network('192.0.2.128/26')]
>>> ip_network('192.0.2.64/26').supernet()
IPv4Network('192.0.2.0/25')
>>> ip_network('192.0.2.128/26').supernet()
IPv4Network('192.0.2.128/25')
>>> list(ip_network('192.0.2.0/24').address_exclude(ip_network('192.0.2.0/26')))
[IPv4Network('192.0.2.128/25'), IPv4Network('192.0.2.64/26')]
>>> list(summarize_address_range(ip_address('203.0.113.0'), ip_address('203.0.113.191')))
[IPv4Network('203.0.113.0/25'), IPv4Network('203.0.113.128/26')]
>>> ip_network('192.0.2.64/25')
ValueError: 192.0.2.64/25 has host bits set

In FRRouting, "In order to advertise an aggregated prefix, a more specific (longer) prefix MUST exist in the BGP table" (FRRouting documentation, BGP). summary-only suppresses the more-specifics to all neighbours and as-set survives as a legacy option; the latest (development) documentation says bgp reject-as-sets, defined under RFC 9774, is enabled by default. Illustrative, with documentation prefixes and AS numbers:

router bgp 64500
 address-family ipv4 unicast
  aggregate-address 198.51.100.0/24 summary-only
 exit-address-family

show bgp ipv4 unicast aggregate-address 198.51.100.0/24

In Junos an aggregate becomes active with one contributing route. By default its next hop rejects packets with an Internet Control Message Protocol () unreachable, discard drops them silently, and brief keeps only the longest common leading sequences of the contributing AS paths (Juniper Networks, Configuring Route Aggregation). The options, as documented:

as-path <as-path> <origin (egp | igp | incomplete)> <atomic-aggregate> <aggregator as-number in-address>;
discard;
(brief | full);

Cisco's command reference gives this syntax:

aggregate-address address mask [as-set] [as-confed-set] [summary-only] [suppress-map map-name] [advertise-map map-name] [attribute-map map-name]

There summary-only filters the more-specific routes from updates, and "The atomic aggregate attribute is set automatically when an aggregate route is created with this command unless the as-set keyword is specified" (Cisco, BGP Command Reference: aggregate-address). A route towards Null0 goes into the routing table automatically, to help prevent loops, and the reference warns, for BGP and Multiprotocol BGP (mBGP) alike: "If a more-specific route leaks out, all BGP or mBGP routers will prefer that route over the less-specific aggregate you are generating (using longest-match routing)." On a receiving router, show ip bgp ends the AS path line with aggregated by, the aggregating AS and its router ID, and lists atomic-aggregate among the attributes (Cisco, Understand Route Aggregation in BGP). An illustrative copy, rebuilt with documentation addresses and AS numbers:

RouterA# show ip bgp 198.51.100.0
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  64501 64502, (aggregated by 64501 192.0.2.1)
    192.0.2.1 from 192.0.2.1 (192.0.2.1)
      Origin IGP, localpref 100, valid, external, atomic-aggregate, best

What to remember

  • Blocks make one prefix only when their union is one unbroken power-of-two run whose first address has every bit after the new prefix at zero.
  • Adjacency is not enough: two touching /26s merge only when the lower one starts on a multiple of 128.
  • An exact aggregate covers only the inputs; a covering supernet claims more, and is legitimate only for space you hold, with a discard route for the unused parts.
  • Longest match beats any aggregate, so a leaked or hijacked more-specific wins wherever it spreads; filters on prefix length and minimal ROAs are the defences.
  • A BGP aggregate is a shorter prefix marked by ATOMIC_AGGREGATE and AGGREGATOR, and since RFC 9774 (May 2025) it carries no AS_SET.
  • Aggregation slowed the table's growth without stopping it: about 4,700 entries in 1992, 1,085,532 prefixes on 18 October 2026.

Sources