Advanced VLSM Design Scenarios

What Makes VLSM "Advanced"

Basic VLSM teaches you how to divide address space efficiently by matching subnet sizes to host counts. Advanced VLSM is about applying those mechanics to real network design problems where constraints come from multiple directions simultaneously:

• A fixed address block that must accommodate multiple sites of different sizes
• Point-to-point links that need minimal addressing
• A summarisation requirement that forces you to place subnets at specific boundaries
• Growth capacity that must be built into the design without waste

This guide works through complete enterprise design scenarios with the reasoning behind each decision.

Scenario 1: Multi-Site Enterprise Network

The Problem

Your organisation has been allocated 192.168.100.0/22 (1,024 addresses). You need to accommodate:

Total host requirement: 617 hosts + 8 point-to-point links (max 2 IPs each)

Step 1: List Requirements from Largest to Smallest

Always start with the largest requirements when allocating VLSM:

Step 2: Allocate in Descending Size Order

Starting address pool: 192.168.100.0/22 (192.168.100.0 – 192.168.103.255)

1. HQ Users /23 → 192.168.100.0/23
   Range: 192.168.100.0 – 192.168.101.255
   Usable: 192.168.100.1 – 192.168.101.254 (510 hosts)

2. Branch A Users /25 → 192.168.102.0/25
   Range: 192.168.102.0 – 192.168.102.127
   Usable: 192.168.102.1 – 192.168.102.126 (126 hosts)

3. Branch B Users /26 → 192.168.102.128/26
   Range: 192.168.102.128 – 192.168.102.191
   Usable: 192.168.102.129 – 192.168.102.190 (62 hosts)

4. HQ Servers /27 → 192.168.102.192/27
   Range: 192.168.102.192 – 192.168.102.223
   Usable: 192.168.102.193 – 192.168.102.222 (30 hosts)

5. Remote C Users /27 → 192.168.102.224/27
   Range: 192.168.102.224 – 192.168.102.255
   Usable: 192.168.102.225 – 192.168.102.254 (30 hosts)

6. Branch A Servers /28 → 192.168.103.0/28
   Range: 192.168.103.0 – 192.168.103.15
   Usable: 192.168.103.1 – 192.168.103.14 (14 hosts)

7. Branch B Servers /29 → 192.168.103.16/29
   Range: 192.168.103.16 – 192.168.103.23
   Usable: 192.168.103.17 – 192.168.103.22 (6 hosts)

8. Remote C Servers /30 → 192.168.103.24/30
   Range: 192.168.103.24 – 192.168.103.27
   Usable: 192.168.103.25 – 192.168.103.26 (2 hosts)

9–12. WAN links /30 × 4:
   WAN-1: 192.168.103.28/30  → .29, .30
   WAN-2: 192.168.103.32/30  → .33, .34
   WAN-3: 192.168.103.36/30  → .37, .38
   WAN-4: 192.168.103.40/30  → .41, .42

Remaining Space

192.168.103.44 – 192.168.103.255 = 212 addresses available for growth

This is roughly a /24 equivalent — enough for future expansion without a re-addressing project.

Verification

Total allocated: 510 + 126 + 62 + 30 + 30 + 14 + 6 + 2 + 8 = 788 host addresses Total pool: 1,022 usable addresses (1,024 minus network and broadcast for the /22) Remaining: 234 addresses free for growth

Scenario 2: Point-to-Point Links — /30 vs /31

Point-to-point links need exactly two host addresses. The traditional approach is /30 (4 addresses, 2 usable), but RFC 3021 introduced /31 for exactly this purpose.

/30 Analysis

Network:   10.0.0.0/30
Host 1:    10.0.0.1
Host 2:    10.0.0.2
Broadcast: 10.0.0.3

Waste: 50% (2 of 4 addresses are network/broadcast)

/31 Analysis (RFC 3021)

With /31, the concept of network and broadcast addresses is intentionally omitted:

10.0.0.0/31
Host 1:    10.0.0.0  ← the "network address" becomes a host address
Host 2:    10.0.0.1  ← the "broadcast address" becomes a host address

Waste: 0% (both addresses are usable)

When to Use /30 vs /31

Recommendation: Use /31 on modern equipment between routers. Use /30 if you are supporting legacy hardware or if your team is more comfortable with the familiar convention.

Allocating Point-to-Point Links with /31

Address pool for WAN links: 10.255.0.0/24

Core–Router1:  10.255.0.0/31  (10.255.0.0 and 10.255.0.1)
Core–Router2:  10.255.0.2/31  (10.255.0.2 and 10.255.0.3)
Core–Router3:  10.255.0.4/31  (10.255.0.4 and 10.255.0.5)
Router1–R1A:   10.255.0.6/31
Router2–R2A:   10.255.0.8/31
Router2–R2B:   10.255.0.10/31
...

With /31: 256 addresses in /24 → 128 point-to-point links
With /30: 256 addresses in /24 → 64 point-to-point links

The efficiency advantage of /31 doubles the number of WAN links you can support from the same address pool.

Scenario 3: Route Summarisation with VLSM

Route summarisation (also called route aggregation or supernetting) is one of the key reasons to care about subnet placement. A good VLSM design allows you to summarise many subnets into a single route advertisement, reducing routing table size and limiting the blast radius of topology changes.

The Summarisation Rule

For multiple subnets to be summarised into a single advertisement, they must: 1. Share a common bit prefix 2. Be contiguous in address space

Example: Multi-Branch Summarisation

You have 4 branch offices, each with a /24 network. You want to advertise a single summary route to the WAN instead of 4 routes.

Can these 4 subnets be summarised?

Branch 1: 10.1.0.0/24
Branch 2: 10.1.1.0/24
Branch 3: 10.1.2.0/24
Branch 4: 10.1.3.0/24

Convert to binary and find the common prefix:

10.1.0.0  = 00001010.00000001.00000000.xxxxxxxx
10.1.1.0  = 00001010.00000001.00000001.xxxxxxxx
10.1.2.0  = 00001010.00000001.00000010.xxxxxxxx
10.1.3.0  = 00001010.00000001.00000011.xxxxxxxx

Common:     00001010.00000001.000000xx.xxxxxxxx
                                    ^^— first 22 bits are common

Summary: 10.1.0.0/22 — one route instead of four.

What Breaks Summarisation

Inserting a subnet from outside the range breaks summarisation:

Branch 1: 10.1.0.0/24
Branch 2: 10.1.1.0/24
Branch 3: 10.2.0.0/24  ← different /16 block!
Branch 4: 10.1.3.0/24

Now you cannot summarise into a single prefix without including address space you do not own or do not want to advertise. You are forced to advertise either: - 4 separate /24 routes, or - An imprecise summary that covers 10.0.0.0/14 (including address space you don't own)

The lesson: Plan your address space so that sites or regions occupy contiguous blocks that can be summarised cleanly.

Designing for Summarisation

If you want to summarise 8 branch offices under one route:

Reserve: 10.2.0.0/21  (10.2.0.0 – 10.2.7.255, 8 × /24 blocks)

Branch 1:  10.2.0.0/24
Branch 2:  10.2.1.0/24
Branch 3:  10.2.2.0/24
Branch 4:  10.2.3.0/24
Branch 5:  10.2.4.0/24
Branch 6:  10.2.5.0/24
Branch 7:  10.2.6.0/24
Branch 8:  10.2.7.0/24

Summary:   10.2.0.0/21  ← single advertisement covers all 8 branches

Every branch is within the /21 block. The core network only needs to receive one route for all 8 branches.

Scenario 4: Mixed Environment — Hierarchical VLSM

Larger enterprises use hierarchical subnetting: top-level allocation per region, second-level per site, third-level per VLAN.

Address Space: 10.0.0.0/8

Layer 1 — Regional /12 allocations:

AMER (Americas):    10.0.0.0/12    (10.0.0.0 – 10.15.255.255)
EMEA (Europe/ME/AF):10.16.0.0/12  (10.16.0.0 – 10.31.255.255)
APAC (Asia Pacific):10.32.0.0/12  (10.32.0.0 – 10.47.255.255)
Reserved:           10.48.0.0/12  (growth)
Data Centres:       10.64.0.0/12  (global DCs)

Layer 2 — Site /20 allocations within AMER/12:

New York HQ:    10.0.0.0/20   (4,096 addresses)
Chicago:        10.0.16.0/20
Los Angeles:    10.0.32.0/20
Dallas:         10.0.48.0/20
Toronto:        10.0.64.0/20

Layer 3 — VLAN /24 allocations within New York /20:

NY-Corp-Users:  10.0.0.0/24
NY-Servers:     10.0.1.0/24
NY-Voice:       10.0.2.0/24
NY-Printers:    10.0.3.0/24
NY-Guest-WiFi:  10.0.4.0/24
NY-Management:  10.0.5.0/24
NY-P2P-Links:   10.0.6.0/26 (with further /30 or /31 subdivision)
NY-Reserved:    10.0.7.0/24 – 10.0.15.255/24

Summarisation at Each Layer

Advertisement to WAN from NY site router:  10.0.0.0/20
Advertisement for AMER region from core:   10.0.0.0/12
All AMER → EMEA traffic summarised to:     10.0.0.0/8 is internal; /12 specific routes only

Each layer of the hierarchy can summarise the layer below, creating clean, manageable routing tables even for very large networks.

Scenario 5: VLSM with Growth Constraints

A classic mistake in VLSM design is allocating subnets so tightly that there is no room for growth. When you later need to expand a subnet, you face re-addressing.

Bad Design: No Growth Room

10.100.0.0/24 given to site with 100 users

/25 for users:   10.100.0.0/25   (126 usable) ← at 80% utilisation already
/26 for servers: 10.100.0.128/26 (62 usable)  ← at 50% utilisation
/27 for printers:10.100.0.192/27 (30 usable)
/27 for CCTV:    10.100.0.224/27 (30 usable)

Available for growth: zero bytes — all /24 is allocated

If users grow to 150, you must re-address the user VLAN.

Better Design: Structured Reserves

10.100.0.0/23 given to site (double the space initially)

/24 for users:   10.100.0.0/24   (254 usable) ← room to grow to 254
/25 for servers: 10.100.1.0/25   (126 usable) ← growth to 126
/26 for printers:10.100.1.128/26 (62 usable)
/28 for CCTV:    10.100.1.192/28 (14 usable)
Reserve:         10.100.1.208 – 10.100.1.255 (48 free addresses)

The extra /23 costs nothing — you are not paying per IP address in a private allocation. The cost of generous allocation is zero; the cost of re-addressing is very high.

Rule of thumb: Allocate twice the address space you think you need for each subnet. For the overall site, allocate double the sum of all planned subnets.

Summary: VLSM Design Process

Follow this process for any VLSM design:

1. Enumerate all segments — List every subnet needed with host count requirements
2. Sort largest to smallest — Always allocate the largest subnets first
3. Choose prefix lengths — Round up to the next power-of-2 subnet that fits the hosts plus reserves
4. Verify boundary alignment — Confirm each subnet starts at a valid boundary for its prefix length
5. Check for summarisation — If subnets need to be summarised later, ensure they are contiguous and share a common prefix boundary
6. Document remaining space — Record what address space is reserved for growth
7. Verify no overlap — Double-check that no two subnets occupy the same address range

VLSM is a design skill, not a calculation skill. The mathematics are straightforward; the judgement lies in choosing allocations that will remain workable as the network grows over years.