IP and network calculations
Split a network for departments with different host counts
Tools to use
Having 256 addresses does not mean you can carve out arbitrary groups of sixty from any start. Subnets have power-of-two sizes and aligned boundaries, with conventional IPv4 reservations too. Subnet splitting makes the step from requested hosts to actual CIDRs visible.
Splitting /24 into /26 produces four blocks
192.0.2.0/24
new prefix: 26192.0.2.0/26
192.0.2.64/26
192.0.2.128/26
192.0.2.192/26Increasing the prefix by two divides the original into 2²=4 blocks, each containing 64 addresses. Starts are .0, .64, .128, and .192. Host-bit inputs such as .1/26 and .65/26 normalize to the corresponding .0 and .64 boundaries.
Together the four blocks cover the source, but host capacity is separate. A conventional IPv4 /26 has 62 host addresses after two reservations. Sixty hosts fit; sixty-three do not. Do not compare total addresses directly with required hosts as if they were the same quantity.
For 100, 50, and 20 hosts, vary block sizes
In VLSM mode, enter 192.0.2.0/24 and host requirements 100, 50, 20. Allocations are .0/25, .128/26, and .192/27, with conventional capacities 126, 62, and 30. The .224/27 remains unallocated. Each request receives the smallest power-of-two block that fits the model.
A request for 100 hosts needs at least 102 addresses, rounded up to a 128-address block. Fifty needs at least 52, hence 64; twenty needs 22, hence 32. A total demand of 170 below 256 alone is not sufficient evidence of fit: reservations and block rounding matter.
Allocation starts with larger blocks, not input order
Try requests in the order 20, 100, 50. Output rows follow request order, while allocation begins with larger blocks: twenty gets .192/27, one hundred .0/25, and fifty .128/26. Match each result by request identifier and host count, not an assumed allocation order.
This models fresh allocation into an empty source range. It does not accept existing reservations and route around them. Compare results with your address inventory. 'Unallocated' means unused by this calculation, not discovered to be free on a network.
A small host total can still fail to fit
Requirements 100, 100, 20 need blocks of 128+128+32=288 addresses and do not fit a /24. Although 220 hosts is below 256, the rounded block total exceeds the source. The tool reports failure rather than presenting a partial allocation as complete.
Before revising the plan, decide whether requirements represent current hosts or planned growth. The tool adds no guessed reserve margin. A larger source, different grouping, or another range each has operational constraints. Reducing the input merely to make it fit hides the planning issue.
A two-host VLSM request is not a /31 link model
The IPv4 VLSM model adds network and broadcast reservations to every request. Two hosts therefore receive a four-address /30. The IPv4/CIDR tool's /31 point-to-point policy is a different model. A general-subnet host request does not automatically select /31 for router links.
IPv6 does not subtract two, but mechanically choosing the smallest prefix from a host count is not necessarily an appropriate IPv6 design. This is range arithmetic. Address-configuration mechanisms and device requirements can impose separate allocation constraints.
Review containment, overlap, and the remainder
Use CIDR comparison to check that allocations lie within the source and do not overlap. Equal splits should cover the source; VLSM allocations plus the remainder should account for it. Boundaries and remaining space make future planning clearer than host capacities alone.
Enumeration is limited to 1,024 subnets. Inspect the needed granularity instead of producing an enormous list. Results are planning data, not changes to DHCP, routers, or cloud settings. Before applying them, reconcile existing allocations and platform reservations.
Capacity today is different from room to grow
The 100-, 50- and 20-host example consumes /25, /26 and /27, leaving one /27. If the 50-host team grows to 70, its /26 with 62 conventional hosts no longer fits; it needs /25. Just twenty additional hosts can make the requested blocks exceed the /24. Adding spare address counts does not establish that an aligned contiguous block of the needed size exists.
Recalculate with explicitly chosen headroom to see which request moves to the next block size. The tool does not forecast growth for you. Keep current need and future allowance separate so the reason for a larger allocation is visible. Spare space has a location and size, not just a count. A computed allocation is a design candidate, not a disruption-free migration plan for an existing network.
Check capacity, nonoverlap and containment separately, then account for the remainder. Explaining the full parent range helps spot gaps or unintended expansion. Results displayed in request order can still come from largest-first allocation. Do not mistake row order for organizational priority; retain the mapping between each requirement and its CIDR.