OSPF Neighbour Stuck in EXSTART? A Troubleshooting Checklist

Your interfaces are up and the routers can ping each other, but show ip ospf neighbor keeps showing EXSTART. Start OSPF EXSTART troubleshooting at database description exchange: compare MTUs, inspect the adjacency and prove the repair with FULL state, learned routes and two-way traffic.

Lab note: This is an illustrative Cisco IOS/IOS XE OSPFv2 lab, not output captured from a running device. Timers, messages and interface names vary. Use an isolated practice environment; review the impact before changing a live link.

Start with the stuck adjacency

R1# show ip ospf neighbor
Neighbor ID     Pri   State        Dead Time   Address      Interface
2.2.2.2           0   EXSTART/-    00:00:36    10.12.0.2   GigabitEthernet0/0

A brief EXSTART transition is normal. A neighbour that stays there or repeatedly cycles through EXSTART and EXCHANGE needs investigation. The peer may show a different state, so collect evidence on both routers.

Two-router topology and intended baseline

The deliberate fault is R2’s IP MTU of 1400 while R1 uses 1500. The lab network type is point-to-point at both ends, so the expected final state is FULL/-, with no DR/BDR role.

Reproducible lab configuration

R1 baseline:

configure terminal
router ospf 1
 router-id 1.1.1.1
 exit
interface GigabitEthernet0/0
 ip address 10.12.0.1 255.255.255.252
 ip mtu 1500
 ip ospf network point-to-point
 ip ospf 1 area 0
 no shutdown
 exit
interface Loopback0
 ip address 192.0.2.1 255.255.255.255
 ip ospf 1 area 0
end

R2 with the intentional MTU fault:

configure terminal
router ospf 1
 router-id 2.2.2.2
 exit
interface GigabitEthernet0/0
 ip address 10.12.0.2 255.255.255.252
 ip mtu 1400
 ip ospf network point-to-point
 ip ospf 1 area 0
 no shutdown
 exit
interface Loopback0
 ip address 198.51.100.2 255.255.255.255
 ip ospf 1 area 0
end

Use fresh lab processes so the intended router IDs are active. OSPF process IDs are locally significant and do not have to match between neighbours.

Why EXSTART can persist when small pings work

Hello communication and database synchronization are different steps. EXSTART negotiates the DBD sequence and primary/subordinate roles; EXCHANGE carries database summaries. Loading retrieves required LSAs, and FULL means the adjacency has completed database synchronization.

OSPF carries an interface MTU value in its DBD packets. A receiver can reject a DBD advertising an MTU larger than it can accept, even when that particular DBD is small. In this lab, R2 cannot accept R1’s advertised 1500-byte value. A successful small ICMP ping therefore does not clear the MTU check.

OSPF EXSTART troubleshooting checklist

For foundational study, first understand the neighbour state sequence. On a broadcast network, two DROTHER routers can legitimately remain 2-WAY; that is different from this point-to-point EXSTART fault.

Compare MTU evidence on both routers

R1# show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.12.0.1/30
  MTU is 1500 bytes

R2# show ip interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.12.0.2/30
  MTU is 1400 bytes

These are relevant excerpts. The hardware-facing show interfaces MTU can still be 1500 on both sides when an ip mtu override exists. Read show ip interface and the interface configuration too.

show running-config interface GigabitEthernet0/0
show ip ospf interface GigabitEthernet0/0
show ip ospf neighbor detail

Inspect database exchange without hiding the cause

In a small isolated lab, use:

debug ip ospf adj
! Observe a short adjacency attempt, then stop:
undebug all

Illustrative diagnostic message:

OSPF: Nbr 1.1.1.1 has larger interface MTU

Actual wording differs by release. In an authorized capture, inspect OSPF Database Description packets, the Interface MTU field, DBD sequence number and I/M/MS flags. Repeated initial DBDs or sequence restarts identify a failed exchange, but do not establish MTU as the cause without supporting evidence. Avoid unbounded debugging on busy production routers.

Fix the actual MTU mismatch

This Ethernet lab supports 1500 bytes end-to-end. Restore R2’s intended IP MTU:

R2# configure terminal
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip mtu 1500
R2(config-if)# end

If a tunnel or underlay supports less, choose a consistent supported value instead of blindly increasing it. Allow the adjacency to retry and converge; a global OSPF process reset is not the first corrective step.

Should you use ip ospf mtu-ignore?

ip ospf mtu-ignore bypasses the received DBD MTU check; it does not enlarge the data path or repair packet loss. Reserve it for a justified design or interoperability case with separate MTU validation. Matching the supported MTU is the appropriate fix in this lab.

Verify FULL state, database synchronization and routes

After convergence, expect both ends to show:

R1# show ip ospf neighbor
Neighbor ID     Pri   State        Dead Time   Address      Interface
2.2.2.2           0   FULL/-       00:00:36    10.12.0.2   GigabitEthernet0/0

R2# show ip ospf neighbor
Neighbor ID     Pri   State        Dead Time   Address      Interface
1.1.1.1           0   FULL/-       00:00:36    10.12.0.1   GigabitEthernet0/0

On broadcast Ethernet, FULL/DR or FULL/BDR may be appropriate instead. Check the expected role for your network type.

show ip ospf database
show ip route ospf
show ip ospf neighbor detail

R1 should see R2’s router LSA in area 0 and an OSPF route to 198.51.100.2/32 through 10.12.0.2. R2 should learn 192.0.2.1/32 through 10.12.0.1. An illustrative R1 route is:

O 198.51.100.2/32 [110/2] via 10.12.0.2, 00:00:12, GigabitEthernet0/0

The metric assumes a cost of 1 on the transit link and loopback; use the cost calculated by your lab. FULL confirms the adjacency, not every application or routing policy.

Test both directions and packet size

R1# ping 198.51.100.2 source 192.0.2.1
R2# ping 192.0.2.1 source 198.51.100.2

Expected result after ARP and routing convergence:

!!!!!
Success rate is 100 percent (5/5)

Also test the intended link MTU with Cisco IOS extended ping: target the neighbour, choose a 1500-byte datagram and set the Don’t Fragment bit. Repeat in the reverse direction. IOS datagram size and Linux ICMP payload size use different conventions; do not copy the same number across tools without accounting for headers. Success validates that specific test path and size.

Observe the neighbours over several hello/dead intervals. Confirm no repeated resets or DBD retransmission symptoms before saving:

copy running-config startup-config

If EXSTART remains after matching MTU

Check for duplicate router IDs, OSPF packet filtering, inconsistent network types, interface drops, tunnel encapsulation limits and platform defects. An unchanged symptom means the first hypothesis was incomplete. Collect both ends’ neighbour details and a short capture rather than making several unrelated changes together.

Practise the complete troubleshooting workflow

Repeat this lab from a clean baseline: record the working state, introduce one MTU fault, explain the DBD evidence and prove the repair. Use our CCNP ENARSI lab checklist to extend your practice to BGP, redistribution and return-path failures. If the underlying link carries VLANs, our VLAN trunk troubleshooting guide helps check the switching path.

Frequently asked questions

What is the most useful first check for OSPF stuck in EXSTART?

Compare the neighbour-facing IP MTU at both ends, then inspect DBD exchange. MTU is a common cause, but not the only one.

Why does ping work while OSPF stays in EXSTART?

A small ICMP packet can pass while OSPF rejects a DBD’s advertised MTU or protocol 89 traffic is filtered.

Does FULL mean all traffic will work?

No. Verify the expected prefixes, next hops, return path and endpoint traffic separately.

Technical references

• Cisco: Troubleshoot OSPF Neighbors Stuck in Exstart/Exchange State
• Cisco: Troubleshoot OSPF Neighbor Problems