OSPF Stuck in INIT: Diagnosing the One-Way Hello

An OSPF neighbor sitting in INIT is one of the few troubleshooting states that hands you the answer for free, if you know how to read it. INIT is not "still negotiating" and it is not a slow start. It is a router telling you something very specific: I am receiving your hellos, and you are not receiving mine. The adjacency is broken in exactly one direction, and that single fact eliminates most of the causes people go hunting for.

The mistake almost everyone makes is to stare at the INIT side. That router is the healthy one. The interesting device is the other end, and the diagnostic move that solves this in about ninety seconds is to run show ip ospf neighbor on both routers and compare the two tables. If you are still building your mental model of how OSPF forms adjacencies, the state machine is the part worth internalising, because every neighbor problem you will ever meet announces itself by getting stuck in one particular state.

Everything below was captured on a live lab: two iol-xe routers running IOS XE 17.18.2 in Cisco Modeling Labs, back to back over a /30, with an inbound ACL deliberately dropping OSPF in one direction. No output on this page was typed by hand.

The symptom: one router sees a neighbor, the other sees nothing

Here is the broken state, held stable for about two minutes so there was no doubt it was a steady condition rather than a transient:

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   INIT/DROTHER    00:00:32    10.0.12.2       Ethernet0/0

R2# show ip ospf neighbor
(no output - R2 has no OSPF neighbor at all)

Look at what those two tables say together. R1 knows R2 exists. It has R2's router ID, its interface address, and a dead timer that is counting down and being reset, which means hellos from R2 are arriving on schedule. R2, meanwhile, has an empty neighbor table. Not an error, not a partially formed neighbor. Nothing.

That combination has exactly one meaning. Hellos are flowing from R2 to R1 and are not flowing from R1 to R2. Everything else in this problem is downstream of that sentence.

What INIT actually means

An OSPF hello packet carries a neighbor list: the router IDs of every neighbor this router has recently heard on that segment. RFC 2328 section 10.5 defines the receive logic in a way that is easy to state and easy to forget. When a router receives a hello, it checks whether its own router ID appears in that hello's neighbor list. If it does, the two routers have proved bidirectional reachability and the neighbor moves to 2WAY. If it does not, the neighbor stops at INIT.

So INIT is not a timing artefact and it does not clear on its own. R1 is receiving hellos from R2 and R1's router ID (1.1.1.1) is not in them, because R2 has never heard from R1 and therefore has nothing to list. R1 records the neighbor, marks it INIT, and waits forever. The state progresses from DOWN through 2WAY, EXSTART and LOADING to FULL only after that mutual acknowledgement happens, so a one-way hello path stops the whole machine at the first gate.

Two details in that R1 output are worth noticing. The dead time of 00:00:32 is healthy and refreshing, which tells you the reverse direction is fine and rules out a hello and dead interval mismatch on the path you can see. And the DROTHER role attached to the state is meaningless here, because DR election only runs once neighbors reach 2WAY. Do not read anything into it.

Reading the direction, then reading the cause

The asymmetry is the diagnosis, and it is what separates this failure from every other adjacency problem. Most neighbor mismatches are symmetric in their symptoms. An area ID mismatch, a subnet mask mismatch, an MTU mismatch, mismatched timers: in all of those, both routers receive each other's packets and both have something to complain about, whether that is a log message or a neighbor stuck in EXSTART. Both sides see something.

A completely empty neighbor table on one end while the other end holds a stable INIT is different. That is a packet delivery problem, not a parameter problem. Something between R1's OSPF process and R2's OSPF process is eating packets in one direction only, and your search space is now the list of things that can be applied to a single direction:

Two of those deserve a note. Authentication is the one that fools people, because it can present as either symmetric or one-way depending on how the mismatch was created: if one side has authentication configured and the other has none, the configured side silently discards the unauthenticated hellos while its own hellos are quite happily accepted by the peer that is not checking. That is a genuine one-way hello with no packet filter anywhere, and it is worth reading up on how OSPF authentication mismatches present in the logs before you go looking for an ACL that does not exist.

The passive-interface case is the inverse shape and the easiest to spot once you know it. A passive interface still listens, so the passive router is the one that ends up with the neighbor in INIT while the other router, which never hears a hello at all, sits with an empty table.

What this was captured on

R1 and R2 are iol-xe nodes on IOS XE 17.18.2 in CML, connected back to back on Ethernet0/0 in 10.0.12.0/30, both in OSPF area 0, with router IDs 1.1.1.1 and 2.2.2.2. The break was baked into R2 before the routers came up:

! Applied inbound on R2 Ethernet0/0
ip access-list extended OSPF-BLOCK
 deny   ospf host 10.0.12.1 any
 permit ip any any

That permit ip any any is the whole reason this failure is nasty in production. Only IP protocol 89 from one source is dropped, so ARP resolves, pings succeed both ways, the interface is up/up with no errors, and the link passes every test a reasonable engineer runs before deciding the problem must be "an OSPF thing". If you are auditing filters on a transit link, it is worth knowing how an inbound ACL is evaluated on IOS XE and which control-plane traffic an over-broad rule can quietly swallow.

One note on method, for honesty: show ip ospf neighbor was logged to syslog by an on-box EEM applet and read back through the CML console-log API, because the PyATS console path was unavailable during this run. The text is verbatim device output either way.

The fix and the proof

Removing the filter is one line on the interface:

R2(config)# interface Ethernet0/0
R2(config-if)# no ip access-group OSPF-BLOCK in

The recovery is immediate, and this is the part to pay attention to, because it is what confirms the diagnosis rather than merely ending the outage. Five seconds after the ACL came off, both routers logged the transition, within a millisecond of each other:

*Jul 20 12:51:42: %SYS-5-CONFIG_I: Configured from console by on vty1 (EEM:FIX)
                  FIX-DONE removed OSPF-BLOCK inbound ACL; expect FULL
*Jul 20 12:51:47.620: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Ethernet0/0 from LOADING to FULL, Loading Done  (R1)
*Jul 20 12:51:47.621: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from LOADING to FULL, Loading Done  (R2)

R1 did not need to be touched, restarted, or cleared. It had been holding a valid neighbor entry the entire time, waiting for one hello that listed its router ID. The moment R2 could hear R1, R2 started including 1.1.1.1 in its own hellos, R1 moved to 2WAY on the next one it received, and the rest of the state machine ran to completion in under a second. Both tables agree afterwards:

R1# show ip ospf neighbor
2.2.2.2           1   FULL/DR         00:00:38    10.0.12.2       Ethernet0/0

R2# show ip ospf neighbor
1.1.1.1           1   FULL/BDR        00:00:37    10.0.12.1       Ethernet0/0

Note that the DR election ran only now, and R2 won it. During the whole INIT period there was no election at all, which is why the earlier DROTHER label was noise. If you want the full breakdown of what each OSPF neighbor state means and what stalls it, that is the reference to keep open next to the CLI.

Gotchas

• Do not troubleshoot the INIT router. The router showing INIT is working correctly. Its peer, the one with the empty neighbor table, is where the filter, the passive interface or the authentication statement lives.
• An empty show ip ospf neighbor is not "OSPF is down". It is easy to read blank output as a dead process and start re-checking network statements. Confirm the interface is actually in OSPF with show ip ospf interface before you rewrite any configuration.
• Ping proves nothing about OSPF. A filter that drops protocol 89 and permits everything else leaves the link looking flawless to every generic connectivity test.
• Symmetric symptoms mean a different problem. If both routers can see each other and are stuck together, you are not looking at a one-way hello. Stuck in EXSTART or EXCHANGE on both ends points at an OSPF MTU mismatch, and neighbors that keep reaching FULL and then dropping usually mean two routers sharing a router ID.
• Prove the direction before you change anything. debug ip ospf hello on both routers, or an on-box packet capture on IOS XE, will show you hellos arriving on one router and never on the other. That is a two-minute check that saves you from a maintenance window spent editing OSPF config that was never wrong.

Key takeaways

• INIT means "I hear you, you do not hear me". The neighbor's hello arrived, but it did not list your router ID, so the adjacency cannot advance to 2WAY.
• Run show ip ospf neighbor on both ends. INIT on one side plus an empty table on the other is a one-way packet delivery problem, not a parameter mismatch.
• The silent router is the broken one. Look for an inbound ACL dropping IP protocol 89, a passive interface, authentication configured on only one end, or multicast to 224.0.0.5 failing in one direction.
• An ACL that ends in permit ip any any will pass every ping and traceroute you throw at it while still killing the adjacency.
• Recovery is automatic and near instant once hellos flow both ways. In the lab both routers hit FULL five seconds after the filter was removed, with no clear or reload on either side.
• DR and BDR roles shown alongside INIT are meaningless, because election does not run until neighbors reach 2WAY.

One-way hellos are the cleanest failure in the adjacency family precisely because the evidence is asymmetric, and asymmetry always points at direction. Get in the habit of collecting both neighbor tables before you form a theory. For the rest of the protocol, from area design to LSA behaviour and the other ways adjacencies fail, work through the complete OSPF configuration and troubleshooting guide.