CCNA IP Routing Practice Question
Exhibit
R1# ping 10.1.23.2 !!!!! R1# show ip route 192.168.3.0 % Network not in table
Exhibit: R1 can ping 10.1.23.2 but cannot ping 192.168.3.10 behind R3. The routing table on R1 lacks 192.168.3.0/24. What is the best next check?
⚠ Common exam trap
A frequent exam trap is to confuse physical connectivity with routing issues. Because R1 can ping 10.1.23.2 (likely the next-hop router), candidates might mistakenly try to fix cables or interfaces instead of checking routing advertisements. Another trap is to focus on router ID changes or disabling features like CEF, which do not affect route learning. The key mistake is ignoring the routing table contents and assuming that reachability to the next-hop router guarantees full path reachability. This leads to wasted time and incorrect troubleshooting steps.
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 whether the remote LAN is being advertised into the routing process
Because the directly connected next router is reachable, the problem is likely missing routing information for the remote LAN. The best next check is whether R3 is advertising 192.168.3.0/24 or whether that network is present in the routing domain at all.
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 whether the remote LAN is being advertised into the routing process
Why this is correct
The symptom that R1 can ping the next-hop address 10.1.23.2 but not 192.168.3.10 indicates that reachability to the remote host is blocked at the routing layer, not the link layer. Since OSPF neighbors are up (the next hop responds), the most likely cause is that the subnet containing 192.168.3.10 is not being injected into the OSPF domain—either because there is no network statement under the OSPF process on the router that owns that LAN, because the interface is configured as passive-interface, or because an outbound distribute-list is filtering the route. Verifying the OSPF database for the 192.168.3.0/24 prefix directly confirms whether the route is being advertised.
- ✗
Replace the Ethernet cable between R1 and R2
Why it's wrong here
Replacing the Ethernet cable between R1 and R2 is irrelevant because R1 can already ping 10.1.23.2, which is the IP address on the R2-facing interface. Successful ICMP to that next-hop address proves that Layer 1 and Layer 2 connectivity across that segment are functioning correctly, including cabling, switchports, and interface status. The failure is specific to the remote LAN 192.168.3.10, so the issue lies in route propagation or routing policies, not the physical medium to the directly connected neighbor.
When this WOULD be correct
This would be correct in a scenario where R1 cannot ping R2's directly connected interface (e.g., 10.1.23.2) and there is evidence of physical connectivity issues, such as link lights off or interface down/down. The question would explicitly state that Layer 1/2 is suspected.
- ✗
Change the OSPF router ID on R1 immediately
Why it's wrong here
Changing the OSPF router ID on R1 is not a valid next step because the router ID is used only to identify the router in OSPF neighbor relationships and for DR/BDR elections on broadcast segments; it has no bearing on whether a remote LAN is advertised or selected in the routing table. A router-ID mismatch or a duplicate router ID would cause OSPF adjacency problems, but since R1 can reach the next-hop router at 10.1.23.2, the OSPF neighbor relationship is functioning. There is no evidence of a router-ID conflict, and altering it would only reset OSPF adjacencies, potentially causing a temporary outage without addressing the missing route.
When this WOULD be correct
In a scenario where OSPF adjacencies fail to form due to duplicate router IDs, changing the router ID on one router (and restarting OSPF) would be the correct step to resolve the adjacency issue and allow route exchange.
- ✗
Disable CEF so the route can be learned
Why it's wrong here
Disabling CEF (Cisco Express Forwarding) on R1 would not help because CEF is a packet-switching mechanism that operates only after a route is installed in the routing table; it does not influence OSPF's ability to learn or receive routes. Even with CEF disabled, OSPF will still populate the RIB with the 192.168.3.0/24 prefix if that network is advertised by a neighbor. The absence of connectivity is due to missing route information, not forwarding-mode behavior, so disabling CEF would leave the routing table unchanged and the ping would still fail.
When this WOULD be correct
In a scenario where a router has a route in the routing table but packets are not being forwarded correctly (e.g., due to CEF polarization or a CEF-related bug), disabling CEF might be a troubleshooting step to verify if CEF is causing the forwarding failure. For example, if R1 can ping 10.1.23.2 but traffic to 192.168.3.10 fails despite the route being present, disabling CEF could isolate the issue.
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 whether the remote LAN is being advertised into the routing processCorrect answer▾
Why this is correct
The symptom that R1 can ping the next-hop address 10.1.23.2 but not 192.168.3.10 indicates that reachability to the remote host is blocked at the routing layer, not the link layer. Since OSPF neighbors are up (the next hop responds), the most likely cause is that the subnet containing 192.168.3.10 is not being injected into the OSPF domain—either because there is no network statement under the OSPF process on the router that owns that LAN, because the interface is configured as passive-interface, or because an outbound distribute-list is filtering the route. Verifying the OSPF database for the 192.168.3.0/24 prefix directly confirms whether the route is being advertised.
✗Replace the Ethernet cable between R1 and R2Wrong answer — click to see why▾
Why this is wrong here
The question states R1 can ping 10.1.23.2 (R2) but not 192.168.3.10 behind R3, and the routing table lacks 192.168.3.0/24. This indicates a routing advertisement issue, not a physical layer problem. Replacing the Ethernet cable would not fix a missing route.
★ When this WOULD be the correct answer
This would be correct in a scenario where R1 cannot ping R2's directly connected interface (e.g., 10.1.23.2) and there is evidence of physical connectivity issues, such as link lights off or interface down/down. The question would explicitly state that Layer 1/2 is suspected.
Why candidates choose this
Candidates often jump to physical layer troubleshooting when connectivity fails, especially if they overlook that partial reachability (ping to R2 works) already rules out a cable problem. The temptation is to assume any connectivity issue could be caused by a faulty cable.
✗Change the OSPF router ID on R1 immediatelyWrong answer — click to see why▾
Why this is wrong here
Changing the OSPF router ID on R1 does not affect route advertisement of remote LANs; it only influences OSPF neighbor relationships and LSA origination, not the presence of a specific prefix in the routing table.
★ When this WOULD be the correct answer
In a scenario where OSPF adjacencies fail to form due to duplicate router IDs, changing the router ID on one router (and restarting OSPF) would be the correct step to resolve the adjacency issue and allow route exchange.
Why candidates choose this
Candidates may think that a router ID mismatch or misconfiguration prevents route learning, but here the problem is that the route is not being advertised, not an OSPF neighbor issue.
✗Disable CEF so the route can be learnedWrong answer — click to see why▾
Why this is wrong here
Disabling CEF (Cisco Express Forwarding) would not help R1 learn the missing route; CEF is a switching mechanism that optimizes packet forwarding, not a routing protocol that learns routes. The issue is that 192.168.3.0/24 is not in the routing table, indicating a routing advertisement problem, not a CEF issue.
★ When this WOULD be the correct answer
In a scenario where a router has a route in the routing table but packets are not being forwarded correctly (e.g., due to CEF polarization or a CEF-related bug), disabling CEF might be a troubleshooting step to verify if CEF is causing the forwarding failure. For example, if R1 can ping 10.1.23.2 but traffic to 192.168.3.10 fails despite the route being present, disabling CEF could isolate the issue.
Why candidates choose this
Candidates may confuse CEF with routing table population, thinking that disabling CEF forces the router to use process switching and thus learn routes via routing protocols. However, CEF does not affect route learning; it only affects how packets are forwarded after routes are learned.
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
Quick reference
Routing Protocol Comparison
| Protocol | Metric | Max Hops | Algorithm | Type |
|---|---|---|---|---|
| RIP v2 | Hop count | 15 | Bellman-Ford | Distance vector |
| OSPF | Cost (bandwidth) | Unlimited | Dijkstra (SPF) | Link state |
| EIGRP | Composite metric | Unlimited | DUAL | Hybrid |
| IS-IS | Cost | Unlimited | Dijkstra | Link state |
| BGP | Policy / attributes | Unlimited | Path vector | Path vector |
RIP's 15-hop limit makes it unsuitable for large networks. OSPF and EIGRP dominate modern enterprise deployments.
Go deeper
Related to this question
Learn chapter
OSPFv3 Single-Area Configuration for IPv6
Key term
Ping
Ping is a network utility used to test whether a remote computer or device is reachable across an IP network and to measure the round-trip time of data packets.
Key term
Routing table
A routing table is a data set stored in a router or host that contains information about network paths and is used to determine where to forward data packets.
About these practice questions
Courseiva writes every 200-301 question from scratch — 1,389 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.