Neighbour stuck in EXSTART / EXCHANGE / Loading — MTU, DD exchange, LSR retransmission

An OSPF neighbour stuck in EXSTART, EXCHANGE, or LOADING is the canonical OSPF troubleshooting failure. The adjacency is not fully formed; the LSDB is not synchronised; traffic to the neighbour’s prefixes blackholes. The cause is almost always one of: an MTU mismatch, a duplicate router-id, a unidirectional link, or a buggy peer implementation that mishandles the Database Description exchange.

This lesson covers the three stuck states, the dominant causes for each, and the diagnostic sequence the operator uses to identify which one applies.

The OSPF neighbour state machine

The OSPF neighbour state machine (RFC 2328 Section 10) has eight states. The relevant subset for this lesson:

Down -> Attempt -> Init -> 2-Way -> Exstart -> Exchange -> Loading -> Full
                                       |          |          |
                                       v          v          v
                                 (DBD master/  (DBD exchange  (LSR retrans
                                  slave neg)   complete)      until done)

• Down. No Hellos received from the neighbour.
• Init. Hellos received; the neighbour does not list this router.
• 2-Way. Bidirectional communication established. DR/BDR election on broadcast networks.
• Exstart. Master/slave negotiation for the DBD exchange.
• Exchange. DBD packets exchanged; LSDB summary compared.
• Loading. LSR (Link State Request) packets sent for missing LSAs; LSU (Link State Update) packets received.
• Full. LSDBs synchronised.

The states relevant to this lesson are Exstart, Exchange, and Loading. Each has a specific stuck-cause and a specific diagnostic.

Stuck in Exstart

A neighbour stuck in Exstart means the master/slave negotiation for the DBD exchange has failed. The two routers are sending DBD packets but cannot agree on which is master and which is slave.

The dominant cause is MTU mismatch. The DBD packet contains the interface MTU; if the two routers disagree on the MTU, the DBD packet is too large to fit on the smaller-MTU interface and the exchange fails.

sequenceDiagram
  participant R1 as R1 (MTU 1500)
  participant R2 as R2 (MTU 1400)
  R1->>R2: DBD packet (MTU 1500)<br/>interface MTU = 1500
  Note over R1,R2: R2 receives DBD<br/>1500 > interface MTU 1400<br/>DBD dropped
  R2->>R1: DBD packet (MTU 1400)<br/>interface MTU = 1400
  Note over R1,R2: R1 receives DBD<br/>1400 <= interface MTU 1500<br/>OK
  R1->>R2: DBD (slave ack)<br/>R1 wants slave role
  Note over R1,R2: R2's DBD was dropped<br/>R2 never agrees to slave role
  Note over R1,R2: Stuck in Exstart

The diagnostic:

show ip ospf neighbor detail
# Neighbor 10.255.0.2, interface address 10.0.0.2, Area 0
#   State: Exstart, Priority: 1, ...
#   DB Summaries: 0
#   LSAs in queue: 0

show ip ospf interface eth0
# Interface eth0
#   Area 0, MTU 1500

# On the neighbour:
show ip ospf interface eth0
# Interface eth0
#   Area 0, MTU 1400

# The MTU values disagree.

The fix is either:

1. Align the MTU. Set the interface MTU to the same value on both sides: set interfaces ethernet eth0 mtu 1500.
2. Configure ip ospf mtu-ignore. Tell OSPF to ignore the MTU mismatch: set protocols ospf interface eth0 mtu-ignore.

The mtu-ignore configuration tells OSPF to fragment the DBD packet instead of refusing to send it. It is the operational escape hatch when the lower MTU is required (e.g. a tunnel interface with reduced MTU).

Secondary causes of Exstart

• Duplicate router-id. Two routers with the same router-id cannot complete the master/slave negotiation because they believe they are the same router. The diagnostic is show ip ospf on both sides.
• Unidirectional link. Hellos flow one way but not the other. The diagnostic is tcpdump -ni eth0 proto ospf on both sides.
• Vendor bug. Some implementations mishandle the master/slave negotiation when the DBD packets have specific flags set. Vendor-specific workarounds may be required.

Stuck in Exchange

A neighbour stuck in Exchange means the DBD packets are being exchanged but the LSDB summary comparison is not converging. The two routers agree on the master/slave roles but the DBD sequence numbers are not progressing.

The common causes:

• Mismatched interface MTU with mtu-ignore. The DBD packets are exchanged but the LSA headers in the DBD are too large; the comparison loops.
• Mismatched area-id. A router in area 0 receiving a DBD with area-id 1 drops it; the comparison fails.
• Mismatched area-type. A stub area router receiving a DBD with E-bit set drops it.
• Network instability. The DBD packets are lost in transit; the comparison times out.

sequenceDiagram
  participant R1
  participant R2
  R1->>R2: DBD seq=1<br/>LSA headers: 100
  R2->>R1: DBD seq=2<br/>LSA headers: 100<br/>(master)
  R1->>R2: DBD seq=3<br/>LSA headers: 100<br/>(slave)
  Note over R1,R2: Sequence progresses<br/>LSDB summary agrees<br/>Exchange complete
  R1->>R2: DBD seq=N<br/>LSA headers: 100
  R2-->>R1: (DBD dropped due to MTU)
  R1->>R2: DBD seq=N retry
  R2-->>R1: (DBD dropped due to MTU)
  Note over R1,R2: Sequence stuck at N<br/>Exchange incomplete

The diagnostic:

show ip ospf neighbor detail
# State: Exchange
# DB Summaries: N (sequence number)
# LSAs in queue: 0

debug ospf adj
# log shows: DBD retransmit at sequence N

# Check the DBD packets with tcpdump
tcpdump -ni eth0 proto ospf
# Show DBD packets with sequence numbers

The fix is to identify the cause (MTU, area, network) and address it directly.

Stuck in Loading

A neighbour stuck in Loading means the DBD exchange completed but the LSR (Link State Request) packets for missing LSAs are not being satisfied. The router is requesting LSAs but not receiving the corresponding LSU (Link State Update) replies.

The common causes:

• LSR retransmission storm. The requesting router sends an LSR, the responding router sends an LSU, but the LSU is lost in transit. The requesting router retransmits the LSR; the responding router retransmits the LSU. The cycle continues.
• Network congestion. Heavy loss or latency on the link prevents the LSU from being received.
• Buggy peer implementation. Some implementations do not respond to specific LSR packets.

sequenceDiagram
  participant R1 as R1 (requesting)
  participant R2 as R2 (responding)
  R1->>R2: LSR<br/>request LSA X
  R2->>R1: LSU<br/>LSA X
  Note over R1: LSA X lost in transit
  R1->>R2: LSR (retransmit)<br/>request LSA X
  R2->>R1: LSU (retransmit)<br/>LSA X
  Note over R1: LSA X lost in transit
  R1->>R2: LSR (retransmit)<br/>request LSA X
  R2->>R1: LSU (retransmit)<br/>LSA X
  Note over R1,R2: LSR retransmission storm<br/>Stuck in Loading

The diagnostic:

show ip ospf neighbor detail
# State: Loading
# LSAs in queue: N (LSAs waiting for LSU reply)

debug ospf packet ls-request
# log shows: LSR retransmit for LSA X

debug ospf packet ls-update
# log shows: LSU sent for LSA X

The fix depends on the cause:

• Network congestion. Identify the congestion source (interface errors, queue drops). Address the congestion.
• Buggy peer. Vendor-specific workarounds may be required. Update to a fixed firmware version.
• Unidirectional link. Verify bidirectional connectivity.

The diagnostic command set

The complete command set for diagnosing neighbour-stuck states:

show ip ospf neighbor
show ip ospf neighbor detail
show ip ospf interface
show ip ospf interface <ifname>
show ip ospf
show ip ospf database
show ip ospf statistics

debug ospf adj
debug ospf packet hello
debug ospf packet dd
debug ospf packet ls-request
debug ospf packet ls-update
debug ospf lsa

tcpdump -ni eth0 proto ospf
tcpdump -ni eth0 proto ospf -vv  # verbose
tcpdump -ni eth0 -s0 -w /tmp/ospf.pcap proto ospf
# (capture for offline analysis)

The debug ospf packet commands are deep diagnostics. They print every OSPF packet sent and received, with the protocol fields parsed. The output is large (a single adjacency formation can produce hundreds of log lines); the operator enables them sparingly and only on the affected router.

Production failure modes

The production failure modes the engineer must recognise:

• MTU mismatch (Exstart). Most common. The fix is align MTU or use mtu-ignore.
• Duplicate router-id (Exstart). Less common but high-impact. The fix is to set unique router-ids.
• Area-id mismatch (Exchange). Rare but possible. The fix is to align area-id.
• Network congestion (Loading). Common in production networks with QoS issues. The fix is to identify and address the congestion.
• Buggy peer implementation (any state). Vendor-specific. Update to a fixed firmware version.

The diagnostic playbook

The diagnostic sequence for a neighbour-stuck failure:

1. Confirm the state. show ip ospf neighbor shows the neighbour in Exstart, Exchange, or Loading.
2. Read the verbose output. show ip ospf neighbor detail shows the sequence number, LSA queue, and other state.
3. Check the interface MTU. show ip ospf interface on both sides. Disagreement is the dominant Exstart cause.
4. Check the area-id and area-type. show ip ospf interface on both sides. Disagreement is the Exchange cause.
5. Check the configuration. show configuration commands | match "router-id". Two routers with the same router-id cannot form an adjacency.
6. Check the network. tcpdump -ni eth0 proto ospf to see what packets are arriving. ping to verify bidirectional connectivity.
7. Enable OSPF debug for the specific subsystem. Use debug ospf packet dd for Exstart/Exchange, debug ospf packet ls-request for Loading.
8. Apply the remediation. Make the configuration change and verify.

Rollback

The rollback for an OSPF neighbour-stuck change:

# Capture the running configuration
show configuration commands | save /tmp/ospf-neighbour-stuck-$(date +%s).txt

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

# Rollback if needed
rollback 1
commit

For a router-id change, the OSPF process restart:

vtysh -c 'clear ip ospf process'

The process restart tears down every OSPF adjacency and refloods every Type-1 LSA. Plan a maintenance window.

Production discipline

Cross-course references

The OSPF configuration lessons vyos-xix-02-ospf-interface-config (per-interface parameters, MTU handling), vyos-xix-01-ospf-basics (router-id, area assignment), and vyos-xix-05-ospf-authentication (authentication) cover the primitives this lesson assumes. The OSPF fundamentals lessons vyos-xviii-02-neighbours-and-adjacency (neighbour state machine) and vyos-xviii-03-lsa-types (LSA types) cover the conceptual basis. The OSPF troubleshoot lessons vyos-xxii-02-mtu-mismatch, vyos-xxii-03-area-mismatch, and vyos-xxii-05-duplicate-router-id cover specific failure modes in detail.

Quiz