← Problem Library
Network L5 NETWORK-1372 · 15 min

Two OSPF neighbors stay in EXSTART after a VLAN migration because the subinterface IP MTU was updated but the parent physical interface MTU remained lower on one side

Hello packets succeed, yet adjacency stalls when database exchange begins because the effective frame size differs between peers.

NetworkFoundation OpsLevel 5Free15 min
Scenario

A routed VLAN migration completes and later one OSPF adjacency never progresses beyond EXSTART despite matching interface configs at the subinterface layer.

What to check first
  • Identify the primary failure signal in the The Subinterface Looked Correct and the Parent Link Still Limited the Conversation scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Inspect effective MTU inheritance on parent links before tuning timers or clearing neighbors repeatedly.

Questions worth viewing together
What should you verify first when Two OSPF neighbors stay in EXSTART appears?

Community-field network problem inspired by Cisco and Server Fault patterns where OSPF stuck in EXSTART due to parent interface MTU drift. Routing adjacencies often inherit hidden limits from parent interfaces that subinterface configs do not reveal.

What usually causes Two OSPF neighbors stay in EXSTART in production?

Teams often blame authentication or packet loss when an inherited MTU mismatch is what stalls database exchange.

What should you document after resolving Two OSPF neighbors stay in EXSTART?

Parent and child interface MTU should be validated together after VLAN or encapsulation migrations.