The thread title appears constantly on the Juniper community forums and r/Juniper: "OSPF adjacency stuck in Exstart state". The replies are nearly always right: it is an MTU mismatch. But not always — and knowing the full decision tree turns a two-hour outage into a two-minute fix.

What ExStart Actually Means

OSPF neighbor states run Down, Init, 2-Way, ExStart, Exchange, Loading, Full. Reaching ExStart proves hellos are flowing and the neighbors agree on subnet, area, authentication and timers. The session then begins Database Description (DBD) exchange to elect master/slave and sync the LSDB. ExStart means the DBD exchange keeps failing and retransmitting. The most common reason DBDs bounce: each side advertises its interface MTU in the DBD, and the smaller-MTU side refuses to continue against a larger-MTU neighbor.

Cause 1: MTU Mismatch (the Usual Suspect)

show interfaces ge-0/0/0 | match MTU
show ospf neighbor
show ospf statistics

The neighbor sticks in ExStart with DBD retransmissions visible in show ospf statistics. Compare the physical MTU on both ends. Classic scenarios from real outages:

  • One side defaults to 1514, the other was raised to 9000 for jumbo frames.
  • The link rides an L2VPN, VPLS or tunnel transport that cannot carry full-size DBDs — the community thread about OSPF over L2VPN is exactly this failure.
  • A carrier middlebox silently drops oversized frames while small pings pass.

Fix: make the MTUs match end to end. If you cannot change the transport, lower the interface MTU on both OSPF sides (for example to 1400) so DBDs fit — adjacency forms immediately, which also confirms the diagnosis.

Cause 2: Duplicate Router IDs

Two routers with the same router ID confuse the DBD master/slave election and the adjacency never converges:

show ospf overview | match "Router ID"
set routing-options router-id 10.255.0.1
commit

Cause 3: Policy or Filter Blocking DBDs

Hellos are multicast to 224.0.0.5, but DBDs are unicast. A firewall filter or SRX zone policy that permits multicast but drops the unicast session leaves the neighbor exactly in ExStart. On SRX, remember that per our zone firewall guide, intra-zone traffic can still be filtered by policy — allow OSPF explicitly or via host-inbound-services per zone.

Cause 4: Broken Transport Passing Small Packets

When the link is a pseudowire, GRE or IPsec transport, verify what MTU survives: ping across it with do-not-fragment and increasing sizes. If 1472 bytes fails while 1400 succeeds, size the OSPF interfaces below the working value. The same MTU logic underlies our interface error counter guide — physical-layer damage corrupts large frames first, producing identical ExStart symptoms.

Confirm and Move On

show ospf interface
show ospf log
show route protocol ospf

Once Full, check that routes actually install with show route protocol ospf. If adjacency flaps after forming rather than sticking in ExStart, follow our session-flap field method — the transport-hunt technique is the same — and if the box is busy while all this churns, check routing engine CPU before blaming OSPF.

If you are building OSPF from scratch instead of fixing it, the complete MX configuration example gives you a known-good baseline to diff against.