SPF neighbors are stuck in exstart and exchange state

due to MTU mismatch

Core Issue
When Open Shortest Path First (OSPF) is enabled on a router or when a router
configured for OSPF is powered up, OSPF neighbors are not known and the OSPF
state is said to be init. The router then discovers other OSPF speaking routers and
synchronizes its database with them. In this process, the status of the OSPF
relationship between OSPF neighbors transitions through several states, ultimately
changing to full state. However, at times the status of the OSPF relationship does not
transition to full state and may get stuck in exstart and exchange state.
Resolution
The most common reason for this problem is a mismatch in the Maximum Transmission
Unit (MTU) settings. When attempting to run OSPF between a Cisco router and another
vendor's router, if the default interface MTUs do not match, the router with the higher
MTU sends a packet larger than the MTU set on the neighboring router. This results in
the neighboring router ignoring the packet. The solution is to change the MTU on one
router to match the neighbor's MTU.
To set the MTU size of IP packets sent on an interface, issue the ip mtu command in
interface configuration mode.
In some instances, disabling MTU mismatch detection may be necessary. To disable
OSPF MTU mismatch detection on receiving Database Descriptor (DBD) packets, issue
the ip ospf mtu-ignore command in interface configuration mode.
For more information on why OSPF neighbors get stuck in the exstart and exchange
state, refer to Why Are OSPF Neighbors Stuck in Exstart/Exchange State?.