R1 and R2 are directly connected via a serial link running OSPF. Their neighbor state is stuck in EXSTART/EXCHANGE and never progresses to FULL. A technician checks the interfaces and finds R1's serial interface MTU is 1500 bytes while R2's is set to 1400 bytes. What is the most likely cause of the stuck adjacency, and how can it be resolved?
- AThe routers have mismatched OSPF process IDs; changing the process ID on either router to match will fix it
- BDatabase Descriptor (DBD) packets are being dropped due to the MTU mismatch; matching the MTU values or configuring 'ip ospf mtu-ignore' on both interfaces resolves the issue
- CThe routers are on different OSPF network types; changing one router's network type to match the other resolves the issue
- DThe Hello and Dead timers do not match; adjusting them to identical values on both routers will allow the adjacency to reach FULL
Show answer & explanationAnswer & explanation
Correct answer: B. Database Descriptor (DBD) packets are being dropped due to the MTU mismatch; matching the MTU values or configuring 'ip ospf mtu-ignore' on both interfaces resolves the issue
OSPF routers exchange DBD (Database Description) packets during the EXSTART/EXCHANGE states, and OSPF checks that the MTU advertised in these packets doesn't exceed the receiving interface's MTU. A mismatch causes DBD packets to be silently dropped, stalling the adjacency in EXSTART/EXCHANGE. The fix is to make MTU values match on both sides or to configure 'ip ospf mtu-ignore' to bypass the check.
Why the other options are wrong
- A. OSPF process IDs are locally significant and mismatches between them don't prevent adjacency formation.
- C. A network type mismatch typically prevents routers from forming a neighbor relationship at all (stuck in INIT or DOWN), not specifically EXSTART/EXCHANGE.
- D. A hello/dead timer mismatch would cause the routers to remain in INIT, not progress to EXSTART/EXCHANGE and then stall.
OSPF MTU Mismatch (EXSTART/EXCHANGE Stall)
OSPF neighbors stuck in EXSTART or EXCHANGE state often indicate an MTU mismatch between the two interfaces, since DBD packets larger than the receiving interface's MTU are silently dropped.
- EXSTART/EXCHANGE involves negotiating master/slave roles and exchanging DBD packets describing the LSDB
- MTU mismatch causes large DBD packets to be dropped, stalling progression to FULL
- Fixes: match interface MTUs, or use 'ip ospf mtu-ignore' to disable the MTU check
Memory trick: Big packet, small door — DBDs get stuck at EXCHANGE.