OSPF neighbour stuck in EXSTART, INIT, or 2-WAY? Here's the real fix.

The four neighbour states you actually care about

When you run show ip ospf neighbor (Cisco) or equivalent on HPE/Aruba/Juniper, the state column tells you 90% of what you need. The four states that mean "something is wrong":

The other state — FULL — is what you want. EXCHANGE and LOADING are transient.

INIT state — "they see us, we don't see them"

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2        1   INIT            00:00:34    10.0.0.2        GigabitEthernet0/1

R1 can hear R2's hellos (otherwise the neighbour wouldn't be in the table at all), but R2 is not seeing R1's hellos. The most common causes:

1. Area ID mismatch. R1 is in area 0, R2 is in area 1. The hello from R1 has area 0 in it, R2 silently drops it because it expects area 1. 2. Source IP filtering. R2 has an ACL on the interface that drops the hello from R1's router-id or interface IP. 3. Hello / dead timer mismatch. R1 hellos every 10s, R2 expects 30s. R2 drops the unexpected hellos. 4. Authentication mismatch. R1 is sending MD5 auth, R2 is configured for cleartext (or vice versa). 5. Passive interface on R2. R2 is configured to *not* send OSPF hellos out the interface facing R1, but will still receive them. So R1 sees R2, R2 never advertises itself back.

Fix: walk through these in order. show ip ospf interface <int> on both ends will tell you the hello/dead timers and area. Authentication problems show up as a counter incrementing in show ip ospf neighbor — look at the "Pending" events.

EXSTART state — "MTU, MTU, MTU"

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2        1   EXSTART/DR      00:00:38    10.0.0.2        GigabitEthernet0/1

Both routers can hear each other (they got past INIT) but the database-description-packet exchange is failing. In 95% of cases this is an MTU mismatch. The router with the higher MTU sends a DBD that's too big for the other side, which silently drops it.

Fix on Cisco: `` interface GigabitEthernet0/1 ip mtu 1500 !

Fix on HPE/Aruba Comware: `` interface GigabitEthernet1/0/1 mtu 1500 !

Fix on Juniper: `` set interfaces ge-0/0/1 mtu 1500

If you genuinely cannot match MTU (because one side is a service provider transit and they don't take your MTU requests), the workaround is ip ospf mtu-ignore on the higher-MTU side. This is a workaround, not a fix — it papers over a real problem. If your OSPF is up but slow, this is often the cause.

2-WAY state — sometimes fine, sometimes not

On Ethernet (broadcast) networks, 2-WAY between two non-DR routers is normal. The DR and BDR form FULL adjacency with everyone. Everyone else stays at 2-WAY with each other and only forms FULL with the DR and BDR.

Check this: the DR and BDR should both be FULL with all other routers. If they aren't, look at priority:

R1# show ip ospf interface GigabitEthernet0/1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    ...
  Neighbor Count is 3, Adjacent neighbor count is 2
    Adjacent with neighbor 10.10.10.2  (Designated Router)
    Adjacent with neighbor 10.10.10.3  (Backup Designated Router)

If "Adjacent neighbor count" is 0 or 1, the DR election went wrong. Set the priority explicitly on the routers you want to be DR/BDR.

On point-to-point links, 2-WAY is always a problem. Check the network type — if one side is configured as broadcast and the other as point-to-point, the DR election breaks and the adjacency stays at 2-WAY.

The 30-second field checklist

When you get a "OSPF not coming up" call, run these in order:

1. show ip ospf interface on both ends — check area, hello/dead, network type, MTU 2. show ip ospf neighbor on both ends — note the state 3. show ip route ospf on both ends — are you learning the expected routes? 4. show ip ospf database on the DR — is the LSDB populated? 5. debug ip ospf adj (Cisco only, with care) — see exactly which hello/DBD is being dropped

Most of the time the answer is in step 1.

When to call us

OSPF adjacency problems that won't resolve after this checklist — we get these calls a lot from teams that have spent half a day on it. We can usually fix it remotely in 15–30 minutes because we know which show command reveals the cause. Toll-free 1800-5GHZ-NET, or raise a ticket.