TTR Networks

Beginner · Linux Network Connectivity · section 10 of 11

What broke? Three faults

✓ Lab-tested 17 October 2026 on Debian 12

Three faults, broken on purpose in the lab, each with its symptom and the command that pins it down. Each matches a step of the bottom-up method.

  1. No default route on the client. Network is unreachable comes back instantly, because the kernel refuses to send. No packet ever leaves the host. ip route get confirms there's no route.
  2. Forwarding disabled on the router. Now packets leave, but replies never arrive: 100% loss, no error. The client can still ping the router itself, so the fault is at the router. sysctl net.ipv4.ip_forward shows it.
  3. The server has no route back. The most confusing kind: the request does reach the server, but the reply can't be sent. From the client it looks identical to case 2. A capture on the router's server-side interface proves it: echo requests go out, and nothing comes back. On the server, ip route get to the client fails.

That last pattern, packets leave and never return, is the subject of the next lesson. When it happens on real networks, the cause is usually asymmetric routing, NAT or a stateful firewall, and capturing at several points is how you find out which.

Interactive: Replay the three faults The three faults from this section, as packet journeys. The terminal output is the real output from the lab. (needs JavaScript)

Three faults, as seen in the lab (real output; ### headers added)
### 1. No default route
root@client:~# ping -c 2 198.51.100.20
ping: connect: Network is unreachable
root@client:~# ip route get 198.51.100.20
RTNETLINK answers: Network is unreachable
### 2. Router not forwarding
root@client:~# ping -c 2 -W 1 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 56(84) bytes of data.

--- 198.51.100.20 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1036ms

root@router:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
### 3. Server has no route back
root@router:~# timeout 4 tcpdump -l -nn -i eth1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:35:12.225989 IP 192.0.2.10 > 198.51.100.20: ICMP echo request, id 55406, seq 1, length 64
18:35:13.246250 IP 192.0.2.10 > 198.51.100.20: ICMP echo request, id 55406, seq 2, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@server:~# ip route get 192.0.2.10
RTNETLINK answers: Network is unreachable
  • Lines 2–5: Instant local error: the kernel has no route, so nothing is sent.
  • Lines 7–11: Silent 100% loss: the packets leave, but nothing comes back.
  • Lines 13–14: Forwarding is off, so the router drops transit packets.
  • Lines 16–23: A capture on the router's server-facing interface: requests go out to the server, and no replies ever come back.
  • Lines 24–25: The cause, on the server: no route back to the client's network.

Check your understanding

ping 198.51.100.20 gives 100% loss with no errors. You can ping the router at 192.0.2.1. What's the best next step?

  • Reboot the client
  • Capture on the router's interface toward the server to see whether requests leave and replies return
  • Check the client's DNS
  • Change the client's MTU