LFCE 10 🐧 VLSM — Variable Length Subnet Masking - KandZ

⏱️ Estimated read: 13 min | |

Variable Length Subnet Masking is the technique that turns a single address block into a hierarchy of differently sized subnets. Fixed-length subnetting forces every subnet to use the same mask, which means every subnet holds the same number of hosts. This works when all segments have identical requirements. It fails when a network contains a 200-host user LAN, a 60-host server segment, a 14-host management VLAN, and a 2-host point-to-point WAN link. Applying one mask to all four either wastes addresses on the small segments or leaves the large segment without enough capacity. VLSM solves this by allowing each subnet to carry its own prefix length, allocated sequentially from a parent block . For the LFCE candidate, VLSM is the practical expression of classless routing: every route you configure on a Linux router carries an explicit prefix, and VLSM is the design discipline that determines what those prefixes should be.

Key point: VLSM allocates subnets from largest to smallest host requirement, assigning each segment the smallest prefix that satisfies its host count. The critical constraint is that subnets must never overlap. Because different masks produce subnets that can contain one another, overlap detection requires comparing the full address range of each subnet, not just the network address.

Why VLSM exists

The uniform-mask waste problem.

Fixed-length subnetting divides a block into equal-sized pieces. A /24 split into four /26 subnets gives four segments of 62 usable hosts each . If one segment needs 60 hosts and three segments need 10 hosts each, the three small segments waste 52 addresses apiece. Over a large network with dozens of segments, this waste compounds. VLSM allows the designer to allocate a /26 to the 60-host segment, a /28 to each 10-host segment, and a /30 to a router-to-router link, using only the addresses each segment actually needs . The parent block is consumed more slowly, and the address plan reflects reality rather than an arbitrary uniformity.

The hierarchical aggregation problem.

A well-designed VLSM plan produces contiguous subnets that can be summarized. If a site receives a /22 and subdivides it into /24 user LANs and /28 infrastructure segments, the entire site can still be advertised to the wider network as a single /22 aggregate. The internal routers carry the more specific routes, and the external routers see only the summary. This aggregation depends on VLSM allocation being sequential and aligned to bit boundaries . A poorly planned VLSM scheme that scatters subnets across the parent block breaks summarization and forces every specific prefix into the global routing table.

The classless routing dependency.

VLSM requires a routing protocol that carries the subnet mask in its updates. Classful protocols like RIPv1 assume the mask from the address class and cannot represent a /27 or a /30. Every modern routing protocol—OSPF, BGP, RIPv2, EIGRP—is classless and carries the mask explicitly . On a Linux router, the ip route command is inherently classless: every route carries a prefix length. VLSM is therefore not an optional design technique on Linux; it is the native mode of operation. The question is whether the designer uses it deliberately or allows the address plan to emerge by accident.

a. The VLSM allocation procedure

VLSM allocation follows a fixed sequence. List every segment and its host requirement. Sort the segments from largest to smallest. Select a parent block large enough for the total requirement. Allocate the largest segment first, then the next largest, each time choosing the smallest prefix that satisfies the host count and placing it at the next available address after the previous allocation .

# VLSM allocation for a parent block 192.168.20.0/23
# Requirements:
#   Building A: 200 hosts
#   Building B: 100 hosts
#   Servers:     60 hosts
#   Lab:         30 hosts
#   Management:  14 hosts
#   WAN link:     2 hosts

# Step 1: Sort largest to smallest (already sorted above)

# Step 2: Allocate Building A (200 hosts)
# 2^8 - 2 = 254 >= 200, so 8 host bits → /24
# Subnet: 192.168.20.0/24
# Range: 192.168.20.1 – 192.168.20.254, broadcast .255

# Step 3: Allocate Building B (100 hosts)
# 2^7 - 2 = 126 >= 100, so 7 host bits → /25
# Next available: 192.168.21.0
# Subnet: 192.168.21.0/25
# Range: .1 – .126, broadcast .127

The allocation pointer advances after each subnet. The next subnet must start at an address that is aligned to its own size. A /26 subnet must start on a multiple of 64, a /27 on a multiple of 32. If the previous allocation ended at an address that is not aligned, padding addresses are skipped. This alignment requirement is what prevents overlap and preserves the possibility of aggregation.

# Continuing the allocation
# Step 4: Servers (60 hosts) → 6 host bits → /26
# Next available after 192.168.21.128 is 192.168.21.128 (aligned to 64)
# Subnet: 192.168.21.128/26
# Range: .129 – .190, broadcast .191

# Step 5: Lab (30 hosts) → 5 host bits → /27
# Next available: 192.168.21.192 (aligned to 32)
# Subnet: 192.168.21.192/27
# Range: .193 – .222, broadcast .223

# Step 6: Management (14 hosts) → 4 host bits → /28
# Next available: 192.168.21.224 (aligned to 16)
# Subnet: 192.168.21.224/28
# Range: .225 – .238, broadcast .239

# Step 7: WAN link (2 hosts) → 2 host bits → /30
# Next available: 192.168.21.240 (aligned to 4)
# Subnet: 192.168.21.240/30
# Range: .241 – .242, broadcast .243

The remaining space from 192.168.21.244 through 192.168.21.255 is unused and reserved for future growth. The allocation is complete, and every subnet is contiguous within the parent /23.

b. Overlap detection and the alignment rule

VLSM’s flexibility introduces a failure mode that fixed-length subnetting does not have: overlapping subnets that use different masks. A /24 and a /26 can occupy overlapping address ranges while having different network addresses. If both are configured, hosts in the overlapping range become unreachable because the router has conflicting information about where to send their traffic .

# Example of a VLSM overlap
# Subnet A: 172.16.3.0/24    range 172.16.3.0 – 172.16.3.255
# Subnet B: 172.16.2.0/23    range 172.16.2.0 – 172.16.3.255
# These overlap: both include 172.16.3.0 through 172.16.3.255
# The /23 contains the /24 entirely

# Configuring both on a router creates ambiguity
ip route add 172.16.3.0/24 via 10.0.0.1
ip route add 172.16.2.0/23 via 10.0.0.2
# Traffic to 172.16.3.50 matches both; the /24 wins by longest match
# But traffic to 172.16.2.50 also goes to 10.0.0.2, including the range
# that the /24 claims to own. The /24 hosts may be unreachable.

Preventing overlap requires two disciplines. First, allocate sequentially from the start of the parent block. Second, align each subnet to its own size. A /26 must start at an address divisible by 64. A /27 must start at an address divisible by 32. A /30 must start at an address divisible by 4. When these rules are followed, subnets cannot overlap because each one occupies a distinct, aligned block . Verification tools can confirm the plan before configuration.

# Verify a VLSM plan with subnetcalc
subnetcalc 192.168.21.128/26
# Network:   192.168.21.128
# Broadcast: 192.168.21.191
# Host range: .129 - .190

subnetcalc 192.168.21.192/27
# Network:   192.168.21.192
# Broadcast: 192.168.21.223
# Host range: .193 - .222
# No overlap: the /27 starts where the /26 broadcast ends (+1)

c. Configuring VLSM subnets on Linux

Every Linux route is a VLSM route in the sense that it carries an explicit prefix. Configuring a VLSM plan means assigning interface addresses with the correct prefix lengths and adding routes for remote subnets with the correct masks. The kernel’s longest-prefix-match algorithm handles the rest.

# Configure a Linux router with VLSM subnets on separate interfaces
# Building A: /24
ip addr add 192.168.20.1/24 dev eth0.10
# Building B: /25
ip addr add 192.168.21.1/25 dev eth0.20
# Servers: /26
ip addr add 192.168.21.129/26 dev eth0.30
# Lab: /27
ip addr add 192.168.21.193/27 dev eth0.40
# Management: /28
ip addr add 192.168.21.225/28 dev eth0.50
# WAN: /30
ip addr add 192.168.21.241/30 dev eth1

# The kernel now knows each subnet's range directly
# No static routes are needed for directly connected networks

For remote subnets, the route command carries the VLSM prefix explicitly. The routing table may contain multiple routes for overlapping address space only if they are intentionally hierarchical—for example, a /23 aggregate and a more specific /24 within it. The longest-prefix-match rule ensures the more specific route wins.

# Add a route to a remote VLSM subnet
ip route add 10.50.1.64/26 via 192.168.21.242
# The /26 is explicit; the kernel does not infer it from the address

# Verify the route is selected for a host in that subnet
ip route get 10.50.1.70
# Output: 10.50.1.70 via 192.168.21.242 dev eth1

Complete Example Session

# ============================================
# PART 1: THE PARENT BLOCK AND REQUIREMENTS
# ============================================
# Parent: 10.10.0.0/22
# Address range: 10.10.0.0 – 10.10.3.255 (1,024 addresses)
# Requirements:
#   Data Center:  500 hosts
#   Office LAN:   200 hosts
#   VoIP:         100 hosts
#   Management:    50 hosts
#   IoT:           20 hosts
#   WAN links:      2 hosts each (three links)

# ============================================
# PART 2: SORT AND ALLOCATE THE DATA CENTER
# ============================================
# 500 hosts → 2^9 - 2 = 510 → 9 host bits → /23
# Subnet: 10.10.0.0/23
# Range: 10.10.0.1 – 10.10.1.254, broadcast 10.10.1.255

# ============================================
# PART 3: ALLOCATE THE OFFICE LAN
# ============================================
# 200 hosts → 2^8 - 2 = 254 → /24
# Next available: 10.10.2.0 (aligned to 256)
# Subnet: 10.10.2.0/24
# Range: 10.10.2.1 – 10.10.2.254, broadcast 10.10.2.255

# ============================================
# PART 4: ALLOCATE VoIP
# ============================================
# 100 hosts → 2^7 - 2 = 126 → /25
# Next available: 10.10.3.0 (aligned to 128)
# Subnet: 10.10.3.0/25
# Range: 10.10.3.1 – 10.10.3.126, broadcast 10.10.3.127

# ============================================
# PART 5: ALLOCATE MANAGEMENT
# ============================================
# 50 hosts → 2^6 - 2 = 62 → /26
# Next available: 10.10.3.128 (aligned to 64)
# Subnet: 10.10.3.128/26
# Range: .129 – .190, broadcast .191

# ============================================
# PART 6: ALLOCATE IoT
# ============================================
# 20 hosts → 2^5 - 2 = 30 → /27
# Next available: 10.10.3.192 (aligned to 32)
# Subnet: 10.10.3.192/27
# Range: .193 – .222, broadcast .223

# ============================================
# PART 7: ALLOCATE WAN LINKS
# ============================================
# 2 hosts each → /30 (2 usable)
# Link 1: 10.10.3.224/30, range .225-.226, broadcast .227
# Link 2: 10.10.3.228/30, range .229-.230, broadcast .231
# Link 3: 10.10.3.232/30, range .233-.234, broadcast .235

# ============================================
# PART 8: CONFIGURE LINUX ROUTER INTERFACES
# ============================================
ip addr add 10.10.0.1/23 dev eth0      # Data Center gateway
ip addr add 10.10.2.1/24 dev eth1      # Office LAN gateway
ip addr add 10.10.3.1/25 dev eth2      # VoIP gateway
ip addr add 10.10.3.129/26 dev eth3    # Management gateway
ip addr add 10.10.3.193/27 dev eth4    # IoT gateway
ip addr add 10.10.3.225/30 dev eth5    # WAN link 1

# ============================================
# PART 9: VERIFY WITH SUBNETCALC
# ============================================
subnetcalc 10.10.3.128/26
# Network: 10.10.3.128, Broadcast: 10.10.3.191
subnetcalc 10.10.3.192/27
# Network: 10.10.3.192, Broadcast: 10.10.3.223
# No overlap: .192 follows .191

# ============================================
# PART 10: AGGREGATE FOR REMOTE ROUTERS
# ============================================
# The entire plan fits within 10.10.0.0/22
# A remote router needs only one route:
ip route add 10.10.0.0/22 via 10.10.3.226
# The internal /23, /24, /25, /26, /27, and /30s
# are hidden behind the /22 aggregate

The ten parts traced a complete VLSM allocation: parent block selection, largest-first allocation, alignment-preserving placement, interface configuration, verification, and aggregation. The plan consumes the parent block from 10.10.0.0 through 10.10.3.235, leaving 10.10.3.236 through 10.10.3.255 for future use.

Quick Reference

VLSM Allocation Steps

Step	Action
1	List all segments and host requirements
2	Sort from largest to smallest host count
3	Select a parent block large enough for total
4	Allocate largest segment from start of block
5	Advance pointer; align to next subnet’s size
6	Allocate next segment; repeat until done
7	Verify no overlap with `subnetcalc`
8	Document network, broadcast, host range for each

Prefix Selection by Host Count

Hosts Needed	Host Bits	Prefix	Usable Hosts
2	2	/30	2
6	3	/29	6
14	4	/28	14
30	5	/27	30
62	6	/26	62
126	7	/25	126
254	8	/24	254
510	9	/23	510

VLSM vs FLSM

Property	FLSM	VLSM
Subnet sizes	Equal	Variable
Masks used	One mask for all	Different mask per subnet
Address waste	High	Minimal
Routing protocol	Classful or classless	Classless only
Overlap risk	Low	Requires alignment discipline

Best Practices

✅ Do This:

# Allocate largest segment first
# 500 hosts → /23 before 200 hosts → /24                    # ✅
# Align each subnet to its own size
# /26 starts at multiple of 64; /27 at multiple of 32        # ✅
# Verify with subnetcalc before configuring
subnetcalc 10.10.3.128/26                                    # ✅
# Use /30 for point-to-point WAN links
ip addr add 10.10.3.225/30 dev eth5                          # ✅
# Aggregate VLSM plan into a single parent route
ip route add 10.10.0.0/22 via 10.10.3.226                     # ✅
# Document the plan before implementation
# Network, broadcast, host range for every subnet             # ✅

❌ Don’t Do This:

# Allocate small segments first, then discover the large one doesn't fit
# 2-host WAN at 10.10.0.0/30, then 500-host DC has no /23      # ❌
# Place a /26 at an address not divisible by 64
# 10.10.3.130/26 overlaps with the /25                       # ❌
# Use a /24 for a WAN link
# Wastes 252 addresses for 2 hosts                           # ❌
# Assume overlap doesn't exist because network addresses differ
# 172.16.3.0/24 and 172.16.2.0/23 overlap despite different IDs # ❌
# Configure routes without verifying the kernel's selection
ip route get 10.10.3.200    # Check longest-prefix match     # ❌
# Use classful routing protocols with VLSM
# RIPv1 cannot carry the mask                               # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Overlapping subnets	Small subnet placed inside larger one’s range	Allocate sequentially with alignment
Large segment doesn’t fit	Small segments allocated first	Sort largest to smallest
WAN link wastes addresses	/24 used instead of /30	Use /30 for 2-host links
Route not selected	More specific prefix exists elsewhere	`ip route get` to verify
Aggregation fails	Subnets not contiguous or aligned	Allocate from block start sequentially
Host unreachable	Overlap creates conflicting routes	Verify ranges with `subnetcalc`
Interface prefix wrong	Copy-paste error	`ip addr show` to confirm

Real-World Examples

1. Allocate 500 hosts from /22

# 500 hosts → /23
ip addr add 10.10.0.1/23 dev eth0
# Range: 10.10.0.1 – 10.10.1.254

2. Allocate 200 hosts next

# Next available after /23: 10.10.2.0
# 200 hosts → /24
ip addr add 10.10.2.1/24 dev eth1

3. Allocate 2-host WAN link

# /30 provides exactly 2 usable addresses
ip addr add 10.10.3.225/30 dev eth5
ip addr add 10.10.3.226/30 dev eth6

4. Verify no overlap

subnetcalc 10.10.3.128/26    # Broadcast .191
subnetcalc 10.10.3.192/27    # Network .192, no overlap

5. Aggregate VLSM plan

# All subnets fit within 10.10.0.0/22
ip route add 10.10.0.0/22 via 10.10.3.226

6. Check longest-prefix match

ip route add 10.10.0.0/22 via 10.10.3.226
ip route add 10.10.3.128/26 via 10.10.3.129
ip route get 10.10.3.150    # Matches /26, not /22

7. Document a subnet

# 10.10.3.192/27
# Network: .192, Broadcast: .223
# Hosts: .193 – .222 (30 usable)

8. Add a new VLSM segment

# Next available after .235 is .236
# A /30 at 10.10.3.236/30 fits without overlap
ip addr add 10.10.3.237/30 dev eth7

9. Avoid FLSM waste

# FLSM /26 for all: 62 hosts per segment
# VLSM: /26 for 50, /27 for 20, /30 for 2
# VLSM preserves addresses for growth

10. Verify interface prefix

ip addr show eth3 | grep inet
# Output: inet 10.10.3.129/26
# Confirms the correct VLSM mask

Visual

VLSM Allocation from a Parent Block

┌──────────────────────────────────────────────────────────────┐
│  10.10.0.0/22 — VLSM ALLOCATION SEQUENCE                     │
│                                                              │
│  10.10.0.0 ────────────────────────────────────────────────  │
│                                                              │
│  ┌──────────────────────────────────────────────┐            │
│  │ Data Center  10.10.0.0/23  (500 hosts)       │            │
│  │ Range: 10.10.0.1 – 10.10.1.254               │            │
│  └──────────────────────────────────────────────┘            │
│  ┌──────────────────────────────┐                            │
│  │ Office 10.10.2.0/24 (200)    │                            │
│  │ Range: .2.1 – .2.254         │                            │
│  └──────────────────────────────┘                            │
│  ┌─────────────────────┐                                     │
│  │ VoIP 10.10.3.0/25   │                                     │
│  │ (100) .3.1 – .3.126 │                                     │
│  └─────────────────────┘                                     │
│  ┌──────────────┐                                            │
│  │ Mgmt /26 (50)│                                            │
│  │ .128 – .191  │                                            │
│  └──────────────┘                                            │
│  ┌────────┐                                                  │
│  │IoT /27 │                                                  │
│  │.192-.223│                                                 │
│  └────────┘                                                  │
│  ┌──┐┌──┐┌──┐                                                │
│  │/30││/30││/30│  ← WAN links (2 hosts each)                │
│  └──┘└──┘└──┘                                                │
│                                                              │
│  Allocations are sequential and aligned. No overlap.         │
│  Entire plan aggregates to 10.10.0.0/22.                     │
└──────────────────────────────────────────────────────────────┘

VLSM vs FLSM Address Efficiency

┌──────────────────────────────────────────────────────────────┐
│  SAME REQUIREMENTS, TWO METHODS                              │
│                                                              │
│  Requirements: 50 hosts, 20 hosts, 2 hosts                   │
│                                                              │
│  FLSM (/26 for all):                                         │
│  ┌─────────────────────┐                                     │
│  │ Subnet 1: 62 hosts  │  50 used, 12 wasted                │
│  ├─────────────────────┤                                     │
│  │ Subnet 2: 62 hosts  │  20 used, 42 wasted                │
│  ├─────────────────────┤                                     │
│  │ Subnet 3: 62 hosts  │  2 used, 60 wasted                 │
│  └─────────────────────┘                                     │
│  Total wasted: 114 addresses                                 │
│                                                              │
│  VLSM (right-sized):                                         │
│  ┌─────────────────────┐                                     │
│  │ Subnet 1: /26 (62)  │  50 used, 12 spare                 │
│  ├───────────────┤                                           │
│  │ Subnet 2: /27 (30)  │  20 used, 10 spare                │
│  ├───────┤                                                   │
│  │ Subnet 3: /30 (2)   │  2 used, 0 spare                  │
│  └───────┘                                                   │
│  Total wasted: 22 addresses (spare capacity only)            │
│                                                              │
│  VLSM uses 188 fewer addresses for the same requirements.    │
└──────────────────────────────────────────────────────────────┘

Overlap Detection

┌──────────────────────────────────────────────────────────────┐
│  WHY DIFFERENT NETWORK ADDRESSES CAN STILL OVERLAP           │
│                                                              │
│  Subnet A: 172.16.3.0/24                                     │
│  Range: 172.16.3.0 ────────────── 172.16.3.255               │
│                                                              │
│  Subnet B: 172.16.2.0/23                                     │
│  Range: 172.16.2.0 ──────────────────────── 172.16.3.255    │
│                                                              │
│  Overlap region:                                             │
│  172.16.3.0 ────────────── 172.16.3.255                      │
│  Both subnets claim this range.                              │
│                                                              │
│  The /23 contains the /24 entirely.                          │
│  Configuring both creates routing ambiguity.                 │
│                                                              │
│  Prevention: allocate sequentially from the parent block,    │
│  align each subnet to its size, verify with subnetcalc.      │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
VLSM	Variable Length Subnet Masking; different masks per subnet
Allocation order	Largest host requirement first, smallest last
Prefix selection	Smallest prefix satisfying 2^h − 2 ≥ required hosts
Alignment rule	Each subnet starts at an address divisible by its size
Overlap prevention	Sequential allocation from parent block start
Overlap detection	Compare full address ranges, not network addresses
Parent aggregation	All subnets summarize to the original block
WAN link prefix	/30 for 2 usable hosts
Linux configuration	`ip addr add` with correct prefix; `ip route add` with explicit masks
Verification	`subnetcalc`, `ip route get`, `ip addr show`

Key takeaways:

VLSM allocates largest to smallest. The 500-host segment gets its /23 before the 2-host WAN link gets its /30. Reversing the order risks fragmenting the parent block so the large segment no longer fits.
Alignment prevents overlap. A /26 must start at a multiple of 64. A /27 at a multiple of 32. When every subnet is aligned and sequential, overlap is impossible .
Different network addresses do not guarantee different ranges. A /24 at 172.16.3.0 and a /23 at 172.16.2.0 have different network addresses but identical broadcast addresses. They overlap completely in the upper half .
VLSM requires classless routing. OSPF, BGP, and RIPv2 carry the mask. Classful protocols cannot represent a /27 or a /30. Linux routing is inherently classless .
The /30 is the standard WAN prefix. Two usable addresses for a point-to-point link. A /24 on a router-to-router link wastes 252 addresses that a VLSM plan could use elsewhere.
Aggregation depends on allocation discipline. A VLSM plan that fills the parent block sequentially from the start can be summarized as a single route. A scattered plan cannot.
Verify before configuring. subnetcalc confirms network, broadcast, and host range. ip route get confirms the kernel’s selection. Manual calculation is error-prone; the tools are not.

Remember: VLSM is the design discipline that makes classless addressing practical. The parent block is a finite resource, and every subnet consumes a portion of it. Allocating largest to smallest ensures the big segments get the contiguous space they need. Aligning each subnet to its size ensures no two subnets claim the same address. Verifying with subnetcalc and ip route get ensures the plan on paper matches the kernel’s behavior. When the LFCE exam asks you to configure a system to route IP traffic dynamically, the prefixes you advertise are the output of a VLSM plan. Get the allocation right, and the routing follows.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!