BLOG POSTS

MangoHost Blog / Understanding IP Addresses, Subnets, and CIDR Notation for Networking

Understanding IP Addresses, Subnets, and CIDR Notation for Networking

Alright, so you’ve decided to dive into the wonderful world of server management, and suddenly everyone’s throwing around terms like “subnet masks,” “CIDR blocks,” and “network ranges” like they’re speaking some ancient networking dialect. Don’t panic – this stuff is actually pretty straightforward once you get the hang of it. Understanding IP addresses, subnets, and CIDR notation isn’t just networking theory; it’s the foundation that’ll save you from headaches when you’re setting up firewalls, configuring load balancers, or trying to figure out why your servers can’t talk to each other. Whether you’re spinning up your first VPS or managing a fleet of dedicated servers, this knowledge will make your life infinitely easier and help you avoid those “why isn’t this working?” moments at 2 AM.

How IP Addresses and Subnets Actually Work

Let’s start with the basics. An IP address is essentially your server’s postal address on the internet. But unlike your home address, IP addresses follow a very specific mathematical structure that makes routing and organization possible.

An IPv4 address consists of 32 bits, typically written as four decimal numbers separated by dots (like 192.168.1.100). Each of those numbers represents 8 bits (an octet), and can range from 0 to 255. Here’s where it gets interesting – not all IP addresses are created equal.

**Private vs Public IP Ranges:**
• **Private ranges** (RFC 1918): 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, 192.168.0.0-192.168.255.255
• **Public ranges**: Everything else (minus some special-use addresses)
• **Loopback**: 127.0.0.0/8 (your local machine)
• **Link-local**: 169.254.0.0/16 (auto-assigned when DHCP fails)

Now, subnets are where things get practical. A subnet is basically a way to slice up a larger network into smaller, manageable chunks. Think of it like dividing a city into neighborhoods – each subnet can have its own rules, security policies, and routing behavior.

The subnet mask determines which part of an IP address identifies the network and which part identifies the host. A common subnet mask like 255.255.255.0 means the first three octets identify the network, and the last octet identifies individual hosts within that network.

**CIDR Notation – The Shorthand That Rules Them All:**

CIDR (Classless Inter-Domain Routing) notation is just a compact way to express network ranges. Instead of writing “192.168.1.0 with subnet mask 255.255.255.0,” you write “192.168.1.0/24.” That “/24” means the first 24 bits are the network portion.

# Common CIDR blocks and their meanings:
/8  = 255.0.0.0     = 16,777,214 hosts
/16 = 255.255.0.0   = 65,534 hosts  
/24 = 255.255.255.0 = 254 hosts
/32 = 255.255.255.255 = 1 host (single IP)

Here’s a fun fact: AWS uses CIDR blocks extensively. When you create a VPC, you might specify something like 10.0.0.0/16, giving you 65,534 possible IP addresses to work with. Then you can create smaller subnets within that range, like 10.0.1.0/24 for your web servers and 10.0.2.0/24 for your database servers.

Step-by-Step Network Configuration

Let’s get our hands dirty with some practical examples. I’ll walk you through setting up networking on a typical Linux server, because let’s be honest – that’s probably what you’re running.

**Step 1: Check Your Current Network Configuration**

# See all network interfaces
ip addr show

# Check routing table
ip route show

# Display network interface statistics
ip -s link show

# Alternative using older tools (still works everywhere)
ifconfig -a
route -n

**Step 2: Understanding Your Server’s Network Setup**

# Check which networks your server can reach directly
ip route show | grep -E "^[0-9]"

# See what your default gateway is
ip route show default

# Test connectivity to different subnets
ping -c 3 8.8.8.8    # Public internet
ping -c 3 10.0.0.1   # Private network gateway

**Step 3: Configuring Static IP Addresses**

For modern systems using netplan (Ubuntu 18.04+):

# Edit /etc/netplan/01-netcfg.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

# Apply the configuration
sudo netplan apply

For systems using traditional networking (CentOS, older Ubuntu):

# Edit /etc/sysconfig/network-scripts/ifcfg-eth0 (CentOS)
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.1.100
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=8.8.8.8
DNS2=8.8.4.4
ONBOOT=yes

# Restart networking
sudo systemctl restart network

**Step 4: Setting Up Multiple Subnets**

Here’s where things get interesting. Let’s say you want to set up multiple network interfaces for different purposes:

# Add a secondary IP to existing interface
sudo ip addr add 10.0.1.100/24 dev eth0

# Add routing for the new subnet
sudo ip route add 10.0.1.0/24 dev eth0

# Make it permanent by adding to your network config
# This creates a virtual interface eth0:1
sudo ip link add link eth0 name eth0:1 type macvlan mode bridge
sudo ip addr add 10.0.1.100/24 dev eth0:1
sudo ip link set eth0:1 up

**Step 5: Firewall Configuration with Subnets**

This is where understanding CIDR really pays off:

# Allow SSH from your management subnet only
sudo ufw allow from 10.0.0.0/24 to any port 22

# Allow HTTP/HTTPS from anywhere
sudo ufw allow 80
sudo ufw allow 443

# Allow MySQL only from application servers subnet
sudo ufw allow from 192.168.100.0/24 to any port 3306

# Block a problematic subnet
sudo ufw deny from 192.168.50.0/24

# Using iptables directly (more powerful)
sudo iptables -A INPUT -s 10.0.1.0/24 -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -s 192.168.0.0/16 -p tcp --dport 3306 -j ACCEPT

Real-World Examples and Use Cases

Let me share some scenarios you’ll actually encounter when managing servers, along with both the right way and the wrong way to handle them.

**Scenario 1: Multi-Tier Application Architecture**

✅ **The Right Way:**

# Web servers subnet: 10.0.1.0/24
# App servers subnet: 10.0.2.0/24  
# Database subnet: 10.0.3.0/24
# Management subnet: 10.0.10.0/24

# Web servers can talk to app servers
iptables -A FORWARD -s 10.0.1.0/24 -d 10.0.2.0/24 -j ACCEPT

# App servers can talk to databases
iptables -A FORWARD -s 10.0.2.0/24 -d 10.0.3.0/24 -j ACCEPT

# Management subnet can reach everything
iptables -A INPUT -s 10.0.10.0/24 -j ACCEPT

❌ **The Wrong Way:**
Putting everything in one big flat network (10.0.0.0/16) with no segmentation. Sure, it’s easier initially, but good luck troubleshooting when something goes wrong, or implementing security policies later.

**Scenario 2: Load Balancer Configuration**

Here’s a practical example using HAProxy with multiple backend subnets:

# /etc/haproxy/haproxy.cfg
frontend web_frontend
    bind *:80
    # Allow connections from CDN subnets
    acl cdn_networks src 185.199.108.0/22 140.82.112.0/20
    acl internal_networks src 10.0.0.0/8 192.168.0.0/16
    
    http-request deny unless cdn_networks or internal_networks
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 10.0.1.10:8080 check
    server web2 10.0.1.11:8080 check
    server web3 10.0.1.12:8080 check

**Scenario 3: Docker Networking (Because You Know You’re Using It)**

# Create custom networks for different services
docker network create --driver bridge --subnet=172.20.0.0/16 app-network
docker network create --driver bridge --subnet=172.21.0.0/16 db-network

# Run containers with specific IP addresses
docker run -d --name web1 --network app-network --ip 172.20.0.10 nginx
docker run -d --name db1 --network db-network --ip 172.21.0.10 mysql:8.0

# Connect web container to database network (multi-homed)
docker network connect db-network web1

**Performance and Scalability Comparison:**

| Network Size | CIDR | Usable IPs | Best For | Management Complexity |
|————–|——|————|———-|———————|
| /30 | x.x.x.x/30 | 2 | Point-to-point links | Low |
| /29 | x.x.x.x/29 | 6 | Small server clusters | Low |
| /24 | x.x.x.x/24 | 254 | Department/service networks | Medium |
| /16 | x.x.x.x/16 | 65,534 | Large corporate networks | High |
| /8 | x.x.x.x/8 | 16,777,214 | ISP/cloud provider networks | Very High |

**Automation and Scripting Opportunities:**

Understanding networking opens up tons of automation possibilities. Here are some scripts I use regularly:

#!/bin/bash
# Automatic subnet scanner
scan_subnet() {
    local subnet=$1
    echo "Scanning $subnet..."
    
    nmap -sn $subnet | grep -E "Nmap scan report|MAC Address" | \
    while read line; do
        if [[ $line == *"Nmap scan report"* ]]; then
            ip=$(echo $line | awk '{print $5}')
            echo -n "$ip "
        elif [[ $line == *"MAC Address"* ]]; then
            mac=$(echo $line | awk '{print $3}')
            vendor=$(echo $line | cut -d'(' -f2 | cut -d')' -f1)
            echo "- $mac ($vendor)"
        fi
    done
}

# Usage
scan_subnet "192.168.1.0/24"

#!/bin/bash
# Automatic firewall rule generator for new subnets
generate_firewall_rules() {
    local web_subnet="10.0.1.0/24"
    local app_subnet="10.0.2.0/24" 
    local db_subnet="10.0.3.0/24"
    
    echo "# Generated firewall rules"
    echo "iptables -A INPUT -s $web_subnet -p tcp --dport 80 -j ACCEPT"
    echo "iptables -A INPUT -s $app_subnet -p tcp --dport 8080 -j ACCEPT"
    echo "iptables -A INPUT -s $db_subnet -p tcp --dport 3306 -m state --state NEW -j ACCEPT"
}

**Useful Tools You Should Know About:**

• **ipcalc** – IP calculator that’s a lifesaver for subnet planning
• **nmap** – Network discovery and security auditing
• **netstat/ss** – Network connection monitoring
• **tcpdump/wireshark** – Packet capture and analysis
• **iperf3** – Network performance testing between subnets

# Install essential networking tools
sudo apt install ipcalc nmap tcpdump iperf3 net-tools

# Quick subnet calculation
ipcalc 192.168.1.0/24

# Test network performance between subnets
# On server 1 (10.0.1.10):
iperf3 -s

# On server 2 (10.0.2.20):
iperf3 -c 10.0.1.10 -t 30

Interesting fact: Netflix uses a massive /8 network (38.0.0.0/8) for their CDN infrastructure. That’s over 16 million IP addresses! They need this scale because they have servers in thousands of locations worldwide, and proper IP management is crucial for their routing and performance optimization.

Advanced Integration and Automation

Here’s where things get really fun. Once you understand networking fundamentals, you can integrate this knowledge with configuration management tools, monitoring systems, and cloud automation.

**Terraform Network Automation:**

# terraform/networking.tf
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "main-vpc"
  }
}

resource "aws_subnet" "web" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "web-subnet-${count.index + 1}"
    Type = "web"
  }
}

resource "aws_subnet" "database" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "db-subnet-${count.index + 1}"
    Type = "database"
  }
}

**Ansible Network Configuration:**

# ansible/network-setup.yml
---
- name: Configure server networking
  hosts: all
  become: yes
  vars:
    web_subnet: "10.0.1.0/24"
    app_subnet: "10.0.2.0/24"
    db_subnet: "10.0.3.0/24"
  
  tasks:
    - name: Configure firewall for web servers
      ufw:
        rule: allow
        src: "{{ web_subnet }}"
        port: "80,443"
      when: "'web' in group_names"
    
    - name: Configure firewall for database servers
      ufw:
        rule: allow
        src: "{{ app_subnet }}"
        port: "3306"
      when: "'database' in group_names"
    
    - name: Set up network monitoring
      template:
        src: network-monitor.sh.j2
        dest: /usr/local/bin/network-monitor.sh
        mode: '0755'

**Monitoring Network Performance Across Subnets:**

#!/bin/bash
# network-performance-monitor.sh
SUBNETS=("10.0.1.0/24" "10.0.2.0/24" "10.0.3.0/24")
LOGFILE="/var/log/network-performance.log"

for subnet in "${SUBNETS[@]}"; do
    # Get gateway IP for each subnet
    gateway=$(echo $subnet | sed 's/0\/24/1/')
    
    # Test latency
    latency=$(ping -c 5 $gateway | tail -1 | awk '{print $4}' | cut -d '/' -f 2)
    
    # Test bandwidth (requires iperf3 server running on gateway)
    bandwidth=$(iperf3 -c $gateway -t 5 -J | jq -r '.end.sum_received.bits_per_second')
    
    echo "$(date): Subnet $subnet - Latency: ${latency}ms, Bandwidth: ${bandwidth}bps" >> $LOGFILE
done

One thing that’s often overlooked: **IPv6 is becoming increasingly important**. While most of this article focuses on IPv4, IPv6 uses a completely different addressing scheme (/64 subnets are standard, giving you 18 quintillion addresses per subnet). Many hosting providers now offer IPv6 by default, and understanding how it works alongside IPv4 will save you headaches down the road.

# IPv6 examples
# Link-local address (like 169.254.x.x in IPv4)
fe80::1/64

# Global unicast address
2001:db8:85a3::8a2e:370:7334/64

# Configure IPv6 on Linux
sudo ip -6 addr add 2001:db8:85a3::100/64 dev eth0
sudo ip -6 route add default via 2001:db8:85a3::1

Troubleshooting Common Network Issues

Let’s talk about the stuff that’ll actually break and how to fix it, because theory is great until your production servers can’t communicate.

**Issue 1: Servers Can’t Reach Each Other**

# Diagnostic commands in order of usefulness
traceroute 10.0.2.100        # See where packets are getting dropped
mtr 10.0.2.100 --report-cycles 100  # Better than traceroute
ss -tuln                      # Check what's actually listening
netstat -rn                   # Verify routing table

# Common fixes
sudo ip route add 10.0.2.0/24 via 10.0.1.1  # Add missing route
sudo iptables -I INPUT -s 10.0.2.0/24 -j ACCEPT  # Allow subnet access

**Issue 2: Performance Problems Between Subnets**

# Test network performance
iperf3 -c target_server -P 4 -t 30  # Parallel streams test
ping -f -c 1000 target_server        # Flood ping (be careful!)

# Check for network interface errors
ethtool -S eth0 | grep -E "(error|drop|fifo)"

# Monitor bandwidth usage by connection
nethogs eth0
iftop -i eth0

**Issue 3: DNS Resolution Problems**

# Test DNS resolution from different subnets
dig @8.8.8.8 example.com
nslookup example.com 1.1.1.1

# Check if DNS works from specific network interfaces
dig @8.8.8.8 example.com -b 10.0.1.100  # Bind to specific source IP

Here’s a comparison of different networking approaches and their trade-offs:

Conclusion and Recommendations

Here’s the bottom line: understanding IP addresses, subnets, and CIDR notation isn’t just academic knowledge – it’s the foundation that makes everything else possible. Whether you’re setting up a simple web server or architecting a complex microservices environment, this stuff matters.

**My recommendations for getting started:**

**For beginners:** Start with a simple /24 network (like 192.168.1.0/24) and get comfortable with basic concepts. Use tools like `ipcalc` to understand how different subnet masks affect your available IP ranges. Don’t try to over-architect your first setup.

**For intermediate users:** Learn to segment your networks logically. Web servers in one subnet, databases in another, management interfaces in a third. This isn’t just good security practice – it makes troubleshooting infinitely easier when things go wrong.

**For advanced users:** Embrace automation. Use Infrastructure as Code tools like Terraform to manage your network configurations. Set up monitoring that tracks network performance between subnets. Consider IPv6 adoption – it’s not going away, and the sooner you understand it, the better.

**Where to use this knowledge:**
• **Cloud environments** (AWS VPCs, Google Cloud Networks, Azure Virtual Networks)
• **Container orchestration** (Kubernetes networking, Docker Swarm)
• **On-premises server deployments** (especially when setting up multiple dedicated servers)
• **Hybrid cloud setups** (connecting on-prem to cloud resources)
• **Development environments** (mimicking production network topology)

**Why this matters for server management:**
Understanding networking fundamentals will save you countless hours of debugging, improve your security posture, and make scaling your infrastructure much more predictable. Plus, when you’re explaining to your team why the database servers need to be in a separate subnet, you’ll sound like you know what you’re talking about (because you will).

The networking landscape is constantly evolving – IPv6 adoption is accelerating, container networking is becoming more sophisticated, and edge computing is creating new networking challenges. But the fundamentals covered in this post remain constant. Master these concepts, and you’ll be ready for whatever networking challenges come your way.

And remember: every expert was once a beginner who got confused by subnet masks. Take your time, practice with real servers (spin up a few VPS instances if you need to), and don’t be afraid to break things in a test environment. That’s how you really learn this stuff.

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.