Subnet overlap and safe route aggregation: worked examples

Subnet overlap and route aggregation answer different questions. An overlap check asks whether two allocations contain any of the same addresses. Aggregation asks whether several routes can be represented by a shorter prefix without claiming addresses outside the intended routing domain.

Treating those operations as interchangeable causes expensive mistakes. A summary route can hide an allocation conflict, and removing a redundant contained route does not resolve two teams claiming the same addresses. This guide works through both checks in the order a network plan should use them.

How CIDR overlap works

Two valid CIDR blocks overlap when one block's network address falls inside the other block. Because CIDR boundaries are aligned powers of two, two blocks cannot partially cross like arbitrary numeric ranges: if they overlap, the smaller block is fully contained by the larger block. Equal blocks are an exact overlap.

Normalize host-bit input before comparing it. For example, 10.24.9.40/21normalizes to 10.24.8.0/21. Comparing only the entered strings can miss that those values describe the same block.

Worked overlap example: company VPN merger

Company A uses 10.24.0.0/20 for office and VPN clients. Its range is10.24.0.0–10.24.15.255. Company B uses 10.24.8.0/21, ranging from10.24.8.0–10.24.15.255. When the companies connect their networks, every Company B address is already inside Company A's allocation.

A route table cannot decide which organization owns a destination such as10.24.10.25. Longest-prefix matching may send it toward Company B because its/21 is more specific, but that merely makes Company A's hosts in the same range unreachable across the connection. The address-ownership conflict still exists.

Resolution options

1. Renumber one side: the cleanest long-term answer. Allocate a verified non-overlapping block, migrate services in stages, and retire the old routes.
2. Translate at the boundary: useful as a temporary merger or partner-network bridge, but it adds state, logging requirements, and troubleshooting ambiguity.
3. Expose selected services through proxies: avoids routing whole conflicting networks when only a small application set must communicate.

Suppose Company B renumbers to 10.24.16.0/21. That block spans10.24.16.0–10.24.23.255, so it no longer overlaps Company A's10.24.0.0/20. The adjacent space from 10.24.24.0 onward remains available for later verified allocations.

Worked overlap example: cloud and on-premises

An on-premises network advertises 10.60.0.0/17, covering10.60.0.0–10.60.127.255. A new cloud VPC is created as10.60.64.0/18, covering 10.60.64.0–10.60.127.255. The entire VPC is contained inside the on-premises route.

The conflict may go unnoticed before the private connection is established because each environment works in isolation. Once routes are exchanged, return traffic can follow the covering on-premises route instead of the tunnel, while a more-specific cloud route can divert existing on-premises traffic. Check proposed VPC and VNet blocks against every routed private prefix, not only the allocations already present in that cloud account.

Moving the VPC to 10.60.128.0/18 removes this specific conflict: the on-premises/17 ends at 10.60.127.255, and the new VPC begins at10.60.128.0. Before approving that replacement, the same overlap check must include other sites, VPN partners, container pools, and reserved growth space.

When route aggregation is safe

Aggregation replaces several more-specific routes with a shorter prefix. A safe exact aggregate has three properties:

1. The child prefixes are contiguous; there are no address gaps.
2. The combined range starts on the candidate summary's network boundary.
3. The routing domain owns or intentionally routes every address covered by the summary.

Safe example: four /26 routes become one /24

Together the four routes cover every address from 10.90.8.0 through10.90.8.255 exactly once. The first address is a valid /24 boundary, so 10.90.8.0/24 is an exact aggregate.

Unsafe example: a shorter route includes gaps

Now consider only 10.90.8.0/25 and 10.90.9.0/25. The shortest single prefix covering both is 10.90.8.0/23, but that /23 also includes10.90.8.128/25 and 10.90.9.128/25. Half of the advertised summary is absent from the input routes.

Advertising the /23 is unsafe if those gaps are unowned, routed elsewhere, or intentionally unreachable. Keep the two /25 routes, add the missing owned ranges, or use a summary only at a boundary where a discard route and routing policy deliberately handle unused space.

Overlap-to-aggregation workflow

1. Collect allocations from IPAM, cloud accounts, sites, VPN partners, and reserved pools.
2. Normalize each CIDR and remove exact duplicates without discarding ownership metadata.
3. Run the full set through the overlap checker.
4. Resolve every ownership conflict through renumbering, translation, or scoped connectivity.
5. Group conflict-free routes by routing domain and policy.
6. Use the route aggregator to find exact reductions.
7. Compare every proposed summary range with the original ranges before advertising it.
8. Test forward and return paths, longest-prefix behavior, and failure withdrawal.

Common mistakes

• Comparing CIDR strings: host-bit aliases can hide identical normalized networks.
• Calling containment harmless: a child route may be valid routing hierarchy or conflicting ownership. Keep the allocation context.
• Using longest-prefix match as a fix: it selects a route but does not make duplicate addresses unique.
• Accepting any covering supernet: the shortest cover may advertise gaps or another team's space.
• Aggregating across policy boundaries: contiguous networks may require different security, tenancy, or failure behavior.

Authoritative sources

• RFC 4632 — defines CIDR prefixes, longest-match routing, and address aggregation.
• RFC 1918 — reserves the private IPv4 ranges used in the overlap and aggregation examples.
• RFC 4271 — defines BGP route advertisement and route-selection behavior.