Subnet Planner

Planning is not the same as calculating

A subnet calculator answers a question about one subnet: given 10.0.0.0/24, what is the broadcast address? A planner answers the harder question: I have 10.0.0.0/16 and six sites needing 500, 200, 60, 25, 12 and 4 hosts — how should I carve it up? The second problem is where networks go wrong, because the obvious approach of giving everyone a /24 wastes most of the space and still fails the site that needs 500.

VLSM: allocate largest first

Variable Length Subnet Masking means different subnets get different prefix lengths sized to their actual need. The rule that makes it work is to allocate the largest requirement first and proceed downward. Do it in any other order and you fragment the space so that a later large block has no contiguous room, even though enough total addresses remain. This is the same problem as memory allocation, and the same solution applies.

Two addresses are always gone

Every subnet loses its network address and its broadcast address, so a /24 provides 254 usable hosts rather than 256. That overhead is trivial at /24 and brutal at /30, where four addresses yield two usable — which is exactly why /30 was the classic point-to-point link size and why RFC 3021 introduced /31 for links that need only two endpoints and no broadcast.

Size for growth, but not by doubling everything

The common instinct is to double every requirement for headroom. In a /16 that quickly exhausts the space. A better discipline is to round each requirement up to the next power of two, which the prefix length forces anyway, then leave whole unallocated blocks between allocations rather than padding each one. Contiguous free space can absorb growth anywhere; padding scattered inside each subnet cannot.

Keep allocations summarisable

If you allocate blocks so that each site's subnets sit inside one larger contiguous range, the routing table can advertise one summary route per site instead of six. Aligning allocations on power-of-two boundaries is what makes summarisation possible, and it is far easier to design in at the start than to retrofit after addresses are in production.

Private ranges and the overlap trap

RFC 1918 gives you 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Almost every home router defaults to 192.168.0.0/24 or 192.168.1.0/24, which means any VPN using those ranges collides with a remote worker's home network and routing breaks in ways that look like a firewall problem. Planning corporate space out of 10.x with a non-obvious second octet avoids an entire category of support ticket.