Question 1,076 of 1,819
IP RoutinghardMultiple ChoiceObjective-mapped

Quick Answer

The correct next step is to check whether an inbound ACL on R3 is blocking packets with R1’s source IP address. This is because the ping failure is isolated to traffic sourced specifically from R1, while R2 can successfully ping the same destination, confirming that routing, Layer 3 reachability, and the return path from R3 to R2’s subnet are all functional. The problem must therefore be a filtering rule on R3 that denies R1’s source IP, likely applied as an inbound access-list on the interface receiving the ICMP echo requests. On the CCNA 200-301 v2 exam, this scenario tests your ability to differentiate between routing failures and ACL-based filtering, a common trap where students waste time rechecking OSPF neighbors or default routes when the real issue is a security policy. A useful memory tip is “source-specific silence”—if one source can ping but another cannot, suspect an ACL targeting the failing source IP.

CCNA IP Routing Practice Question

This 200-301 practice question tests your understanding of ip routing. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

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?

Question 1hardmultiple choice
Review the full routing breakdown →

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

Check whether an inbound ACL on R3 is blocking packets with R1’s source IP address.

Because R2 can successfully ping R3, we know that R3 is reachable, the path from R2 to R3 is functional, OSPF (or whatever IGP) is working between them, and R3 has a route back to R2's subnet. The failure is isolated to traffic sourced from R1. This strongly suggests a filtering issue that specifically denies R1's source IP address. Checking for an inbound ACL on R3’s receiving interface is the logical next step at the transport/application layer; it directly tests the hypothesis that R3 is receiving R1’s pings but discarding them due to a security policy. It avoids unnecessary investigation of routing or link-layer problems that have already been ruled out.

Key principle: OSPF neighbour adjacency depends on matching area, hello/dead timers, network type, and authentication — IP reachability alone is not enough.

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 it's wrong here

    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 this is correct

    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.

    Related concept

    OSPF neighbours must agree on key parameters.

  • 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.

Check whether an inbound ACL on R3 is blocking packets with R1’s source IP address.Correct answer

Why this is correct

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.

Verify that R3 has a route back to R1’s subnet.Wrong answer — click to see why

Why this is wrong here

It skips the more targeted hypothesis that an access control list is selectively blocking R1. The candidate mistakenly assumes that a unidirectional reachability problem is always caused by a missing return route.

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?”

Common exam traps

Common exam trap: OSPF can fail even when IP connectivity looks correct

OSPF neighbour formation depends on matching areas, timers, network type, authentication and passive-interface behaviour. Do not choose an answer only because the devices can ping.

Trap categories for this question

  • Scenario analysis trap

    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.

Detailed technical explanation

How to think about this question

OSPF questions usually test the details that control adjacency and route selection. Read the neighbour state, area, router ID and interface configuration before deciding what is wrong.

KKey Concepts to Remember

  • OSPF neighbours must agree on key parameters.
  • Router ID selection can affect neighbour relationships and LSDB output.
  • OSPF cost influences the preferred path.
  • A route can appear in OSPF information but not become the installed route.

TExam Day Tips

  • Check area mismatch first when OSPF adjacency fails.
  • Review passive interfaces when a network is advertised but no neighbour forms.
  • Use show ip ospf neighbor and show ip route clues carefully.

Key takeaway

OSPF neighbour adjacency depends on matching area, hello/dead timers, network type, and authentication — IP reachability alone is not enough.

Real-world example

How this comes up in practice

A network engineer at a university connects two campus buildings via a fibre link. Both routers run OSPF, but no adjacency forms — even though both routers can ping each other. The engineer finds one router is in area 0 and the other in area 1. OSPF adjacency requires matching area numbers, hello/dead timers, and network type. IP reachability alone is not enough.

What to study next

Got this wrong? Here's your next step.

Review OSPF neighbour requirements — matching area type, hello and dead timers, network type, stub flags, and authentication. Study show ip ospf neighbor states (INIT, 2-WAY, FULL). Then practise related 200-301 OSPF questions on adjacency and route selection.

Related practice questions

Related 200-301 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

Practice this exam

Start a free 200-301 practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

FAQ

Questions learners often ask

What does this 200-301 question test?

IP Routing — This question tests IP Routing — OSPF neighbours must agree on key parameters..

What is the correct answer to this question?

The correct answer is: Check whether an inbound ACL on R3 is blocking packets with R1’s source IP address. — Because R2 can successfully ping R3, we know that R3 is reachable, the path from R2 to R3 is functional, OSPF (or whatever IGP) is working between them, and R3 has a route back to R2's subnet. The failure is isolated to traffic sourced from R1. This strongly suggests a filtering issue that specifically denies R1's source IP address. Checking for an inbound ACL on R3’s receiving interface is the logical next step at the transport/application layer; it directly tests the hypothesis that R3 is receiving R1’s pings but discarding them due to a security policy. It avoids unnecessary investigation of routing or link-layer problems that have already been ruled out.

What should I do if I get this 200-301 question wrong?

Review OSPF neighbour requirements — matching area type, hello and dead timers, network type, stub flags, and authentication. Study show ip ospf neighbor states (INIT, 2-WAY, FULL). Then practise related 200-301 OSPF questions on adjacency and route selection.

What is the key concept behind this question?

OSPF neighbours must agree on key parameters.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Keep practising

More 200-301 practice questions

Last reviewed: Jun 14, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

Sign in to join the discussion.

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.