CIDR Aggregator
Aggregate a list of IP addresses or subnets into minimal CIDR blocks.
CIDR Aggregator
Computes the real minimal set of CIDR blocks covering your input addresses (range-merge + power-of-two-aligned decomposition) — not a fixed example.
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The CIDR Aggregator takes a list of IP addresses or CIDR blocks and combines them into the smallest possible set of summary routes — the inverse operation of the CIDR Split Calculator. Route aggregation (also called route summarization) matters because every entry in a router's routing table costs memory and lookup time; a network that's grown organically through many small allocations often ends up with dozens of adjacent /24s that could be represented as a single /20 if a router actually needs to announce or route to all of them as one unit.
- Aggregation isn't just concatenating ranges: two CIDR blocks can only be losslessly combined into one larger block if they're contiguous, equal in size, and properly aligned on a power-of-two boundary for the resulting prefix. Two adjacent /24s starting at 10.0.0.0 and 10.0.1.0 aggregate cleanly into 10.0.0.0/23; the same two blocks starting at 10.0.1.0 and 10.0.2.0 do not, because they don't share a valid /23 boundary.
- This tool checks every candidate pair for exactly this alignment condition, merges what can be losslessly merged, and — critically — reports anything that can't be aggregated as-is, rather than either silently dropping it or producing an oversized block that would incorrectly include address space you don't actually own.
How It Works
- Each input address or CIDR block is normalized to its network address and prefix length.
- The tool sorts the normalized blocks and scans for adjacent pairs of equal size that share a valid parent boundary at one bit shorter than their current prefix.
- Wherever a valid pair is found, it's replaced by the single larger block, and the scan repeats — a block can aggregate multiple times if the result is itself adjacent to and alignable with another block.
- Blocks that have no adjacent, aligned partner are left as-is in the output rather than forced into an inaccurate summary.
- The final result is the minimum set of CIDR blocks that exactly covers the original input address space, with no address included that wasn't in one of the original inputs.
Usage
- Paste or enter the list of IP addresses or CIDR blocks you want to aggregate, one per line.
- Run the aggregation and review the resulting minimal block list.
- Check the output against your original list — the tool will show which inputs merged together and which remain separate because they weren't aligned or adjacent.
- Use the resulting minimal list directly in router configuration, firewall rules, or BGP announcement templates.
Examples
- Aggregating 10.0.0.0/24 and 10.0.1.0/24 into a single 10.0.0.0/23 summary route.
- Attempting to aggregate 10.0.1.0/24 and 10.0.2.0/24 and confirming they cannot merge, because they don't share a valid /23 boundary — they remain two separate routes in the output.
- Reducing eight contiguous /24 blocks down to a single /21 summary route.
- Aggregating a mixed list of individual IPs and small blocks into the fewest CIDR entries that exactly cover the original addresses, with nothing extra included.
Real-World Use Cases
- Reducing a routing table by summarizing many small, contiguous allocations into fewer, larger route announcements.
- Cleaning up a subnet inventory that grew through many separate small allocations over time, before documenting the current state.
- Preparing a minimal, accurate CIDR block list for a firewall allow-list or BGP announcement instead of listing dozens of individual small ranges.
- Verifying whether a specific set of allocated subnets could be represented as one summary route before requesting a supernet from an upstream provider.
Best Practices
- Allocate new subnets from a parent block sequentially, rather than scattering them, so they remain aggregatable later — this is the single biggest factor in whether a network stays summarizable as it grows.
- Re-run aggregation periodically on your subnet inventory rather than only when a routing table gets uncomfortably large; catching non-aligned allocations early is cheaper than renumbering later.
- When a summary route is possible but not exact — some addresses in the resulting supernet aren't actually assigned to you — treat that as a signal to renumber, not to announce a block wider than what you actually control.
- Document why a block wasn't aggregated (non-adjacent vs. misaligned) rather than just noting that it wasn't — the fix is different in each case.
Common Mistakes
- Assuming any two adjacent blocks of the same size can always merge — they can only merge if they also fall on a valid boundary for the resulting shorter prefix, not just if their address ranges happen to be next to each other.
- Manually eyeballing a supernet from a list of subnets and accidentally including address space you don't actually own, because the visually 'obvious' summary block is larger than the union of the actual inputs.
- Aggregating and then forgetting to update downstream documentation or DHCP scope references that still list the old, smaller blocks individually.
- Trying to aggregate blocks of different sizes directly — aggregation only combines equal-size blocks pairwise; blocks of mismatched sizes need to be split to a common size first, or left as separate routes.
Limitations
- This tool aggregates IPv4 CIDR blocks; IPv6 prefix aggregation follows the same underlying logic but with 128-bit boundaries, not currently covered by this specific tool.
- Aggregation only produces a valid result when the inputs are genuinely contiguous and aligned — it cannot summarize disjoint or overlapping address ranges into one accurate block, and correctly reports those as unmergeable rather than guessing.
- The tool works from the addresses you provide; it has no way to know which addresses you actually control versus which merely appear adjacent, so always verify a proposed BGP announcement against your actual allocation records before publishing it.
Technical Reference Guide
- CIDR aggregation, also called route summarization, is a direct application of the variable-length subnet masking defined in RFC 4632.
- Two blocks can only aggregate into a valid supernet if they are the same size, adjacent, and the lower block's network address is evenly divisible by the resulting (larger) block's total address count — the formal boundary-alignment condition.
- Excessive unaggregated routes in BGP contribute to global routing table growth, which is part of why upstream providers often filter or reject overly specific route announcements from downstream networks.
FAQ
Why won't two adjacent /24 blocks always aggregate into a /23?
They aggregate only if the lower block's network address falls on a valid /23 boundary — meaning its third octet is even. 10.0.0.0/24 and 10.0.1.0/24 aggregate cleanly; 10.0.1.0/24 and 10.0.2.0/24 do not, despite being adjacent, because 10.0.1.0 isn't a valid /23 network address.
What happens to blocks that can't be aggregated?
They're returned unchanged in the output alongside whatever did successfully aggregate — the tool never forces a merge that would include address space outside your original inputs.
Can I aggregate a mix of single IPs and CIDR blocks together?
Yes — single IPs are treated as /32 blocks and aggregated using the same alignment rules as any other block size.
Does aggregation change which addresses I control?
No — a correct aggregation covers exactly the same set of addresses as the original inputs, just represented with fewer routing table entries. It never adds or removes address space.
Why does route summarization matter for BGP?
Every announced route consumes memory and lookup time on every router that receives it globally. Summarizing many small announcements into fewer, larger ones reduces the load on the entire internet's routing infrastructure, and is often required by upstream providers' route filters.
Can I reverse an aggregation back into the original smaller blocks?
Yes, in the sense that the CIDR Split Calculator can re-divide any resulting block back into smaller subnets — though it won't automatically reproduce your original, possibly unequal, allocation without you specifying the target sizes again.
Part of this Developer Hub
This utility is part of our comprehensive Networking & Infrastructure topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Network Operations Lab workshop for complementary engineering workflows.
View all Network Operations Lab tools