When OSPF neighbors get stuck in the INIT state, route exchange halts and the network may experience routing black holes or suboptimal paths. This is a classic CCNA 200-301 troubleshooting scenario (exam objective 3.4) that tests your ability to diagnose Layer 3 connectivity, authentication mismatches, and OSPF packet filtering. Mastering this topic not only helps you pass the exam but also equips you to fix real-world adjacency failures quickly.
Jump to a section
Imagine two radio operators, Alice and Bob, trying to establish a communication channel. Alice sends a greeting: 'This is Alice, can you hear me?' (Hello packet). Bob hears it and replies: 'Alice, I hear you. This is Bob, can you hear me?' (Hello packet with Alice's ID). At this point, Alice knows Bob exists but hasn't confirmed that Bob can hear her reply. Alice then sends a second greeting: 'Bob, I hear you too' (Hello packet with Bob's ID). Bob receives it and now both know they can hear each other. They have established a two-way communication and can proceed to exchange detailed messages (Database Description packets). Now imagine Bob's radio has a faulty receiver: he hears Alice's first greeting but Alice never hears Bob's reply. Alice keeps sending her greeting but never sees Bob's ID in any received Hello. Alice remains in the INIT state—she knows Bob is out there (she heard his first transmission) but has no confirmation of two-way communication. In OSPF terms, a router in INIT state has received a Hello from the neighbor but has not seen its own Router ID in the neighbor's Hello packet. The analogy highlights that INIT means one-way reception is working, but the return path is broken. Common causes: ACL blocking OSPF packets, mismatched authentication, or a neighbor not sending Hellos due to passive interface configuration.
What is the INIT State and Why Does It Exist?
The OSPF neighbor state machine defines the progression from Down to Full. The INIT state is the first state after Down when a router receives a Hello packet from a neighbor but has not yet established two-way communication. Specifically, a router enters INIT when it sees a Hello packet containing its own interface IP address (or the neighbor's Router ID, depending on network type) but does not yet see its own Router ID in the neighbor's Hello. This indicates that the router knows the neighbor exists, but the neighbor may not have received any Hello from this router yet.
Step-by-Step Mechanism at the Packet Level
Hello Transmission: Router R1 sends a multicast Hello packet (224.0.0.5) on its OSPF-enabled interface. This Hello contains R1's Router ID, a list of neighbors seen (initially empty), and OSPF parameters (area ID, subnet mask, hello interval, dead interval, authentication type, etc.).
Hello Reception: Router R2 receives R1's Hello. R2 checks if the OSPF parameters match its own configuration on the interface. If they match, R2 adds R1 to its neighbor table in the INIT state. R2 then sends its own Hello packet, which now includes R1's Router ID in the neighbor list (indicating R2 has seen R1).
Transition to 2-Way: When R1 receives R2's Hello and sees its own Router ID in the neighbor list, R1 moves the neighbor state from INIT to 2-Way. This confirms bidirectional communication. If R1 never sees its Router ID in R2's Hello, R1 remains in INIT.
Why a Router Stays in INIT
A router stays in INIT if it receives Hellos from the neighbor but never sees its own Router ID in those Hellos. Possible causes:
Unidirectional Link: The neighbor is not receiving Hellos from this router. This could be due to a Layer 1 issue (fiber cut, bad cable) or Layer 2 issue (VLAN mismatch, wrong encapsulation) only in one direction. In Ethernet, this is rare but possible with media converters or faulty transceivers.
ACL Blocking Outgoing Hellos: An access list on the neighbor's interface might be blocking OSPF packets (protocol 89) from this router.
Passive Interface: The neighbor's interface is configured as passive-interface, which stops sending Hellos but still receives them. The neighbor will never include this router's ID in any Hello, so the neighbor stays in INIT.
Authentication Mismatch: If authentication is configured only on one side, the neighbor may silently discard Hellos. The router sees Hellos from the neighbor (if neighbor sends them) but the neighbor never sees this router's Hellos (because they are discarded), so the neighbor never includes this router's ID.
Wrong Network Type: Mismatched OSPF network types (e.g., one side broadcast, the other point-to-point) can cause Hello parameters to differ (hello interval, dead interval), causing Hellos to be ignored. However, this usually results in the neighbor never being seen (Down) rather than stuck in INIT.
Key States, Timers, and Defaults
Hello Interval: Default 10 seconds for broadcast and point-to-point networks; 30 seconds for NBMA.
Dead Interval: Default 4 times the hello interval (40 seconds for broadcast; 120 seconds for NBMA).
OSPF Router ID: A 32-bit number, typically the highest loopback IP or the highest active interface IP. Must be unique.
Neighbor States: Down, Attempt (NBMA only), Init, 2-Way, ExStart, Exchange, Loading, Full.
IOS CLI Verification Commands
Use show ip ospf neighbor to check neighbor states. If a neighbor is stuck in INIT, you see:
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 INIT/DROTHER 00:00:38 192.168.1.2 GigabitEthernet0/0Notice the state is INIT, and the Dead Time is counting down. The neighbor is receiving Hellos but has not confirmed two-way.
To debug further:
show ip ospf interface [interface] – Check OSPF parameters (network type, timers, passive status).
show ip interface [interface] – Check ACLs applied to the interface.
debug ip ospf hello – Watch Hello packets in real time to see if your Router ID appears in received Hellos.
Interaction with Related Protocols
OSPF relies on IP protocol 89. Any ACL or firewall filtering IP protocol 89 will break adjacency. Additionally, OSPF uses multicast addresses 224.0.0.5 (all OSPF routers) and 224.0.0.6 (DR/BDR). IGMP snooping misconfiguration on switches can drop these multicasts, leading to INIT state.
Verify Neighbor State
Use `show ip ospf neighbor` to confirm the neighbor is stuck in INIT. Note the neighbor's Router ID and interface. This command gives you a quick snapshot: if the state is INIT, you know one-way communication is working but the return path is not. Document the output for later comparison after changes. ``` R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 INIT/DROTHER 00:00:38 192.168.1.2 GigabitEthernet0/0 ``` If the neighbor is not listed at all, the issue is likely at Layer 1 or 2, or OSPF is not enabled on the interface.
Check OSPF Interface Parameters
Run `show ip ospf interface GigabitEthernet0/0` on both routers. Verify that the network type, hello interval, dead interval, area ID, and authentication settings match. A mismatch in these parameters causes Hellos to be ignored, but the symptom is often INIT because one side still sees Hellos from the other (if the mismatched side still sends Hellos that the other side accepts). ``` R1# show ip ospf interface GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 10.0.0.1, Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 10.0.0.2, Interface address 192.168.1.2 Backup Designated router (ID) 10.0.0.1, Interface address 192.168.1.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:04 Neighbor Count is 1, Adjacent neighbor count is 0 Adjacent with neighbor 10.0.0.2 (Backup Designated Router) Suppress hello for 0 neighbor(s) ``` Pay attention to the 'Neighbor Count' and 'Adjacent neighbor count'. If neighbor count is 1 but adjacent count is 0, the neighbor is in INIT or 2-Way.
Verify ACLs and Firewall Rules
Check for inbound and outbound ACLs on the interface that might block OSPF (IP protocol 89). Use `show ip interface GigabitEthernet0/0` to see if an ACL is applied. If an ACL is present, examine it with `show access-lists <acl-name>`. Look for any deny statements that match OSPF packets. Also check if there are any firewall rules on intermediate devices (like a stateful firewall) that drop OSPF. ``` R1# show ip interface GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up Internet address is 192.168.1.1/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is 100 R1# show access-lists 100 Extended IP access list 100 10 permit ip any any ``` If an ACL is blocking OSPF, you may see the neighbor in INIT because the router receives Hellos (if inbound ACL permits) but the neighbor never receives Hellos (if outbound ACL denies).
Check for Passive Interface
A passive interface on the neighbor router will prevent it from sending Hellos. The neighbor will still receive Hellos and may appear in INIT on this router. Use `show ip ospf interface` on the neighbor to see if the interface is passive. Alternatively, run `show running-config | section router ospf` and look for `passive-interface` statements. ``` R2# show running-config | section router ospf router ospf 1 passive-interface GigabitEthernet0/0 ``` If the interface is passive, remove the `passive-interface` command or explicitly enable OSPF with `no passive-interface GigabitEthernet0/0`.
Verify Authentication Configuration
Authentication must match on both ends. If one side has authentication configured and the other does not, Hellos from the non-authenticating side are ignored. Use `show ip ospf interface` to see if authentication is enabled (e.g., 'Message Digest Authentication' or 'Simple password authentication'). Also check the key ID and key string with `show key chain` if using MD5. ``` R1# show ip ospf interface GigabitEthernet0/0 ... Simple password authentication enabled ``` If authentication is mismatched, you may see the neighbor in INIT because the router receives Hellos (if the neighbor sends them without authentication) but the neighbor never receives authenticated Hellos from this router.
Use Debug to Confirm Hello Exchange
Enable `debug ip ospf hello` on both routers to see if Hellos are being sent and received. This will show you if your Router ID appears in the neighbor's Hello. Pay attention to the 'Neighbor list' in the debug output. ``` R1# debug ip ospf hello OSPF hello debugging is on *Mar 1 00:00:10.123: OSPF: Send hello to 224.0.0.5 via GigabitEthernet0/0 *Mar 1 00:00:10.123: OSPF: Rcv hello from 10.0.0.2 area 0 from GigabitEthernet0/0 192.168.1.2 *Mar 1 00:00:10.123: OSPF: End of hello processing ``` If you see 'Rcv hello' but the neighbor list does not include your Router ID, then the neighbor is not seeing your Hellos. Check for ACLs, passive interface, or authentication on the neighbor side.
In a large enterprise network, OSPF is often used as the IGP for campus and data center environments. A common scenario is a new link added between two distribution switches to provide redundancy. After configuring OSPF on the new interface, the engineer checks show ip ospf neighbor and sees the neighbor stuck in INIT. The first instinct might be to check Layer 1 (cables, optics), but often the issue is a misconfigured ACL on the management segment that inadvertently blocks OSPF traffic. For example, a standard ACL permitting only HTTP/HTTPS might be applied to the outbound direction of the interface, blocking protocol 89. The engineer would need to add a permit statement for OSPF (permit ospf any any) or change the ACL.
Another real-world scenario involves authentication. Many organizations require OSPF authentication for security. When a new router is added to the network, the engineer might forget to configure authentication on the new router. The existing routers see Hellos from the new router (since they don't require authentication on receive by default? Actually, if authentication is configured, they will drop unauthenticated Hellos). The new router sees Hellos from the existing routers (because it doesn't check authentication), so it enters INIT. The existing routers never see the new router's ID because they drop its Hellos. The fix is to configure matching authentication on the new router.
Passive interface is another common pitfall. In a branch office, the network administrator might configure OSPF on all interfaces but set some as passive to prevent OSPF from forming adjacencies with end devices. However, if a router-to-router link is accidentally set as passive, the neighbor will never receive Hellos and will remain in INIT. This is easy to miss because the interface shows OSPF enabled, but the passive flag suppresses Hello transmission.
When misconfigured, the symptoms are subtle: routes may be missing only for certain subnets, causing asymmetric routing or black holes. The dead timer counts down and resets because Hellos are still received, so the neighbor never times out. This makes INIT a stable but broken state.
The CCNA 200-301 exam tests OSPF troubleshooting under objective 3.4 'Troubleshoot static and dynamic routing.' You will likely see a scenario where a router is stuck in INIT and you must identify the cause from a list of options. The exam expects you to know the difference between INIT and 2-Way states, and what causes each.
Common wrong answers candidates choose: 1. 'The neighbor has a mismatched area ID.' – While area mismatch can prevent adjacency, it usually results in the neighbor never being seen (Down) or a state of EXSTART/EXCHANGE with errors. INIT specifically indicates one-way reception is working. 2. 'The hello interval is mismatched.' – Mismatched hello intervals cause Hellos to be ignored entirely, so the neighbor never appears in the neighbor table (Down). INIT requires that a Hello is received. 3. 'The dead timer expired.' – If the dead timer expires, the neighbor goes to Down, not INIT. INIT is a stable state where Hellos are still being received. 4. 'The router ID is duplicated.' – Duplicate Router IDs cause OSPF to behave unpredictably, but usually the neighbor state will flap or stay in EXSTART/EXCHANGE. INIT is not typical.
Specific values and commands to remember:
- Default hello interval: 10 seconds (broadcast/point-to-point)
- Default dead interval: 40 seconds
- show ip ospf neighbor to see state
- show ip ospf interface to check parameters
- debug ip ospf hello to see Hello exchange
Decision rule for scenario questions: If the neighbor is in INIT, the problem is one-way communication: router R1 receives Hellos from R2, but R2 does not receive Hellos from R1. Possible causes: ACL blocking outbound Hellos on R1, passive interface on R2, authentication mismatch (R2 discarding R1's Hellos), or unidirectional link issue. Eliminate any answer that suggests a problem on R1's receiving side (e.g., 'R1 has an ACL blocking inbound OSPF') because R1 is already receiving Hellos. Focus on what would prevent R2 from seeing R1's Hellos.
INIT state means the router has received a Hello from the neighbor but has not seen its own Router ID in the neighbor's Hello.
Common causes: ACL blocking OSPF (protocol 89), passive interface on neighbor, authentication mismatch, unidirectional link.
Use 'show ip ospf neighbor' to identify INIT state; 'show ip ospf interface' to check parameters; 'debug ip ospf hello' to verify Hello exchange.
Mismatched hello/dead intervals or area IDs usually result in no neighbor (Down), not INIT.
If a router is stuck in INIT, the problem is likely on the return path (neighbor not receiving Hellos from this router).
Always check both sides of the link; the issue may be on the neighbor router.
For ACL issues, verify both inbound and outbound ACLs on the interface of both routers.
These come up on the exam all the time. Here's how to tell them apart.
INIT State
One-way communication: Router receives Hellos but neighbor does not see this router's ID.
Neighbor state shown as INIT in 'show ip ospf neighbor'.
No adjacency formed; no database exchange.
Common causes: ACL, passive interface, authentication mismatch.
Dead timer still counts down and resets upon Hello receipt.
2-Way State
Two-way communication: Both routers see each other's Router ID in Hellos.
Neighbor state shown as 2-Way.
Adjacency may form; DR/BDR election occurs on broadcast networks.
Indicates OSPF parameters match and bidirectional communication works.
Neighbor is ready to proceed to ExStart and Exchange states.
Mistake
INIT state means no OSPF packets are being received from the neighbor.
Correct
INIT actually means the router IS receiving Hellos from the neighbor, but the neighbor is not seeing Hellos from this router (no two-way communication).
Candidates confuse INIT with Down. The state name 'Init' implies initial contact, but it specifically indicates one-way reception.
Mistake
A mismatched hello interval causes the neighbor to be stuck in INIT.
Correct
A mismatched hello interval causes Hellos to be ignored entirely, so the neighbor never appears (Down). INIT requires that a Hello is received.
Candidates think that a mismatch just prevents full adjacency, but OSPF drops Hellos with mismatched intervals, so no state is reached.
Mistake
If one router has a passive interface, the neighbor will be stuck in INIT on both sides.
Correct
Only the router that is not passive will see the neighbor in INIT. The passive router will not send Hellos, so it will not see any neighbor (Down).
Candidates forget that passive interface stops sending Hellos but still receives them, creating asymmetry.
Mistake
Authentication mismatch causes both routers to be stuck in INIT.
Correct
Typically, only the router that does not have authentication configured will see the neighbor in INIT, because it receives Hellos (without authentication) but the neighbor discards its unauthenticated Hellos.
Candidates think both sides discard Hellos equally, but the side without authentication may accept Hellos from the authenticated side (depending on configuration).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Stuck in INIT means that the router has received a Hello packet from a neighbor, but the neighbor has not yet acknowledged receiving a Hello from this router. In other words, one-way communication is working, but two-way communication is not established. The router sees the neighbor's Router ID in the neighbor list of received Hellos? Actually, INIT means the router has seen a Hello from the neighbor, but has not seen its own Router ID in any Hello from that neighbor. This indicates that the neighbor is not receiving this router's Hellos. Common causes include ACLs blocking OSPF, passive interface configuration, authentication mismatches, or unidirectional link issues.
Start by running 'show ip ospf neighbor' to confirm the INIT state. Then check 'show ip ospf interface' on both routers to verify that OSPF parameters (area, network type, timers, authentication) match. Check for ACLs on the interfaces with 'show ip interface'. Verify if the neighbor interface is configured as passive under OSPF. Use 'debug ip ospf hello' to see if your Router ID appears in received Hellos. If not, the neighbor is not seeing your Hellos, so focus on why your Hellos are not reaching the neighbor (outbound ACL on your side, inbound ACL on neighbor, passive interface on neighbor, authentication mismatch).
No, a mismatched MTU typically causes problems during the ExStart/Exchange state, not INIT. OSPF uses Database Description packets that can be fragmented if MTU is too small, leading to state flapping or stuck in EXSTART. INIT is only concerned with Hello exchange, which has small packets that usually fit within any reasonable MTU. So MTU mismatch is not a cause for INIT.
In INIT, the router has received a Hello from the neighbor but has not seen its own Router ID in any Hello from that neighbor. In 2-Way, the router has received a Hello that contains its own Router ID, confirming bidirectional communication. 2-Way indicates that both routers are receiving each other's Hellos. On broadcast networks, 2-Way is the state before DR/BDR election; on point-to-point, the adjacency can proceed directly to ExStart.
When authentication is configured on one router but not the other, the router without authentication sends Hellos without authentication. The router with authentication discards those Hellos, so it never sees the neighbor. However, the router without authentication receives Hellos from the authenticated router (because it doesn't check authentication). It then sees the neighbor in INIT because it receives Hellos but the neighbor never includes its Router ID (since the neighbor never received its Hellos). Thus, only the non-authenticating router shows INIT.
Yes, if a firewall is blocking OSPF packets (IP protocol 89) in one direction. For example, if the firewall allows OSPF from R2 to R1 but blocks from R1 to R2, then R1 will receive Hellos from R2 (so R1 sees R2 in INIT), but R2 never receives Hellos from R1 (so R2 does not see R1 at all). To fix, allow OSPF traffic in both directions through the firewall.
Use 'show ip ospf interface [interface]' and look for 'Suppress hello for 0 neighbor(s)' – if the interface is passive, it will say 'Suppress hello for 1 neighbor(s)' or similar. Alternatively, use 'show running-config | section router ospf' and look for 'passive-interface default' or 'passive-interface [interface]'. If the interface is passive, remove the passive configuration with 'no passive-interface [interface]'.
You've just covered Troubleshoot: OSPF Stuck in INIT State — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?