VLSM design guide

Plain subnetting divides a block into equal pieces. That is fine when your segments are the same size, but real networks are not. A typical site has a 100-device office, a 50-device lab, a 20-camera video segment and a handful of switch management addresses. Splitting a /24 into four equal /26s gives each of them 62 usable addresses: the office is short and the management segment has 52 addresses it will never use.

VLSM — Variable Length Subnet Masking — solves this by allowing a different prefix length for each subnet. The same /24 can be divided as one /25, one /26, one /27 and one /28, which fits the real requirements almost exactly and leaves a 16-address reserve. The total address count never changes; only how it is divided does.

Every allocation starts from a host count. Convert it to a prefix in three steps: reserve the network and broadcast addresses, find the next power of two, and subtract its exponent from 32.

required addresses = hosts + 2
addresses          = next power of two ≥ required
prefix             = 32 − log2(addresses)

50 hosts  → 52 required → 64 addresses → 2^6 → 32 − 6 = /26
100 hosts → 102 required → 128 addresses → 2^7 → 32 − 7 = /25
20 hosts  → 22 required → 32 addresses → 2^5 → 32 − 5 = /27

The two-address reservation is why a 30-device segment cannot use a /27: 32 addresses minus network and broadcast leaves exactly 30 usable, with no room for the segment to grow at all. In practice you should size for the device count you expect in a couple of years, not the count you have on the day you write the plan.

Requirements of zero or one are special cases. A /32 is a single host route, useful for a loopback or a management address. A /31 is a two-address point-to-point link defined by RFC 3021, which wastes nothing at all. Note how the rounding is harsh at the boundaries: 25 hosts and 20 hosts both need a /27, and 100 hosts needs a /25 because a /26 offers only 62.

Once every requirement has a prefix, order them from largest subnet to smallest and place them at increasing offsets in the block. This is not a stylistic preference — it is what makes the plan always succeed. A subnet must start at an offset that is a multiple of its own size, so a /25 can only sit at offset 0 or 128, while a /28 can sit at any multiple of 16.

The reason is simple. After placing a block of size n at an aligned offset, the remaining space is a multiple of n, and every subsequent block is no larger than n, so a valid aligned offset always exists. That invariant is what the planner relies on, and it is why the allocation is deterministic.

Here is a full worked allocation. The base block is 10.0.0.0/24 — 256 addresses from offsets 0 to 255, which is 10.0.0.0 to 10.0.0.255.

Office        100 hosts → 128 addresses → /25
Development    50 hosts →  64 addresses → /26
Camera         20 hosts →  32 addresses → /27
Management     10 hosts →  16 addresses → /28
                         --------------------
                           240 of 256 addresses

Sorted largest-first the order is already correct. Each subnet must start at a multiple of its own size, so the planner walks the cursor forward and aligns it before each placement.

Compare what uniform subnetting would have done. Four /26s give the office only 62 usable addresses, so the 100-device requirement does not fit at all, and three of the four subnets carry 40-plus unused addresses each. VLSM fits a larger office and still finds room to spare.

• Size for growth, not for today. Round the device count up before deriving the prefix. Going from a /27 to a /26 costs 32 addresses; renumbering a production segment costs a maintenance window.
• Keep segments of similar size adjacent. Grouping the /26s together and the /28s together makes the plan easier to read and leaves larger contiguous gaps rather than scattered small ones.
• Reserve a management block deliberately. Loopbacks and switch management interfaces are easy to forget and awkward to retrofit. Carve out a /28 or /27 for them near the top of the block.
• Document the allocation before you deploy it. The plan is only useful if the next person can read it. Record the base block, each subnet, its prefix, its range and its purpose.
• Consider route summarisation. If you will advertise the block externally, keeping it contiguous means a single summary route covers every subnet. Breaking the plan across two unrelated ranges doubles the number of entries your upstream sees.

• Allocating smallest-first. This is the classic error and the cause of most plans that “do not fit”. The largest subnet is the least flexible, so it must be placed first.
• Starting a subnet off its boundary. A /27 must start on a multiple of 32. 10.0.0.192/27 is valid; 10.0.0.200/27 is not, and it overlaps the .192 and .224 blocks at the same time.
• Sizing on host count instead of address count. A 30-device segment needs 32 addresses, not 30, because the network and broadcast addresses are not assignable. Deriving the prefix from 30 instead of 32 is the single most common arithmetic slip.
• Forgetting the point-to-point links. Router-to-router links are usually the last thing added and the first thing to break a tight plan. Use /31s per RFC 3021 or /30s, and count them in the requirement list from the start.
• Overlapping ranges. A subnet that overlaps its neighbour will behave unpredictably — some hosts reachable, some not, depending on which route each router installs. Always verify the plan by checking that no address appears in two subnets.
• Planning on the wrong base. Confirm the base block before dividing it. Discovering that you have a /25 rather than a /24 after allocation means redoing the whole plan.

Run your own requirements through the VLSM calculator — enter the base block and the host counts and it returns the aligned allocation, the leftover space and the per-subnet host ranges. The subnet calculator verifies any single subnet in detail, and the subnetting guide covers the block-size arithmetic that VLSM builds on. If any of the requirements are larger than a /24, the CIDR reference table shows exactly how many addresses each prefix provides.