An engineer configures an IPv6 manual tunnel between two routers. The tunnel comes up and pings succeed, but OSPFv3 over the tunnel fails to form an adjacency, stuck in EXSTART state. MTU is set to 1500 on all physical interfaces. What is the most likely cause?
OSPFv3 uses the interface MTU for database description packets. The tunnel MTU is 1460, but the physical path can only handle 1500 bytes including the outer header, leading to a mismatch.
Why this answer
In an IPv6 manual tunnel (IPv6-in-IPv4), the tunnel interface has a default MTU of 1480 bytes (1500 minus 20-byte IPv4 header). OSPFv3 uses the tunnel MTU to determine the size of Database Description (DBD) packets during the EXSTART state. When the physical interface MTU is 1500, the tunnel MTU of 1480 causes OSPFv3 DBD packets to be fragmented or dropped, preventing the adjacency from progressing beyond EXSTART.
Setting the tunnel MTU to 1480 or adjusting OSPFv3's ipv6 mtu-ignore can resolve this.
Exam trap
Cisco often tests the subtlety that OSPFv3 adjacency stalls in EXSTART due to MTU mismatch, where candidates mistakenly think the issue is with tunnel mode or OSPF area configuration rather than the default tunnel MTU reduction from encapsulation overhead.
How to eliminate wrong answers
Option A is wrong because setting the tunnel MTU to 1500 would exceed the physical interface's ability to encapsulate the IPv4 header, causing fragmentation or packet loss; the tunnel MTU must be reduced to account for encapsulation overhead. Option B is wrong because 'ipv6ip' is the correct tunnel mode for an IPv6 manual tunnel (RFC 4213), and GRE is not required; GRE would add additional overhead (4 bytes) and is not the default for manual tunnels. Option D is wrong because OSPFv3 adjacency formation does not require the tunnel source interface and tunnel interface to be in the same OSPF area; the tunnel interface is a separate OSPF interface, and area mismatch between interfaces does not cause EXSTART state issues.