Networking — Linux Administration Level 7

TCP/IP fundamentals for administrators

IP addresses, ports, and TCP vs. UDP — the vocabulary every other networking lesson builds on. · 10 min

An IP address identifies a device on a network — IPv4 addresses look like `192.168.1.10` (four numbers 0-255), IPv6 addresses look like `2001:db8::1` (hexadecimal, far larger address space). A port number (0-65535) identifies a specific service or connection on that device — a single IP address can run many services simultaneously, each listening on its own port (SSH conventionally on 22, HTTP on 80, HTTPS on 443). An IP address plus a port together (`192.168.1.10:443`) uniquely identifies a specific network endpoint.

TCP (Transmission Control Protocol) is connection-oriented and reliable: it establishes a connection first, guarantees delivery and correct ordering of data (retransmitting anything lost), and is what almost all everyday services use — web traffic, SSH, database connections. UDP (User Datagram Protocol) is connectionless and makes no delivery guarantees: it sends packets without establishing a connection or confirming receipt, which sounds worse but is exactly the right tradeoff for latency-sensitive use cases (DNS queries, video streaming, VoIP) where a dropped and retransmitted-late packet is worse than a dropped one.

A gateway (or default gateway) is the router a device sends traffic through to reach anything outside its local network — without a correctly configured gateway, a device can talk to other devices on its own local subnet but nothing beyond it. DNS translates human-readable names into IP addresses, covered in depth in its own lesson — for now, recognize that "the website is down" and "DNS can't resolve the website's name" are different problems requiring different diagnosis.

Command	Purpose	Example
ip addr	Show network interfaces and their assigned IP addresses	—
ip route	Show the routing table, including the default gateway	—

• IP address — identifies a device on the network
• Port — identifies a specific service on that device
• TCP — reliable, ordered, connection-based (most services)
• UDP — fast, connectionless, no delivery guarantee (DNS, streaming)
• Gateway — the router used to reach anything outside the local network

Takeaway: TCP trades speed for reliability; UDP trades reliability for speed — knowing which a given service uses tells you a lot about how it will fail under packet loss.

Diagnosing connectivity: ip, ss, ping, curl, and traceroute

A practical toolkit for answering "is it the network, or is it the application?" · 11 min

When something is unreachable, work outward in layers rather than guessing. `ip addr` confirms your own interface actually has the IP address you expect. `ping <host>` tests basic reachability at the network layer — a successful ping tells you the path exists and basic connectivity works, but says nothing about whether the actual service (a specific port) is reachable or working, since ping uses ICMP, not TCP/UDP on a specific port.

`ss` (the modern replacement for the older `netstat`) shows active sockets — which ports are listening and which connections are established. `ss -tulpn` is the single most useful invocation: TCP and UDP listening sockets, with process names and PIDs, showing you exactly what's actually listening on which port on this machine right now — the first command to run when "is anything even listening on port 8080" is the question.

`curl` tests an actual HTTP/HTTPS request end-to-end, which `ping` cannot — a host can respond to ping while its web server is completely down, or vice versa (ICMP blocked by a firewall while HTTP works fine). `traceroute` (or `tracepath` when traceroute isn't installed) shows the network path — every router hop — between you and a destination, useful for spotting exactly where along a path connectivity breaks down or slows dramatically, rather than only knowing "somewhere between here and there".

Command	Purpose	Example
ping -c 4 host	Send 4 ICMP echo requests to test basic reachability	ping -c 4 8.8.8.8
ss -tulpn	Show all listening TCP/UDP ports with owning process	—
curl -I https://example.com	Fetch just the HTTP headers, to test a web endpoint quickly	—
traceroute host	Show the network path (router hops) to a destination	—
wget	Download a file over HTTP/HTTPS/FTP	wget https://example.com/file.tar.gz

Diagnostic sequence: "the API is down"

$ ping -c 2 api.example.com
# Confirms the host is reachable at all (network layer)

$ ss -tulpn | grep :8080
# Confirms something is actually listening on the expected port,
# locally, if you're on the server itself

$ curl -I https://api.example.com/health
# Tests the actual HTTP response — this is what "is the API up" really means

Common Mistakes

⚠ Treating a successful `ping` as proof "the server is fine" — ping only tests ICMP reachability, not whether the actual service/port is working
⚠ Not checking `ss -tulpn` first when a service "isn't reachable" — if nothing is even listening on the expected port, that's the whole problem right there

🧪

Hands-On Lab

Diagnose a "service unreachable" scenario

Ubuntu Server 24.04 LTS

Objectives

✓ Confirm whether a target host is reachable at the network layer
✓ Confirm whether a specific port is actually listening
✓ Confirm whether the actual HTTP service responds correctly

Instructions

Start a simple test HTTP server: `python3 -m http.server 8080` (leave it running in one terminal or background it with `&`).
From the same machine, run `ss -tulpn | grep 8080` and confirm you see the listening process.
Run `curl -I http://localhost:8080` and confirm you get an HTTP response.
Stop the server, then re-run both the `ss` and `curl` commands — observe how each one reports the service is now gone, in a different way (ss shows nothing listening; curl gives a connection-refused error).

Hints (1)

If port 8080 is already in use by something else, pick a different port: `python3 -m http.server 8090`.

Takeaway: Diagnose network problems in layers — reachability (ping), then "is anything even listening" (ss), then "does the actual service respond correctly" (curl) — rather than jumping straight to assumptions.