Skip to content

Lab: TCP/IP Diagnostics

Pairs with: TCP/IP Networking and the ip Command Suite

Environment: Two disposable VMs on the same virtual network (e.g., a VirtualBox/libvirt host-only network), so you have a controllable, isolated link between them.

Starting conditions

  1. Two VMs, host-a and host-b, on the same subnet, confirmed reachable from each other via ping before you introduce any fault.
  2. Root/sudo access on both.

Instructions

Part 1 — Break it, deliberately

On host-b, introduce one of the following faults:

  • Wrong route: sudo ip route del default (removes the default route entirely — host-b can still reach host-a directly on the same subnet, but nothing beyond it).
  • Wrong address: change host-b's own IP to one that's on a different subnet than host-a's, without updating the route accordingly: sudo ip addr add 192.0.2.99/24 dev eth0 (leave the original address in place too, for now — don't remove it).

Part 2 — Diagnose it, from host-a

Using only the layer-by-layer approach from the article (ip link, ip addr, ip route get, ping), determine, from host-a, whether host-b is reachable at all, and if not, at which layer the failure occurs.

Expected results

  • Missing default route fault: host-a pinging host-b directly on the shared subnet still succeeds (no default route needed for same-subnet traffic) — the fault only manifests if host-b needs to reach something beyond the local subnet, which won't show up in a same-subnet ping test at all. This is itself the lesson: confirm you're testing the actual failure condition, not just "is the host up."
  • Wrong-subnet address fault: depends on which address host-a is targeting. If host-a targets the original (still-present) address, it still works — again demonstrating that adding a wrong address doesn't remove the right one. If targeting the new 192.0.2.99 address, and host-a has no route to that subnet, the ping will fail with "Network is unreachable" reported locally on host-a before any packet is even sent — a distinct failure mode from a timeout (a timeout means packets were sent but no reply came; "Network is unreachable" means the local kernel never attempted to send at all, because it has no route).

Diagnosis checklist

  • [ ] Did you distinguish "Network is unreachable" (no local route exists) from a silent timeout (packets sent, no reply)? These indicate different problems — one is local, one could be anywhere on the path or at the destination.
  • [ ] Did you use ip route get <target-ip> on host-a before pinging, to predict whether the kernel even believes it has a path?
  • [ ] For the missing-default-route fault: did you correctly identify that same-subnet connectivity is unaffected, and reason about why (no default route is needed within a single subnet)?

Success criteria

You can, from host-a alone (without logging into host-b to check its config directly), narrow down whether a described connectivity failure is a routing problem on the remote end, an addressing mismatch, or something else — using only ip route get, ping, and reasoning about the error messages each produces.

Cleanup / rollback

# On host-b, restore the default route (adjust gateway IP to your actual lab network):
sudo ip route add default via <gateway-ip> dev eth0

# Remove the extra address if you added one:
sudo ip addr del 192.0.2.99/24 dev eth0

Confirm ping from host-b to something beyond the local subnet (e.g., your lab's gateway, or the internet if the lab network has access) succeeds again before considering the environment restored.