Traffic dies at the second hop
Three routers in a chain, and the far LAN is unreachable. The first hop is configured; the transit router and the return path are not.
Scenario
A branch was added to the network in a hurry: host-A's site (R1) now connects to the new host-B site (R3) through a core router (R2). Someone added a route on R1 pointing at R2, declared victory, and went home. host-A still can't reach host-B.
traceroute from host-A makes it exactly one hop: the packet reaches R2 and vanishes.
Topology
- host-A
10.0.1.10/24→ gateway R110.0.1.1 - R1 ↔ R2 link: R1
10.0.12.1/30, R210.0.12.2/30 - R2 ↔ R3 link: R2
10.0.23.1/30, R310.0.23.2/30 - host-B
10.0.3.10/24→ gateway R310.0.3.1
Your job
Get host-A and host-B talking, without changing any IP addressing. R1's existing route is correct. Leave it; the gaps are elsewhere.
What "done" looks like
host-A ↔ host-B ping works in both directions, and every router on the path can forward toward both LANs.
Teaches: static routing through a transit router: every hop on the path needs a route for the destination, and the reply path is its own routing problem.
What gets checked
Your solution is verified against each of these:
- R1 can forward traffic all the way to host-B's LAN (10.0.3.0/24)
- R3 can forward traffic back to host-A's LAN (10.0.1.0/24)
- host-A (10.0.1.10) and host-B (10.0.3.10) reach each other
Solve it in the browser lab
No setup, no install. Open a live lab: configure each device in the editor or its Cisco IOS terminal, run show/ping/traceroute (or test from the hosts), and watch the network react. The in-house engine grades your fix instantly and issues your proof the moment every check passes.
Open the lab →Prefer your own lab?
- Build the fix locally. New to the tooling? See setting up your lab.
- Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
- Submit the repo link. We review it by hand, confirm it works, and issue your proof page.