What's changed: Initial version (topic 1.07, subtopics 1.07.1–1.07.4)
2.3Basic Network Troubleshooting
Learn to isolate network failures: reachability (ping, ping6), path tracing (traceroute, tracepath), name resolution checks (host, dig), port/connection inspection (ss, netstat, netcat), interface reconfiguration (ifconfig, ifup/ifdown, hostname), and fixing the routing table.
"It does not connect" always has a layer: link, IP, path, name resolution, or the port (service). Applying this section's tools from the bottom layer up is the isolation pattern that works in practice and on the exam.
2.3.1Reachability and path
- ping (ping6 for IPv6) checks whether the target is reachable via ICMP echo. Try gateway → external IP → FQDN to bisect layers.
- traceroute (traceroute6) / tracepath (tracepath6) show each router hop, pinpointing where traffic stops; tracepath needs no privileges and also probes MTU.
- Verify resolution with host (concise) and dig (detailed, full answer sections)—the confirmation when "IP works, names do not".
2.3.2Ports, connections, and route fixes
- ss lists sockets (successor to netstat).
ss -tlnp= TCP, LISTEN, numeric, process—the staple for "is the service listening?". Legacy: netstat. - netcat (nc, ncat) tests connections to arbitrary ports (
nc -zv host 443)—first-pass separation of firewall drops vs missing services. - On the fixing side: interface add/remove/restart (ifconfig, ifup/ifdown, hostname) and manually correcting a wrong default route (
ip route del default→ip route add default via <correct GW>; legacy: route).
Standard pairings: where hops stop = traceroute/tracepath, is it listening = ss -tlnp (legacy netstat), test any port = nc, resolution details = dig. Scenario questions ask you to name the layer: "ping works but ssh fails → a port/service-layer problem (check with ss or nc)".
Learn the canonical scenarios as patterns.
① "Cannot reach the web server": ping web01 succeeds → IP layer is fine. nc -zv web01 80 refused → on the server check ss -tlnp | grep :80; no LISTEN = service down (start via systemctl); LISTEN present but unreachable from outside = suspect the firewall (topic 1.10).
② "Only external sites fail": check ip route; if the default points at a wrong GW, fix with ip route del default → ip route add default via <correct GW>.
③ "Only names fail": read dig example.com; SERVFAIL/timeout leads to /etc/resolv.conf (next section). If traceroute keeps dying at the same mid-path hop, the fault is a downstream router/link—not fixable from your host (escalation is the right answer), itself a practical exam point.
| Symptom | Tool | What to look for |
|---|---|---|
| Target unreachable | ping → traceroute/tracepath | Where hops stop |
| Names fail | host / dig | Answers, SERVFAIL |
| Port refuses | nc -zv / ss -tlnp | LISTEN state, process |
| All external fails | ip route | Default route correctness |
Trap: watch for role swaps like "ss shows disk usage" (ss = socket statistics, netstat's successor). "If ping works, the web must work" is wrong—ping checks ICMP (IP layer); whether TCP 80/443 (service layer) is alive is separate. Options calling tracepath a name-resolution tool are wrong too.
2.3.3Section summary
- Bottom-up: ping (IP) → traceroute/tracepath (path) → host/dig (names) → ss/nc (ports)
- Fix with ifup/ifdown, ip route del/add default; judge by layer—no LISTEN = the service, dead mid-hop = the path
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to see how far along the router path your packets get. Which command?
Q2. On the web server, you must check whether a process is listening on port 80. Which current-standard command?
Q3. ping 8.8.8.8 succeeds but ping example.com fails. What should you suspect most?