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?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.