Split 192.168.1.0/24 into four equal /26 subnets and you get four blocks of 62 usable hosts each. That works fine if every department actually needs somewhere between 1 and 62 hosts — but a sales floor with 100 people, a lab with 10 machines, and a point-to-point link that only ever needs 2 addresses don't have anything close to equal requirements. Forcing them into equal-sized subnets either breaks the biggest one or wastes most of the smallest ones. VLSM — Variable Length Subnet Masking — is the fix: carve a differently sized block out of the same base network for each group, sized to what it actually needs.
The problem fixed-length subnetting runs into
Ordinary subnetting (covered in CIDR Explained) lengthens a prefix by a fixed number of bits and applies that same new prefix everywhere —/24 to /26 gives four equal /26 blocks, no exceptions. That's exactly right when every subnet genuinely needs about the same number of hosts. It falls apart the moment requirements vary widely:
192.168.1.0/26 62 usable — big enough for a 100-host sales floor? No.
192.168.1.64/26 62 usable — a 2-host point-to-point link only needs 2.
192.168.1.128/26 62 usable — wasting 60 addresses here for nothing.
192.168.1.192/26 62 usable — wasting 60 addresses here too.One oversized requirement (100 hosts) doesn't fit in any of the four equal blocks at all, while the smaller ones burn through address space they'll never use. VLSM solves both problems at once by letting every subnet take whatever size it actually needs.
The rule: size each subnet to its own host count
For each group, find the smallest block that covers its required host count plus the network and broadcast address every ordinary CIDR subnet reserves — the same -2 rule from CIDR Explained, applied independently per group:
Hosts needed Smallest block that fits Prefix
1-2 4 addresses (2 usable) /30
3-6 8 addresses (6 usable) /29
7-14 16 addresses (14 usable) /28
15-30 32 addresses (30 usable) /27
31-62 64 addresses (62 usable) /26
63-126 128 addresses (126 usable) /25A 2-host point-to-point link gets a /30. A 100-host sales floor gets a /25. Neither one is forced into the other's size.
A worked example
Take 192.168.1.0/24 (256 addresses) and four groups: Sales needs 100 hosts, Engineering needs 50, Support needs 25, and Lab needs 10. Working out the minimum block for each from the table above:
Sales: 100 hosts → /25 (128 addresses, 126 usable)
Engineering: 50 hosts → /26 (64 addresses, 62 usable)
Support: 25 hosts → /27 (32 addresses, 30 usable)
Lab: 10 hosts → /28 (16 addresses, 14 usable)Allocating largest to smallest, starting from 192.168.1.0:
Sales 192.168.1.0/25 .0 - .127 (126 usable)
Engineering 192.168.1.128/26 .128 - .191 (62 usable)
Support 192.168.1.192/27 .192 - .223 (30 usable)
Lab 192.168.1.224/28 .224 - .239 (14 usable)
.240 - .255 (16 addresses still free)240 of the 256 addresses are allocated, 16 are left over for a future subnet — and every group got exactly the size it needed, instead of four identical /26s that couldn't have held Sales at all.
Why allocation order matters
Every VLSM block is a power of two, and a block can only start at an address that's a multiple of its own size — a /25 has to begin at .0 or .128, a /26 at a multiple of 64, and so on. Allocating largest-first, as above, satisfies this automatically: each new block starts exactly where the previous one ended, and because sizes are non-increasing, that boundary is always correctly aligned for the next block too.
Allocate in a different order and that stops being true. Take the same four requirements, but carve Lab's /28 out first simply because it was listed first:
Lab 192.168.1.0/28 .0 - .15 ✓ fine on its own
Sales needs a /25 (128 addresses) starting right after — but
.16 isn't a multiple of 128. The next valid /25 boundary
is .128, so .16-.127 (112 addresses) are stranded —
unusable by Sales, and too fragmented to hand to anyone else.Nothing about the math was wrong — Lab's /28 is a perfectly valid block on its own. The problem is purely ordering: sizing every subnet correctly doesn't help if a small one gets carved out of the middle of space a larger one will need later. Sort every requirement from largest to smallest before allocating, and this can't happen.
Common mistakes
- Allocating in request order instead of size order. The single most common VLSM mistake — see the misalignment example above.
- Forgetting the -2 rule still applies per subnet. A 2-host requirement still costs a full /30 (4 addresses), not 2 — the network and broadcast address aren't waived just because VLSM is in use.
- Sizing for today's headcount with zero room to grow. A department at 60 hosts today that gets exactly a /26 (62 usable) has nowhere to go without re-addressing the moment it adds two more machines.
- Not reserving space for subnets that don't exist yet. The 16 addresses left over in the worked example above aren't wasted — they're headroom for the next department, without having to renumber anything already assigned.
FAQ
Is VLSM a different protocol from CIDR?
No — VLSM is just CIDR subnetting applied more than once, at different prefix lengths, inside the same base network. There's no separate addressing scheme to learn; the arithmetic for each individual subnet is identical to working out any other CIDR block.
Why allocate the largest subnet first instead of in whatever order the requirements were listed?
Every subnet's size is a power of two, and a block can only start on an address that's a multiple of its own size. Packing from largest to smallest guarantees that property automatically; packing in an arbitrary order can land a smaller, earlier block on an address a later, larger block can't start from without leaving a gap or overlapping it.
Does VLSM still reserve a network and broadcast address per subnet?
Yes — each VLSM subnet is an ordinary CIDR block, so the same -2 rule applies to every one of them individually. A request for 2 hosts still costs a full /30 (4 addresses), for the same reason a single /30 does outside of VLSM.
What happens if the base network isn't big enough for every subnet?
Whichever subnets don't fit have to be flagged or dropped rather than silently overlapping an existing one — the fix is either a larger base network (a shorter prefix) or re-examining whether every host count is actually accurate, not forcing the allocation to proceed anyway.
Is VLSM still relevant with cloud VPCs instead of on-prem routers?
Yes — a cloud VPC's address range gets split into subnets for different availability zones, tiers, or environments exactly the same way, and those subnets are rarely all the same size: a public-facing subnet, a small management subnet, and a large application subnet within one VPC is VLSM, whether or not the cloud console calls it that.
Try it yourself
VLSM Subnet Calculator runs this exact allocation — largest-first packing, per-subnet mask and host range, and a flag on any requirement that doesn't fit — for any base network and list of host counts, entirely in your browser. For the arithmetic behind a single subnet rather than a whole VLSM allocation, see CIDR Calculator and CIDR Explained.