ZNetLab › Published › Question
OSPF neighbours stuck in EXSTART — both sides, no errors in the log
Two routers either side of a GRE tunnel. The tunnel is up, I can ping across it, and the OSPF neighbour appears and then sits at EXSTART for ever.
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 0 EXSTART/- 00:00:35 10.255.0.2 Tunnel0
Timers match, area matches, no authentication configured, interfaces are up. Nothing in the log on either side. What am I missing?
1 answer
@admin · 2026-10-09
Check the MTU on the two tunnel interfaces. EXSTART is where the database description packets are exchanged, and those carry the sender's MTU — a router that is offered an MTU larger than its own refuses to go any further and says nothing about it from the other side's point of view.
A GRE tunnel defaults to 1476 (1500 minus 24 bytes of GRE and IP header), but if one end has had its MTU set by hand, or one of them is carrying IPsec as well, the two will differ.
R1# show interface Tunnel0 | include MTU
MTU 1476 bytes, BW 100 Kbit/sec
Set them the same:
R1(config)# interface Tunnel0
R1(config-if)# ip mtu 1400
on both ends, and the adjacency will come up within a dead interval. If you
genuinely cannot make them match, ip ospf mtu-ignore on both sides works —
but that is a decision to live with a mismatch, not a fix, and it belongs in
the documentation rather than just in the config.
debug ip ospf adj will show the mismatch explicitly if you want to confirm
it before changing anything.
Can you answer this?
Replies, likes and bookmarks live in the community half, which needs a free account. Writing here is free too, and everything is reviewed before it is published.
Open this in the communityEverything publishedHow this works