LogoENEnglish

Subnetting and VLSM: Dividing Networks Efficiently

Subnetting breaks a large network into smaller, more manageable pieces, and Variable Length Subnet Masking extends this to allow each piece to be sized exactly to its actual needs rather than wasting addresses. This article walks through the subnetting process step by step with worked examples, explains how to calculate the number of usable hosts and subnets, and covers VLSM as the modern approach to efficient address allocation.

SubnettingVLSMSubnet Calculation

~5 دقیقه مطالعه · آخرین به‌روزرسانی ۱۸ شهریور ۱۴۰۵

Why Networks Get Subnetted

A single flat network, discussed earlier in this series regarding IPv4 addressing, becomes impractical as it grows: every device shares the same broadcast domain, security policies cannot be applied to different groups of devices separately, and a single large network wastes address space when only a fraction of it is actually needed in one physical location. Subnetting solves this by borrowing bits from the host portion of an address to create multiple smaller networks from one larger block.

The Subnetting Process

Subnetting works by extending the subnet mask further into what would otherwise be host bits, creating additional network bits at the cost of fewer available host addresses per subnet.

Starting network: 192.168.1.0/24 (256 addresses, 254 usable hosts)

Borrowing 2 bits for subnetting (/24 becomes /26):
New mask: 255.255.255.192
Binary:   11111111.11111111.11111111.11000000

This creates 2^2 = 4 subnets,
each with 2^6 = 64 addresses (62 usable hosts)

The core formula for subnetting: borrowing n bits creates 2^n subnets, and each resulting subnet has 2^(32-new prefix) total addresses, with 2 subtracted for the network and broadcast addresses to find the usable host count.

Working Through a Complete Subnetting Example

Task: subnet 192.168.1.0/24 into 4 equal subnets

Step 1: determine bits needed
  4 subnets requires 2^2 = 4, so borrow 2 bits
  New prefix: /24 + 2 = /26

Step 2: calculate the subnet size (block size)
  2^(32-26) = 2^6 = 64 addresses per subnet

Step 3: list the subnets by incrementing by the block size
Subnet 1: 192.168.1.0/26   (hosts: .1 - .62,  broadcast: .63)
Subnet 2: 192.168.1.64/26  (hosts: .65 - .126, broadcast: .127)
Subnet 3: 192.168.1.128/26 (hosts: .129 - .190, broadcast: .191)
Subnet 4: 192.168.1.192/26 (hosts: .193 - .254, broadcast: .255)

This "increment by block size" technique is the fastest practical method for listing subnets by hand, and it directly reflects the binary pattern created by the borrowed bits — each subnet's starting address is simply the previous one plus the block size.

The Limitation of Fixed-Length Subnetting

The example above creates four equal-sized subnets, which works well when every subnet needs roughly the same number of hosts. In practice, this is rarely true: a WAN link between two routers needs only 2 usable addresses, while a large office LAN might need 100 or more.

Wasteful fixed-size subnetting:
A point-to-point WAN link assigned a /26 subnet
(62 usable hosts) when only 2 are ever needed —
60 addresses permanently wasted on that single link

VLSM: Sizing Each Subnet to Its Actual Needs

Variable Length Subnet Masking (VLSM) solves this waste by allowing each subnet within the same address block to use a different prefix length, sized appropriately for its actual number of required hosts.

VLSM example using 192.168.1.0/24:

Requirement: Office A needs 100 hosts,
             Office B needs 50 hosts,
             a WAN link needs 2 hosts

Office A: 192.168.1.0/25    (126 usable hosts)
Office B: 192.168.1.128/26  (62 usable hosts)
WAN link: 192.168.1.192/30  (2 usable hosts)

Each subnet is sized to its actual need, rather
than forcing every subnet to the same fixed size

The standard VLSM methodology allocates subnets starting with the largest requirement first, then works down to the smallest, since this ordering makes it straightforward to find contiguous address space for each subnet without wasteful gaps or overlaps.

The Special Case of /30 and /31 for Point-to-Point Links

WAN links connecting exactly two routers are common enough to have a standard convention: a /30 subnet provides exactly 2 usable host addresses (from 4 total, minus network and broadcast), a perfect fit for a point-to-point connection.

Point-to-point link example:
192.168.1.192/30
Network:    192.168.1.192
Router A:   192.168.1.193
Router B:   192.168.1.194
Broadcast:  192.168.1.195

A /31 subnet (4 total addresses, both usable, no
broadcast address) is an even more efficient
alternative specifically permitted for point-to-point
links by RFC 3021, saving 2 additional addresses per link

Verifying Subnet Configuration on a Cisco Device

Router(config)# interface gigabitethernet 0/0
Router(config-if)# ip address 192.168.1.193 255.255.255.252
Router(config-if)# no shutdown

Router# show ip interface brief
Interface              IP-Address       Status   Protocol
GigabitEthernet0/0      192.168.1.193    up       up

The subnet mask entered in dotted-decimal form (255.255.255.252 for a /30) must match exactly what was calculated during the VLSM planning process — a mismatched mask is one of the most common configuration errors and causes devices that appear correctly cabled to be unable to communicate.

Why Subnetting Fluency Is a Core Practical Skill

Nearly every hands-on networking task — designing an address plan for a new office, troubleshooting why two devices cannot reach each other, or configuring a routing protocol's network statements — requires quickly and accurately performing the subnetting calculations covered in this article. Unlike many networking concepts that can be looked up when needed, subnetting math is expected to be done quickly and confidently, making it one of the most heavily practiced skills in Cisco certification preparation and daily network administration alike.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

ادامه

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

ادامه

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

ادامه

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

ادامه

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

ادامه

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

ادامه
مقاله‌ی قبلیمقاله‌ی بعدی