An OSPF neighbor that keeps returning to ExStart or Exchange has moved beyond basic neighbor discovery but cannot complete database synchronization.[1] This guide focuses on OSPFv2 and the practical interview question: why do Hellos work while the adjacency never reaches Full?
Short answer: Check the interface MTU first, then verify Database Description (DBD/DD) packet delivery, unique router IDs, and DBD sequence negotiation.[1] An MTU mismatch can cause a router to reject even a small DBD packet because the packet advertises an interface MTU larger than the receiver supports.[4]
What happens in ExStart and Exchange?
In ExStart, the routers negotiate the DBD master/slave relationship and initial sequence number; the router with the higher router ID becomes master.[1] These terms describe database exchange roles, not the DR/BDR election.[4]
In Exchange, DBD packets carry LSA headers that summarize the database, rather than the full contents of every LSA.[4] Each router identifies missing or newer LSAs and requests the information it needs.[4]
| Stage | What you should understand | Diagnostic focus |
|---|---|---|
| 2-Way | Bidirectional neighbor discovery has succeeded.[4] | Decide whether this pair should form a full adjacency. |
| ExStart | DBD roles and initial sequence are being negotiated.[1] | MTU field, router IDs, initial DBD delivery. |
| Exchange | LSA summaries are being exchanged.[4] | Sequence progression, retransmissions, packet loss. |
| Loading | Outstanding requested LSAs are still needed.[4] | Requests and corresponding updates. |
| Full | Database synchronization for the adjacency is complete.[4] | Check routes and actual forwarding separately. |
The simplified process is:
Bidirectional Hellos
-> decide whether a full adjacency is needed
-> ExStart: negotiate DBD roles and sequence
-> Exchange: compare LSA headers
-> Loading, if requested LSAs remain
-> Full
Loading is not mandatory: after Exchange completes, an empty link-state request list allows a direct transition to Full.[4] On a broadcast network, two DROTHER routers normally stay at 2-Way with each other; that is not the same problem as a repeatedly failing ExStart negotiation.[4]
Why an MTU mismatch breaks OSPF even when ping works
The OSPFv2 DBD packet includes an Interface MTU field.[4] RFC 2328 section 10.6 requires rejection when that advertised size exceeds what the receiving interface can accept without fragmentation.[4] The check is about the advertised capability, not only the length of the DBD packet currently arriving.[4]
Consider this illustrative lab, not captured production output:
R1 -------- directly connected link -------- R2
OSPF interface MTU: 1500 OSPF interface MTU: 1400
If R1 advertises 1500 in its DBD, R2 cannot accept that advertised size under the standard check, even if the initial DBD itself is small.[4] Small Hellos and small ICMP tests can therefore work while database exchange fails.[1] The two routers can show different states at the same time, such as ExStart on one and Exchange on the other.[1]
Recommended fix: align the effective IP MTU and supported transport size on both ends, accounting for any tunnel encapsulation along the path. Do not raise a configured MTU beyond the capacity of the underlying network just to make the displayed values match.
A practical troubleshooting checklist
1. Capture the state on both routers
Start with read-only Cisco IOS/IOS XE checks; interface names and command availability vary by platform:
show ip ospf neighbor
show ip ospf interface GigabitEthernet0/0
show interfaces GigabitEthernet0/0
show ip interface GigabitEthernet0/0
show ip ospf
show ip ospf database
show ip route ospf
Record the neighbor ID, interface, state, uptime or state changes, network type, timers, and MTU. Repeat the checks rather than assuming that a single brief ExStart observation represents a fault: ExStart and Exchange are normal transient states during adjacency formation.[1]
2. Compare configured and advertised MTU
Compare both routers, then inspect the Interface MTU field in an actual DBD capture. Keep Ethernet frame limits, interface MTU, IP MTU, and tunnel overhead separate in your notes; a matching label in two command outputs is weaker evidence than a decoded DBD plus a successful appropriately sized path test.
Use a controlled extended ping with the Don't Fragment option and an explicit source interface or address. Verify how your platform defines its ping size before interpreting the result. Test increasing sizes in both directions; a successful small ping alone is not a large-packet test.
3. Check DBD delivery, not just Hellos
Cisco documents broken unicast delivery, ACLs, NAT, and underlying transport problems among the causes of ExStart/Exchange failures.[1] OSPF runs directly over IP protocol 89, not a TCP or UDP port.[4]
For a packet capture, use the broad Wireshark display filter ospf first. Compare sent and received DBDs on both sides, including router ID, Interface MTU, sequence number, and the I, M, and MS flags. Their meanings are initialization, more DBD packets to follow, and master/slave role respectively.[4]
Do not assume that seeing multicast Hellos proves that every packet needed by the adjacency can traverse the path. Packet addressing depends on the OSPF network type.[4]
4. Verify unique router IDs and sequence progress
Duplicate router IDs are another documented cause of failure at this stage.[1] Check the OSPF router ID explicitly rather than inferring it from the current interface address.
Unexpected DD sequence numbers, an unexpectedly set initialization bit, and changed Options during exchange can trigger a sequence-mismatch event and restart the exchange process.[4] Repeated DBDs are a symptom to investigate, not proof that the router with the higher ID is faulty.
If MTU and packet delivery are demonstrably correct, collect a short, scoped adjacency debug and check vendor release notes for the exact software version. On Cisco platforms that support it, debug ip ospf adj is relevant to this workflow.[1] Prefer a lab or approved maintenance window, watch CPU/log volume, and stop debugging promptly with undebug all; avoid broad packet debugging on a busy production router.
Should you use ip ospf mtu-ignore?
Cisco's interface command ip ospf mtu-ignore disables the OSPF MTU mismatch check.[1] It does not increase the physical path capacity or make oversized packets deliverable.
Treat it as a documented exception or controlled diagnostic, not the default repair. If bypassing the check allows Full, still test supported packet sizes and monitor database exchange and forwarding. A green neighbor state is not proof that the underlying MTU design is correct.
Common interview and troubleshooting pitfalls
- “MTU must match in the Hello.” The relevant MTU field is in the DBD packet, not the Hello packet.[4]
- “The DR must be the DBD master.” DR election and DBD role negotiation are different mechanisms; DBD role negotiation uses router IDs.[4]
- “Exchange carries all the full LSAs.” DBDs carry LSA headers; Link State Updates carry LSAs.[4]
- “ExStart always means MTU.” MTU is an important first check, but duplicate IDs and unsuccessful DBD delivery are also documented causes.[1]
- “Every neighbor must be Full.” DROTHER-to-DROTHER 2-Way is normal on a broadcast segment.[4]
- “Clear the OSPF process first.” Capture evidence and fix the underlying condition before considering a disruptive reset.
A concise interview answer
“ExStart is where OSPF negotiates DBD master/slave roles and the initial sequence number; Exchange is where neighbors compare database summaries.[1] If a neighbor stays there, I first compare interface MTUs and the advertised MTU in the DBD, then check unique router IDs, packet delivery, and sequence negotiation.[1][4] Hellos can succeed even when the DBD MTU check fails.[4] I prefer fixing the MTU or transport problem instead of blindly applying mtu-ignore.”
Optional lab and acceptance checks
On an isolated two-router OSPFv2 lab, establish Full first, record the baseline, and then deliberately introduce an IP MTU mismatch using your platform's supported configuration. Observe both neighbor states and capture DBDs before restoring the original MTU. This is a suggested exercise, not a claim that these commands were executed on physical routers.
Use this acceptance checklist after the repair:
- The intended adjacency reaches Full and remains stable during observation.
- DBD exchange no longer restarts repeatedly.
- Expected LSAs and routes are present.
- Appropriately sized data-plane tests succeed in both directions.
- Any temporary debug or diagnostic workaround has been removed or documented.
Related reading
- OSPF Neighbor States: Step-by-Step
- OSPF Hello Packets: Timers, Neighbors and Troubleshooting Checks
- OSPF Network Types Explained
Summary
ExStart/Exchange troubleshooting is about completing DBD negotiation and database exchange, not merely proving that Hellos arrive.[1] Start with MTU evidence, then follow the DBD packets and sequence numbers before changing the configuration.
Preparing for a network engineering interview? Explain why a small ping can work while OSPF fails, then practise proving the cause in a two-router lab.
Post a Comment