Courseiva
IP RoutinghardMultiple ChoiceObjective-mapped

CCNA IP Routing Practice Question

Two OSPF routers connected on an Ethernet link remain in the INIT state. Which issue is the most likely cause?

⚠ Common exam trap

A common exam trap is to assume that duplicate router IDs cause routers to remain stuck in the INIT state. While duplicate router IDs do cause adjacency issues, they typically result in different neighbor states or error messages, not the INIT state specifically. Another trap is to think that using the same OSPF process ID on both routers causes adjacency failure; however, the process ID is locally significant and does not affect neighbor formation. Misinterpreting the INIT state as a sign of routers already being fully adjacent or waiting to install routes is also incorrect, as FULL is a later state. The key is to recognize that INIT indicates one-way Hello communication, often due to Layer 2 or multicast issues.

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

The routers cannot exchange Hellos bidirectionally on the segment

INIT means a router is seeing Hellos from its neighbor but does not see its own router ID in the neighbor field of received Hellos. A common cause is one-way communication or a mismatched multicast/adjacency problem, often at Layer 2.

Answer analysis

Option-by-option breakdown

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

  • The routers have identical router IDs

    Why it's wrong here

    Duplicate Router IDs do cause serious OSPF problems, but those problems typically surface after the routers have exchanged Hellos and progressed to the ExStart or Exchange states, not while stuck in INIT. In INIT, a router is looking for its own Router ID inside the neighbor's Hello; having identical IDs could actually trick the router into thinking it has seen itself, but this leads to identifier conflicts, neighbor flapping, and rejection during database exchange. The most common reason for a persistent INIT state is unidirectional Hello delivery—due to multicast filtering, access lists, or mismatched hello/dead intervals—not duplicate Router IDs.

    When this WOULD be correct

    In a different scenario, if the question asked about OSPF routers failing to establish adjacency due to configuration errors, such as a misconfigured network segment where router IDs are incorrectly set to the same value, this option could be correct. For example, if the routers were on a point-to-point link and the question specified that they could not form a neighbor relationship due to identical router IDs, then this would be valid.

  • The routers cannot exchange Hellos bidirectionally on the segment

    Why this is correct

    In OSPF, the INIT state means that a router has received a Hello packet from a neighbor but did not find its own Router ID listed in that Hello, so bidirectional communication is not yet confirmed. This situation often arises from mismatched OSPF network types, incorrect subnet masks, or outbound/inbound Hello filtering on the Ethernet segment. Until both routers see each other's Router IDs in their respective Hello packets, they cannot proceed to 2-WAY and beyond, leaving the adjacency perpetually stuck in INIT.

  • The routers have already reached FULL and are waiting to install routes

    Why it's wrong here

    FULL is a much later neighbor state that occurs after the Database Exchange and Loading processes complete, meaning the routers have already synchronized their link-state databases. In FULL state, LSAs have been exchanged and routes are installed via SPF calculations independently, not while waiting to install routes. Since the question describes routers remaining in INIT, that state is far earlier in the adjacency formation, so reaching FULL first would be a logical impossibility.

    When this WOULD be correct

    In a different scenario where the question states that two OSPF routers are already in the FULL state and are experiencing issues with route installation, this option would be correct, indicating that they are waiting for route updates or processing.

  • The routers are using the same OSPF process ID

    Why it's wrong here

    The OSPF process ID is a locally significant parameter used by the IOS to identify a routing process on a single router; it is never transmitted in OSPF Hello packets. Because the process ID is not part of the Hello message, two routers can use different process IDs on the same link and still form an adjacency. Therefore, sharing the same process ID has no effect on neighbor state progression, and the real cause of INIT is one-way Hello reception rather than any process ID matching requirement.

    When this WOULD be correct

    In a scenario where the question specifies that two OSPF routers are on different networks but have been configured with the same OSPF process ID, the option would be correct if the question asks about potential issues in establishing OSPF adjacency. In this case, the process ID conflict would prevent proper neighbor formation.

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.

The routers cannot exchange Hellos bidirectionally on the segmentCorrect answer

Why this is correct

In OSPF, the INIT state means that a router has received a Hello packet from a neighbor but did not find its own Router ID listed in that Hello, so bidirectional communication is not yet confirmed. This situation often arises from mismatched OSPF network types, incorrect subnet masks, or outbound/inbound Hello filtering on the Ethernet segment. Until both routers see each other's Router IDs in their respective Hello packets, they cannot proceed to 2-WAY and beyond, leaving the adjacency perpetually stuck in INIT.

The routers have identical router IDsWrong answer — click to see why

Why this is wrong here

Duplicate router IDs can cause adjacency issues, but the INIT state specifically indicates that a router has received a Hello from a neighbor but the neighbor has not received a Hello back. Duplicate IDs typically lead to neighbor state flapping or failure to progress beyond EXSTART, not INIT.

★ When this WOULD be the correct answer

In a different scenario, if the question asked about OSPF routers failing to establish adjacency due to configuration errors, such as a misconfigured network segment where router IDs are incorrectly set to the same value, this option could be correct. For example, if the routers were on a point-to-point link and the question specified that they could not form a neighbor relationship due to identical router IDs, then this would be valid.

Why candidates choose this

Students may confuse the symptoms of duplicate router IDs with one-way communication, as both can prevent full adjacency. However, duplicate IDs are detected during the exchange of Database Description packets, not during the Hello phase.

The routers have already reached FULL and are waiting to install routesWrong answer — click to see why

Why this is wrong here

The FULL state is the final OSPF neighbor state, indicating that the routers have completed the adjacency process and have identical LSDBs. Routers in FULL do not wait to install routes; they already have the full topology. INIT is an early state, far before FULL.

★ When this WOULD be the correct answer

In a different scenario where the question states that two OSPF routers are already in the FULL state and are experiencing issues with route installation, this option would be correct, indicating that they are waiting for route updates or processing.

Why candidates choose this

Students might think that after reaching FULL, routers wait for a timer to install routes, confusing OSPF with other protocols like EIGRP. However, OSPF installs routes immediately upon reaching FULL.

The routers are using the same OSPF process IDWrong answer — click to see why

Why this is wrong here

The OSPF process ID is locally significant and is not exchanged in Hello packets. Two routers can have different process IDs and still form an adjacency. Therefore, identical process IDs are not required and do not cause the INIT state.

★ When this WOULD be the correct answer

In a scenario where the question specifies that two OSPF routers are on different networks but have been configured with the same OSPF process ID, the option would be correct if the question asks about potential issues in establishing OSPF adjacency. In this case, the process ID conflict would prevent proper neighbor formation.

Why candidates choose this

Students often confuse the OSPF process ID with the area ID or autonomous system number, thinking they must match for adjacency. However, only area ID, subnet mask, Hello/dead intervals, and authentication must match.

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

This 200-301 question is part of Courseiva's 1,389-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 →

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.