Variable-length subnet masks () let the subnets carved from one parent block have different prefix lengths, each sized to the hosts it must hold. The (RFC) on router requirements describes it: "an address block associated with a given network prefix could be subdivided into subblocks of different sizes, so that the network prefixes associated with the subblocks would have different length" (RFC 1812, section 4.2.3.4). You meet it wherever a hundred-host segment sits next to a two-router link, because no single mask fits both without waste. The mask arithmetic is assumed from Subnetting basics and the slash notation of Classless Inter-domain Routing () from CIDR notation explained. After reading, you can size each subnet, place the blocks so that no hole opens, name the protocols that can carry the plan, explain why longest match keeps mixed masks safe, and check the result in the site's calculator.

One mask per network, then more than one

RFC 950, the subnetting standard of August 1985, introduced the address mask, but the division was made once per network: "the width of the <subnet-number> field is constant for a given network" (RFC 950, section 2.1), and one stored mask, "my_ip_mask" (section 2.2), served every address of the network. The constant width lasted two years. The gateway requirements of June 1987 said "we allow a particular subnetted network to use more than one subnet mask" (RFC 1009, section 1.1.4) and drew the consequence for routing tables: "for full generality the mask needs to be given explicitly for each entry" (section 4.2). RFC 1009 is Historic now, but the permission begins there.

In June 1995 the permission became an obligation: "Routers MUST support variable length network prefixes in both their interface configurations and their routing databases" (RFC 1812, section 4.2.3.4). RFC 1878, now Historic, tabulated every prefix length with its mask and address count (RFC 1878, Table); RFC 4632 absorbed the table into the rule that "prefixes may be defined to describe any power of two-sized block of between one and 2^32 end system addresses" (RFC 4632, section 3.1). None of these documents uses the acronym: RFC 1812 writes "variable length subnet masks (variable length network prefixes)" (Appendix E) and 's specification says "variable length subnetting" (RFC 2328, section 1.1). VLSM is the trade's name for what they describe.

What the mask has to travel with

A plan with several masks runs only on routers that learn a mask with every route. "Network masks or prefix lengths must be explicitly carried in routing protocols" (RFC 4632, section 5): OSPF, Intermediate System to Intermediate System (), version 2 of the Routing Information Protocol (), the Enhanced Interior Gateway Routing Protocol () and do; RIP version 1, HELLO and the older Interior Gateway Routing Protocol (IGRP) do not (section 5). The families are compared in Dynamic routing compared.

RIP shows the difference in its packet format. A version 1 route entry carries an "IP address (4)" followed by two fields marked "must be zero (4)" (RFC 1058, section 3.1). RIP version 2 put "Subnet Mask (4)" in one of those fields (RFC 2453, section 4), because the omission was "a particularly serious problem for routers since they need a subnet mask to know how to determine a route" (section 2). OSPF version 2 carries a mask in every Hello and every route: "Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (i.e., different masks)" (RFC 2328, section 1.1), as OSPF: the map, the math, and area 0 shows. A static route states its destination as a prefix too (RFC 1812, section 7.4).

Once masks differ, one destination may match several routes, and the forwarding rule makes that safe: "Routers must use the most specific matching route (the longest matching network prefix) when forwarding traffic" (RFC 1812, section 2.2.5.2). OSPF makes it the planner's duty: "Subnet masks must be assigned so that the best match for any IP destination is unambiguous" (RFC 2328, section 3.5). The lookup is in Static routes, longest prefix match and administrative distance.

Sizing each subnet

Every ordinary subnet gives up its all-zeros and all-ones host numbers, which is why, as RFC 1812 notes, "each of these fields will be at least two bits long" (RFC 1812, section 4.2.2.11), and the block for h hosts is the smallest power of two that is at least h plus 2. The table lists the plan's sizes and the edges where one more host changes the answer:

Hosts neededHosts plus 2Block (addresses)PrefixUsable hostsNetmask
244/302255.255.255.252
101216/2814255.255.255.240
252732/2730255.255.255.224
505264/2662255.255.255.192
626464/2662255.255.255.192
6365128/25126255.255.255.128
100102128/25126255.255.255.128
127129256/24254255.255.255.0

A segment of 60 hosts fits a /26 with 2 to spare, and the 63rd host forces a /25: sizing to today's count is how a plan renumbers next year. A two-router link may take a /31, since "In a point-to-point link with a 31-bit subnet mask, the two addresses above MUST be interpreted as host addresses" (RFC 3021, section 2.1), but a link "in which only one end supports the use of 31-bit prefixes may not operate correctly" (section 5). The /31 and /32 cases are in Subnetting basics; the plan below keeps a /30.

Alignment, and why largest first works

A block of 2^k addresses can start only where the low k bits of the address are zero, which is why RFC 4632 says allocations are "made in contiguous bit-aligned blocks" (RFC 4632, section 3.1). In the last octet, .0 is 00000000, .128 is 10000000, .192 is 11000000, .224 is 11100000 and .240 is 11110000: each offset is a multiple of the block it begins (128, 64, 32, 16 and 4).

Take 192.0.2.0/24, which the Internet Assigned Numbers Authority () registry lists as "Documentation (TEST--1)" (IANA, IPv4 Special-Purpose Address Space), and five requirements: 100, 50, 25 and 10 hosts, plus a two-router link. Largest first, one after another:

RequirementSubnetNetmaskUsable rangeBroadcastUsable hosts
100 hosts192.0.2.0/25255.255.255.128192.0.2.1 to 192.0.2.126192.0.2.127126
50 hosts192.0.2.128/26255.255.255.192192.0.2.129 to 192.0.2.190192.0.2.19162
25 hosts192.0.2.192/27255.255.255.224192.0.2.193 to 192.0.2.222192.0.2.22330
10 hosts192.0.2.224/28255.255.255.240192.0.2.225 to 192.0.2.238192.0.2.23914
Link192.0.2.240/30255.255.255.252192.0.2.241 to 192.0.2.242192.0.2.2432

Used 244 of 256 addresses, 12 free, 95.3 per cent. Each block begins where the previous one ended, by arithmetic: every block already placed is a power of two at least as large as the next, so the sum of their sizes is a multiple of the next size (128 is a multiple of 64, 192 of 32, 224 of 16, 240 of 4), and no block has to skip ahead. A /22 allocation, with the discard route for its summary, is carved end to end in A VLSM allocation, worked end to end.

How a plan goes wrong

The wrong order leaves holes. Place the same five blocks smallest first, each at the next aligned address. The link takes 192.0.2.0/30; a /28 cannot start at .4, since 4 is not a multiple of 16, so it jumps to 192.0.2.16/28, then 192.0.2.32/27, 192.0.2.64/26 and 192.0.2.128/25 follow. Everything fits, 244 used and 12 free, but the free space is now 192.0.2.4/30 and 192.0.2.8/29, two pockets inside the plan instead of one tail. A hole is unallocated space, not a conflict: aligned blocks stay disjoint in any order; overlaps come from a block off its boundary or an address used twice (Subnet overlaps and gaps).

In an exactly full parent, the wrong order loses a subnet. Requirements of 62, 126 and 62 hosts need a /26, a /25 and a /26: 64 plus 128 plus 64 is 256, the whole /24. Largest first gives 192.0.2.0/25, 192.0.2.128/26 and 192.0.2.192/26, 100 per cent used. Smallest first gives 192.0.2.0/26, the /25 jumps to 192.0.2.128/25, and the last /26 has nowhere to go: the 64 free addresses, 192.0.2.64 to 192.0.2.127, lie behind the cursor. Used 192, free 64, 75.0 per cent, one requirement unmet although the totals add up.

RFC 4632 shows the effect at provider scale: six sites connect to a 10.24.0.0/13 "in the following order (significant because it demonstrates how temporary 'holes' may form in the service provider's address space)" (RFC 4632, section 6.1). C1 takes 10.24.0.0/21; needs a /20, and since 2048 is not a multiple of 4096 it goes to 10.24.16.0/20, leaving 10.24.8.0 to 10.24.15.255 as a hole that the /22s of C3 and C4 later fill (section 6.1). Verified erratum 2955 corrects the diagram there, which prints C4 as a /20.

Mixing RIP versions takes the freedom back. Where version 1 routers listen, "a single subnet mask should be used throughout the network" (RFC 2453, section 6), or blackhole routes may follow.

A mask mismatch on a shared segment stops OSPF before routing starts. The Network Mask in a received Hello is checked against the interface's own, and "Any mismatch causes processing to stop and the packet to be dropped" (RFC 2328, section 10.5): two routers on one segment with a /25 and a /24 never become neighbours, and the symptom is an adjacency that never appears, not a wrong route.

Scattering a site across the plan throws away its summary. A site's routes collapse into one prefix only "by allocating a contiguous power-of-two block address space to the site" (RFC 4632, section 4.1); see Route summarization and Supernetting and route aggregation.

Leaving room to grow

The tail of the plan above, 192.0.2.244 to 192.0.2.255, is 12 addresses, but as aligned blocks it is a /30 at 192.0.2.244 and a /29 at 192.0.2.248: no subnet of more than 6 hosts will ever fit there. Count free space in aligned blocks, not addresses, and reserve next year's /27 while an aligned /27 is still free. RFC 4632's provider did the same, since "the number of IPv4 addresses 'required' by each site is assumed to allow for significant growth" (RFC 4632, section 6.1).

RFC 1219's mirror-image counting lets a mask change without renumbering: "host bits (mask = 0) are assigned from the least significant bit working towards the most, and subnet bits (mask = 1) are assigned from the most significant bit working towards the least" (RFC 1219, Overview), so that when a subnet grows "no host ever need change addresses" (Overview).

Seeing it

On a Linux router the plan is visible as several prefix lengths under one parent. Since "root PREFIX selects routes with prefixes not shorter than PREFIX" (ip-route(8), ip route show), ip route show root 192.0.2.0/24 lists every subnet carved from the parent, while ip route get 192.0.2.130 prints the single route the kernel would use, the longest-match decision made visible. Interface masks are read with ip address show and set with ip address add 192.0.2.129/26 dev eth0, where "The ADDRESS may be followed by a slash and a decimal number which encodes the network prefix length" (ip-address(8), ip address add). The table itself is introduced in Routing Tables and the Default Gateway.

Python's ipaddress module checks a plan in a few lines, which the Python playground runs in the browser:

>>> from ipaddress import ip_network, collapse_addresses
>>> plan = [ip_network(p) for p in ('192.0.2.0/25', '192.0.2.128/26',
...         '192.0.2.192/27', '192.0.2.224/28', '192.0.2.240/30')]
>>> free = [ip_network('192.0.2.244/30'), ip_network('192.0.2.248/29')]
>>> list(collapse_addresses(plan + free))
[IPv4Network('192.0.2.0/24')]
>>> list(ip_network('192.0.2.0/24').address_exclude(ip_network('192.0.2.0/25')))
[IPv4Network('192.0.2.128/25')]
>>> ip_network('192.0.2.128/26').supernet_of(ip_network('192.0.2.192/27'))
False

collapse_addresses returning the parent proves that the five subnets and two free blocks cover every address exactly once; address_exclude lists what is left of a block as aligned pieces; supernet_of is False because the /26 and the /27 are siblings, not nested (Python 3.14 documentation, ipaddress).

The CIDR / Subnet Calculator has a VLSM mode beside its Subnet, Supernet and Overlap / gap modes. It takes a parent block and a list of requirements, each a name and a host count, and on Allocate prints the addresses used and free, the utilisation, and each subnet's network, prefix, netmask, usable range, broadcast and usable hosts; requirements that cannot be placed appear under "Did not fit". It sorts the requirements largest first itself, so the five above give the table above in any order, and the smallest-first failure can only be reproduced by hand or in Python. It sizes every requirement as hosts plus two, so a 2-host link always gets a /30, never a /31; RFC 3021 links are checked one at a time in Subnet mode, which counts a /31 the RFC 3021 way. And it masks a parent's host bits silently, so 192.0.2.77/24 is allocated as 192.0.2.0/24: read the network address it prints back. On 192.0.2.0/25 with requirements of 200, 50 and 10 hosts, it places the 50 at 192.0.2.0/26 and the 10 at 192.0.2.64/28 and lists the 200 under Did not fit, at 62.5 per cent.

What to remember

  • VLSM means subnets of one parent with different prefix lengths: RFC 950 fixed one width per network in 1985, RFC 1009 allowed several masks in 1987, RFC 1812 made them a MUST in 1995.
  • Size each subnet as hosts plus 2 rounded up to a power of two: 100 hosts need a /25, 50 a /26, 25 a /27, 10 a /28, a link a /30 (or a /31 where both ends support RFC 3021).
  • A block of 2^k addresses starts only where its low k bits are zero; placed largest first, each block begins where the previous one ended.
  • The wrong order leaves holes, not overlaps, and in an exactly full parent it can leave a block with nowhere to go although the sizes add up.
  • The plan runs only where every router learns a mask with each route (RIP version 2, OSPF, IS-IS, EIGRP, BGP, static routes); RIP version 1 carries none.
  • Forwarding is longest match, so every destination needs one most specific route; a mask mismatch in OSPF Hellos stops the adjacency.
  • Count free space in aligned blocks, reserve growth while an aligned block is free, and keep each site in one power-of-two block so it summarises to one route.

Sources