Supernetting and Route Summarization: Designing Address Blocks That Keep Routing Tables Small
Every router keeps a list called a routing table. Each line in it pairs a block of destination addresses with a direction: to reach these addresses, send the packet that way. When a packet arrives, the router looks up its destination in the table and forwards it accordingly, and every router along the path repeats the lookup. The interesting question is how long that list has to be. It can hold one line for every subnet in the organization, or, if the addresses were laid out with some care, one line per site, per region, or per company. Our subnetting guide explained how to divide a large block of IP (Internet Protocol) addresses into smaller ones. This guide runs the same math in reverse. Supernetting combines small blocks back into a large one, and route summarization is the practice of announcing that large block as a single route in place of all the small ones. Done well, it keeps routing tables short, stable, and readable, and the design work happens long before anyone touches a router.
The postal system has been doing this for decades. A sorting facility in Ohio does not keep a list of every street in Los Angeles. It keeps one rule, roughly "ZIP codes starting with 9 go west," and lets facilities closer to the destination worry about the details. That works because ZIP codes are hierarchical: the first digit names a region of the country, the next two narrow it to a sorting center, and the last two pick the post office. Every facility needs fine detail only for its own patch and a coarse rule for everywhere else. A routing table can work exactly the same way, with one condition. The addresses have to be hierarchical too, and in a network that grew one subnet at a time, they usually are not.
To see how a router can make one line cover many subnets, it helps to know how it chooses between lines. A table entry is written in CIDR (Classless Inter-Domain Routing) notation, like 10.1.0.0/16, where the number after the slash says how many leading bits of the address have to match. When a destination matches more than one entry, the router picks the one with the longest match, the most specific route. That rule, called longest prefix match, is what makes summarization safe. A router can hold a broad entry for 10.1.0.0/16 and a narrow one for 10.1.50.0/24 at the same time; traffic for 10.1.50.7 follows the narrow entry and everything else in the /16 follows the broad one. The broad entry is the summary, and the narrow one is an exception it tolerates.
Longest prefix match: the most specific route wins
Destination Next hop
0.0.0.0/0 internet router matches everything (the default route)
10.1.0.0/16 Dallas link matches 10.1.x.x
10.1.50.0/24 data center link matches 10.1.50.x
Packet to 10.1.50.7 all three match /24 wins data center
Packet to 10.1.8.9 first two match /16 wins Dallas
Packet to 8.8.8.8 only /0 matches /0 wins internetThe arithmetic of a summary is the subnetting arithmetic run backward. Take four neighboring /24 blocks, 10.1.0.0/24 through 10.1.3.0/24, and write the third octet of each in binary. The values 0, 1, 2, and 3 are 00000000, 00000001, 00000010, and 00000011. The first six bits of that octet are identical across all four, and the first two octets match completely, so the four blocks share their first 22 bits. That shared prefix is the summary: 10.1.0.0/22, a single block of 1,024 addresses that covers exactly the four /24s and nothing else. One line in the routing table now does the job of four.
Four /24s become one /22
10.1.0.0/24 00001010 . 00000001 . 00000000 . 00000000
10.1.1.0/24 00001010 . 00000001 . 00000001 . 00000000
10.1.2.0/24 00001010 . 00000001 . 00000010 . 00000000
10.1.3.0/24 00001010 . 00000001 . 00000011 . 00000000
|------- 22 bits shared -------|
Summary: 10.1.0.0/22 (10.1.0.0 through 10.1.3.255)Here is the part that turns a routing trick into a design problem. A summary block of a given size can only begin at certain addresses. A /22 holds four /24s, so its third octet has to be a multiple of four; a /21 holds eight and must start on a multiple of eight; a /20 holds sixteen and must start on a multiple of sixteen. Blocks that start anywhere else cannot be described with a single prefix, however neatly they sit next to each other. Compare two sets of four consecutive /24s. The set from 10.1.4.0 through 10.1.7.0 starts on a multiple of four and collapses to 10.1.4.0/22. The set from 10.1.3.0 through 10.1.6.0 contains the same number of addresses, but no single prefix covers it without also swallowing blocks it does not own, so the smallest honest description takes three routes.
Same size, different starting point, very different result
Aligned: 10.1.4.0/24 10.1.5.0/24 10.1.6.0/24 10.1.7.0/24
= 10.1.4.0/22 1 route
Misaligned: 10.1.3.0/24 10.1.4.0/24 10.1.5.0/24 10.1.6.0/24
= 10.1.3.0/24 + 10.1.4.0/23 + 10.1.6.0/24 3 routes
(10.1.0.0/21 would cover them, but also claims .0, .1, .2, and .7)The lesson is that whether a site's subnets can be summarized is decided the day they are assigned, and it rarely changes afterward. The subnet calculator draws a block map that shows where the aligned boundaries fall, and the CIDR converter reports how many prefixes an arbitrary range needs, which is a quick test of whether a range you already use will summarize into one route or shatter into several.
A few dozen extra routes sounds harmless, and on a small network it is. The cost shows up with scale and with change. Every entry takes memory in the specialized chips routers use for high-speed lookups, and that memory is finite in ways that surprise people. On August 12, 2014, the public internet's routing table crossed 512,000 entries, the default capacity of a popular class of router, and networks around the world dropped offline until operators reconfigured or replaced hardware; the event is still known as 512k day. Change costs even more than size. When a link fails, every router that holds a route across that link has to learn the news and recompute, and a network with ten thousand small routes has ten thousand things to recompute where a summarized network has a hundred. A summary also contains the news: if one subnet behind a summary flaps up and down, the rest of the network never hears about it, because the summary being advertised stays the same.
The routing table is also copied, in spirit, into every other list that names your network. Firewall rules and ACLs (access control lists, the rules that decide which traffic a router or firewall allows) are written in prefixes, so "allow Dallas to reach the file servers" is one rule when Dallas is one prefix and thirty rules when it is thirty. VPN (virtual private network) configurations list the prefixes that belong on each side of the tunnel, and cloud providers cap those lists; Amazon Web Services (AWS), for example, will not accept more than a hundred routes from your router over a site-to-site VPN connection, and an AWS route table holds fifty routes by default. An address plan that summarizes well fits inside all of those limits without anyone noticing them, and one that does not meets them in the middle of a change window.
Summarization pays off most when it happens at every level of a hierarchy, and the hierarchy has to be built into the addresses. Our worked example of designing an IP plan from scratch gave a fictional company the whole of 10.0.0.0/8, reserved 10.0.0.0/12 for its offices, and handed each office a /16 inside that: Chicago at 10.0.0.0/16, Dallas at 10.1.0.0/16, Atlanta at 10.2.0.0/16. Each office carves its /16 into a /24 per VLAN (Virtual Local Area Network, a way of running several separate networks over the same switches) for users, phones, Wi-Fi, printers, servers, and management gear. Those choices were made so that summarization would fall out for free. The Chicago router advertises one route, 10.0.0.0/16, toward the WAN (wide area network, the long-distance links between sites), and the eight VLAN subnets behind it never appear anywhere else. The router at the edge of the office region advertises 10.0.0.0/12 toward the data center and the cloud, and the three offices, plus the thirteen not yet built, collapse to one entry there.
The data center core, before and after summarization
Without summaries (every VLAN subnet from every office):
10.0.10.0/24 Chicago users 10.1.10.0/24 Dallas users
10.0.20.0/24 Chicago voice 10.1.20.0/24 Dallas voice
10.0.30.0/24 Chicago Wi-Fi 10.1.30.0/24 Dallas Wi-Fi
... 24 office routes, plus one more every time any site adds a VLAN
With a summary at each boundary:
10.0.0.0/12 all offices, present and future
10.32.0.0/12 all cloud regions
10.64.0.0/16 infrastructure (loopbacks, WAN links, management)
3 routes, unchanged when a site adds a VLAN or a new office opensThe point-to-point WAN links themselves are part of the same discipline. Every router-to-router link needs a tiny subnet of its own, and a network with forty links has forty of them, so the worked plan draws all of them from one /24 inside the infrastructure block, where they summarize with everything else the whole company shares. Our guide to addressing point-to-point links covers the sizing; the placement matters as much as the size.
Now picture the same three offices in a network that grew without a plan. Dallas got 10.1.5.0/24 in 2015, took 10.1.6.0/24 when the phones arrived, was handed 10.3.40.0/24 for Wi-Fi because that was the next free block in the spreadsheet, and picked up 10.77.0.0/24 during a merger. No prefix describes Dallas. Every one of those subnets is its own route on every router in the company, its own line in every firewall rule that mentions Dallas, and its own entry in every VPN. Multiply by forty sites and the routing table holds hundreds of entries that carry no information a well-drawn plan would not have expressed in forty. Our guide to right-sizing subnets warned about a route table littered with fragments, and this is where the fragments come from. The fix lives outside the router configuration: either renumber the scattered subnets into an aligned block, which is a project, or live with the long table, which is a tax. Companies that absorb another company's network meet the same choice at larger scale, which is why the worked plan sets aside a dedicated block as an acquisitions holding pen and why our guide to merging networks after an acquisition treats a clean target block as the foundation for the whole renumbering effort.
Summaries carry two hazards that are worth knowing before you configure one. The first is a loop. When the Chicago router advertises 10.0.0.0/16, it promises to handle all 65,536 addresses in that block while actually using a few thousand of them. A packet addressed to an unused corner, say 10.0.200.5, arrives in Chicago, matches no specific subnet, and follows the router's default route back out toward the WAN, where the next router consults its table, sees the summary, and sends the packet back to Chicago. The two routers bounce it between them until its time-to-live (TTL) counter, the hop budget every packet carries, runs out. The fix is a discard route: an entry on the summarizing router for the summary itself that says "if nothing more specific matches, throw this away here." Routing protocols such as OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol) install one automatically when you configure a summary, and it is worth checking that yours did.
The second hazard is that a summary hides what it covers. If the Dallas server subnet goes down, the rest of the network keeps sending traffic toward Dallas, because the /16 it advertises has not changed; the packets travel all the way to Dallas to be dropped. When a site has two paths into it, a summary on one path can also pull traffic along a longer route than the specific subnets would have chosen. Both hazards point to the same practice: summarize at the edges of real administrative boundaries, a site, a region, a company, where the loss of visibility matches a boundary you already treat as a unit, and keep the option of announcing a more specific route when an exception is needed. Longest prefix match provides that option. During a migration, a single /24 that has physically moved from Dallas to the data center keeps working from its new home simply by being advertised on its own; the /24 beats the /16 everywhere the two meet.
The public internet is the largest working demonstration of all this, and it exists in its present form because summarization was invented to save it. Until the early 1990s, addresses came in three fixed sizes, the classes A, B, and C, holding roughly 16 million, 65,000, and 256 addresses respectively. Mid-sized organizations needed more than a class C and far less than a class B, so they were handed several class Cs, and every one of them became a separate route in every backbone router. The routing table grew faster than router memory, and the medium-sized class B blocks were running out entirely. A 1992 specification called RFC 1338 (RFC stands for Request for Comments, the name for the documents that define internet standards) proposed "supernetting": assign organizations groups of neighboring class Cs and let routers announce each group as one route. The following year, RFC 1519 generalized the idea into CIDR, the slash notation that finally let a network be any power-of-two size and a route describe any aligned block. Every prefix you have ever typed is downstream of that rescue.
The same hierarchy still runs the internet today. The five Regional Internet Registries (RIRs), the organizations that hand out address space by continent, allocate large aligned blocks to ISPs (internet service providers); an ISP allocates a slice of its block to a customer; the customer subnets its slice as it pleases. The rest of the world sees only the ISP's summary. Your company's forty subnets do not exist anywhere outside your own routers, and your ISP's thousands of customers show up in the global table as a handful of routes. Even so, that table now holds more than a million IPv4 (Internet Protocol version 4) entries, because organizations that switch providers or want control over how traffic reaches them announce their own smaller blocks, punching exceptions through the summaries exactly as longest prefix match allows. The most sweeping summary of all sits at the bottom of nearly every routing table: 0.0.0.0/0, the default route, which matches every address there is and says "for anything not listed above, send it that way." A home router's entire table is that one line plus its local subnet.
IPv6 (Internet Protocol version 6, the newer addressing scheme with vastly more room) changes the numbers and leaves the logic untouched. The prefixes are longer and the blocks are astronomically larger, but a site summarizes to one route only if its allocations sit inside one aligned block, and the alignment rule works on the same binary arithmetic. What changes is the temptation. With no scarcity to fight, there is no reason to pack subnets edge to edge, and every reason to space allocations far apart so each site keeps an enormous aligned block to grow into, a practice our guide to IPv6 address planning calls sparse allocation. Sparse plans stay summarizable for decades, because a site can grow tenfold without spilling past the boundary of its summary.
A plan stays summarizable only if the habit of aligned allocation survives every future change, and the habit is easiest to keep when the tool that hands out subnets understands the hierarchy. In IPCraft, an IPAM (IP address management) tool, every subnet lives inside a parent, so the /24s for an office sit visibly inside that office's /16, and the /16 sits inside the region's /12. Blocks that exist only to hold other blocks, like the /12 for all offices, can be marked as containers, which keeps them out of utilization statistics while preserving them as the summaries they are. When someone needs a new subnet for a site, the Add Child Subnet dialog finds the next free, correctly aligned block inside that site's parent, so the new VLAN lands inside the site's summary instead of at the next empty row in a spreadsheet. Over years, that one default decides whether the core carries forty routes or four hundred.
Subnetting and supernetting are the same arithmetic pointed in opposite directions, and a good address plan is drawn so that both work at once: blocks small enough at the bottom to keep broadcast domains and trust boundaries sane, aligned within blocks large enough above them that each site, region, and company collapses to a single route. Get the alignment right when the space is first handed out, summarize at every boundary that matches how the organization is actually run, and give the summarizing routers somewhere to discard the traffic for the empty parts. The routing table that results is short, changes rarely, and can be read by a person, which is the closest thing to a health check a network offers.