Octet

Say this first

Almost always an IP MTU mismatch. The DBD packet carries the interface MTU, and a router rejects DBDs from a neighbor whose MTU is larger than its own, so the database exchange never finishes. I match the MTU on both sides. ip ospf mtu-ignore is a workaround, not a fix. Duplicate router IDs can also cause it.

Go deeper

What you see

Output

R2# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   EXSTART/BDR     00:00:34    10.0.12.1       GigabitEthernet0/0/0

Output

R2# debug ip ospf adj
OSPF-1 ADJ   Gi0/0/0: Nbr 1.1.1.1 has larger interface MTU

The router with the smaller MTU logs this. The neighbor eventually goes down after too many retransmissions and starts again, so the state can flap between EXSTART, EXCHANGE and DOWN.

Check and fix

Output

R2# show ip interface GigabitEthernet0/0/0 | include MTU
  MTU is 1400 bytes

Cisco IOS

R2(config)# interface GigabitEthernet0/0/0
R2(config-if)# no ip mtu

Why mtu-ignore is not a fix

The adjacency forms, but an LSU bigger than the small side's MTU is fragmented or dropped. With a large LSDB, updates then fail later and in a much more confusing way.

Other causes

Duplicate router IDs: both claim master and the exchange loops.
Unicast reachability broken on NBMA: hellos make it, DBDs do not.
An MTU change on only one side of a switch path with jumbo frames, so large DBDs are dropped in the middle.

They will ask next

Which side gets stuck in which state?
The side with the smaller MTU rejects the DBDs and stays in EXSTART. The other side can move to EXCHANGE and then time out. Exactly what each side shows depends on timing, so I compare MTU on both rather than reason from the state.

Traps

Reaching for ip ospf mtu-ignore first. It hides the problem.
Checking the layer 2 mtu only. OSPF compares the IP MTU.

How did you do?