A subnet calculator answers the address arithmetic. A usable network plan also needs host requirements, capacity headroom and overlap checks before you connect routing domains. This walkthrough allocates four IPv4 networks inside 10.42.0.0/22, deliberately introduces a conflicting partner prefix and prepares the result for engineering review. The example is synthetic; it describes no customer network.
I built the networking tools linked here. Use them to calculate and inspect a candidate plan, then check that plan against your address inventory and connection requirements. A browser result cannot establish what is already deployed or which routes your organisation should permit.
Start with requirements, not a favourite subnet mask
Assume a new site needs 200 addresses for Office, 100 for Production, 50 for Management and 20 for Guest. For this example, those are planning requirements that already include gateways, infrastructure addresses and the growth allowance agreed for each group. They are not counts of people, switch ports or currently active leases.
That distinction changes the answer. If Office means 200 laptops today, add the other address consumers and planned growth before sizing it. A phone and laptop can use separate addresses; a redundant gateway design can need several. Guest capacity depends on concurrent clients and lease behaviour, not simply the number of visitors through reception.
Record those assumptions beside the requested numbers. Ask the service owner what must still fit during a refresh, when old and replacement equipment may coexist. An allocation can fit today's fleet and still fail the first migration. Do not silently treat the spare capacity created by binary rounding as an approved growth forecast.
Our parent block, 10.42.0.0/22, spans 10.42.0.0 through 10.42.3.255. It is private IPv4 space, suitable for a synthetic internal planning exercise. In a real project, confirm that your organisation has assigned this parent to the site and that it is not already reserved elsewhere. Private addresses are reusable, not globally unique.
The group names describe intended purposes. Different subnets do not themselves enforce security isolation. The Production-to-Office policy still needs routing, firewall rules and an explicit decision about permitted traffic.
Allocate the largest networks first
Variable-length subnet masking, or VLSM, lets you assign different prefix lengths within one parent. For ordinary IPv4 LAN subnets in this example, choose the smallest power-of-two block whose address count minus the network and broadcast addresses meets the requirement. This convention is not a universal rule for every IPv4 prefix or cloud platform.
Office needs 200 usable addresses. A /25 provides 126, so choose /24 with 254. Production fits in /25, Management in /26 and Guest in /27. Allocating from largest to smallest makes it easier to preserve the alignment each block requires. Starting with scattered small allocations can leave enough total space but no suitably aligned larger block.
Open the VLSM planning page and use its Open tool in AdeOS button to enter the application. The landing page explains the tool; it is not an inline calculator. Enter 10.42.0.0/22 as the parent and the requirements 200, 100, 50 and 20. Compare the allocation with the independently calculated reference below.
| Group | Required | CIDR | Usable IPv4 addresses | Usable range |
|---|---|---|---|---|
| Office | 200 | 10.42.0.0/24 | 254 | 10.42.0.1–10.42.0.254 |
| Production | 100 | 10.42.1.0/25 | 126 | 10.42.1.1–10.42.1.126 |
| Management | 50 | 10.42.1.128/26 | 62 | 10.42.1.129–10.42.1.190 |
| Guest | 20 | 10.42.1.192/27 | 30 | 10.42.1.193–10.42.1.222 |
The reference uses Python's standard-library ipaddress module independently of the browser tool. Each subnet lies inside the parent, meets its stated requirement and does not overlap another allocation. Their broadcast addresses are 10.42.0.255, 10.42.1.127, 10.42.1.191 and 10.42.1.223 respectively. Check these boundaries as well as the displayed capacity; a plausible host count alone does not prove the network address is correct.
The four blocks consume 480 of the parent's 1,024 addresses. That leaves 544 unallocated addresses: 10.42.1.224/27 and 10.42.2.0/23. These are two CIDR blocks, even though the remaining address interval is continuous. You cannot describe all 544 addresses with one correctly aligned CIDR prefix.
Unallocated parent space is different from unused host capacity inside an allocated subnet. Office's spare addresses remain part of Office. They are not a pool that Management can borrow without changing the design. Nor does 544 unallocated addresses mean 544 additional assignable endpoints: future subnet boundaries and platform reservations reduce that figure.
Recalculate capacity for the deployment platform
The table uses conventional IPv4 LAN arithmetic, not AWS resource capacity. AWS documents its IPv4 subnet reservations: under the standard reservation rule, the first four addresses and the last address of each subnet are unavailable for resource assignment. AWS also documents a BYOIP exception, which is outside this private-address example.
Using the standard AWS rule, these block sizes offer 251, 123, 59 and 27 assignable addresses respectively. All four still satisfy the example requirements, but the spare capacity is smaller. A /27 that fits a 30-address conventional LAN requirement would not fit 30 AWS resource addresses under that rule.
This does not turn the table into an AWS architecture. Availability Zone placement, service-specific allocations, interface counts and quotas can change the plan. Recheck the provider's rules for the actual deployment rather than assuming an AWS calculation applies to Azure, Google Cloud or an on-premises VLAN.
Add the partner network and inspect the overlap
Now imagine a partner proposes connecting 10.42.1.0/24. Open the CIDR conflict checker through its AdeOS launch button. Supply the four allocated prefixes plus that partner prefix. Keep the parent /22 out of this first comparison: it intentionally contains all four children and would add containment findings that do not represent competing allocations.
The independently computed relationships below were also reproduced in the live scanner. The interface reported seven findings under “Conflicts”: three containment warnings and four informational adjacency notices. Only the three containment warnings correspond to the partner overlaps in this table. Do not interpret the headline total as seven overlapping networks. Adjacency is not itself a collision, and adjacent blocks of different sizes cannot necessarily be merged into one exact CIDR without including additional addresses.
| Existing allocation | Partner prefix | Address relationship |
|---|---|---|
| Office: 10.42.0.0/24 | 10.42.1.0/24 | No overlap |
| Production: 10.42.1.0/25 | 10.42.1.0/24 | Fully contained by partner prefix |
| Management: 10.42.1.128/26 | 10.42.1.0/24 | Fully contained by partner prefix |
| Guest: 10.42.1.192/27 | 10.42.1.0/24 | Fully contained by partner prefix |
The partner block spans 10.42.1.0 through 10.42.1.255. It contains Production, Management and Guest, including the still-unallocated 10.42.1.224/27. It does not intersect Office. Copy the actual scanner report into the review record after you run the check, and preserve the input set so another engineer can reproduce it.
An overlap is an address relationship, not proof of an outage. Separate VRFs can intentionally reuse addresses. A parent prefix and its children naturally overlap in an IPAM hierarchy. The operational question is whether these ranges must coexist in a routing context that makes their destinations ambiguous.
Do not use longest-prefix matching as a blanket answer. More-specific local routes can win over a partner's covering route, but that does not let the same destination address reliably identify two different endpoints. Return paths, route imports and intended service access still need review. A flat CIDR list cannot infer those requirements.
For AWS VPC peering, the rule is more restrictive than a generic routing discussion. AWS prohibits peering between VPCs with matching or overlapping CIDR blocks. If a VPC has multiple IPv4 CIDRs, any overlap prevents peering even when you intend to use only non-overlapping blocks. Selecting fewer routes does not remove that platform restriction.
Resolve the address decision before connecting
For a hypothetical new partner deployment, choose 10.43.0.0/24 instead, assuming its owner and the wider inventory confirm that it is available. It sits outside our site's /22 and overlaps none of the four allocations. Replace the partner entry and rerun the same comparison. The expected result is no overlap among those five entries.
That result is deliberately scoped. It says nothing about omitted VPN pools, other sites, cloud secondary CIDRs or an acquisition's networks. Compare against the complete inventory relevant to the proposed connection before accepting the new range. An empty conflict report from incomplete inputs is easy to misread.
An existing partner network is harder to move. Renumbering can require DHCP changes, DNS updates, firewall edits, monitoring changes and application configuration work. Plan a transition and rollback with the owners of affected systems. Avoid fitting the new design by simply renumbering a live dependency in a spreadsheet.
NAT may be an option when renumbering is impractical, but it introduces a second addressing view, translation state and troubleshooting work. Applications that embed addresses can complicate it further. Specify which side sees which prefix, how return traffic is translated and what happens during failover. NAT is not a universal workaround for cloud peering restrictions; it may require a different connectivity design.
If the domains do not need direct connectivity, retaining isolation can be the right answer. Document that decision and revisit it when someone requests shared services or route leaking. Today's intentional overlap can become tomorrow's integration constraint.
Hand over a plan another engineer can review
Keep the allocation table, exact scan inputs and actual report together. Add the parent assignment, purpose, routing domain or VRF, named owner and review trigger. For each subnet, distinguish the requested capacity from today's observed use and record whether the growth allowance is included. Include the platform reservation rule used for sizing.
The handoff also needs a connection decision: which networks may communicate, whether the partner range changed, and which unresolved assumptions block deployment. Mark proposed allocations separately from deployed ones. A saved browser scenario can help reproduce calculations, but local browser persistence is not a shared change record or multi-user synchronisation.
For ongoing inventory, NetBox's IPAM documentation describes prefixes, ranges, individual addresses and VRF-specific hierarchies, including overlapping space in separate VRFs. That is the kind of context a lasting source of truth needs. This workflow does not claim a tested integration between the calculator and NetBox.
Treat infrastructure-as-code generation as a separate review step. HashiCorp warns that changing existing cidrsubnets arguments after assigning real infrastructure can invalidate later allocations. A fresh VLSM calculation is therefore not permission to reorder a deployed address plan. Preserve stable assignments and review the effect of each change.
This walkthrough stops at a reviewable address plan. It does not supply deployment-ready Terraform, Ansible or router configuration, and it makes no claim that every export target has been validated. Before adopting any generated configuration, evaluate its resulting prefixes independently and check the target platform's syntax and behaviour.
Run the example before using production data
Start with the VLSM planner, compare the four allocations, then add 10.42.1.0/24 in the conflict checker. After confirming the three containment relationships, substitute the hypothetical 10.43.0.0/24 partner range and rescan. The networking tools overview provides the entry point if you need to revisit the address basics.
Use synthetic inputs for demonstrations and shared links. Review a URL, report or screenshot before sharing it; private addresses and labels can still reveal infrastructure structure. Do not assume that a browser tool guarantees that nothing leaves the browser.
The calculator cannot discover devices, prove duplicate endpoint use, validate routing policy, check every cloud quota or approve a security architecture. This exercise covers IPv4 only. For a hybrid-cloud or industrial network plan, request an infrastructure design review once you have the requirements and inventory ready. The useful starting material is the allocation, the overlap evidence and the connectivity decision, not merely a screenshot with a green result.
