---
{
  "title": "Variable-length subnet masks",
  "summary": "Plan different-sized IPv4 subnets with aligned prefixes, non-overlapping ranges, and room for growth instead of assigning every segment the same block.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "Cisco: Networking basics",
      "url": "https://www.cisco.com/site/us/en/learn/topics/networking/what-is-computer-networking.html"
    },
    {
      "title": "IETF: CIDR",
      "url": "https://www.rfc-editor.org/rfc/rfc4632.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

VLSM allocates subnets with different prefix lengths inside a larger address range. It helps avoid assigning the same oversized network to every requirement. Plan the largest required blocks first, respect prefix alignment, and leave appropriate capacity. Verify that ranges do not overlap. IPv4 usable-address conventions depend on context, so calculate with the actual design rather than repeating a single host-count rule everywhere.

## In practice

A small office needs subnets of different sizes for users, management, and point-to-point connections. The plan assigns aligned prefixes sized for each role.

## A common misunderstanding

Adding a desired host count to an arbitrary starting address does not necessarily create a valid aligned subnet.

## Check your understanding

What should an allocation table show?

**Think it through:** Prefix, address range, intended role, capacity, and any reserved space.

## Size the requirements before allocating

Imagine a fictional lab has one group needing about fifty ordinary host addresses and another needing about twenty. A conventional /26 provides a 64-address block, while a /27 provides a 32-address block. These sizes can fit the requirements better than assigning a /24 to every group.

Host-count conventions depend on the use case. Reserve space deliberately for gateways, infrastructure, and expected growth. A capacity calculation that exactly fits today's laptops may become difficult to maintain when another device category appears.

## Alignment prevents accidental overlap

Starting with 192.168.50.0/24, one illustrative allocation is 192.168.50.0/26 followed by 192.168.50.64/27. The first block spans .0 through .63; the second spans .64 through .95. Their boundaries are aligned to their respective sizes and they do not overlap.

Writing a desired number of hosts after an arbitrary starting address does not create a valid prefix. Verify the network boundary mathematically and with an appropriate calculator, and explain the result rather than treating the tool output as magic.

## Document what remains unassigned

The unused part of a larger block is operationally valuable. Record whether it is reserved for growth, future segments, or another owner. Without that record, two administrators can allocate overlapping space while both believe it is available.

The address plan should also describe the intended security role. A larger or smaller prefix changes address capacity, not the application's permission model. Communication restrictions still need an enforcement mechanism.

For a learning exercise, add a third small management segment to the illustrative allocation. Identify an aligned block that does not overlap either existing range, then state the conventional host range and any reservations. Explain where routing would connect the segments and which paths should be denied. A successful plan combines arithmetic, growth assumptions, ownership, and policy instead of optimizing address counts alone.

## Keep exploring

- [[subnetting]]
- [[ipv4]]
- [[network-segmentation]]