OSPFv3 Stuck in EXSTART Across a GRE Tunnel
R1 and R2 run OSPFv3 area 0 over a GRE tunnel protected by IPsec. Physical interfaces are 1500-byte MTU. The tunnel interface is configured with tunnel mode gre ipv6, ipv6 address 2001:db8:12::1/64, and ipv6 ospf 1 area 0. R2's tunnel uses 2001:db8:12::2/64. show ospfv3 neighbor on R1 shows R2 in EXSTART, then EXCHANGE, then back to EXSTART; the log shows %OSPFv3-5-ADJCHG: Process 1, Nbr ... from EXCHANGE to EXSTART, Retransmitting. A floating static IPv6 default route on R1 points to R2's physical address and is installed. The tunnel comes up, and IPv6 pings across it succeed at 1400 bytes but fail at 1450 bytes. R1 has ipv6 unicast-routing and ipv6 cef.
1. Explain the adjacency symptom and the root cause.
Read the worked answer
The tunnel path MTU is 1400, but the OSPFv3 interfaces are advertising/using 1500. OSPFv3 DBD packets carry the interface MTU. R1 and R2 disagree, so the exchange never completes: the neighbor cycles EXSTART → EXCHANGE → EXSTART and retransmits. The tunnel adds GRE (4 bytes) plus IPv6 (40) plus IPsec overhead to the 1500-byte physical MTU, leaving roughly 1400 bytes of payload. The ping result confirms it: 1400 succeeds, 1450 fails.
Fix on both tunnel interfaces:
interface Tunnel0
ipv6 mtu 1400
ipv6 ospf 1 area 0
Then clear the adjacency (clear ospfv3 process) and verify show ospfv3 neighbor reaches FULL. ipv6 ospf mtu-ignore is a workaround, not a fix, because it hides the real path-MTU problem.
2. Why does ping at 1400 succeed but 1450 fail, and what does that tell you about the tunnel?
Read the worked answer
1400/1450 brackets the tunnel's effective MTU. The physical interface is 1500. GRE consumes 4 bytes, the outer IPv6 header 40, and IPsec ESP adds its own header/trailer (and possibly NAT-T). The inner IPv6 packet therefore has about 1400 bytes before the outer packet hits 1500. A 1450-byte inner packet must be fragmented or receive an ICMPv6 Packet Too Big. IPv6 routers do not fragment in transit, so if the ICMPv6 PTB is filtered, the sender keeps retrying and the flow blackholes. That is exactly why OSPFv3 DBD packets, which can be full-size, fail while small hellos succeed.
3. The floating static is installed while OSPF is down. What operational risk does that create, and how do you verify OSPF is actually carrying the routes?
Read the worked answer
The floating static can mask a dead OSPF adjacency and create a forwarding loop or blackhole. If the static has a lower administrative distance than OSPFv3 (or is installed while OSPF is down), traffic follows the static to R2's physical address instead of the tunnel, bypassing the IPsec policy and possibly returning via the tunnel. It also makes show ipv6 route look healthy when OSPF is not.
Verify with:
show ospfv3 neighbor- must be FULL, not EXSTART/EXCHANGE.show ipv6 route ospf- confirms OSPF-learned prefixes, not just static.show ipv6 route <prefix>- check the source and next hop.show ipv6 protocols- confirm the tunnel interface is not passive and is in the process.
Keep the static as a backup with AD 250, or use an IP SLA track so it installs only when the tunnel is truly down.