IP Overlap Checker

IPv4 overlap happens when two planned ranges share at least one address. That sounds like a small bookkeeping problem until a VPN pool lands inside a campus aggregate, a partner test segment falls inside a production VLAN, or a new cloud network cannot be peered because its address space already exists somewhere else.

Overlap checks matter because routing, firewall, NAT, and peering decisions usually assume that each address belongs to one clear place. When the same address appears in two inventories, traffic can follow the wrong route, fail policy review, require avoidable translation, or force a late readdressing change. A clean address plan needs valid CIDR blocks and ranges that can coexist.

Address overlap is a range relationship, not a naming relationship. Two rows can have different labels, owners, groups, and notes while still covering the same numeric addresses. The reverse is also true: two rows can look similar in a spreadsheet and still be separate if their start and end addresses never intersect.

The useful result is a change-review signal, not proof of live traffic or policy state. It helps locate duplicate, contained, and partially shared IPv4 ranges so the next routing, VPN, VLAN, VPC, or partner-connectivity change starts from an address plan that can be defended.

Technical Details:

Classless Inter-Domain Routing, or CIDR, writes an IPv4 network as a dotted address plus a prefix length. The prefix length fixes the leading network bits, and the remaining host bits define the size of the block. A /32 covers one address, a /24 covers 256 addresses, a /20 covers 4,096 addresses, and a /16 covers 65,536 addresses.

Overlap testing becomes exact once every accepted row is converted to a numeric start address and end address. A row such as 10.44.80.0/20, a single host such as 10.44.88.10, and a start-end span such as 203.0.113.16-203.0.113.31 can all be compared as closed integer ranges. If the highest starting address is still less than or equal to the lowest ending address, the two rows share addresses.

The equation applies only when the ranges intersect. If startB is greater than endA after sorting, the later range begins outside the earlier range and that pair can be skipped.

Relationship labels come from range geometry. Exact duplicates have the same start and end address. A containment row means one range fully encloses the other. A partial overlap means neither range contains the other, but the ranges still share at least one address. Adjacent ranges are not conflicts, although the advanced setting can annotate them for route summarization or cleanup review.

Address-space labels add context to each parsed range. Private RFC 1918 ranges, shared carrier-grade NAT space, loopback, link-local, benchmark, documentation, multicast, reserved, current-network, mixed, and public ranges are classified from known IPv4 blocks. Those labels do not prove ownership or reachability; they help reviewers spot a documentation example, special-use block, or public range before they rely on the row in a change plan.

The merged coverage blocks show unique address coverage after overlaps and adjacency have been collapsed. Declared address count can be larger than the merged union when duplicate or contained rows exist. That difference is the duplicate address count shown in the summary and structured results.

Everyday Use & Decision Guide:

Start with the inventory exactly as it appears in the change ticket, IPAM export, route plan, or spreadsheet. The parser accepts headers such as label,cidr,group,note, but it can also pull a range from loose text when a line contains a recognizable IPv4 token. Keep group names meaningful, such as core, remote, cloud, partner, or edge, because group scope changes how conflicts are filtered.

Leave Host-bit handling on normalize for a first pass through messy exports. That mode turns host-bearing CIDRs such as 10.44.1.77/24 into their network boundary and records the correction in Inventory Ledger. Switch to strict mode when the review itself should fail non-canonical source rows before anyone copies the cleaned output.

• Use Audit all ranges when you need a complete cleanup list, including duplicate rows inside the same group.
• Use Only flag overlaps between different groups for migration, VPN, VPC, and partner reviews where same-group overlaps are already known.
• Keep Minimum shared addresses at 1 for a full audit. Raise it only when tiny point overlaps are intentionally out of scope.
• Turn on Adjacent range notes when route summarization or allocation cleanup matters. Adjacent ranges are not overlap conflicts.
• Use Normalize after the result is valid to rewrite the source into canonical label, CIDR, group, and status rows.

A common wrong assumption is that a clear overlap result makes the routing plan ready. It only means the submitted IPv4 ranges do not intersect under the selected scope and minimum shared-address setting. It does not verify that the ranges belong to the right owners, that peering will be accepted, that firewall rules match the plan, or that the address inventory is current.

For approval work, read Overlap Findings first, then confirm each row in Inventory Ledger and the merged view in Coverage Blocks. Use Overlap Pressure Map as a quick way to spot broad ranges with many overlap pairs, but resolve the table evidence before treating a network change as ready.

Step-by-Step Guide:

Review one address inventory at a time so the summary, tables, chart, and structured output all describe the same network change.

1. Paste rows into IP inventory, or use Browse to load a text, CSV, log, or config-style file under 512 KiB.
2. Use CIDR, address plus dotted mask, single IPv4 host, start-end range, or CSV rows with label, range, group, and note fields. The run accepts up to 600 non-blank rows.
3. Choose Host-bit handling. Normalize mode keeps common spreadsheet exports usable; strict mode reports rows whose host bits are set.
4. Choose Conflict scope. Audit every pair for cleanup work, or restrict findings to cross-group pairs for peering, partner, and migration reviews.
5. Open Advanced only when needed. Set Adjacent range notes for cleanup candidates, and change Minimum shared addresses only when smaller intersections should be filtered.
6. Read the summary. No overlaps means no intersecting pair survived the current filters; Input needs review means a source row must be corrected before results are valid.
7. Open Overlap Findings and work from the highest severity rows first. The Relationship, Shared addresses, Overlap CIDRs, and Action columns explain the conflict.
8. Open Inventory Ledger to verify normalized CIDR, address count, usable hosts, address-space label, overlap count, and status for each source row.
9. Use Coverage Blocks to see merged unique coverage. If validation reports an invalid IPv4 address, prefix, non-contiguous mask, or host-bit problem, fix the named line and rerun before using the result.

A useful finish is a summary that matches the intended scope, an overlap table with every conflict either resolved or explained, and an inventory ledger whose normalized CIDRs match the change plan.

Interpreting Results:

The strongest warning is an Overlap Findings row with Critical or High severity. Critical usually means an exact duplicate or cross-group containment. High usually means one same-group containment or a cross-group partial overlap. Medium usually points to same-group partial overlap that still deserves cleanup before the inventory is treated as authoritative.

A clear result deserves one more check when filters were changed. Only flag overlaps between different groups can hide same-group duplicates, and a raised Minimum shared addresses can hide small intersections. Read the warning text and settings before calling the inventory clear.

The chart is useful for triage because broad ranges and rows with many overlap pairs stand out. The tables remain the audit record: they name the two ranges, the groups, the shared span, and the action needed to make the address plan coherent.

Worked Examples:

VPN pool inside a production aggregate

A source list with Prod LAN,10.44.0.0/16,core, VPN pool,10.44.80.0/20,remote, and Partner staging,10.44.88.0/22,partner produces three conflict rows. Overlap Findings reports that the production range contains the VPN pool, the production range contains the partner segment, and the VPN pool contains the partner segment. The largest shared count is 4,096 addresses for the production range against the VPN pool, so the next step is to readdress, isolate, or explicitly reserve the smaller ranges before route exchange.

Separate cloud VPC stays outside the conflict

Add Cloud VPC,10.80.0.0/16,cloud to the same list. Inventory Ledger shows 65,536 addresses for that range and zero overlaps because it does not intersect 10.44.0.0/16. Coverage Blocks keeps it as a separate merged block, which is the result you want before a peering or transit-routing review.

A small point overlap filtered by threshold

Two rows such as Branch users,192.168.8.0/25,branch and Printer host,192.168.8.10/32,branch share one address. With Minimum shared addresses set to 1, Overlap Findings reports a same-group containment row with one shared address. If the threshold is raised to 2, that row is filtered and the warnings state that smaller overlap rows were omitted.

Strict mode catches host bits

With Host-bit handling set to strict, a line such as 10.44.1.77/24 returns a validation message telling you that host bits are set and suggesting 10.44.1.0/24. In normalize mode, the same row is accepted, Inventory Ledger records Host bits normalized, and the normalized CIDR is used for overlap comparison.

FAQ:

Glossary:

CIDR

Classless Inter-Domain Routing notation, written as an IPv4 address plus a slash prefix such as 10.44.0.0/16.

Prefix length

The slash number that says how many leading bits are fixed as the network part of the address.

Host bits

The address bits left after the prefix; non-zero host bits make a CIDR source non-canonical for its network boundary.

Overlap

A relationship where two IPv4 ranges share at least one address.

Containment

A relationship where one range fully covers another range.

RFC 1918

The private IPv4 ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

Documentation range

An IPv4 example block such as 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24.

References:

• Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, IETF, August 2006.
• Address Allocation for Private Internets, IETF, February 1996.
• IPv4 Special-Purpose Address Space, IANA.
• Invalid VPC peering connection configurations, Amazon Web Services.