VLSM Explained: Variable-Length Subnet Masking from Scratch

Before VLSM (Variable-Length Subnet Masking), networks had to use uniform subnet sizes — every subnet of a parent network had the same prefix. If you had a /16 and split it into /24s, you got 256 equal subnets whether you needed them or not. A four-person admin team got the same 254 addresses as a 250-person sales team. The result was massive waste.

VLSM lets you use different prefix lengths within one parent network. The admin team gets a /27 (30 hosts), sales gets a /24 (254 hosts), and the address space is allocated efficiently. This is the modern default, and it is the only realistic way to size networks for cloud or enterprise scale.

This article shows you how VLSM actually works through a worked example, explains the strict alignment rules, and walks through the common mistakes that cause re-IPing pain later. If you want to skip the math and just design VLSM allocations interactively, use our VLSM Designer.

The fundamental rule: largest first

VLSM allocation always proceeds from the largest subnet to the smallest. This is not a preference — it is a structural requirement. If you allocate small subnets first, you create unallocatable holes in the address space.

Here is why. CIDR blocks must align on a boundary that is a multiple of their own size. A /24 (256 addresses) must start at a multiple of 256 (10.0.0.0, 10.0.1.0, 10.0.2.0...). A /22 (1024 addresses) must start at a multiple of 1024 (10.0.0.0, 10.0.4.0, 10.0.8.0...).

If you allocate two /27s at the start of a /24, you have consumed 10.0.0.0 through 10.0.0.63. Now suppose you need a /25 (128 addresses). It must start at .0 or .128. The .0 spot is taken, so the /25 goes at .128 — and .64 through .127 is wasted forever.

Allocating the /25 first would have put it at .0–.127, leaving .128 through .255 for the two /27s with no waste.

Worked example: a small office network

Suppose you have 192.168.0.0/22 (1,022 usable addresses) and need to allocate for these teams:

Total hosts needed: 470. Total usable available in the /22: 1,022. There is plenty of room, but only if we allocate in the right order.

Step 1: Allocate the /24 (Sales, largest)

192.168.0.0/24    Sales       (192.168.0.0 - 192.168.0.255)

Step 2: Allocate the /25 (Engineering)

The next available aligned /25 position is 192.168.1.0:

192.168.0.0/24    Sales       (192.168.0.0 - 192.168.0.255)
192.168.1.0/25    Engineering (192.168.1.0 - 192.168.1.127)

Step 3: Allocate the /26 (Marketing)

Next aligned /26 position is 192.168.1.128:

192.168.0.0/24    Sales       (192.168.0.0 - 192.168.0.255)
192.168.1.0/25    Engineering (192.168.1.0 - 192.168.1.127)
192.168.1.128/26  Marketing   (192.168.1.128 - 192.168.1.191)

Step 4: Allocate the /27 (Operations)

192.168.1.192/27  Operations  (192.168.1.192 - 192.168.1.223)

Step 5: Allocate the /28 (Admin)

192.168.1.224/28  Admin       (192.168.1.224 - 192.168.1.239)

Step 6: Allocate the /30 (Lab P2P)

192.168.1.240/30  Lab         (192.168.1.240 - 192.168.1.243)

Final allocation

192.168.0.0/24    Sales       254 usable
192.168.1.0/25    Engineering 126 usable
192.168.1.128/26  Marketing    62 usable
192.168.1.192/27  Operations   30 usable
192.168.1.224/28  Admin        14 usable
192.168.1.240/30  Lab           2 usable
== Free ==
192.168.1.244 - 192.168.3.255  (768 addresses available for growth)

Every team has just enough space, the allocations are contiguous, and the remaining 768 addresses are aligned to multiple useful prefixes for future allocations (/24, /23, smaller).

Sizing rule: round up to a power of 2

To find the right prefix for N hosts, find the smallest power of 2 that is at least N + 2 (the +2 accounts for network and broadcast addresses). Then the prefix is 32 − log₂(that power).

For cloud environments, remember that AWS, Azure, and GCP reserve additional addresses per subnet. See our guide on AWS reserved IPs for the exact counts.

Common VLSM mistakes

Allocating small subnets first

The most common mistake, covered above. If your tool or process does not enforce largest-first, you will fragment the address space and lose room for larger future allocations.

Forgetting alignment

Engineers sometimes try to "tighten" allocations by putting a /24 at 10.0.0.128 instead of 10.0.0.0 or 10.0.1.0. This is invalid — the network address would have non-zero host bits, which breaks routing. Most tools quietly normalize the input to the nearest valid network address, which may not be what you intended.

Not leaving headroom

If you allocate exactly the addresses you need today, the first team that grows by 10% will force a re-IPing operation. The standard practice is to round up by one prefix length beyond the minimum, then leave the rest of the parent network unallocated as growth space. The /22 example above naturally has 768 addresses of headroom because the teams are small relative to the parent.

Mixing VLSM with discontiguous subnets

If you split a /16 into /24s across two physical sites and use them non-contiguously (e.g., site A uses 10.0.1.0/24 and 10.0.3.0/24, site B uses 10.0.2.0/24 and 10.0.4.0/24), older routing protocols cannot summarize correctly. Modern routing (OSPF, IS-IS, BGP, EIGRP) handles this, but the operational complexity is unnecessary. Always allocate contiguous blocks per site.

VLSM in cloud environments

Cloud VPCs are the modern application of VLSM. A typical AWS VPC layout uses VLSM principles even if you do not think of it that way: large /20 subnets for application tiers, medium /24 subnets for databases, and tiny /28 subnets for VPN endpoints and transit gateways. All allocated from one parent VPC CIDR like 10.0.0.0/16.

The key extra constraint in cloud is that AWS, Azure, and GCP reserve addresses per subnet, so your usable counts are 3-5 fewer than the VLSM math predicts. Our Cloud calculator handles this automatically.

Subnetting practice and tooling

Doing VLSM by hand is a useful skill (and shows up on certification exams — see our CCNA subnetting question patterns), but for production work you should always use a tool. The cost of getting a subnet allocation wrong is usually a multi-hour maintenance window to re-IP a workload, so verify before you commit.

• Our VLSM Designer handles arbitrary host requirements, applies the largest-first rule, and exports the result as CSV or to our IaC Export tool.
• The Validate tool checks a list of existing CIDRs for overlaps before you commit.
• The IPAM-Lite tracker records your allocations and warns about conflicts when you add a new entry.

Key takeaways

• VLSM lets you allocate different prefix lengths within one parent network. Always allocate largest first.
• Each subnet must align on a boundary that is a multiple of its size. You cannot put a /24 at 10.0.0.128.
• For N hosts, round up to the next power of 2, add 2 for network and broadcast, and compute the prefix from there.
• Leave headroom — round one prefix length above the minimum, or leave the parent network's remaining space unallocated for growth.
• In cloud, subtract 3-5 reserved addresses per subnet from the usable count.