What a CIDR aggregator does
A CIDR aggregator receives several IPv4 prefixes and checks whether they can be represented by shorter prefixes without covering addresses that were not present in the original set. This is the practical basis of exact route summarization: combine only networks that are contiguous, compatible in size and aligned on the correct binary boundary.
The tool does not create an approximate supernet just because two networks are close to each other. If merging them would include additional space, they remain separate. Read the supernetting and route summarization guide for the routing concepts behind the calculation.
How to enter prefixes for aggregation
Enter one CIDR network per line, or separate networks with commas. For example, use 192.168.0.0/24 and 192.168.1.0/24. The tool normalizes each input, removes prefixes already contained by a broader input, and repeatedly combines compatible pairs until no further exact reduction is possible.
If any entry is invalid, the calculation stops rather than producing a misleading result. You can inspect a single input first with the CIDR range calculator or compare many prefixes with the overlap checker.
Example: two /24 networks that form one /23
192.168.0.0/24 and 192.168.1.0/24 are adjacent and correctly aligned. Together they cover exactly 192.168.0.0 through 192.168.1.255, which is the block represented by 192.168.0.0/23. The aggregation therefore loses no information.
By contrast, 192.168.1.0/24 and 192.168.2.0/24 cannot be represented by one /23 without adding unrelated address space. They are contiguous as text ranges, but the pair is not aligned on the required /23 boundary.
Why binary alignment is as important as adjacency
CIDR blocks always begin at boundaries determined by their size. A /23 contains 512 addresses, so its network must start at an address aligned to a 512-address boundary. A /22 contains 1024 addresses and has an even stricter alignment requirement. Two adjacent prefixes can therefore fail to aggregate if the lower network is not aligned for the shorter prefix.
This is why route summarization cannot be done safely by looking only at the final decimal octet. The tool evaluates network values and prefix lengths mathematically.
Aggregation, routing tables and policy
Summaries can reduce routing-table size and simplify advertisements between network regions. A well-planned address hierarchy makes it possible for many detailed internal routes to be represented by a smaller number of external summaries. The routing guide explains how routers choose routes, while the supernetting guide focuses on aggregation.
However, a mathematically valid summary is not automatically a correct routing-policy decision. Before deploying it, verify that the device advertising the summary can actually reach every more-specific destination covered by that prefix and that failure behavior is understood.
Exact aggregation versus covering aggregation
This tool performs exact aggregation. It never intentionally expands coverage beyond the union of the supplied networks. Some design tasks use a broader covering prefix even when it includes unused addresses, but that is a policy choice and can create black holes or unintended reachability if not handled carefully.
If your starting data is a simple continuous address interval rather than existing CIDR networks, use the IP range to CIDR converter first. It generates the minimum exact prefix set for the interval.
Frequently asked questions
Can two adjacent /24 networks always become a /23?
No. The first /24 must be aligned on the correct /23 boundary. Adjacency alone is not sufficient.
What happens if one prefix is already inside another?
The more-specific prefix is redundant for coverage and can be removed from the exact aggregate set.
Does a smaller result always mean better routing?
No. Aggregation must match topology and policy. A summary can be mathematically valid yet operationally inappropriate.
Can I aggregate IPv6 with this tool?
This version is for IPv4 CIDR prefixes. IPv6 planning uses separate tooling.
Validate the summary before deployment
After calculating the result, verify each summary against the intended topology, next-hop reachability and failure domains. Exact math is necessary, but safe route summarization also depends on network design.