Supernet Aggregation Calculator: CIDR Route Summarization

Over time, routing tables fills with extra routes. Whenever you bring up a new subnet, all the routers along the way has to check, advertise, and store it in their routing table. Add enough small block like this and you end up with a makeshift network. By supernetting, you turn this mess into order by combining multiple smaller networks under a single larger prefix. That cuts down dozens of routes to just one route.

It sounds easy enough, right? The problem is doing the math to find summary without summarizing someone else’s address space. Bitwise arithmetic! Fortunately, the calculator above take care of that for you while you decide if summary will fit your setup.

How Supernetting Helps Your Network

This is basic idea. Routing relies on leading bits aligning with each other. IPv4 addresses are 32-bit numbers, so they’re represented as binary numbers. For instance, if we take two addresses like 192.168.0.0/24 and 192.168.1.0/24, they looks like this in binary: The key point is that the first 23 bits aligns. Only at bit 24 do the two differ. Masking off the final bit gives us a /23 address that encompasses both of the original /24s perfectly.

When blocks of addresses line up neatly against power-of-two boundaries, this is all very clean. Two /24s make a /23; four /24s are a /22, etc. But if the blocks aren’t aligned or is spread out, then this goes south immediately. Strict common-prefix mode will find the biggest shared prefix no matter how misaligned the addresses are. However, contiguous block mode assume perfect adjacent blocks and uses a quicker formula.

Over aggregation is not a problem with math itself. It’s something most network designer screw up because their networks aren’t contiguous. This means you end up advertising routes for networks that don’t actualy belong to you. Because you don’t actually have the address space in between, the router has to blow out your prefix to include all the space to make it one route for both sets of addresses. Instead of advertising only your 512 IP addresses, you’re now advertising a /21 which include 2,048 addresses. So you’re advertising space for other peoples networks or unallocated space. Any traffic going to those non-existent subnets ends up getting directed at you and falling into a black hole. The “over aggregation” metric in the above shows exactly how many additional IPs you’re claiming. If that’s high then your summary is too loose. Either rearrange your subnetting to conform to a clean boundary, or break it down into two separate advertised routes.

The trick is to align the leading block of your allocation with its proper edge. If you want a /22, then the third octet has to be a multiple of four (e.g., 0, 4, 8). Addresses starting with 1 or 3 will include extra numbers and force the summary to expand toward lower numbers until it hit the previous boundary. This is why many traditional classful networks aren’t easily aggregated; they’re built on an old system predating CIDR and frequently straddle random bits. If you’re building out a network, think about aggregatable schemes from day one when you choose your addressing plan. Give yourself blocks that group naturaly into larger allocations: two, four, or eight, for example. If done right, it pays off big time.

Router performance is limited by how large their routing tables gets. A smaller number of entries result in faster lookups and smaller update packets. It also leads to quicker convergence after link failures. It also helps keep things stable. Say you have an aggregate with 1/24 inside of it that goes down. That summary route will still be advertised out to other peers. Your little problem gets kept contained within your own network, without causing unnecessary churn on the larger part of the internet. In effect, you’re masking the grotty insides of your own network, with a stable, clean interface towards everyone else.

It does take some time to get used to doing CIDR arithmetic, but after you start getting the feel for how the bits stack up, it gets pretty easy. Whether you’re tuning your production backbone or studying for a certification exam, you’ll find that understanding the mask is more important then knowing any table by heart. When you have an idea about what kind of summary you want, this will show you immediately where it cuts off and how far you can go without going too far. Try out your edge cases here first so you don’t commit something to your configuration file that you end up having to troubleshoot for hours later when the traffic dissapears into nothing.