Networking Fundamentals Master Class #

Engineering-grade reference manual for TCP/IP, DNS, routing, subnetting, load balancing, VPNs, CDN behavior, and network troubleshooting.

Overview #

Infrastructure engineers debug through the network constantly. Containers, Kubernetes, cloud platforms, databases, CI/CD runners, and web applications all depend on routing, DNS, ports, TLS, load balancers, and firewalls.

This guide focuses on practical commands and mental models that help you prove where traffic succeeds or fails.

Core Mental Model #

Every network problem can be narrowed down by layers:

1. Physical or virtual link exists.
2. Interface has an address.
3. Local route table knows where to send packets.
4. Firewall allows traffic.
5. Remote host is reachable.
6. Remote port is listening.
7. DNS resolves to the expected address.
8. TLS handshake succeeds.
9. Application protocol responds correctly.

Interface and Address Inspection #

Show interfaces and addresses:

ip addr show

Show brief interface state:

ip -brief addr

Show link-level state:

ip link show

Show default route:

ip route show default

Show full routing table:

ip route show

Show neighbor/ARP table:

ip neigh show

macOS equivalents:

ifconfig
netstat -rn
arp -a

TCP and UDP Ports #

List listening TCP and UDP sockets:

ss -tulpn

List established connections:

ss -tan state established

Check a TCP port with netcat:

nc -vz example.com 443

Listen on a test port:

nc -l 8080

Send a test payload:

echo 'hello' | nc HOSTNAME 8080

DNS Resolution #

Query A records:

dig example.com A

Query AAAA records:

dig example.com AAAA

Query a specific resolver:

dig @1.1.1.1 example.com A

Trace delegation path:

dig +trace example.com

Show concise answer:

dig +short example.com

Check CNAME chain:

dig example.com CNAME +short

Use nslookup when dig is unavailable:

nslookup example.com

HTTP and TLS Checks #

Fetch headers:

curl -I https://example.com

Verbose TLS and HTTP trace:

curl -v https://example.com

Force DNS resolution to a specific IP:

curl --resolve example.com:443:203.0.113.10 https://example.com

Show certificate dates:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Show certificate subject and issuer:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer

Subnetting Fundamentals #

CIDR notation defines network size. A /24 has 256 addresses, normally 254 usable IPv4 host addresses. A /16 has 65,536 addresses.

Common private ranges:

Range	CIDR	Typical Use
10.0.0.0 - 10.255.255.255	10.0.0.0/8	large private networks
172.16.0.0 - 172.31.255.255	172.16.0.0/12	private networks
192.168.0.0 - 192.168.255.255	192.168.0.0/16	home/lab networks

Calculate subnet details with Python:

python3 - <<'PY'
import ipaddress
net = ipaddress.ip_network('10.20.4.0/24')
print('network', net.network_address)
print('broadcast', net.broadcast_address)
print('hosts', net.num_addresses - 2)
print('first', next(net.hosts()))
print('last', list(net.hosts())[-1])
PY

Split a /24 into four /26 networks:

python3 - <<'PY'
import ipaddress
for subnet in ipaddress.ip_network('10.20.4.0/24').subnets(new_prefix=26):
    print(subnet)
PY

Routing #

Show route to a destination:

ip route get 8.8.8.8

Add a temporary route:

ip route add 10.50.0.0/16 via 10.20.1.1

Delete a temporary route:

ip route delete 10.50.0.0/16

Trace route path:

traceroute example.com

Use TCP traceroute when ICMP is blocked:

traceroute -T -p 443 example.com

Modern tracepath alternative:

tracepath example.com

Packet Capture #

Capture DNS traffic:

tcpdump -i any port 53

Capture traffic to a host:

tcpdump -i any host 203.0.113.10

Capture HTTP/TLS traffic metadata:

tcpdump -i any 'tcp port 80 or tcp port 443'

Write capture to a file:

tcpdump -i any -w capture.pcap host 203.0.113.10

Read capture file:

tcpdump -r capture.pcap

Firewalls #

Check UFW status:

ufw status verbose

Allow SSH:

ufw allow OpenSSH

Allow HTTPS:

ufw allow 443/tcp

List nftables rules:

nft list ruleset

List iptables rules when legacy tooling is used:

iptables -S

Load Balancing Concepts #

Layer 4 load balancing operates on TCP/UDP connections. Layer 7 load balancing understands HTTP concepts such as hosts, paths, headers, redirects, and cookies.

NGINX upstream example:

upstream app_backend {
    server 10.20.1.10:8080;
    server 10.20.1.11:8080;
}

server {
    listen 80;
    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Test NGINX config:

nginx -t

Reload NGINX:

systemctl reload nginx

HAProxy backend example:

backend app_backend
    balance roundrobin
    server app1 10.20.1.10:8080 check
    server app2 10.20.1.11:8080 check

VPN Fundamentals #

WireGuard key generation:

wg genkey | tee privatekey | wg pubkey > publickey

Show WireGuard interfaces:

wg show

Bring up a WireGuard interface:

wg-quick up wg0

Bring it down:

wg-quick down wg0

Check routes after VPN comes up:

ip route show table main

CDN and Caching Checks #

Inspect response headers:

curl -I https://example.com/static/app.js

Look for cache headers:

curl -I https://example.com/static/app.js | grep -iE 'cache-control|etag|age|cf-cache-status|x-cache'

Bypass cache with a query string:

curl -I 'https://example.com/static/app.js?cachebust=1'

Check DNS for CDN CNAME:

dig www.example.com CNAME +short

Kubernetes Networking Checks #

List services:

kubectl get svc -A

List ingress objects:

kubectl get ingress -A

Check endpoints:

kubectl get endpoints -A

Run DNS test pod:

kubectl run dns-test --rm -it --image=busybox:1.36 -- nslookup kubernetes.default

Run curl test pod:

kubectl run curl-test --rm -it --image=curlimages/curl -- curl -I http://SERVICE_NAME.NAMESPACE.svc.cluster.local

Port-forward a service:

kubectl port-forward svc/web 8080:80 -n production

Cloud Network Review #

AWS VPC route tables:

aws ec2 describe-route-tables --query 'RouteTables[].{id:RouteTableId,routes:Routes}'

AWS security groups:

aws ec2 describe-security-groups --query 'SecurityGroups[].{name:GroupName,id:GroupId}' -o table

Azure VNets:

az network vnet list -o table

Azure NSG rules:

az network nsg rule list --resource-group RESOURCE_GROUP --nsg-name NSG_NAME -o table

Troubleshooting Flow #

Use this order for most outages:

1. Confirm DNS resolves to the expected IP.
2. Confirm route to destination.
3. Confirm TCP port reachability.
4. Confirm TLS certificate and SNI.
5. Confirm HTTP status and headers.
6. Confirm backend service is listening.
7. Check local firewall, cloud security group, and Kubernetes network policy.
8. Capture packets if the failure is still ambiguous.

Example flow:

dig +short app.example.com
ip route get 203.0.113.10
nc -vz app.example.com 443
curl -Iv https://app.example.com
ss -tulpn | grep 443

Common Pitfalls #

• Testing IP reachability but forgetting DNS points elsewhere.
• Checking the load balancer but not the backend health check path.
• Forgetting that Kubernetes Service ports and container ports can differ.
• Ignoring IPv6 records when clients prefer IPv6.
• Treating ICMP failure as proof TCP is blocked.
• Making firewall changes without capturing before/after evidence.
• Assuming CDN cache purge is instant globally.

Quick Reference #

ip -brief addr
ip route show
ip route get 8.8.8.8
ss -tulpn
dig +short example.com
curl -Iv https://example.com
nc -vz example.com 443
traceroute -T -p 443 example.com
tcpdump -i any port 53
ufw status verbose
nft list ruleset
kubectl get svc -A
kubectl get ingress -A
az network vnet list -o table
aws ec2 describe-security-groups -o table