Courseiva
IP RoutinghardMultiple ChoiceObjective-mapped

CCNA IP Routing Practice Question

Exhibit

R1 G0/0: ip 10.1.12.1/30, ip ospf hello-interval 10, ip ospf dead-interval 40
R2 G0/0: ip 10.1.12.2/30, ip ospf hello-interval 5,  ip ospf dead-interval 20
Both interfaces are up/up and in area 0.

R1 and R2 are directly connected via Ethernet on interface G0/0. Both interfaces are in the same subnet and configured for OSPF area 0. After enabling OSPF, R1's G0/0 is stuck in the INIT state in the OSPF neighbor table. What is the most likely cause?

⚠ Common exam trap

A common exam trap is selecting MTU mismatch or missing router IDs as the cause of OSPF adjacency failure. While MTU mismatches can cause adjacency issues during database exchange, they do not prevent the initial neighbor relationship from forming. Missing router IDs do not block adjacency because routers automatically generate IDs if none are configured. Another trap is confusing static routes with neighbor discovery; static routes do not influence OSPF adjacency. The key is to focus on timer mismatches, as hello and dead intervals must be identical for routers to recognize each other as neighbors and establish adjacency.

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

Hello and dead timer mismatch

Being stuck in the INIT state means R1 has received Hello packets from R2 but has not transitioned to the 2-WAY state. This most often occurs when critical OSPF parameters like the hello and dead timers do not match. An MTU mismatch, while problematic, would cause the adjacency to fail during database exchange (Exstart/Exchange), not during initial neighbor formation. Missing router IDs are not a real issue because routers auto-generate them, and a duplicate static route to the connected subnet would not affect OSPF neighbor discovery.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • MTU mismatch

    Why it's wrong here

    An MTU mismatch on the GigabitEthernet link will not prevent OSPF from receiving Hellos and forming a neighbor relationship; it typically causes the adjacency to become stuck in EXSTART/EXCHANGE because DBD packets are larger than the smaller MTU and get dropped. Since the problem is that no adjacency forms at all (not even a stuck state), this distractor would not explain a complete failure. In a properly operating OSPF, Hellos are small enough to pass regardless of MTU, so initial neighbor discovery is unaffected.

    When this WOULD be correct

    In a different scenario where the question specifies that both routers are configured with different MTU sizes, and the OSPF packets exceed the smaller MTU, this option would be correct. For example, if R1 has an MTU of 1500 and R2 has an MTU of 1400, this could lead to adjacency issues.

  • Hello and dead timer mismatch

    Why this is correct

    OSPF adjacency requires that Hello and Dead intervals match exactly between neighbors on the same link. The Dead interval is typically four times the Hello interval, but if one side is configured with different timers (e.g., 10/40 vs 30/120), the routers will discard each other's Hello packets and never reach the 2-Way state. This is the classic cause of a neighbor relationship that remains completely down, with no OSPF neighbor entry at all.

  • Missing router ID on both routers

    Why it's wrong here

    OSPF does not require an explicitly configured router ID; if none is set, the router automatically selects the highest loopback address, or if no loopback exists, the highest active interface IP address. As long as each router has at least one active interface with an IP address, a unique router ID will be determined automatically, and the OSPF process can still originate Hellos and establish adjacency. Therefore, the absence of a manually configured router ID is not a barrier to forming an adjacency.

    When this WOULD be correct

    In a different question, if the scenario described routers that were configured to use OSPF but had no router ID set, and the question asked why OSPF routes were not being advertised, then this option would be correct as it directly impacts OSPF operation.

  • A duplicate static route to 10.1.12.0/30

    Why it's wrong here

    Static routes are stored in the routing table and have no effect on the OSPF process itself; OSPF neighbor discovery and adjacency formation are carried out via multicast hello packets on the link, independent of any routing table entries. Even if a static route duplicates the OSPF-learned route, it does not change OSPF hello/dead timers, router IDs, or the exchange of Link-State Advertisements. Thus, a duplicate static route is completely irrelevant to the inability to form an OSPF adjacency.

    When this WOULD be correct

    In a scenario where the question specifies that R1 and R2 are using static routing instead of OSPF, and both routers have a duplicate static route configured for the same destination, this could lead to routing conflicts. The question would need to focus on static routing behavior rather than OSPF adjacency.

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.

Hello and dead timer mismatchCorrect answer

Why this is correct

OSPF adjacency requires that Hello and Dead intervals match exactly between neighbors on the same link. The Dead interval is typically four times the Hello interval, but if one side is configured with different timers (e.g., 10/40 vs 30/120), the routers will discard each other's Hello packets and never reach the 2-Way state. This is the classic cause of a neighbor relationship that remains completely down, with no OSPF neighbor entry at all.

MTU mismatchWrong answer — click to see why

Why this is wrong here

An MTU mismatch would typically prevent OSPF packets from being successfully transmitted, but it does not directly cause an adjacency failure. OSPF can still establish adjacency if the MTU is mismatched, as long as the packets are small enough to be transmitted.

★ When this WOULD be the correct answer

In a different scenario where the question specifies that both routers are configured with different MTU sizes, and the OSPF packets exceed the smaller MTU, this option would be correct. For example, if R1 has an MTU of 1500 and R2 has an MTU of 1400, this could lead to adjacency issues.

Why candidates choose this

Candidates may choose this option because they associate MTU mismatches with connectivity issues in networking, leading them to believe it could be a plausible cause for OSPF adjacency failures.

Missing router ID on both routersWrong answer — click to see why

Why this is wrong here

This option is wrong because a missing router ID does not prevent OSPF adjacency formation; it only affects OSPF routing. OSPF can still establish adjacencies without a router ID, as it will generate a default one if not configured.

★ When this WOULD be the correct answer

In a different question, if the scenario described routers that were configured to use OSPF but had no router ID set, and the question asked why OSPF routes were not being advertised, then this option would be correct as it directly impacts OSPF operation.

Why candidates choose this

Candidates may choose this option because they associate router IDs with OSPF functionality and believe that a missing router ID would inherently disrupt OSPF operations, leading to adjacency issues.

A duplicate static route to 10.1.12.0/30Wrong answer — click to see why

Why this is wrong here

A duplicate static route to 10.1.12.0/30 would not prevent R1 and R2 from forming an OSPF adjacency, as OSPF does not rely on static routes for neighbor relationships. OSPF adjacency issues are typically related to configuration mismatches rather than routing table entries.

★ When this WOULD be the correct answer

In a scenario where the question specifies that R1 and R2 are using static routing instead of OSPF, and both routers have a duplicate static route configured for the same destination, this could lead to routing conflicts. The question would need to focus on static routing behavior rather than OSPF adjacency.

Why candidates choose this

Candidates might choose this option because they associate routing issues with static routes and believe that any routing conflict could disrupt OSPF operations, even though this is not the case.

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

R1 R2 R3 R4 10 100 10 100 OSPF picks R1→R2→R4 (cost 20) over R1→R3→R4 (cost 200)

Quick reference

Routing Protocol Comparison

ProtocolMetricMax HopsAlgorithmType
RIP v2Hop count15Bellman-FordDistance vector
OSPFCost (bandwidth)UnlimitedDijkstra (SPF)Link state
EIGRPComposite metricUnlimitedDUALHybrid
IS-ISCostUnlimitedDijkstraLink state
BGPPolicy / attributesUnlimitedPath vectorPath vector

RIP's 15-hop limit makes it unsuitable for large networks. OSPF and EIGRP dominate modern enterprise deployments.

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 →

How Courseiva writes practice questions · Editorial policy

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.