CCNA IP Routing Practice Question
R1 cannot reach host 10.3.3.1 on R3. The technician checks routing: R1 has a route to 10.3.3.0/24 via next-hop 10.1.1.2 (R2). R2 has a route to 10.3.3.0/24 via next-hop 10.2.2.2 (R3). A ping from R1 to 10.3.3.1 times out. A ping from R2 to 10.3.3.1 succeeds. What should the technician do next?
⚠ Common exam trap
A successful ping from an intermediate router does not prove end-to-end connectivity. You must always consider the return path from the destination to the original source. A missing route on the destination router back to the source subnet is a common cause of asymmetric reachability.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Verify that R3 has a route back to R1’s subnet.
Since R2 can ping 10.3.3.1 successfully, R2 has connectivity to R3, and R3 can send replies to R2's subnet. The failure from R1 indicates that while the forward path from R1 to R3 works, the return path from R3 to R1 is broken. The most likely cause is that R3 does not have a route back to R1's subnet (10.1.1.0/24). Therefore, the technician should verify R3's routing table for a return route to R1's subnet. An inbound ACL on R3 would affect the forward path (the echo request), not the return path, and would be a secondary check after confirming routing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Verify that R3 has a route back to R1’s subnet.
Why this is correct
If R3 were missing a route to R1’s subnet, it would not be able to send reply packets to R1. However, R2 and R1 typically reside in the same stub network (e.g., 10.1.1.0/24). The fact that R2 can ping R3 successfully proves that R3 already has a working return path to that network via R2. Checking the routing table at this stage duplicates a condition that is already indirectly verified.
- ✗
Check whether an inbound ACL on R3 is blocking packets with R1’s source IP address.
Why it's wrong here
The symptom is that pings from R1 fail while pings from R2 succeed. This points to a packet filter that treats the two source addresses differently. An ACL applied to the interface on R3 that receives the pings could be permitting traffic from R2 but denying traffic from R1. Inspecting the ACL directly tests this hypothesis and is a precise next troubleshooting step.
When this WOULD be correct
R2 can reach R3, confirming that general routing, OSPF, and the return path to R2 are all operational; the failure is specific to R1’s source IP, making ACL inspection the most logical next action.
- ✗
Verify the OSPF neighbor adjacency between R2 and R3.
Why it's wrong here
R2’s successful ping to R3 relies on proper routing, which in turn depends on OSPF if dynamic routing is used. A failed adjacency would prevent R2 from reaching R3’s loopback or connected interface, so the ping from R2 would also fail. Thus, the OSPF adjacency is already proven to be functional.
- ✗
Test for an MTU mismatch along the path from R1 to R3.
Why it's wrong here
An MTU mismatch typically causes problems only with large packets, while small pings (the default ICMP echo size) succeed. In this scenario, standard-sized pings from R1 time out entirely, and pings from R2 succeed, which is inconsistent with an MTU issue. Furthermore, an MTU problem would affect all traffic over the path, not just traffic from a specific source.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓Verify that R3 has a route back to R1’s subnet.Correct answer▾
Why this is correct
If R3 were missing a route to R1’s subnet, it would not be able to send reply packets to R1. However, R2 and R1 typically reside in the same stub network (e.g., 10.1.1.0/24). The fact that R2 can ping R3 successfully proves that R3 already has a working return path to that network via R2. Checking the routing table at this stage duplicates a condition that is already indirectly verified.
✗Check whether an inbound ACL on R3 is blocking packets with R1’s source IP address.Wrong answer — click to see why▾
Why this is wrong here
The symptom is that pings from R1 fail while pings from R2 succeed. This points to a packet filter that treats the two source addresses differently. An ACL applied to the interface on R3 that receives the pings could be permitting traffic from R2 but denying traffic from R1. Inspecting the ACL directly tests this hypothesis and is a precise next troubleshooting step.
★ When this WOULD be the correct answer
R2 can reach R3, confirming that general routing, OSPF, and the return path to R2 are all operational; the failure is specific to R1’s source IP, making ACL inspection the most logical next action.
✗Verify the OSPF neighbor adjacency between R2 and R3.Wrong answer — click to see why▾
Why this is wrong here
This option investigates a Layer 3 adjacency that the successful R2-to-R3 ping has already validated. Candidates often default to checking neighbor state without considering the evidence that rules it out.
✗Test for an MTU mismatch along the path from R1 to R3.Wrong answer — click to see why▾
Why this is wrong here
Candidates may recall MTU as a cause of intermittent connectivity issues, but here the symptom is a total failure from one source, making MTU a low-probability next step.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Go deeper
Related to this question
Learn chapter
Troubleshoot: Static Route Not Working
Key term
Access Control List
An Access Control List is a set of rules that decides which traffic is allowed or denied entry to a network or device.
Key term
Inbound ACL
An inbound ACL is a set of rules applied to network traffic entering an interface that decides whether to allow or block that traffic based on criteria like source IP, destination port, or protocol.
About these practice questions
This 200-301 question is part of Courseiva's 1,450-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.