Multi-router troubleshooting scenarios appear in simulation questions and exhibit-based multiple choice on the CCNA exam. The topology is usually R1 — R2 — R3, and the problem is that R1 cannot ping R3. Understanding what to check and in what order separates candidates who pass from those who guess.
The Topology
R1 (10.1.1.1/24) --- R2 (10.1.1.2/24 | 10.2.2.1/24) --- R3 (10.2.2.2/24)
R1 and R3 are not directly connected. R2 connects them. For R1 to reach R3, several things must be true simultaneously.
Step 1: Verify the Route Exists on R1
Run show ip route on R1. You need to see a route to R3's network (10.2.2.0/24).
If the route is missing, R1 has no idea how to reach R3 and drops the packet immediately.
Possible causes:
- Routing protocol not configured or not advertising that network
- Static route missing:
ip route 10.2.2.0 255.255.255.0 10.1.1.2 - OSPF
networkstatement does not cover R2's 10.2.2.x interface
Exam trap: the network command in OSPF uses a wildcard mask, not a subnet mask. A common misconfiguration is using 255.255.255.0 instead of 0.0.0.255. If the network statement does not match the interface, OSPF does not include it and the route is not advertised.
Step 2: Check R2's Routing Table
R2 must have routes to both R1's network (10.1.1.0/24) and R3's network (10.2.2.0/24). Since both are directly connected to R2, the directly connected routes appear automatically — as long as the interfaces are up and the IP addresses are correct.
If static routing is used, verify R2 has the correct static routes for remote networks.
Step 3: The Return Path — The Most Missed Step
This is the most common mistake on CCNA routing troubleshooting questions. Routing must work in both directions.
When R1 pings R3:
- R1 sends an ICMP Echo to 10.2.2.2 — forwarded via R2
- R3 receives the Echo and must send an Echo Reply to 10.1.1.1
- R3 needs a route to 10.1.1.0/24 to send that reply
If R3 does not have a route to 10.1.1.0/24, the reply is dropped at R3. R1 never gets a response, so ping fails. But the problem is not on R1 — it is on R3.
Common exam question pattern: "R1 can reach R2 but cannot reach R3. R3's routing table is shown. What is missing?"
The shown routing table will not have a route to 10.1.1.0/24. The fix is a static route on R3:
R3(config)# ip route 10.1.1.0 255.255.255.0 10.2.2.1
Step 4: Check Interface Status
Routing table entries depend on interfaces being up. Run show ip interface brief and confirm all relevant interfaces are in "up/up" state (protocol and line status both up).
If an interface is "up/down," the physical connection exists but the line protocol is not up — often a clocking issue on serial links or duplex mismatch on Ethernet.
Step 5: Check for ACLs
An access list applied inbound on the wrong interface silently drops packets. Check:
R2# show ip interface GigabitEthernet0/0
Look for "Inbound access list is:" — if an ACL is applied, verify it permits the relevant traffic.
How to Interpret Ping Results
R1# ping 10.2.2.2
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent
!= Success.= Timeout (no reply — no route or reply path blocked)U= Unreachable (a router explicitly returned ICMP unreachable — check where it came from)N= Network unreachable
Five dots means packets timed out — either no route exists or the return path is broken. A U is actually helpful because it tells you a router received the packet but could not forward it.
The Diagnostic Order
- Does R1 have a route to the destination? (
show ip route) - Is the next hop reachable? (ping R2's near interface from R1)
- Does R2 have correct routes?
- Does R3 have a route back to R1's network?
- Are all interfaces up? (
show ip interface brief) - Are ACLs blocking traffic?
Work from the source outward — confirm each hop before moving to the next.
Practice CCNA troubleshooting questions with exhibit-based topologies to build a systematic approach.
Full CLI Walkthrough — What to Run on Each Router
When troubleshooting this topology in a CCNA simulation, run commands in this order so you are not chasing symptoms in the wrong place.
On R1:
R1# show ip route
R1# ping 10.1.1.2
R1# ping 10.2.2.2
A route to 10.2.2.0/24 must exist in R1's routing table. If the ping to R2's near interface (10.1.1.2) succeeds but the ping to R3 (10.2.2.2) fails, R1 either has no route to 10.2.2.0 or R3 cannot send the reply back. Both look identical from R1's side — the ICMP Echo times out.
On R2:
R2# show ip interface brief
R2# show ip route
Both 10.1.1.0/24 and 10.2.2.0/24 should appear as directly connected. If either interface is down/down, that is your answer.
On R3:
R3# show ip route
R3# ping 10.1.1.1
This is the check most candidates skip. R3 must have a route to 10.1.1.0/24 for the ICMP Echo Reply to get back to R1. If it does not, R3 drops the reply silently.
Why the Return Path Is the Most Missed Step
Here is the exact failure mode. R1 sends an ICMP Echo to 10.2.2.2. The packet reaches R3 successfully — R2 routes it correctly. R3 receives the Echo, constructs a reply destined for 10.1.1.1, and then looks in its routing table. If there is no route to 10.1.1.0/24, R3 drops the packet. From R1's perspective, the ping simply times out.
This looks identical to a situation where the forward path is broken. Candidates who only check R1's routing table spend time confirming that the static route to 10.2.2.0/24 exists, see it is there, and get confused. The problem is on R3, not R1.
Static routing makes this especially dangerous because both directions must be configured explicitly. With OSPF the problem is usually more symmetric — if the routing protocol is not advertising a network in one direction, it typically is not advertising it in the other direction either.
Static vs OSPF — How Misconfiguration Looks Different
With static routes, a missing direction shows as a specific destination not appearing in show ip route:
R3# show ip route
C 10.2.2.0/24 is directly connected, Serial0/0/1
No entry for 10.1.1.0/24. R3 has no route back. Fix: add ip route 10.1.1.0 255.255.255.0 10.2.2.1 on R3.
With OSPF, a wrong wildcard mask in the network command means the interface is not included. If R2 typed network 10.1.1.0 255.255.255.0 area 0 instead of network 10.1.1.0 0.0.0.255 area 0, OSPF silently rejects the statement. The show ip protocols output shows only the correctly-matched networks.
Extended Ping — The Tool Simulation Questions Test
Basic ping on a router uses the outgoing interface IP as the source. Extended ping lets you specify the source explicitly:
R1# ping 10.2.2.2 source 10.1.1.1
If this fails but plain ping 10.2.2.2 succeeds, the routing is asymmetric. Traffic goes out one interface but the reply routes back via a different path — often because a default route exits a different interface. Extended ping surfaces this class of problem in CCNA simulation questions.
Common Mistakes When Using Static Routes Across Three Routers
The most frequent configuration error is adding the route on R1 but forgetting R3. The second most frequent is getting the wildcard mask wrong in OSPF, so the network statement does not cover the far interface.
A third trap: the next-hop address in the static route must be directly reachable from the router adding the route. On R1, the static route to 10.2.2.0/24 must use 10.1.1.2 as the next-hop — the address of R2's near interface. Using 10.2.2.2 (R3's address) as the next-hop from R1 fails because R1 cannot reach 10.2.2.2 directly.
With OSPF, make sure every router has a network statement that covers every interface involved in the topology. A single missing or incorrect wildcard mask can leave one direction of the routing unresolved.
Troubleshooting Checklist
Work through this in order before touching any configuration:
- Both interfaces on R2 are up/up — show ip interface brief
- R1 has a route to 10.2.2.0/24 — show ip route
- R2 has routes to both 10.1.1.0 and 10.2.2.0 — show ip route
- R3 has a route back to 10.1.1.0/24 — show ip route on R3
- No ACL is blocking ICMP on any router — show ip access-lists
- Static route next-hop is directly reachable (do not use a remote address as next-hop)
Practice Question Sets
The only way to build genuine speed on CCNA questions is reps under realistic conditions. Pick a session size that fits your schedule: