Why an OSPF adjacency sticks in EXSTART

[[POST_DATE]] · [[YOUR_NAME]]

SAMPLE POST: written to show the layout. The output below is illustrative and uses documentation addresses. Edit it, or replace it with your own.

Two routers can see each other, agree on their hello parameters, and still never reach FULL. If show ip ospf neighbor sits in EXSTART or EXCHANGE, the first thing to check is the MTU on both ends of the link.

What the routers are doing

After the two-way check, neighbors move through these states:

State	What happens
`EXSTART`	The routers pick a master and an initial sequence number.
`EXCHANGE`	They trade Database Description (DBD) packets that summarize their LSDBs.
`LOADING`	They request the LSAs they are missing.
`FULL`	The databases match.

Each DBD packet carries the MTU of the sending interface. Under RFC 2328, a router rejects a DBD packet when that value is larger than it can accept on the receiving interface without fragmentation. The sender gets no acknowledgement and keeps retransmitting, so the adjacency never moves on.

Confirming it

Start with the neighbor state:

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.0.2.2         1   EXSTART/DR      00:00:36    198.51.100.2    GigabitEthernet0/0

Then compare the IP MTU on each end. OSPF uses the IP MTU, so check that value and not only the interface MTU:

R1# show ip interface GigabitEthernet0/0 | include MTU
  MTU is 1500 bytes

R2# show ip interface GigabitEthernet0/0 | include MTU
  MTU is 1400 bytes

Here R2 rejects the 1500-byte value advertised by R1. On Cisco IOS, debug ip ospf adj will usually name the mismatch directly, but keep debugs short on a production router.

Fixing it

Make both ends match, and make sure the path between them can carry that size:

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

You will also see ip ospf mtu-ignore suggested. It skips the check, so the adjacency can form, but it does not change what the link can carry. Treat it as a deliberate exception, not the fix.

If the MTUs match

Other causes produce the same symptom:

A duplicate router ID on the two neighbors.
A device in the path that drops large frames, even though both endpoints agree. Small hellos pass, but full-size DBD packets do not.
An ACL or policy that blocks unicast traffic between the neighbors while multicast hellos still arrive.

← All posts