A network engineer configures an IPv6 over IPv4 GRE tunnel with IPsec protection using a transform set that includes ESP encryption and authentication. The tunnel comes up, but OSPFv3 over the tunnel fails to form adjacency. The engineer notices that the tunnel interface has an MTU of 1400. What is the most likely explanation?
With ESP encryption and authentication, the total overhead can be 50-60 bytes. The tunnel MTU of 1400 does not account for this, causing OSPFv3 packets to be fragmented or dropped.
Why this answer
The correct answer is A. When IPsec ESP encryption and authentication are applied to a GRE tunnel, the combined overhead (typically 50–60 bytes for ESP headers, trailers, and authentication data) reduces the effective payload MTU. With a tunnel interface MTU of 1400, the actual packet size after adding GRE (20 bytes) and IPsec overhead can exceed the path MTU, causing fragmentation or drops.
OSPFv3 uses large hello packets (often 1500 bytes), and if the encapsulated packet exceeds the path MTU, adjacency cannot form.
How to eliminate wrong answers
Option B is wrong because OSPFv3 over GRE does not require the 'ipv6 ospf network point-to-point' command; GRE tunnels are inherently point-to-point, and OSPFv3 automatically detects the network type as point-to-point over a GRE tunnel. Option C is wrong because the question states that the tunnel comes up, and IPsec protection is configured via a transform set; the crypto map is likely applied to the physical interface or tunnel interface, and the tunnel being up indicates IPsec is functioning. Option D is wrong because 'tunnel mode gre ipv6' is used for IPv6 transport over IPv6, not for IPv6 over IPv4 GRE; the default 'tunnel mode gre ip' is correct for encapsulating IPv6 in IPv4.