Address and route before packets
Check local interface and routing state before blaming services.
ip route
20 min read, 25 min lab
operator
`ip addr` shows interface addresses. `ip route` shows where packets should go. Reachability starts with local state and route selection.
A host cannot reach an internal API. You need to know whether it has an address and a default route.
Worked command
$ ip addr show$ ip route$ ip route get 10.0.0.20$ ping -c 3 10.0.0.20Do not interpret ping failure as proof that the application is down.
Check address, route, then controlled reachability.
A ping to the internal API times out. Beforehand, `ip route get 10.0.0.20` returned a route via the default gateway. What has this proven?
Show the answer
Correct: B. The kernel picked a route for that destination; it does not prove the host is reachable
`ip route get` only shows which route the kernel would use to send the packet, not whether anything answers. Calling the application down conflates a routing fact with an end-to-end reachability claim ping never made.
Practice checklist
- Run read-only interface and route commands.
- Identify the default route.
- Explain what ping can and cannot prove.
Deliverable evidence
- Interface address, default route, and reachability note.
shows: The diagnostic ladder for a reachability symptom: address and route, then DNS name resolution, then listening socket, then HTTP response, with firewall audited separately, and each command proving only its own layer.
does not prove: It does not prove the failure is single-layer: more than one layer can be broken at once, and a green check at one step is evidence for that step only, not proof the whole path works.
Commit these to memory, then drill them until recall is automatic.
cue You need to see which route and source address the kernel will use to reach 10.0.0.20
show recall target
ip route get 10.0.0.20