Networking Fundamentals

Addresses, ports, DNS, and the diagnostic toolkit for connectivity problems.

Networking is where many real incidents live. This chapter builds a working model of addresses, ports, and name resolution, plus a layered diagnostic method using the modern iproute2 toolset.

By the end of this chapter you will be able to

Inspect interfaces and routes with the ip command.
Explain ports, sockets, and DNS resolution.
Use ss, dig, ping, traceroute, and curl for diagnosis.
Map a service failure to the correct network layer.
Read /etc/hosts and resolver configuration.

9.1 Interfaces and Routes

The modern ip command (replaces ifconfig)
ip addr            # IP addresses on each interface
ip route           # how traffic leaves this machine (default gateway)
hostname -I        # just the IP addresses

9.2 Ports and DNS

An IP address finds the *machine*; a port finds the *service* on it. DNS turns a name like example.com into an IP address.

Port	Service
22	SSH
80	HTTP
443	HTTPS
53	DNS
25 / 587	Email (SMTP)

9.3 Connectivity Testing

Layered connectivity tests

ping -c 4 8.8.8.8          # is the host reachable? (raw IP)
ping -c 4 example.com      # works? then DNS is fine too
traceroute example.com     # the path, hop by hop
curl -I https://example.com  # does the web service actually respond?
nc -zv example.com 443     # is a specific TCP port open?

9.4 Transfers and Firewall Basics

curl and wget fetch from the web on the command line. A firewall controls which ports accept connections; you’ll harden this in Chapter 11.

Downloads and firewall status

curl -O https://example.com/file.tar.gz   # download a file
wget https://example.com/file.tar.gz
 
sudo ufw status            # Ubuntu firewall state
sudo firewall-cmd --list-all  # RHEL-family firewall state

9.5 Guided Lab: Connectivity Diagnosis

Estimated time: 20 minutes. Map your own networking, then run a layered diagnosis the way an engineer does.

Show your addresses and gateway: ip addr and ip route.
Resolve a name: dig example.com +short (or getent hosts example.com).
Test raw reachability: ping -c 4 8.8.8.8.
Test name-based reachability: ping -c 4 example.com. If step 3 worked but this didn’t, suspect DNS.
See what’s listening locally: ss -tulpn.
Check a web service end to end: curl -I https://example.com.

Troubleshooting

Symptom	Likely cause and fix
ping by IP works, by name fails	DNS problem. Check /etc/resolv.conf and your resolver; try a different DNS server (e.g. dig @1.1.1.1 name).
Service running but unreachable from outside	Check it’s actually listening (ss -tulpn), then the host firewall (ufw/firewalld), then any cloud security group. Work outward layer by layer.
‘Connection refused’ vs ‘timed out’	Refused = something replied but nothing is listening on that port. Timed out = a firewall is silently dropping packets or the host is down.
Slow name resolution	A failing or slow DNS server. Switch resolvers, or check systemd-resolved status.

Practice & Prove It

Write-the-command drills

Show the IP addresses on all interfaces.
Resolve example.com to an IP, short output only.
Send 4 ping packets to 1.1.1.1.
List all listening TCP/UDP ports with their processes.
Check whether TCP port 443 on example.com is reachable using netcat.

Quick quiz

What does a port identify, versus an IP address?
Which modern command replaces ifconfig?
What does DNS do?
If ping by IP works but by name fails, what’s wrong?
Which command lists listening ports and their processes?

Key Takeaways

IP finds the machine, port finds the service, DNS maps names to IPs.
Use the modern ip command; ifconfig is deprecated.
Diagnose connectivity in layers: by IP, by name, listening port, firewall, then app.
ss -tulpn reveals what’s listening; curl/nc confirm a service responds.
‘Refused’ means nothing’s listening; ‘timed out’ usually means a firewall is dropping packets.

Next — Chapter 10: service management with systemd.