A real-life situation
A ticket comes in: "PC1 can't reach the server at 192.168.3.10". A colleague added routes last night. R1 has a route to the server LAN, so the routing "looks fine". You need a method that finds the real break instead of guessing.
What to check, in order
Follow the packet the way it really travels: from the sender, one router at a time, then back again. At each router, ask one question: "does this router have a route for the destination, and does it point the right way?"
- The host. Is PC1's IP address, mask and default gateway correct? Can it ping its gateway, 192.168.1.1?
- Each router on the way there. Run
show ip route 192.168.3.10on R1, then on the next hop it names, and so on. - Each router on the way back. Repeat for the reply:
show ip route 192.168.1.10on R3, then R2. - Use traceroute to see where replies stop, then check that router first.
- 1. The request arrives. R1 and R2 both have routes toward 192.168.3.0/24, so the server receives the ping.
- 2. The reply dies at R3. R3 has no route to 192.168.1.0/24 and no default route. It drops the packet.
- 3. One-way traffic: from PC1 it looks like the server is down. Only checking the return path shows the real cause.
Why it works this way
Every router decides on its own, using only its own table. So a correct route on R1 says nothing about R2 or R3. And the reply is a new packet with a new destination, so it needs its own set of routes. That is why "it works one way" problems are so common: people configure the path there and forget the path back.
| Symptom | Likely cause | Check with |
|---|---|---|
| PC can't ping its own gateway | Wrong IP, mask or VLAN on the PC, or the router interface is down | ipconfig, show ip interface brief |
| Traceroute stops at hop 1 | First router has no route, or its next hop is wrong | show ip route <dest> on that router |
| Request arrives but no reply | Missing return route somewhere on the way back | show ip route <source> on each router back |
| Traceroute repeats two routers | Routing loop: each points to the other | Compare both routers' next hops |
| Static route missing from the table | Next hop unreachable or exit interface down | show running-config | include ip route |
How to verify it
Start with traceroute from R1, sourced from the LAN interface so the replies are addressed to LAN 1, just like PC1's. These outputs are based on Cisco documentation, not run on a lab device.
R1#traceroute 192.168.3.10 source GigabitEthernet0/0 Type escape sequence to abort. Tracing the route to 192.168.3.10 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.12.2 1 msec 0 msec 1 msec 2 * * * 3 * * * 4 * * *
R2#show ip route 192.168.3.10 Routing entry for 192.168.3.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.23.2 Route metric is 0, traffic share count is 1
R3#show ip route 192.168.1.10 % Network not in table
⚠️ The fix below is based on Cisco IOS / IOS XE documentation, not run on a lab device.
ip route 0.0.0.0 0.0.0.0 10.0.23.1On R3: a default route toward R2 covers LAN 1 and every other remote network. Run the traceroute again; hop 2 should now be 10.0.23.2.
Check yourself
Traceroute shows 10.0.12.1, 10.0.12.2, 10.0.12.1, 10.0.12.2… What is wrong?
R1 has a correct route to the server LAN, but pings from PC1 fail. What should you check next?
A static route is in the running configuration but not in show ip route. Why?