OSPF Neighbor Flapping Between EXSTART and EXCHANGE

Root cause: an interface MTU mismatch (1500 vs 1400) that breaks the database description exchange.

Reasoning:

• Hello processing already works, because the timers, area, and authentication match. That is why the neighbor gets as far as two-way/ExStart at all.
• The next step is the DBD exchange, and each DBD carries the sender's interface MTU. A router that receives a DBD advertising an MTU larger than its own interface discards it, so master/slave election never completes. The adjacency oscillates between EXSTART and EXCHANGE instead of failing cleanly: that flapping is the signature, not an authentication problem (auth failures normally stop the neighbor from forming at all).
• Ping succeeding proves nothing about MTU, because small packets and fragments fit inside 1400 bytes.

Confirm with:

show ip ospf interface gi0/1     ! on both routers, read the MTU field
show interfaces gi0/1 | include MTU
show ip ospf neighbor            ! record state and how often it cycles

A supporting test (ping 10.10.12.2 size 1500 df-bit fails, size 1400 succeeds) points at a path-MTU problem, but a ping failure could originate anywhere along the path. The authoritative check is comparing the OSPF interface MTU on both ends.

Apply ip ospf mtu-ignore now as a monitored stopgap; schedule MTU alignment as the real fix.

ip ospf mtu-ignore tells the local router to stop checking the MTU field in received DBDs. It is one line, needs no window, is trivially reverted, and the adjacency forms immediately.

Its risk: it removes the guard without fixing the underlying mismatch. OSPF does not negotiate per-packet size, so any OSPF packet larger than roughly 1400 bytes (a full DBD, a large LSA bundle) must still cross a link that cannot carry it in one piece. The result is retransmissions, intermittent SPF churn, and routes that flap instead of a stable, cleanly failing adjacency. That is a worse failure mode than the one you have, so pair it with adjacency-state monitoring and a dated change ticket.

Scheduled fix: set mtu 1400 on R1 Gi0/1 to match R2 during the window (changing MTU can reset the interface and will re-form the adjacency), then remove ip ospf mtu-ignore so the guard is restored. Before you do, verify that 1400 is a real path limit and not a leftover from the template: if the physical path supports 1500, restoring 1500 on both ends is the better repair. If you later run eBGP or other TCP across the link, add ip tcp adjust-mss 1360 so TCP negotiates a segment size that fits the 1400-byte MTU.

Duplicate OSPF router IDs. If two routers use the same RID (very common when both are built from one template with router-id 1.1.1.1), a router sees its own RID inside a neighbor's DBD and the exchange cannot complete, so the state sits in or oscillates around EXSTART/EXCHANGE. Check show ip ospf and show ip protocols on both sides and compare the local RID with the neighbor's reported RID. Also rule out an MTU problem on any device in the middle of the path, and confirm the network types match (show ip ospf interface).

What the static cost you:

• It masked the failure. Users had reachability, so the ticket was raised three days late, and the monitoring system never alerted because it was testing reachability, not adjacency state. Add an OSPF neighbor-state alert.
• No reconvergence. A static does not reroute when the preferred path degrades; if the OSPF path had come back healthy, traffic would still have followed the static.
• Manual growth. Every new prefix at the branch has to be added by hand, and any mismatch between the static's next hop and reality black-holes traffic silently.