VLSM — Variable-Length Subnet Masking — is the technique of carving a parent CIDR into subnets of different sizes. It's how real networks are designed, because departments don't conveniently come in powers of two.
The rules are simple: allocate largest-first, align each subnet on a boundary that's a multiple of its size, and don't overlap. Let's walk through an example.
The requirements
You've been given 10.0.0.0/22 (1,024 addresses) and need to allocate five subnets:
- Engineering: 250 hosts
- Sales: 100 hosts
- Operations: 50 hosts
- DMZ: 25 hosts
- Management: 10 hosts
Step 1: Sort largest first
Already sorted above. The reason this matters: if you start with the smallest, you'll leave gaps too small to fit the bigger requirements later.
Step 2: Engineering (250 hosts)
For 250 hosts you need 250 + 2 = 252 addresses minimum. The smallest power of 2 that fits is 256 (2^8), so 8 host bits → a /24. Allocate the first /24 starting at the parent's base: 10.0.0.0/24. That gives 254 usable hosts (4 to spare).
The next available address is 10.0.1.0.
Step 3: Sales (100 hosts)
100 + 2 = 102 addresses minimum. Next power of 2 is 128 (2^7), so /25. The /25 starting at 10.0.1.0 is valid because 0 is a multiple of 128. Allocate 10.0.1.0/25.
The next available address is 10.0.1.128.
Step 4: Operations (50 hosts)
50 + 2 = 52 addresses minimum. Next power of 2 is 64 (2^6), so /26. The /26 starting at 10.0.1.128 is valid because 128 is a multiple of 64. Allocate 10.0.1.128/26.
Next available: 10.0.1.192.
Step 5: DMZ (25 hosts)
25 + 2 = 27 addresses. Next power of 2 is 32 (2^5), so /27. 192 is a multiple of 32. Allocate 10.0.1.192/27.
Next available: 10.0.1.224.
Step 6: Management (10 hosts)
10 + 2 = 12. Next power of 2 is 16 (2^4), so /28. 224 is a multiple of 16. Allocate 10.0.1.224/28.
The final plan
Total addresses consumed: 256 + 128 + 64 + 32 + 16 = 496 of 1,024. Remaining: 10.0.1.240/28 through 10.0.3.255 — half the parent block, available for future growth.
What about cloud reserved IPs?
On AWS, subtract 5 instead of 2 per subnet for usable counts. The Management /28 above would have only 11 usable hosts on AWS, not 14. If your real requirement was 14 hosts you'd need a /27 instead.
Common mistakes
- Allocating smallest first. If you start with /28 at
10.0.0.0, you may end up unable to fit the /24 because alignment breaks. - No headroom. Engineering grew from 250 to 280 hosts and now /24 doesn't fit. Plan for 2× growth.
- Forgetting boundary alignment. A /26 cannot start at
.32— only at.0,.64,.128, or.192.
The VLSM Planner does all of this automatically — drop in your host counts and get back the same plan in one click.