Fundamentals 35 min read

Essential Network Basics for Ops: IP Addresses, Subnet Masks, and Gateways Explained

This guide walks operations engineers through core networking concepts—including IP address structure, binary‑decimal conversion, private address ranges, subnet masks, CIDR notation, gateway functions, VLAN isolation, routing tables, DNS resolution, Docker/Kubernetes networking, and firewall configuration—while providing concrete command‑line examples and step‑by‑step troubleshooting workflows.

MaGe Linux Operations
MaGe Linux Operations
MaGe Linux Operations
Essential Network Basics for Ops: IP Addresses, Subnet Masks, and Gateways Explained

IP Address Basics

IPv4 addresses are 32‑bit binary numbers usually written as four decimal octets separated by dots. Example: 192.168.1.111000000.10101000.00000001.00000001. Quick conversion relies on powers of two (2⁷=128, 2⁶=64, …).

Historical IP Classes

A – Range: 0.0.0.0‑127.255.255.255 – Large networks – Network/host bits: 8/24

B – Range: 128.0.0.0‑191.255.255.255 – Medium networks – Network/host bits: 16/16

C – Range: 192.0.0.0‑223.255.255.255 – Small networks – Network/host bits: 24/8

D – Range: 224.0.0.0‑239.255.255.255 – Multicast – Not used for host addressing

E – Range: 240.0.0.0‑255.255.255.255 – Reserved

In modern practice the private address blocks defined by RFC 1918 are used most often:

10.0.0.0‑10.255.255.255      (10/8)
172.16.0.0‑172.31.255.255    (172.16/12)
192.168.0.0‑192.168.255.255  (192.168/16)

Special IP Addresses

# Loopback
127.0.0.1   # IPv4 localhost
::1         # IPv6 localhost
# Broadcast (rarely used)
192.168.1.255  # Broadcast for 192.168.1.0/24
# Network address
192.168.1.0    # Represents the whole subnet
# Link‑local (auto‑config)
169.254.0.0/16  # Windows APIPA
fe80::/10       # IPv6 link‑local
# Zero address (default route placeholder)
0.0.0.0/0      # "any" address, appears in routing tables

Subnet Mask and CIDR

A subnet mask separates the network portion from the host portion of an IP address. In a 32‑bit mask, bits set to 1 denote network bits, bits set to 0 denote host bits.

# Example mask 255.255.255.0
Binary: 11111111.11111111.11111111.00000000
IP 192.168.1.100 & mask → network 192.168.1.0
Broadcast = network | (~mask) → 192.168.1.255

Subnet masks can be expressed in dotted‑decimal ( 255.255.255.0) or CIDR notation ( /24), where the suffix indicates the number of leading network bits.

CIDR Quick Reference

/32  = 255.255.255.255  Hosts: 1
/31  = 255.255.255.254  Hosts: 2 (point‑to‑point)
/30  = 255.255.255.252  Hosts: 4
/29  = 255.255.255.248  Hosts: 8
/28  = 255.255.255.240  Hosts: 16
/27  = 255.255.255.224  Hosts: 32
/26  = 255.255.255.192  Hosts: 64
/25  = 255.255.255.128  Hosts: 128
/24  = 255.255.255.0    Hosts: 256 (254 usable)
/23  = 255.255.254.0    Hosts: 512
/22  = 255.255.252.0    Hosts: 1024
/21  = 255.255.248.0    Hosts: 2048
/20  = 255.255.240.0    Hosts: 4096
/16  = 255.255.0.0      Hosts: 65536
/8   = 255.0.0.0        Hosts: 16777216

Usable hosts are calculated as 2^(32‑CIDR) - 2 (subtracting network and broadcast addresses).

Choosing a CIDR Block Size

/30 or /31 – Point‑to‑point links

/29 – Small services with a few machines

/28 – Department‑level server clusters

/27 – Business‑line infrastructure

/26 – Full business‑line infrastructure

/25 or /24 – Large Kubernetes clusters or VPC subnets

/16 or /8 – Data‑center‑scale allocations

Subnet Division Example

Assume a 192.168.0.0/24 network that must be split among four departments, each needing ~50 hosts. Using four /26 subnets (64 addresses each) yields:

Dept A: 192.168.0.0/26   Network 192.168.0.0   Usable 192.168.0.1‑62   Broadcast 192.168.0.63
Dept B: 192.168.0.64/26  Network 192.168.0.64  Usable 192.168.0.65‑126  Broadcast 192.168.0.127
Dept C: 192.168.0.128/26 Network 192.168.0.128 Usable 192.168.0.129‑190 Broadcast 192.168.0.191
Dept D: 192.168.0.192/26 Network 192.168.0.192 Usable 192.168.0.193‑254 Broadcast 192.168.0.255

Verification on Linux can be done with ipcalc:

# Debian/Ubuntu
apt install ipcalc
# CentOS/RHEL
yum install ipcalc
ipcalc 192.168.0.0/26

Default Gateway

Devices in the same subnet communicate directly; traffic to other subnets must be forwarded through a gateway (usually a router or Layer‑3 switch).

# Scenario: 192.168.1.10 wants to reach 192.168.2.20
1. 192.168.1.10 sees the target is outside its /24 subnet
2. Sends the packet to the default gateway (e.g., 192.168.1.1)
3. Gateway looks up its routing table and forwards the packet
4. Packet eventually arrives at 192.168.2.20

View and configure the gateway:

# Show current routing table (includes default gateway)
ip route show
# Example output
# default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.100 metric 600
# Add a temporary default gateway
ip route add default via 192.168.1.1 dev eth0
# Delete the default gateway
ip route del default via 192.168.1.1

In public clouds (Alibaba Cloud, AWS, Tencent Cloud) the VPC gateway is automatically assigned as the first IP of the subnet (e.g., 192.168.1.1).

VLAN (Virtual LAN)

VLANs partition a physical switch into multiple broadcast domains. Devices in different VLANs cannot communicate directly even if they share the same physical switch; they must be routed via a Layer‑3 device.

# Scenario: three network purposes on a server
- Management network: 192.168.1.0/24 (VLAN 100)
- Business network:   192.168.2.0/24 (VLAN 200)
- Storage network:    192.168.3.0/24 (VLAN 300)
# After configuration, same‑VLAN devices communicate freely; cross‑VLAN traffic requires routing.

Linux VLAN Configuration

# Load 8021q kernel module
modprobe 8021q
# Create VLAN interface VLAN 100 on eth0
ip link add link eth0 name eth0.100 type vlan id 100
# Assign IP address
ip addr add 192.168.1.10/24 dev eth0.100
# Bring the interface up
ip link set eth0.100 up
# Verify configuration
ip link show type vlan
cat /proc/net/vlan/config
# Delete VLAN interface
ip link del eth0.100

Switch Port Modes

Access – Single VLAN, frames are untagged.

Trunk – Multiple VLANs, frames carry VLAN tags.

Hybrid – Huawei‑specific, flexible tag/untag selection.

Routing Basics

Every IP device (host, router, Layer‑3 switch) maintains a routing table. When sending a packet, the device selects the most specific (longest‑prefix) entry.

# Show Linux routing table
ip route show
route -n
# Typical entries
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100   # Directly connected
10.0.0.0/8 via 192.168.1.1 dev eth0                               # Forward via gateway
default via 192.168.1.1 dev eth0                                 # Default route
# Longest‑prefix match example
Target 10.20.30.40 matches:
0.0.0.0/0, 10.0.0.0/8, 10.20.0.0/16, 10.20.30.0/24 → choose /24

Adding and Deleting Routes

# Add a temporary static route
ip route add 10.10.0.0/16 via 192.168.1.1 dev eth0
# Add a host‑specific route
ip route add 10.10.10.20/32 via 192.168.1.1 dev eth0
# Add a blackhole route (drop traffic)
ip route add blackhole 10.10.10.0/24
# Delete a route
ip route del 10.10.0.0/16 via 192.168.1.1 dev eth0
# Persist on CentOS (add to /etc/sysconfig/network-scripts/route-eth0)
# Persist on Debian/Ubuntu (add to /etc/network/interfaces)
up ip route add 10.10.0.0/16 via 192.168.1.1 dev eth0

Policy Routing (Advanced)

# View policy routing rules
ip rule show
# Add source‑address based rule
ip rule add from 192.168.1.0/24 table 100
ip route add default via 192.168.1.1 dev eth0 table 100
# Add fwmark‑based rule (commonly used for traffic shaping)
iptables -A PREROUTING -s 10.0.0.0/8 -j MARK --set-mark 1
ip rule add fwmark 1 table 200
ip route add default via 10.0.0.1 dev eth1 table 200

DNS Basics

DNS translates human‑readable domain names to IP addresses. A common symptom – “can ping IP but not domain” – usually indicates a DNS problem.

# View DNS configuration
cat /etc/resolv.conf
# Test resolution
nslookup www.baidu.com
dig www.baidu.com
host www.baidu.com
# Restart systemd‑resolved
systemctl restart systemd-resolved
# Query a specific DNS server (Google)
nslookup www.baidu.com 8.8.8.8
dig @8.8.8.8 www.baidu.com

/etc/hosts Local Resolution

# Sample /etc/hosts
127.0.0.1   localhost localhost.localdomain
192.168.1.100 db-master.internal db-master
192.168.1.101 db-slave.internal db-slave
10.244.1.5   redis-01.default.svc.cluster.local redis-01
# /etc/hosts entries have higher priority than DNS

Network Troubleshooting Process

Layered Approach

Layer 1 – Physical: cables, fiber, NIC link lights
Layer 2 – Data link: MAC, ARP, switch ports
Layer 3 – Network: IP, subnet mask, routing table, gateway
Layer 4 – Transport: TCP/UDP ports, firewall state
Layer 5 – Application: HTTP response, DNS, certificates

Common Diagnostic Commands

# IP configuration
ip addr show eth0
# Gateway reachability
ping -c 3 192.168.1.1
# Internet reachability
ping -c 3 8.8.8.8
# Port check (TCP)
nc -zv 192.168.1.100 22
# View routing table
ip route show
traceroute -m 10 8.8.8.8
# DNS checks
nslookup www.baidu.com
# Firewall rules
iptables -L -n -v
# Listening sockets
ss -tlnp
# ARP table
ip neigh show

Typical Failure Cases

Case 1: Server receives a 169.254.x.x address – DHCP failure; verify cable, DHCP config, and manually request an address.

Case 2: Same‑subnet machines cannot ping each other – Check IP/mask consistency, ARP entries, firewall rules, and interface state.

Case 3: Cross‑subnet ping fails – Verify default gateway configuration, gateway reachability, and routing entries on both ends.

Case 4: DNS resolves but connectivity fails – Test TCP/UDP reachability, traceroute, firewall OUTPUT chain, MTU settings, and proxy environment variables.

Docker / Kubernetes Networking

Docker Network Modes

# List Docker networks
docker network ls
# Common modes
# bridge – default, containers on 172.17.0.0/16
# host – uses host network stack
# overlay – Swarm cross‑host networking
# macvlan – containers get independent MAC addresses
# Show container IP
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name
# Debug inside container
docker exec -it container_name ip addr
docker exec -it container_name cat /etc/resolv.conf
# Test inter‑container connectivity
docker exec -it container_a ping -c 1 container_b

Kubernetes Network Model

Kubernetes requires that all Pods can reach each other directly (no NAT) and that nodes can reach every Pod.

# List node IPs and Pod CIDRs
kubectl get nodes -o wide
# List all Pod IPs
kubectl get pods -o wide --all-namespaces
# List Service ClusterIPs
kubectl get svc -o wide
# CNI plugin comparison

Flannel – Subnet 10.244.0.0/16 – Simple, VXLAN encapsulation

Calico – Subnet 10.244.0.0/16 – BGP support, high performance

Cilium – Subnet 10.244.0.0/16 – eBPF acceleration, strong observability

Weave – Subnet 10.32.0.0/16 – Simple, encrypted transport

# Diagnose Pod networking
kubectl exec -it pod_name -- ip addr
kubectl exec -it pod_name -- cat /etc/resolv.conf
kubectl exec -it pod_name -- ping -c 1 8.8.8.8
# View Pod events
kubectl describe pod pod_name
# View CNI logs (Calico example)
kubectl logs -n kube-system -l k8s-app=calico-node
journalctl -u kubelet | grep -i cni

Firewall Basics

iptables

# List all rules
iptables -L -n -v
# Four tables (priority order): raw, mangle, nat, filter (default)
# Five built‑in chains: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING
# Allow SSH, HTTP, HTTPS
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Allow established/related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Drop all other inbound traffic
iptables -A INPUT -j DROP
# Save rules (CentOS)
service iptables save
# Save rules (Debian/Ubuntu)
iptables-save > /etc/iptables/rules.v4
# Restore rules
iptables-restore < /etc/iptables/rules.v4

nftables (new generation)

# Show current rule set
nft list ruleset
# Create table and chain
nft add table ip filter
nft add chain ip filter input { type filter hook input priority 0; }
# Add rules
nft add rule ip filter input tcp dport 22 accept
nft add rule ip filter input ct state established,related accept
nft add rule ip filter input counter drop
# Persist configuration
nft list ruleset > /etc/sysconfig/nftables.conf

Production Network Security Recommendations

Principle of Least Privilege

# Restrict SSH source addresses
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
# Disable ICMP broadcast replies
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Disable source routing
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
# Enable reverse‑path filtering
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
# Disable ICMP redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Internal Network Isolation

# Use VLANs or cloud security groups to separate business segments
# Example: MySQL only reachable from app servers
iptables -A INPUT -p tcp --dport 3306 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP
# Redis limited to internal network and dangerous commands disabled
bind 10.0.1.0/24
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command SHUTDOWN ""
# Periodically check for abnormal connections
ss -tnp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Permanent Network Tuning (sysctl)

# /etc/sysctl.conf or /etc/sysctl.d/99-custom.conf
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 65536 6291456
net.ipv4.tcp_window_scaling = 1
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
# Apply immediately
sysctl -p

Conclusion

Mastering IP addressing, subnet masks, CIDR, gateways, routing, DNS, VLANs, container networking, and firewall rules enables rapid identification and resolution of the majority of connectivity problems within minutes. These fundamentals are mandatory for any operations engineer.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

DockerKubernetesLinuxnetworkinggatewaysubnet maskVLANIP addressing
MaGe Linux Operations
Written by

MaGe Linux Operations

Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.