Most people learn subnetting backwards — memorise the CIDR table, practice converting /27 to a host count, pass the exam, and never actually plan a real address space from a blank sheet of paper. VLSM (Variable Length Subnet Mask) is the part that separates knowing the table from being able to design a network: the skill of assigning a different mask to every subnet based on what it actually needs, instead of forcing every subnet in a site to be the same size because that's what fits in a spreadsheet column.

The problem fixed-length subnetting creates

Take a single /24 — 254 usable addresses — and imagine splitting it into eight equal /27s because that's the tidy, uniform way to divide it. Each /27 gives you 30 usable hosts. That works fine for a subnet that actually has 25-30 devices on it. It's a serious waste for a point-to-point WAN link between two routers, which needs exactly two usable addresses and will never need a third. Fixed-length subnetting forces every subnet — the 300-user office LAN and the 2-address router link alike — into the same size bucket, which means the bucket has to be sized for the largest requirement, and every smaller subnet burns addresses it will never use.

This isn't a theoretical inefficiency. On a /24-sized internal range, giving every WAN link a /27 instead of a /30 when you have a dozen point-to-point links is the difference between using 24 addresses and using 384 — more than the entire /24 has to offer. VLSM exists specifically to let each subnet be sized independently, so a /30 link and a /25 office LAN can coexist in the same parent block without either one distorting the other's allocation.

The actual planning technique: greatest demand first

The practical method that keeps a VLSM design from turning into a mess of overlapping ranges is simple and doesn't require anything more than a list and some arithmetic: list every subnet you need to create along with its required host count, sort that list from largest host requirement to smallest, then allocate address space starting from the biggest subnet first, working down to the smallest.

The reason order matters: each allocation consumes a contiguous, correctly-aligned block starting from wherever the previous allocation left off. If you allocate small subnets first, you fragment the remaining space in ways that make it awkward or impossible to fit the large subnets you still need — you end up with plenty of total addresses left, just not enough contiguous ones in one place. Allocating largest-first avoids that entirely, because big blocks need to start on boundaries that are multiples of their own size, and starting from an untouched, unfragmented range guarantees that alignment works out.

A worked example

Say you've been handed 192.168.1.0/24 for a small site with three LANs and three point-to-point WAN links to other locations:

• LAN A — 100 hosts
• LAN B — 50 hosts
• LAN C — 20 hosts
• WAN link 1, 2, 3 — 2 hosts each

Sorted largest to smallest and allocated in that order:

• LAN A (100 hosts) needs a mask giving at least 100 usable addresses — that's a /25 (126 usable). Allocated as 192.168.1.0/25, covering .0 through .127.
• LAN B (50 hosts) needs at least 50 — a /26 (62 usable). Starting right after LAN A's block: 192.168.1.128/26, covering .128 through .191.
• LAN C (20 hosts) needs at least 20 — a /27 (30 usable). Next available: 192.168.1.192/27, covering .192 through .223.
• WAN link 1 (2 hosts) needs a /30 (2 usable). Next available: 192.168.1.224/30.
• WAN link 2 — 192.168.1.228/30.
• WAN link 3 — 192.168.1.232/30.

That leaves 192.168.1.236 through .255 — 20 addresses, room for five more /30 links or one more small subnet — genuinely available for future growth instead of scattered as unusable fragments between other allocations, which is exactly what greatest-first ordering buys you.

The mental-math shortcut worth actually memorising

Planning VLSM on a whiteboard or in a design conversation without a calculator to hand comes up more often than the tooling-heavy way it's usually taught suggests. The shortcut that makes it practical: for any subnet mask, the block size — how many addresses that mask covers, and therefore where the next block has to start — is 256 minus the relevant octet value of the mask. A /27 has a mask octet of 224, so its block size is 256 − 224 = 32; a /26 is 256 − 192 = 64; a /30 is 256 − 252 = 4. Once you know the block size, every valid starting address for that mask is a multiple of it — a /27 can only start at .0, .32, .64, .96 and so on, never at .16 or .40. That single fact is what lets you sanity-check a proposed VLSM plan by eye: if a subnet's stated network address isn't a clean multiple of its own block size, the plan is wrong, no calculator required to catch it.

Sizing for growth without over-provisioning

Two opposite mistakes show up constantly here. The first is sizing every subnet for the exact current headcount with zero headroom, which means the next new hire or the next device added to that VLAN forces a re-address — genuinely disruptive on a live network, and the kind of task nobody wants to schedule downtime for. The second, more common mistake is overcorrecting and giving every subnet a /24 "to be safe," which burns through the parent block so fast that VLSM's actual benefit — efficient packing — never materialises at all.

A reasonable middle ground: size for actual current need plus roughly 20-30% headroom, rounded up to the next available mask boundary. A subnet with 100 current hosts and realistic growth to maybe 115-120 still comfortably fits a /25 (126 usable) — no need to jump straight to a /24 (254 usable) on the assumption it might someday host 200 devices. Reserve genuinely large growth allowances for the subnets where you have concrete evidence of growth — a new office actively hiring, a VM cluster you know is expanding — not uniformly across every subnet in the design.

The two mistakes that cause real pain months later

The first is skipping documentation, on the assumption the addressing scheme is obvious from the numbers. It isn't — that's precisely VLSM's tradeoff. A naive fixed-length scheme is self-documenting because every subnet follows the same pattern; a well-packed VLSM design, by design, doesn't have a visible pattern, because different-sized blocks start at different offsets for good reasons that aren't visible just from staring at an address. Without a written record — even something as simple as a spreadsheet of block, mask, purpose, and date allocated — the next person (quite possibly you, eight months later) has no way to tell a genuinely free block from one that's reserved but not yet deployed.

The second is allocating in an order that breaks route summarization upstream. VLSM's efficient packing and clean route summarization are in mild tension: summarization works best when subnets that will be advertised together as one covering route sit in a contiguous, correctly-aligned range, and an address plan optimised purely for tight packing can scatter related subnets across the block in a way that prevents ever expressing them as a single summary route later. When you know in advance that a group of subnets will eventually need to summarise upstream — say, everything at one site, advertised as one route to a WAN — it's worth reserving a contiguous parent block for that group specifically, even if it means leaving a few addresses unused inside it, rather than optimising purely for minimum waste and finding out later the routes can't be aggregated.