Summarizing firewall CIDR lists with route aggregation

Published: 2026-09-05

How overlapping and adjacent CIDR blocks collapse into a minimal route list, why host bits must be zero, and how to clean firewall and cloud security-group exports offline.

Firewall exports, cloud security-group rules, and BGP prefix lists often accumulate dozens of overlapping or adjacent CIDRs. Two /24s that sit next to each other can become one /23; a /16 that already covers three nested /24s makes those /24s redundant. Route aggregation (also called summarization or supernetting) turns that mess into the smallest set of CIDR blocks that still covers exactly the same addresses—no more, no less.

This guide explains what “adjacent” and “overlapping” mean in address space, how summarization differs from single-subnet math, why inputs must use network addresses, and how to run the workflow locally so allow-list dumps never hit a third-party pastebin. For prefix length and mask basics, start with Subnet math and CIDR explained.

Why summarize at all?

Long CIDR lists are hard to review, expensive in some ACL engines, and easy to get wrong when someone adds a duplicate range months later. Summarization helps when you:

Clean a security-group or cidr_blocks Terraform list before a PR
Collapse vendor firewall exports into something a human can audit
Prepare a minimal prefix list for a VPN or edge router
Spot that “forty /24s” are really one contiguous /18 with a hole elsewhere

Aggregation does not change policy intent by itself. It only rewrites the representation of the covered address set. If two teams meant two separate /24s for documentation reasons, collapsing them may still be correct for the packet filter and wrong for the ticket narrative—use judgment.

Overlap vs adjacency (integer ranges)

Under the hood, every CIDR is a closed interval of addresses: start (network) through end (last address in the block). Aggregation works on those intervals:

Relationship	Meaning	What summarization does
Contained	One block’s range sits entirely inside another	Drop the inner block; keep the larger cover
Overlapping	Ranges share some addresses but neither contains the other	Merge into one continuous span, then re-emit CIDRs
Adjacent	One range’s end + 1 equals the next range’s start	Merge into one span (they touch with no gap)
Disjoint with a gap	At least one address missing between them	Keep separate; do not invent a supernet that fills the hole

Example (IPv4):

Input:
  192.168.0.0/24
  192.168.1.0/24

Merged span: 192.168.0.0 – 192.168.1.255
Output:      192.168.0.0/23

Those two /24s are adjacent and aligned on a /23 boundary, so one CIDR replaces both. If you instead had 192.168.0.0/24 and 192.168.2.0/24, a gap at 192.168.1.0/24 remains—honest aggregation keeps two blocks, not a /22 that would silently allow the middle subnet.

Minimal CIDR decomposition

After merging overlapping and adjacent spans, the remaining continuous ranges may not each be a single “nice” power-of-two block. Algorithms walk each merged span and emit the fewest CIDRs that tile it exactly (alignment-aware: a range that starts mid-octet may need several prefixes).

Input:
  10.0.0.0/24
  10.0.1.0/24
  10.0.2.0/24
  10.0.3.0/24
  10.0.0.0/16   # already covers the /24s above

Output (conceptually):
  10.0.0.0/16

Nested duplicates disappear. Contiguous peers collapse. Gaps stay gaps.

IPv6 uses the same ideas with 128-bit addresses and prefixes 0–128. Keep IPv4 and IPv6 lists separate; mixed paste is not one address space.

Network addresses only (host bits must be zero)

A CIDR in a route or ACL list names a network, not a host. 192.168.1.10/24 has host bits set in the last octet; the network form is 192.168.1.0/24. Aggregators should reject non-network forms rather than silently masking them—silent mask changes hide typos (/25 vs /24) that matter for coverage.

Paste	Status	Why
`192.168.1.0/24`	OK	Host bits clear
`192.168.1.10/24`	Reject	Host bits set
`192.168.1.10`	Reject	Missing `/prefix`
`# office VLAN`	Skip	Comment line

Blank lines and # comments are normal in exports; parsers should ignore them.

Aggregation vs the Subnet Calculator

Tool job	Question it answers
Subnet Calculator	For one prefix: mask, network, broadcast, usable hosts, wildcard
CIDR Aggregator	For many prefixes: merge overlap/adjacency, emit a minimal list
IP in CIDR checker	For IPs vs a list: which addresses fall inside which blocks

Use the calculator when designing a single VPC subnet. Use aggregation when cleaning a list. After you summarize, membership testing against the shorter list is easier—and still exact if you did not fill gaps.

Policy caveats (do not over-merge by hand)

Manual “make it a /16” shortcuts are a common outage cause:

Filling holes — Combining disjoint islands into one supernet allows the addresses in between. Aggregators that only merge overlap/adjacency avoid that class of error.
Deny vs allow — Summarizing an allow list is usually safe if coverage is identical. Summarizing a deny list the same way can widen the deny if you accidentally fill a gap—or shrink protection if you drop a block you still need. Prefer exact algorithms over eyeballing.
Intentional specificity — Some orgs keep /32 host rules for audit trails even when a /24 would match. Collapsing them is mathematically fine and operationally optional.

Why run this in the browser

Firewall CIDR dumps often sit next to customer site names, VPC IDs, and internal hostnames. Pasting them into a public “CIDR merge” site uploads that topology. A browser-only aggregator parses and merges in your tab—no upload—so the list never leaves the device. See Why “local only” matters for developer tools.

Try it locally

The CIDR aggregator accepts one CIDR per line (IPv4 or IPv6 mode), skips # comments, flags invalid syntax and non-zero host bits, merges overlapping and directly adjacent ranges, then emits the minimal CIDR decomposition with input→output block counts and total addresses covered—entirely offline.

Related LocalTools: Subnet Calculator for single-prefix math, IP in CIDR checker to bulk-test addresses against the cleaned list, and Diff Checker to compare before/after rule files in review.