What variable-length subnet masking does
VLSM means cutting one address block into subnets of different sizes, each one matched to what its segment actually needs. The alternative — splitting a block into equal pieces — wastes an enormous amount of space the moment your segments differ. Divide a /24 into four equal /26s and every point-to-point link between routers gets 62 usable addresses to carry two. VLSM gives that link a /30 with two usable addresses and spends the remaining 60 elsewhere.
The design problem is simple to state and easy to get wrong. Every subnet has to be a power-of-two block, and every subnet has to start at an address that is a multiple of its own size. Those two rules together mean the order in which you allocate matters: place a small subnet first and you can end up with free space that is the right total size but in the wrong place, so a larger subnet no longer fits anywhere.
This calculator takes the host count for each of your segments, rounds each up to a legal block size, sorts them largest first, and lays them down end to end from the start of the parent block. The result is the addressing plan a network designer would draw on a whiteboard: network address, mask, first and last usable host, broadcast, and what is left. If you only need the properties of one fixed-size subnet, the IPv4 subnet calculator is the faster tool; if you want to convert between masks and prefix lengths, use the subnet mask and CIDR converter.
The formula, and why allocation order is part of it
Sizing a segment is one calculation. A subnet wide enough to hold h hosts must also hold the network address and the broadcast address, so it needs h + 2 addresses, rounded up to the next power of two:
size = 2⌈log₂(h + 2)⌉
A segment with 50 hosts needs 52 addresses, and the next power of two is 64, so it gets a /26. A segment with 62 hosts needs 64 exactly and still gets a /26. A segment with 63 hosts needs 65 and jumps to a /25 with 128 addresses — the step from 62 to 63 hosts doubles the block. That cliff is the single most useful thing to know about subnet sizing, and it is why growth estimates matter more than current device counts.
The prefix length follows from the size: p = 32 − log₂(size). A 64-address block is a /26 because 26 = 64 and 32 − 6 = 26.
Alignment is the rule that forces the order. A block of size S must begin at an address that is an exact multiple of S, because the mask has to be able to describe it. If you allocate largest first from an aligned parent, alignment takes care of itself: each block size divides every larger size, so the running pointer is always a multiple of whatever you place next. Allocate a /30 first from 10.0.0.0/24 and the pointer moves to 10.0.0.4, which is not a multiple of 64, so the next /26 cannot start there — you would have to skip to 10.0.0.64 and strand 60 addresses. Largest first is not a heuristic; it is what makes the greedy allocation optimal for powers of two.
One exception changes the arithmetic at the bottom end. RFC 3021 allows a /31 on point-to-point links, where the two addresses are both assignable and there is no broadcast address. Selecting that mode makes a two-host link cost 2 addresses instead of 4.
Worked example: 192.168.1.0/24 for 50, 20, 10 and 2 hosts
A branch office has four segments: 50 workstations, 20 phones, 10 servers, and one router-to-router link carrying two addresses. The site has 192.168.1.0/24, which is 256 addresses. Work the plan by hand.
- Size each segment. 50 + 2 = 52 → next power of two is 64 (/26). 20 + 2 = 22 → 32 (/27). 10 + 2 = 12 → 16 (/28). 2 + 2 = 4 → 4 (/30).
- Sort largest first. 64, 32, 16, 4 — already in order here.
- Place the /26. Starts at 192.168.1.0, covers 64 addresses, so it ends at 192.168.1.63. Usable hosts run .1 to .62; broadcast is .63. Mask 255.255.255.192.
- Place the /27. Starts at 192.168.1.64 — a multiple of 32, so it is aligned. Covers 32 addresses to 192.168.1.95. Usable .65 to .94, broadcast .95. Mask 255.255.255.224.
- Place the /28. Starts at 192.168.1.96, a multiple of 16. Covers 16 addresses to 192.168.1.111. Usable .97 to .110, broadcast .111. Mask 255.255.255.240.
- Place the /30. Starts at 192.168.1.112, a multiple of 4. Covers 4 addresses to 192.168.1.115. Usable .113 and .114, broadcast .115. Mask 255.255.255.252.
- Add it up. 64 + 32 + 16 + 4 = 116 addresses allocated of 256, which is 116 ÷ 256 = 45.31% of the parent. 256 − 116 = 140 addresses free, running from 192.168.1.116 to 192.168.1.255.
- Check the efficiency. You asked for 50 + 20 + 10 + 2 = 82 host addresses and consumed 116, so 82 ÷ 116 = 70.69%. The other 29.31% is the cost of rounding each segment up to a power of two plus the two reserved addresses in each block.
Note that the usable capacity you bought is 62 + 30 + 14 + 2 = 108 host addresses, not 116: each of the three larger blocks loses its network and broadcast address. That gap between allocated addresses and usable hosts is why a plan can look comfortable and still run out.
How to read the plan
Share of the parent allocated tells you whether the block you were given is the right size. Under about 50% and you have room for growth or for a second wave of segments. Above 90% and any new VLAN forces a renumber, because the free space left is fragmented into blocks too small to be useful. A design that lands near 100% is finished, not efficient.
Address efficiency measures something different: how much of what you consumed is actually requested host addresses. It falls whenever a segment sits just above a power of two — a 33-host segment takes a 64-address block and runs at barely half. If efficiency is low and space is tight, look for the segment that just crossed a boundary and ask whether the estimate can be trimmed below it, or whether two small segments could share one subnet.
Usable host addresses provided is the number to compare against your requirement. It is always at least two less than the allocated size for every block wider than a /31, and that subtraction is per subnet: split a /24 into eight /27s and you lose 16 addresses to network and broadcast overhead rather than 2.
The unallocated range is contiguous because the allocation is largest first, which is the property that makes the plan extensible. Whatever is free sits at the top of the block in one piece, so the largest new subnet you can add later is the biggest power of two that both fits in that space and is aligned to it — reported in the note above the table. Fragmented free space, by contrast, is the usual symptom of a plan that was allocated in request order rather than size order.
Subnet size reference for IPv4
| Prefix | Mask | Block size | Usable hosts | Largest requirement it serves |
|---|---|---|---|---|
| /22 | 255.255.252.0 | 1,024 | 1,022 | 1,022 |
| /23 | 255.255.254.0 | 512 | 510 | 510 |
| /24 | 255.255.255.0 | 256 | 254 | 254 |
| /25 | 255.255.255.128 | 128 | 126 | 126 |
| /26 | 255.255.255.192 | 64 | 62 | 62 |
| /27 | 255.255.255.224 | 32 | 30 | 30 |
| /28 | 255.255.255.240 | 16 | 14 | 14 |
| /29 | 255.255.255.248 | 8 | 6 | 6 |
| /30 | 255.255.255.252 | 4 | 2 | 2 |
| /31 | 255.255.255.254 | 2 | 2 (RFC 3021) | 2, point-to-point only |
| /32 | 255.255.255.255 | 1 | 1 | Loopback or host route |
Read it from the right: find the smallest row whose usable-host figure covers your requirement, and that is the block the sizing formula will choose.
Mistakes that break a VLSM plan
- Allocating in request order rather than size order. Place a /30 before a /26 and the free space fragments, so a block that would have fitted no longer does even though the total space is available.
- Forgetting the network and broadcast addresses. A segment with exactly 64 devices does not fit in a /26; it needs 66 addresses and takes a /25. The +2 in the formula is where most hand-worked exercises go wrong.
- Sizing to today's device count. The block doubles at every power of two, so a segment at 60 hosts is one printer away from needing twice the space. Size to the expected count at the end of the equipment's life.
- Starting from an address that is not a block boundary. 10.0.0.5/24 is not a network address. This calculator quietly rebuilds the plan from the block that contains it and tells you which one that is.
- Deploying /31 links on equipment that does not support them. RFC 3021 is widely implemented on modern routers, but a device that treats the lower address as a network number will reject the configuration or drop traffic. Verify before you commit the plan.
- Ignoring what the routing protocol can carry. VLSM requires the mask to travel with the route, so it needs a classless protocol — OSPF, EIGRP, IS-IS, BGP or static routes. Original RIPv1 cannot carry it.
- Leaving no summarisable gap. A plan packed tight to 100% cannot be aggregated into a shorter prefix later. Reserve a contiguous tail so the site can be advertised as one route.
Where VLSM sits among addressing methods
VLSM is the subnetting half of classless addressing. RFC 4632 defines CIDR, which removed the fixed class A/B/C boundaries and made the prefix length an explicit part of every route. VLSM is what you do inside your own allocation once prefixes are arbitrary; route summarisation is the same idea running in the opposite direction, collapsing several contiguous prefixes into one advertisement. A plan built largest-first with a contiguous free tail summarises cleanly; a plan built ad hoc does not.
Two related tools finish the job. The wildcard mask calculator converts each of these subnets into the inverse mask Cisco access lists and OSPF network statements expect, which is the next thing you need after the plan exists. The IPv4 host count calculator answers the reverse question — given a prefix, how many hosts does it carry.
On IPv6 the exercise largely disappears. Every LAN gets a /64 regardless of how many hosts sit on it, because the interface identifier is fixed at 64 bits, so there is nothing to right-size. The IPv6 subnet calculator works out how many of those /64s your allocation contains and where the block starts and ends. Dual-stack networks therefore carry two very different addressing disciplines side by side: scarcity management on the IPv4 side, and structural clarity on the IPv6 side.
Finally, treat the output as a design, not a configuration. It says nothing about which VLAN ID or interface each subnet belongs to, about DHCP scopes and reservations, or about whether the addresses conflict with something already deployed. Record the plan in an IPAM system before you configure anything, because the expensive mistake in addressing is never the arithmetic — it is two engineers allocating the same block on different days.