VLSM subnetting examples: office and cloud network plans

Variable Length Subnet Masking (VLSM) divides one address block into subnets of different sizes. Instead of giving every network the same prefix length, you size each subnet for its actual host requirement and leave deliberate room for growth.

The reliable method is to convert each requirement into a prefix, sort the subnets from largest to smallest, and place each one on a valid boundary. This guide applies that method to two realistic plans: an office with users, voice, guest, and infrastructure networks, and a cloud environment divided across three availability zones.

A repeatable VLSM method

1. List every network and its expected address count.
2. Add growth headroom before choosing prefix lengths.
3. Account for addresses reserved by the platform or subnet model.
4. Choose the smallest prefix that satisfies each adjusted requirement.
5. Sort the resulting subnets from largest to smallest.
6. Allocate each subnet on the next valid boundary.
7. Verify overlaps, gaps, broadcast ranges, and remaining growth blocks.

For a conventional IPv4 LAN, a prefix contains 2^(32 − prefix) total addresses. The network and broadcast addresses are not assigned to hosts, so a /24 normally provides 254 host addresses and a /26 provides 62. Cloud platforms may reserve additional addresses inside every subnet, so use the provider's assignable-address rules rather than relying on the conventional subtraction alone.

Worked example 1: office VLSM plan

An office receives 10.40.0.0/22, a private block containing 1,024 addresses from10.40.0.0 through 10.40.3.255. The design needs separate networks for users, voice devices, guests, infrastructure, and point-to-point or transit assignments.

The planned-capacity column adds 50 percent growth before rounding up to a valid subnet size. Because a /25 has 126 conventional host addresses, it fits 90 guest devices. A/26 has only 62, so it does not. Make this comparison before assigning any network addresses.

Allocate the largest subnet first

This sequence works because every allocation begins at a valid boundary. The /23begins on an even third octet, the /25 begins at .0, the/26 begins at .128, and the /28 begins at.192. The remaining addresses form 10.40.3.208/28 and10.40.3.224/27. Recording those aligned free blocks makes a later allocation safer than writing “48 addresses free.”

Worked example 2: multi-zone cloud VLSM plan

A cloud environment receives 10.80.0.0/20. It must support three availability zones with repeatable application, data, public, and private-endpoint tiers. A fourth equal-sized zone block is reserved for expansion or disaster recovery.

First divide the /20 into four /22 blocks. Assign10.80.0.0/22, 10.80.4.0/22, and 10.80.8.0/22 to zones A, B, and C. Keep 10.80.12.0/22 unallocated. Each zone then uses the same internal pattern:

These peaks include 50 percent growth. The selected totals leave room for provider reservations, but the exact assignable capacity must still be calculated using the chosen cloud's rules. For example, 180 application addresses fit inside a 256-address/24 even after five addresses are withheld; they do not fit inside a 128-address/25.

Repeating one layout reduces operational mistakes, while a contiguous /22 per zone gives route policies a simple zone boundary. The unused /23 inside each zone can later be split without renumbering existing tiers. The untouched fourth /22 leaves room for a whole new zone or a separately routed environment.

In zone A, the application tier spans 10.80.0.0–10.80.0.255, data spans10.80.1.0–10.80.1.127, public spans10.80.1.128–10.80.1.191, private endpoints span10.80.1.192–10.80.1.255, and the aligned growth block spans10.80.2.0–10.80.3.255. Zones B and C repeat those offsets in their own/22 blocks. These are total CIDR spans; provider-reserved addresses must be removed before calculating workload-assignable ranges.

Safe and unsafe route summaries

The complete cloud parent 10.80.0.0/20 spans10.80.0.0–10.80.15.255. Advertising that /20 is a safe summary only when the same environment controls all four /22 zone blocks, including the reserved fourth block. It covers exactly the address space assigned to this design.

Advertising 10.80.0.0/19 to make the route shorter would be unsafe. A/19 spans 10.80.0.0–10.80.31.255, so it also claims the adjacent10.80.16.0/20. If that adjacent block belongs to another environment, the summary can attract traffic that this network cannot deliver. A valid aggregate must align correctly and must not cover space outside the routing domain's ownership.

Common VLSM mistakes

• Allocating in request order: small early allocations can fragment the only boundary that a later large subnet can use. Sort by prefix size first.
• Adding growth after sizing: 60 current hosts fit a /26, but 60 plus 50 percent growth do not. Apply headroom before rounding.
• Ignoring boundaries: 10.40.3.64/25 is not a distinct/25; it normalizes to 10.40.3.0/25 and overlaps that block.
• Counting cloud addresses like an ordinary LAN: provider reservations and managed services reduce the addresses available to workloads.
• Leaving accidental gaps: track free space as CIDR blocks so its boundaries and future uses remain explicit.

VLSM verification checklist

1. Confirm every child subnet is contained by the parent block.
2. Confirm every prefix meets its adjusted capacity requirement.
3. Normalize each CIDR and confirm the entered address is its network boundary.
4. Check every pair of allocations for overlap.
5. Record network, assignable range, broadcast or provider reservations, and purpose.
6. Express every remaining gap as one or more aligned CIDR blocks.
7. Check that routing summaries do not accidentally include another environment.

Use the hierarchical subnet planner to build the allocation tree, the subnet overlap checker to validate the resulting list, and the route aggregator to test which prefixes can be summarized safely.

Authoritative sources

• RFC 4632 — documents CIDR prefix interpretation, allocation, and route aggregation.
• RFC 1918 — reserves the private IPv4 ranges used in these examples.
• Amazon VPC subnet sizing — documents subnet size limits and provider-reserved IPv4 addresses.
• Azure Virtual Network FAQ — documents Azure subnet address reservations and sizing considerations.