IP Subnet Calculator Complete Guide: CIDR, VLSM & Network Planning

Your company just acquired a new office building. IT needs 12 separate networks for departments, guest WiFi, VoIP phones, security cameras, and IoT devices. You’re handed a single /22 network block and told to “make it work.”

You start dividing subnets manually on a whiteboard. Two hours later, you’ve created overlapping address ranges that break routing. Half your VLANs can’t communicate. The CFO’s office has no network access. Security is furious about IoT devices on the same network as payroll servers.

Your network design just failed because of subnet calculation errors.

Or maybe you’re migrating to AWS. You provision a VPC with /24 subnets across three availability zones. Six months later, you need to add container orchestration. Kubernetes requires /20 Pod networks. Your address space is exhausted. Re-architecting means downtime, migration headaches, and explaining to management why “the cloud” isn’t as elastic as promised.

Poor subnet planning cost you weeks of remediation and thousands in consulting fees.

Or perhaps you’re troubleshooting why remote offices can’t access headquarters applications. You discover someone configured 192.168.1.0/24 at both locations. Overlapping subnets cause routing nightmares. VPN tunnels establish but traffic blackholes. Users blame “the network being down” while you explain that two networks can’t use identical address spaces.

Subnet conflicts destroyed inter-site connectivity and your weekend.

The reality network engineers face: Subnetting mistakes cause 40% of network outages (Cisco CCNA study data), misconfigured subnet masks generate thousands of help desk tickets annually, and poor IPAM (IP Address Management) leads to address exhaustion forcing costly renumbering projects that can cost enterprises $50,000-500,000 depending on network size.

But here’s what separates network engineers who design scalable, maintainable networks from those constantly firefighting: systematic subnet planning using proven calculation methods, hierarchical addressing schemes following IETF standards, and automated tools that prevent human error.

This guide teaches you exactly that. You’ll learn how IPv4 subnetting works at the binary level with RFC standards, how to use CIDR notation and calculate subnet masks in seconds, how to design networks with VLSM for maximum efficiency, troubleshoot common subnetting errors systematically, plan enterprise networks and cloud VPCs with growth capacity, and master RFC 1918 private addressing, NAT, and modern SDN concepts.

By the end, you’ll design subnet hierarchies that scale for 5+ years and troubleshoot network issues faster than most engineers can open a calculator.

Quick Answer: Subnet Calculator Essentials

Don’t have time for 12,000 words? Here’s what you need to know right now:

• What subnetting is: Dividing IP address space into smaller broadcast domains for efficient allocation, security segmentation, and routing optimization
• CIDR notation: 192.168.1.0/24 where /24 = subnet mask prefix length (24 bits of network, 8 bits of hosts)
• Usable hosts formula: 2^(32-prefix) - 2 (subtract network and broadcast addresses) — e.g., /24 = 254 hosts, /30 = 2 hosts
• Best calculator: Use our IP Subnet Calculator for instant network/broadcast/host range calculations with binary visualization
• Common subnet masks: /24 (255.255.255.0) = 254 hosts, /25 (255.255.255.128) = 126 hosts, /30 (255.255.255.252) = 2 hosts (point-to-point links)
• RFC 1918 private ranges: 10.0.0.0/8 (16.7M addresses), 172.16.0.0/12 (1M addresses), 192.168.0.0/16 (65K addresses)
• VLSM optimization: Use different prefix lengths within same supernet (e.g., /24 for departments, /30 for WAN links)
• Cloud VPC sizing: AWS/Azure: /16 VPC with /24 public, /20 private subnets per availability zone for 3-5 year growth

Still here? Perfect. Let’s master IP subnetting from fundamentals to enterprise network design.

---

What is IP Subnetting?

The Problem Subnetting Solves

Imagine every device on the internet being on one giant network—18 billion devices broadcasting simultaneously. Network congestion would make the internet unusable. Subnetting solves this by creating hierarchical boundaries that contain broadcast traffic, enable efficient routing, and provide logical separation.

IP subnetting is the process of dividing a network into smaller sub-networks (subnets) by borrowing bits from the host portion of an IP address to extend the network portion. This fundamental technique, standardized in RFC 950 (Internet Standard Subnetting Procedure) in 1985, enables:

1. Efficient Address Allocation

Problem: Classful addressing (Class A/B/C) wasted massive amounts of address space. A company needing 300 addresses got a Class B (/16 = 65,534 addresses), wasting 65,234 addresses.

Solution: Subnetting with CIDR allows allocating exactly what’s needed. Need 300 addresses? Use /23 (510 hosts) instead of /16.

Real-world impact: IANA (Internet Assigned Numbers Authority) reports that CIDR-based subnetting extended IPv4’s usable life by decades, delaying IPv6 adoption pressure.

2. Broadcast Domain Reduction

Problem: Broadcasts (ARP requests, DHCP discovery, NetBIOS) reach every device on a network. Large flat networks suffer from broadcast storms consuming bandwidth and processing power.

Solution: Each subnet is a separate broadcast domain. Broadcasts don’t cross subnet boundaries (Layer 3 routers block broadcasts by design per RFC 1812).

Performance impact: Cisco recommends limiting broadcast domains to 200-500 devices. Subnetting a 2000-device network into four /23 subnets reduces broadcast traffic by 75% per segment.

3. Security Segmentation and Access Control

Problem: Without subnets, any compromised device can access all network resources. Flat networks are security nightmares.

Solution: Subnet-based VLANs with firewall rules create security zones. DMZ in 10.1.0.0/24, internal servers in 10.2.0.0/24, user workstations in 10.3.0.0/24.

Security benefit: NIST Cybersecurity Framework recommends network segmentation as Tier 1 control. Subnets enable microsegmentation, contain breaches, and enforce principle of least privilege via ACLs.

4. Routing Efficiency and Aggregation

Problem: Without subnetting, every IP requires a routing table entry. Internet backbone routers would need 4 billion entries (impossible to process).

Solution: CIDR (RFC 4632) enables route aggregation (supernetting). Summarize 10.1.0.0/24 through 10.1.255.0/24 as single 10.1.0.0/16 route entry.

Routing scale: According to BGP statistics from Hurricane Electric, the global internet routing table contains ~950,000 prefixes instead of 4 billion individual IPs thanks to CIDR aggregation.

How Subnetting Works (Binary Mechanics)

Subnetting manipulates IP addresses at the binary level. Understanding this is critical for mastery.

IPv4 Address Structure:

• 32 bits total divided into 4 octets (8 bits each)
• Written in dotted decimal: 192.168.1.100
• Binary representation: 11000000.10101000.00000001.01100100

Subnet Mask Function:

• Contiguous 1s represent network portion
• Contiguous 0s represent host portion
• Performs bitwise AND with IP to extract network address

Example Calculation:

IP Address:    192.168.1.100    = 11000000.10101000.00000001.01100100
Subnet Mask:   255.255.255.0    = 11111111.11111111.11111111.00000000 (/24)
                                   ↓ Bitwise AND operation ↓
Network Addr:  192.168.1.0      = 11000000.10101000.00000001.00000000

Key Concept: The subnet mask “masks” the network portion. Setting all host bits to 0 gives network address, setting all host bits to 1 gives broadcast address.

Network:    192.168.1.0   (host bits = 00000000)
First Host: 192.168.1.1   (host bits = 00000001)
Last Host:  192.168.1.254 (host bits = 11111110)
Broadcast:  192.168.1.255 (host bits = 11111111)

Usable Hosts: Total hosts minus network and broadcast addresses: 2^(host bits) - 2

For /24: 2^8 - 2 = 256 - 2 = 254 usable hosts

Subnet Calculation with Our Tool

Our IP Subnet Calculator automates these binary calculations, providing instant results:

Input: 10.0.1.0/24 or 10.0.1.0 + 255.255.255.0

Output:

• Network Address: 10.0.1.0
• Broadcast Address: 10.0.1.255
• First Usable IP: 10.0.1.1
• Last Usable IP: 10.0.1.254
• Usable Hosts: 254
• Subnet Mask (Decimal): 255.255.255.0
• Subnet Mask (Binary): 11111111.11111111.11111111.00000000
• CIDR Prefix: /24

Verify subnets work correctly:

• DNS Lookup - Check reverse DNS (PTR records) for subnet
• My IP Address - Determine your current subnet assignment
• HTTP Status Checker - Test inter-subnet routing

---

Understanding CIDR Notation (RFC 4632)

What is CIDR?

Classless Inter-Domain Routing (CIDR), defined in RFC 4632 and introduced in 1993, replaced wasteful classful addressing (Class A/B/C) with flexible prefix-based allocation.

The Classful Problem:

• Class A: /8 (16.7M addresses) - Only 126 organizations could get these
• Class B: /16 (65K addresses) - Exhausted by 1992
• Class C: /24 (254 addresses) - Too small for most organizations

The CIDR Solution:

• Any prefix length from /1 to /32
• Allocate exactly what’s needed: Need 1000 addresses? Use /22 (1022 hosts)
• Route aggregation: Combine multiple networks into single routing entry

CIDR Notation Format and Mathematics

Format: IP_ADDRESS/PREFIX_LENGTH

Where prefix length indicates the number of network bits (contiguous 1s in mask).

Conversion Between CIDR and Decimal Masks:

Usable Hosts Calculation Formula:

Usable Hosts = 2^(32 - prefix_length) - 2

Examples:

• /24: 2^(32-24) - 2 = 2^8 - 2 = 256 - 2 = 254 hosts
• /30: 2^(32-30) - 2 = 2^2 - 2 = 4 - 2 = 2 hosts (perfect for point-to-point links)
• /16: 2^(32-16) - 2 = 2^16 - 2 = 65,536 - 2 = 65,534 hosts

CIDR Real-World Examples with Context

Example 1: Corporate Office Network

Scenario: 500-person company headquarters

Subnet Design:

10.1.0.0/23 - Corporate Network
  Network:    10.1.0.0
  Broadcast:  10.1.1.255
  Range:      10.1.0.1 - 10.1.1.254
  Usable:     510 hosts
  Usage:      Workstations, printers, VoIP phones

Reasoning: /24 (254 hosts) too small for 500 users, /23 (510 hosts) provides headroom for growth.

Example 2: Point-to-Point WAN Link

Scenario: Router-to-router connection between offices

Subnet Design:

10.254.1.0/30 - WAN Link #1
  Network:    10.254.1.0
  Router1:    10.254.1.1
  Router2:    10.254.1.2
  Broadcast:  10.254.1.3
  Usable:     2 hosts

Reasoning: WAN links need exactly 2 addresses per RFC 3021. /30 wastes zero addresses compared to /24 (wasting 252 addresses).

Pro Tip: Modern designs use RFC 3021 unnumbered links for point-to-point, but /30 remains standard.

Example 3: Cloud VPC Design (AWS)

Scenario: Multi-tier web application in AWS

VPC Structure:

10.0.0.0/16 - Production VPC (65,534 hosts)
  ├─ 10.0.0.0/24   - Public Subnet AZ1 (254 hosts) - Load balancers, NAT gateways
  ├─ 10.0.1.0/24   - Public Subnet AZ2 (254 hosts)
  ├─ 10.0.16.0/20  - Private Subnet AZ1 (4,094 hosts) - Application servers
  ├─ 10.0.32.0/20  - Private Subnet AZ2 (4,094 hosts)
  ├─ 10.0.48.0/22  - Database Subnet AZ1 (1,022 hosts) - RDS instances
  └─ 10.0.52.0/22  - Database Subnet AZ2 (1,022 hosts)

Addressing Strategy:

• Public subnets: Small /24 (AWS reserves 5 IPs, only need space for NAT gateways, load balancers)
• Private subnets: Large /20 (4,094 hosts for auto-scaling EC2/containers)
• Database subnets: Medium /22 (RDS multi-AZ, read replicas, future growth)

Reserved Space: 10.0.64.0/18 (16,382 hosts) left for future expansion

Verification: Use AWS VPC documentation and our Subnet Calculator to validate.

CIDR Aggregation (Supernetting)

Route Aggregation combines multiple networks into single routing entry, reducing routing table size per RFC 4632 Section 3.2.

Example Aggregation:

Individual routes:

10.1.0.0/24
10.1.1.0/24
10.1.2.0/24
10.1.3.0/24

Aggregated route:

10.1.0.0/22

How to Aggregate:

1. Identify common prefix bits
2. Use shortest prefix covering all ranges
3. Verify all original networks fit within aggregate

Binary Verification:

10.1.0.0 = 00001010.00000001.00000000.00000000
10.1.1.0 = 00001010.00000001.00000001.00000000
10.1.2.0 = 00001010.00000001.00000010.00000000
10.1.3.0 = 00001010.00000001.00000011.00000000
           ^^^^^^^^^^^^^^^^^^^^^^^^ (22 bits common)
Aggregate: 10.1.0.0/22 covers 10.1.0.0 - 10.1.3.255

Routing Efficiency: 4 routing table entries reduced to 1 (75% reduction).

BGP Context: Internet backbone routers use aggressive aggregation. See Hurricane Electric BGP Toolkit for real-world prefix announcements.

---

RFC 1918 Private IP Addresses and NAT

The Private Addressing Solution

Public IPv4 exhaustion occurred in February 2011 when IANA allocated the last /8 blocks to regional internet registries. RFC 1918 (Address Allocation for Private Internets), published in 1996, defines three address ranges reserved for private networks that will never be routed on the public internet.

RFC 1918 Private Address Ranges

According to IANA’s Special-Purpose Address Registry:

1. Class A Private Range: 10.0.0.0/8

Address Range: 10.0.0.0 - 10.255.255.255

Total Addresses: 16,777,216 (2^24)

Subnet Mask: 255.0.0.0

Best For:

• Large enterprises with 10,000+ devices
• Service providers (ISP internal networks)
• Cloud VPCs (AWS, Azure, GCP default)
• Network lab environments

Common Subnetting:

10.0.0.0/16   - Site 1 (headquarters)
10.1.0.0/16   - Site 2 (regional office)
10.2.0.0/16   - Site 3 (data center)
...
10.255.0.0/16 - Site 256

Advantages:

• Maximum flexibility for hierarchical design
• Room for massive growth (16.7M addresses)
• Easy summarization and aggregation

When to Use: Any enterprise network, cloud infrastructure, multi-site organizations

2. Class B Private Range: 172.16.0.0/12

Address Range: 172.16.0.0 - 172.31.255.255

Total Addresses: 1,048,576 (2^20)

Subnet Mask: 255.240.0.0

Span: 16 Class B networks (172.16.0.0/16 through 172.31.0.0/16)

Best For:

• Medium enterprises (1,000-10,000 devices)
• Multi-site organizations needing segmentation
• Container platforms (Docker default bridge: 172.17.0.0/16)
• Organizations avoiding conflicts with common 10.0.0.0/8 usage

Common Subnetting:

172.16.0.0/16  - Site 1 headquarters
172.17.0.0/16  - Docker containers (default)
172.18.0.0/16  - Site 2 branch office
172.19.0.0/16  - DMZ networks
...
172.31.0.0/16  - Site 16

Advantages:

• Less common than 10.0.0.0/8 (fewer VPN conflicts)
• Good balance between size and manageability
• Standard for container networking

When to Use: Medium enterprises, organizations with frequent VPN connections to partners (who likely use 10.0.0.0/8), containerized environments

Important Note: Many home routers use 192.168.x.x, causing VPN/RDP conflicts. Using 172.16.0.0/12 internally avoids this.

3. Class C Private Range: 192.168.0.0/16

Address Range: 192.168.0.0 - 192.168.255.255

Total Addresses: 65,536 (2^16)

Subnet Mask: 255.255.0.0

Contains: 256 Class C networks (192.168.0.0/24 through 192.168.255.0/24)

Best For:

• Home networks (universal router default)
• Small businesses (<250 devices)
• Individual office locations
• Guest WiFi networks
• Test labs and training environments

Common Usage:

192.168.1.0/24  - Standard home/office LAN (most common)
192.168.2.0/24  - Guest network
192.168.10.0/24 - VoIP phones
192.168.20.0/24 - Security cameras
192.168.100.0/24 - IoT devices

Advantages:

• Universally recognized format
• Simple to remember and configure
• Compatible with all consumer equipment

Disadvantages:

• Limited address space (only 65K addresses total)
• High conflict probability (every home network uses this)
• VPN issues when remote and local networks overlap

When to Use: Small networks, home offices, individual branch locations, networks that will never exceed 60,000 devices

Network Address Translation (NAT)

NAT, standardized in RFC 3022, enables private RFC 1918 networks to access the internet by translating private IPs to public IPs at the network boundary.

How NAT Works

Internal Network (Private):        NAT Router:           Public Internet:
┌─────────────────┐               ┌──────────┐          ┌──────────────┐
│ 10.0.1.10:5000  │──────────────>│  Public  │────────> │ Web Server   │
│ 10.0.1.20:5001  │   Translation │  IP:     │  Single  │ 203.0.113.1  │
│ 10.0.1.30:5002  │      Table    │  Port    │   Public │              │
└─────────────────┘               └──────────┘   Address└──────────────┘
Multiple Private IPs              203.0.113.50            Sees only
on RFC 1918 range                 (Shared Public IP)      router's IP

NAT Translation Table Example:

Types of NAT

1. Static NAT (1:1 Mapping)

One private IP permanently mapped to one public IP.

Configuration Example (Cisco):

ip nat inside source static 10.0.1.100 203.0.113.50

Use Cases:

• Web servers in DMZ needing inbound access
• VPN gateways requiring consistent external IP
• Services that require specific public IP (DNS, email)

2. Dynamic NAT (Pool)

Multiple private IPs share a pool of public IPs, assigned dynamically.

Configuration Example:

ip nat pool PUBLIC_POOL 203.0.113.50 203.0.113.60 netmask 255.255.255.240
ip nat inside source list 1 pool PUBLIC_POOL

Use Cases:

• Organizations with more internal devices than public IPs
• Temporary internet access for internal resources

Limitation: Pool exhaustion when all public IPs are in use.

3. PAT/NAPT (Port Address Translation) - “Overload”

Thousands of private IPs share a single public IP using port multiplexing.

Configuration Example:

ip nat inside source list 1 interface GigabitEthernet0/0 overload

How PAT Works:

• Tracks source IP + source port combinations
• Assigns unique port for each session on public IP
• Supports ~65,000 simultaneous sessions per public IP
• Most common NAT type for home/SMB networks

Capacity Calculation:

Available ports: 65535 - 1024 (reserved) = 64,511 usable ports
Typical sessions per host: 20-50
Theoretical capacity: 64,511 ÷ 30 avg = ~2,150 concurrent hosts
Practical capacity: 500-1000 concurrent hosts (accounting for timeouts)

4. Carrier-Grade NAT (CGN/CG-NAT)

ISPs perform double NAT to conserve public IPv4 addresses further, using RFC 6598 shared address space (100.64.0.0/10).

CGN Architecture:

Home Router            ISP CGN              Public Internet
(192.168.1.0/24)   (100.64.0.0/10)    (Public IP Pool)
    │                   │                    │
    ├─ 192.168.1.1  →  100.64.1.5  →   203.0.113.X
    │  (Private NAT)   (CGN NAT)        (Public Internet)
    └─ Double NAT causes issues

CGN Problems:

• Port forwarding impossible (can’t reach customer router)
• Gaming consoles fail (NAT type “strict”)
• VoIP quality issues
• P2P applications broken
• VPN establishing difficulties

Detection: Use our My IP Address tool - if your public IP is 100.64.x.x, you’re behind CGN.

Solution: Request dedicated public IP from ISP (often costs $5-20/month extra) or use IPv6.

Special-Use IPv4 Addresses (Beyond RFC 1918)

Other reserved ranges per IANA Special-Purpose Registry:

Practical Application:

Check if your IP is private with our tool:

# Is 10.5.2.1 private? Yes (RFC 1918)
# Is 100.64.5.1 private? Yes (CGN per RFC 6598)
# Is 172.32.1.1 private? No (outside 172.16.0.0/12 range)

Verify your current IP classification: My IP Address Checker

---

Subnet Mask Calculations and Binary Operations

Understanding Subnet Masks at Binary Level

Subnet masks define the boundary between network and host portions through binary AND operations with IP addresses.

Fundamental Concept: Subnet mask contains contiguous 1s (network bits) followed by contiguous 0s (host bits).

Valid Subnet Mask Requirements:
✅ Contiguous 1s: 11111111.11111111.11111111.00000000 (/24)
❌ Non-contiguous: 11111111.11111111.11110000.11110000 (INVALID)

Binary AND Operation (How Masks Work)

The subnet mask performs bitwise AND with IP address to extract network address:

Truth Table for AND:

Practical Example:

IP Address:   192.168.10.75
Binary:       11000000.10101000.00001010.01001011

Subnet Mask:  255.255.255.0 (/24)
Binary:       11111111.11111111.11111111.00000000
              ──────────────────────────────────────
AND Result:   11000000.10101000.00001010.00000000
Network:      192.168.10.0

Host Bits:    00000000.00000000.00000000.01001011
Host ID:      0.0.0.75

Key Observations:

• Network bits (1s in mask) are preserved
• Host bits (0s in mask) are zeroed out
• Result is network address

Converting Between CIDR, Binary, and Decimal

Method 1: CIDR to Decimal Mask

Formula: Create 32 bits with prefix length 1s, remaining 0s, convert to decimal.

Example: /26

Step 1: Write 26 ones, 6 zeros
11111111.11111111.11111111.11000000

Step 2: Convert each octet to decimal
11111111 = 255
11111111 = 255
11111111 = 255
11000000 = 192 (128 + 64)

Result: 255.255.255.192

Example: /19

Step 1: Write 19 ones, 13 zeros
11111111.11111111.11100000.00000000

Step 2: Convert to decimal
11111111 = 255
11111111 = 255
11100000 = 224 (128 + 64 + 32)
00000000 = 0

Result: 255.255.224.0

Method 2: Decimal Mask to CIDR

Formula: Convert to binary, count the 1s.

Example: 255.255.248.0

Step 1: Convert each octet to binary
255 = 11111111 (8 ones)
255 = 11111111 (8 ones)
248 = 11111000 (5 ones)
0   = 00000000 (0 ones)

Step 2: Count total ones
8 + 8 + 5 + 0 = 21

Result: /21

Quick Reference: Octet Values

Binary to Decimal for Last Octet:

Memorization Trick: Powers of 2

• 128 = 2^7
• 192 = 128 + 64 = 2^7 + 2^6
• 224 = 128 + 64 + 32 = 2^7 + 2^6 + 2^5
• 240 = 128 + 64 + 32 + 16 (continue pattern)

Calculating Network Addresses

Given: IP 172.16.45.200 with mask 255.255.240.0 (/20)

Step-by-Step Calculation:

Step 1: Convert IP to binary
172.16.45.200 = 10101100.00010000.00101101.11001000

Step 2: Convert mask to binary
255.255.240.0 = 11111111.11111111.11110000.00000000

Step 3: Perform AND operation
10101100.00010000.00101101.11001000  (IP)
11111111.11111111.11110000.00000000  (Mask)
─────────────────────────────────────
10101100.00010000.00100000.00000000  (Network)

Step 4: Convert result to decimal
Network Address = 172.16.32.0

Shortcut for /20 (Third Octet Changes):

Third octet mask = 240 = 11110000

Host bits in third octet = 4 bits (16 possible values: 0, 16, 32, 48, …, 240)

Quick method: Divide third octet by 16, round down, multiply by 16

• 45 ÷ 16 = 2.8125 → round down to 2
• 2 × 16 = 32
• Network: 172.16.32.0

Calculating Broadcast Addresses

Broadcast address = Network address with all host bits set to 1.

Formula: Network address + (2^host_bits - 1)

Example: 192.168.10.0/24

Network:   192.168.10.0
Host bits: 8 (32 - 24)
Range:     2^8 = 256 addresses
Broadcast: 192.168.10.0 + 255 = 192.168.10.255

Binary Method:

Network:   192.168.10.0 = 11000000.10101000.00001010.00000000
Mask:      /24          = 11111111.11111111.11111111.00000000
Host bits: Last 8 bits

Set all host bits to 1:
Broadcast: 11000000.10101000.00001010.11111111
         = 192.168.10.255

Usable Host Range

First usable: Network address + 1
Last usable: Broadcast address - 1

Example: 10.50.0.0/22

Network:      10.50.0.0
First host:   10.50.0.1
...
Last host:    10.50.3.254
Broadcast:    10.50.3.255

Usable hosts: 2^(32-22) - 2 = 2^10 - 2 = 1024 - 2 = 1,022 hosts

Wildcard Masks (For ACLs and Route Filters)

Wildcard mask is the binary inverse of subnet mask, used in Cisco ACLs, OSPF, EIGRP configurations.

Conversion: Subnet mask → Wildcard mask

Subtract each octet from 255

Subnet mask:  255.255.255.0
Wildcard:     0.0.0.255

Subnet mask:  255.255.252.0
Wildcard:     0.0.3.255

Binary Explanation:

Subnet (/24):     11111111.11111111.11111111.00000000
Wildcard (/24):   00000000.00000000.00000000.11111111
                  (Binary NOT operation)

Cisco ACL Example:

! Permit traffic from 192.168.10.0/24
access-list 10 permit 192.168.10.0 0.0.0.255

! Permit traffic from 172.16.0.0/22
access-list 20 permit 172.16.0.0 0.0.3.255

Common Wildcard Patterns:

Use Our Calculator:

Our Subnet Calculator displays wildcard masks automatically for ACL configuration.

Verify network reachability: HTTP Status Checker

---

Variable Length Subnet Masking (VLSM)

What is VLSM and Why It Matters

Variable Length Subnet Masking (VLSM), enabled by RFC 1878 and supported by classless routing protocols (OSPF RFC 2328, BGP RFC 4271, EIGRP), allows applying different subnet masks within the same network, maximizing address utilization.

The Problem VLSM Solves:

Without VLSM (classful addressing):

Company needs:
- 3 departments with 60 hosts each = 180 hosts
- 4 WAN links with 2 hosts each = 8 hosts
Total: 188 hosts needed

Classful solution:
Assign /24 (254 hosts) to each department = 762 addresses
Assign /24 to each WAN link = 1,016 addresses
Total waste: 1,590 addresses wasted (84% waste!)

With VLSM (optimal allocation):

Departments: 3 × /26 (62 hosts) = 186 usable hosts
WAN links: 4 × /30 (2 hosts) = 8 usable hosts
Total addresses used: ~240
Waste: Only 52 addresses (18% waste)

VLSM Design Methodology

Step-by-Step VLSM Planning:

1. List all subnet requirements (ordered largest to smallest)
2. Assign largest subnets first (prevents fragmentation)
3. Calculate each subnet boundary (network, broadcast, range)
4. Verify no overlaps (critical!)
5. Reserve address space for future growth

Real-World VLSM Example: Multi-Site Enterprise

Scenario: Company with headquarters, 2 branch offices, and 3 WAN links

Requirements:

• HQ LAN: 500 users
• Branch 1: 100 users
• Branch 2: 50 users
• WAN Link 1: 2 routers (HQ to Branch 1)
• WAN Link 2: 2 routers (HQ to Branch 2)
• WAN Link 3: 2 routers (Branch 1 to Branch 2)

Allocated Block: 10.1.0.0/16

VLSM Design (Largest First):

Step 1: HQ LAN (500 users)

Need: 500 hosts → Requires: /23 (510 hosts)

Network:      10.1.0.0/23
Range:        10.1.0.0 - 10.1.1.255
First host:   10.1.0.1
Last host:    10.1.1.254
Broadcast:    10.1.1.255
Usable:       510 hosts
Assignment:   HQ workstations, printers, APs

Step 2: Branch 1 LAN (100 users)

Need: 100 hosts → Requires: /25 (126 hosts)

Network:      10.1.2.0/25
Range:        10.1.2.0 - 10.1.2.127
First host:   10.1.2.1
Last host:    10.1.2.126
Broadcast:    10.1.2.127
Usable:       126 hosts
Assignment:   Branch 1 users

Step 3: Branch 2 LAN (50 users)

Need: 50 hosts → Requires: /26 (62 hosts)

Network:      10.1.2.128/26
Range:        10.1.2.128 - 10.1.2.191
First host:   10.1.2.129
Last host:    10.1.2.190
Broadcast:    10.1.2.191
Usable:       62 hosts
Assignment:   Branch 2 users

Step 4: WAN Links (3 links × 2 hosts)

Each WAN link: /30 (2 usable hosts)

WAN Link 1 (HQ ↔ Branch 1):

Network:      10.1.2.192/30
Router 1:     10.1.2.193 (HQ router interface)
Router 2:     10.1.2.194 (Branch 1 router interface)
Broadcast:    10.1.2.195

WAN Link 2 (HQ ↔ Branch 2):

Network:      10.1.2.196/30
Router 1:     10.1.2.197
Router 2:     10.1.2.198
Broadcast:    10.1.2.199

WAN Link 3 (Branch 1 ↔ Branch 2):

Network:      10.1.2.200/30
Router 1:     10.1.2.201
Router 2:     10.1.2.202
Broadcast:    10.1.2.203

Address Space Summary:

• Total used: 10.1.0.0 - 10.1.2.203 (only 715 addresses)
• Remaining: 10.1.2.204 - 10.1.255.255 (65,020 addresses for future growth)
• Efficiency: 99% of /16 still available

VLSM for Cloud VPCs (AWS Example)

Scenario: AWS VPC for 3-tier web application with auto-scaling

VPC Block: 10.0.0.0/16 (65,536 addresses)

Tier Requirements:

• Public tier: Load balancers, NAT gateways (small, ~20 devices per AZ)
• Application tier: Web/app servers (large, up to 4,000 instances per AZ for auto-scaling)
• Database tier: RDS instances (medium, ~500 per AZ with read replicas)
• 3 Availability Zones for high availability

VLSM Allocation Strategy:

Public Subnets (Small):
10.0.0.0/24   - Public AZ1 (254 hosts) - ALB, NAT Gateway
10.0.1.0/24   - Public AZ2 (254 hosts)
10.0.2.0/24   - Public AZ3 (254 hosts)

Application Subnets (Large):
10.0.16.0/20  - Private App AZ1 (4,094 hosts) - EC2, ECS, Lambda ENIs
10.0.32.0/20  - Private App AZ2 (4,094 hosts)
10.0.48.0/20  - Private App AZ3 (4,094 hosts)

Database Subnets (Medium):
10.0.64.0/22  - Private DB AZ1 (1,022 hosts) - RDS multi-AZ
10.0.68.0/22  - Private DB AZ2 (1,022 hosts)
10.0.72.0/22  - Private DB AZ3 (1,022 hosts)

Reserved for Future:
10.0.76.0 - 10.0.255.255 (~46,000 addresses)

AWS Considerations:

• AWS reserves 5 IPs per subnet (network, VPC router +1/+2/+3, broadcast)
• Actual usable in /24: 254 - 5 = 249 hosts
• Leave /18 or /17 blocks for future Kubernetes Pod networks, Lambda scaling, new tiers

Verification: AWS VPC Subnet Calculator

VLSM Route Summarization

Route Summarization combines multiple VLSM subnets into single routing table entry.

Example: Summarizing Branch Office Subnets

Individual routes:

10.1.2.0/25    - Branch 1 LAN
10.1.2.128/26  - Branch 2 LAN
10.1.2.192/30  - WAN Link 1
10.1.2.196/30  - WAN Link 2
10.1.2.200/30  - WAN Link 3

Summary route:

10.1.2.0/24

How to Calculate Summary:

1. Convert all network addresses to binary
2. Find common prefix bits
3. Use shortest prefix covering all ranges

Binary Analysis:

10.1.2.0   = 00001010.00000001.00000010.00000000
10.1.2.128 = 00001010.00000001.00000010.10000000
10.1.2.192 = 00001010.00000001.00000010.11000000
10.1.2.196 = 00001010.00000001.00000010.11000100
10.1.2.200 = 00001010.00000001.00000010.11001000
             ^^^^^^^^^^^^^^^^^^^^^^^^ (24 bits common)

Summary: 10.1.2.0/24 covers 10.1.2.0 - 10.1.2.255

Advertising Summary:

• Headquarters router advertises only 10.1.2.0/24 to internet
• Hides internal VLSM structure from external networks
• Reduces routing table entries from 5 to 1

Routing Protocol Configuration (OSPF):

router ospf 1
 area 0 range 10.1.2.0 255.255.255.0

Verification:

show ip route ospf
show ip protocols

Common VLSM Mistakes and How to Avoid Them

Mistake 1: Overlapping Subnets

Error:

Subnet 1: 10.1.0.0/23  (10.1.0.0 - 10.1.1.255)
Subnet 2: 10.1.1.0/24  (10.1.1.0 - 10.1.1.255) ← OVERLAPS with Subnet 1!

Result: Routing conflicts, unreachable hosts, asymmetric routing

Prevention: Always check previous subnet’s broadcast address before assigning next subnet

Mistake 2: Allocating Small Subnets First

Wrong Order:

Step 1: Assign /30 for WAN link (10.0.0.0/30)
Step 2: Assign /23 for 500 hosts (10.0.0.4/23) ← Can't fit!

Correct Order (Largest First):

Step 1: Assign /23 for 500 hosts (10.0.0.0/23)
Step 2: Assign /30 for WAN link (10.0.2.0/30)

Rule: Always allocate in descending size order

Mistake 3: Not Planning for Growth

Insufficient Planning:

Current need: 200 hosts
Allocation: /24 (254 hosts)
Year 2: Need 300 hosts → Must renumber entire network

Better Approach:

Current need: 200 hosts
Allocation: /23 (510 hosts) - 2x growth capacity
Year 2: Growth to 400 hosts still fits

Recommendation: Allocate for 200-300% of current requirements or 5-year growth projection

VLSM Calculator Workflow

Our Subnet Calculator simplifies VLSM planning:

1. Start with largest subnet: Calculate /23 for 500 hosts
2. Note broadcast address: 10.1.1.255
3. Next subnet starts: 10.1.2.0
4. Calculate next: /25 for 100 hosts
5. Repeat until all subnets allocated

After design:

• Verify DNS: DNS Lookup for reverse zones
• Test routing: HTTP Status Checker
• Confirm gateways: My IP tool

---

Enterprise Subnet Planning and Best Practices

Hierarchical Network Design Principles

Cisco Three-Tier Model:

┌─────────────────────────────────────────────┐
│         Core Layer (10.0.0.0/8)             │
│  Backbone: /30 point-to-point links         │
│  High-speed switching, minimal processing   │
└───────────────┬────────────────────────────┘
                │
      ┌─────────┴──────────┐
      │                    │
┌─────▼──────┐      ┌─────▼──────┐
│Distribution │      │Distribution │
│Layer        │      │Layer        │
│Site-level   │      │Site-level   │
│/16 blocks   │      │/16 blocks   │
└──────┬──────┘      └──────┬──────┘
       │                    │
   ┌───┴────┬───┬───┐      │
   │        │   │   │      │
┌──▼──┐  ┌─▼─┐ │   │   ┌──▼──┐
│Access│  │   │ │   │   │Access│
│Layer │  │   │ │   │   │Layer │
│/24s  │  │   │ │   │   │/24s  │
└──────┘  └───┘ └───┘   └──────┘
User VLANs, Servers, IoT

Address Hierarchy Example:

10.0.0.0/8 - Enterprise supernet
  ├─ 10.0.0.0/16 - Headquarters (Site 1)
  │   ├─ 10.0.1.0/24 - Corporate LAN VLAN 10
  │   ├─ 10.0.2.0/24 - Guest WiFi VLAN 20
  │   ├─ 10.0.10.0/24 - Servers VLAN 100
  │   ├─ 10.0.20.0/24 - VoIP Phones VLAN 200
  │   └─ 10.0.30.0/24 - Security Cameras VLAN 300
  │
  ├─ 10.1.0.0/16 - Regional Office (Site 2)
  │   ├─ 10.1.1.0/24 - Office LAN VLAN 10
  │   ├─ 10.1.2.0/24 - Guest WiFi VLAN 20
  │   └─ 10.1.10.0/24 - Local Servers VLAN 100
  │
  ├─ 10.2.0.0/16 - Data Center (Site 3)
  │   ├─ 10.2.1.0/22 - Web Tier (1,022 hosts)
  │   ├─ 10.2.5.0/22 - App Tier (1,022 hosts)
  │   ├─ 10.2.9.0/24 - DB Tier (254 hosts)
  │   └─ 10.2.10.0/24 - Management Network
  │
  └─ 10.254.0.0/16 - WAN Infrastructure
      ├─ 10.254.0.0/30 - Link: HQ to Site 2
      ├─ 10.254.0.4/30 - Link: HQ to Site 3
      └─ 10.254.0.8/30 - Link: Site 2 to Site 3

Advantages:

• Easy summarization: 10.0.0.0/16 covers entire HQ site
• Logical organization: Site number in second octet
• Scalability: 256 sites possible (10.0.0.0/16 through 10.255.0.0/16)
• Clear ownership: Each site team manages their /16 block

IPAM (IP Address Management) Implementation

Manual tracking fails at scale. Implement IPAM tools for enterprise networks:

Popular IPAM Solutions

1. NetBox (Open Source)

• Features: IP/VLAN/rack management, circuit tracking, device inventory
• Integration: API-driven, integrates with Ansible, Terraform
• Best for: Large enterprises, data centers, service providers
• Cost: Free (open source)

2. phpIPAM (Open Source)

• Features: Subnet calculator, VLAN management, device integration
• Integration: DNS/DHCP integration, REST API
• Best for: SMB to mid-size enterprises
• Cost: Free

3. Infoblox (Commercial)

• Features: IPAM + DNS + DHCP (DDI), security, automation
• Integration: VMware, AWS, Azure, Kubernetes
• Best for: Large enterprises requiring support
• Cost: $$$$ (enterprise pricing)

4. SolarWinds IPAM

• Features: Windows-based, Active Directory integration
• Best for: Windows-centric environments
• Cost: $$$ (moderate)

IPAM Best Practices

1. Documentation Standards:

Create subnet inventory with:

• Network/CIDR: 10.1.5.0/24
• VLAN ID: 105
• Location: HQ Building 2 Floor 3
• Purpose: Engineering Department
• Gateway: 10.1.5.1 (Cisco 9300 Switch)
• DHCP Range: 10.1.5.100 - 10.1.5.200
• Static Range: 10.1.5.201 - 10.1.5.254 (servers, printers)
• DNS Zone: eng.company.local
• Provisioned Date: 2024-01-15
• Owner: IT Manager John Smith

2. Naming Conventions:

Hostname:  <location><device_type><number>
Example:   HQ-SW-ACC-01 (Headquarters Switch Access 01)

VLAN:      <site_code>_<function>_<id>
Example:   HQ_CORP_10 (Headquarters Corporate VLAN 10)

Subnet:    Embedded in addressing hierarchy
Example:   10.<site>.<function>.<host>

3. Change Management:

Implement approval workflow:

• Subnet requests via ticketing system
• IP Address allocation logged
• Changes reviewed before implementation
• Automated conflict detection
• Rollback procedures documented

Network Segmentation for Security

Zero Trust Architecture requires subnet-based security zones per NIST SP 800-207.

Segmentation Strategy

DMZ (Demilitarized Zone):

10.10.0.0/24 - DMZ Subnet
Purpose: Public-facing servers
Devices: Web servers, reverse proxies, mail gateways
Security: Firewall rules allow inbound 80/443 only
Monitoring: IDS/IPS inline, full packet capture

Internal Network Tiers:

10.20.0.0/16 - Internal Zone
  ├─ 10.20.1.0/24 - Domain Controllers (highly restricted)
  ├─ 10.20.10.0/23 - Application Servers
  ├─ 10.20.20.0/22 - Database Servers (no direct internet)
  └─ 10.20.50.0/24 - Management Network (jump boxes)

User Networks:

10.30.0.0/16 - User Zone
  ├─ 10.30.1.0/22 - Corporate Users (4,094 hosts)
  ├─ 10.30.10.0/24 - Executives (additional restrictions)
  ├─ 10.30.20.0/23 - Contractors (limited access)
  └─ 10.30.100.0/24 - Guest WiFi (internet-only)

IoT and OT Networks:

10.40.0.0/16 - IoT/OT Zone
  ├─ 10.40.1.0/24 - IP Cameras (VLAN 401)
  ├─ 10.40.2.0/24 - Door Access Systems (VLAN 402)
  ├─ 10.40.3.0/24 - HVAC Controllers (VLAN 403)
  └─ 10.40.10.0/24 - Building Management (VLAN 410)

Firewall Rules (Example ACL):

! DMZ to Internal - Deny by default
access-list DMZ-IN deny ip any any

! Internal to DMZ - Allow specific services
access-list INT-DMZ permit tcp 10.20.0.0 0.0.255.255 10.10.0.0 0.0.0.255 eq 443

! Users to Internal - Application-specific
access-list USER-INT permit tcp 10.30.0.0 0.0.255.255 10.20.20.0 0.0.3.255 eq 1433

! IoT to Internet - Deny
access-list IOT-OUT deny ip 10.40.0.0 0.0.255.255 any

Verify firewall effectiveness: HTTP Status Checker

Cloud VPC Design Patterns

AWS VPC Multi-Tier Pattern

Production VPC Structure:

10.0.0.0/16 - Production VPC
├─ Public Subnets (Internet Gateway attached):
│  ├─ 10.0.0.0/24 AZ-A (ALB, NAT Gateway, Bastion)
│  ├─ 10.0.1.0/24 AZ-B
│  └─ 10.0.2.0/24 AZ-C
│
├─ Private Application Subnets:
│  ├─ 10.0.16.0/20 AZ-A (EC2, ECS tasks, Lambda ENIs)
│  ├─ 10.0.32.0/20 AZ-B
│  └─ 10.0.48.0/20 AZ-C
│
├─ Private Database Subnets:
│  ├─ 10.0.64.0/22 AZ-A (RDS, ElastiCache, Redshift)
│  ├─ 10.0.68.0/22 AZ-B
│  └─ 10.0.72.0/22 AZ-C
│
└─ Reserved:
   └─ 10.0.128.0/17 - Future (EKS, additional tiers)

AWS-Specific Considerations:

• 5 IPs reserved per subnet: Network + Router + DNS + Future + Broadcast
• VPC Peering: Non-overlapping CIDRs required
• Transit Gateway: Supports 5 CIDR blocks per VPC attachment
• EKS Pod Networks: Requires secondary CIDR or subnet (typically /17 or /18 for Pods)

Interconnectivity:

Production VPC (10.0.0.0/16)
     ├─ VPC Peering ──> Shared Services VPC (10.10.0.0/16)
     ├─ Transit GW ───> On-Prem Network (192.168.0.0/16)
     └─ VPN ──────────> Remote Offices (172.16.0.0/12)

Validation: AWS VPC Calculator

Azure VNet Hub-and-Spoke Pattern

Hub VNet (Shared Services):

10.100.0.0/16 - Hub VNet
├─ 10.100.0.0/24 - Azure Firewall Subnet (must be named "AzureFirewallSubnet")
├─ 10.100.1.0/27 - Azure Gateway Subnet (VPN/ExpressRoute)
├─ 10.100.2.0/24 - Azure Bastion
├─ 10.100.10.0/24 - Shared AD Domain Controllers
└─ 10.100.20.0/24 - Shared DNS, NTP, Monitoring

Spoke VNets (Workloads):

10.110.0.0/16 - Production Spoke
10.120.0.0/16 - Staging Spoke
10.130.0.0/16 - Development Spoke

Azure-Specific:

• Application Gateway: Requires /27 minimum (32 IPs)
• Azure Firewall: Requires /26 minimum (64 IPs)
• VNet Peering: Transitive routing requires Azure Firewall or NVA

Check connectivity: DNS Lookup for Azure private DNS zones

Google Cloud VPC (Global VPC Model)

GCP Unique Approach: Single VPC spans all regions, subnets are regional

global-prod-vpc (10.0.0.0/8)
├─ us-east1-public-subnet:    10.1.0.0/24 (Region: us-east1)
├─ us-east1-private-subnet:   10.1.16.0/20
├─ europe-west1-public:       10.2.0.0/24 (Region: europe-west1)
├─ europe-west1-private:      10.2.16.0/20
└─ asia-east1-private:        10.3.16.0/20 (Region: asia-east1)

GKE Considerations:

10.4.0.0/14 - GKE Cluster CIDR (Nodes)
  ├─ 10.4.0.0/16 - Node Subnet
  ├─ 10.100.0.0/16 - Pod Secondary Range
  └─ 10.101.0.0/20 - Service Secondary Range

GCP Best Practices:

• Allocate /16 per region for flexibility
• Reserve /14 blocks for GKE (large Pod IP requirements)
• Use VPC Peering for multi-VPC architectures

---

This post is Part 1 of our comprehensive subnet guide. Check back soon for Part 2 covering IPv6 subnetting, advanced troubleshooting, SDN overlays, automation scripts, and complete FAQ section.

Related Tools:

• IP Subnet Calculator - Calculate network addresses, masks, and host ranges
• DNS Lookup Tool - Verify DNS zones and PTR records for subnets
• My IP Address - Determine your current network assignment
• HTTP Status Checker - Test inter-subnet routing and connectivity

External Standards and Documentation:

• RFC 950: Internet Standard Subnetting Procedure
• RFC 4632: Classless Inter-Domain Routing (CIDR)
• RFC 1918: Private IP Address Allocation
• RFC 1878: Variable Length Subnet Table
• RFC 3022: Traditional NAT
• RFC 6598: Carrier-Grade NAT (CGN)
• IANA IPv4 Address Space Registry
• Cisco Network Design Guide

---

Master subnet planning for scalable networks. Calculate your subnets now: IP Subnet Calculator