In late June, we added GRE tunnels to netlab, including a Junos implementation. It looked great (as in “everything worked”) until I changed the integration tests to have GRE tunnels between a tested device and a pair of FRR containers. All other implementations worked as before, but Junos failed to establish an OSPFv3 adjacency over the GRE tunnel with FRR.

Stefano Sasso quickly identified the culprit: Junos OSPFv3 process thinks it should send the DBD packets over GRE tunnels with MTU set to zero (the behavior reserved for virtual links)¹.

Next, he did something hilarious: he asked an AI whether that’s the correct behavior. Here’s the “expert” response:

Per RFC2740 (OSPFv3), the “Interface MTU should be set to 0 in Database Description packets sent over virtual links.” JUNOS is correct in sending MTU 0 on a tunnel interface, per the OSPFv3 spec, since the interface MTU field should be set to 0 in DBD packets sent over virtual links. Junos treats GRE/tunnel-type interfaces the same way it would a virtual link, and always transmits MTU 0 on them for OSPFv3 — regardless of what family inet6 mtu or show ospf3 interface extensive reports.

Let’s forget the minor “quoting an obsolete RFC” glitch (the correct RFC is RFC 5340) and the improper capitalization of Junos², it’s obvious the stochastic text generator has a bit of a problem distinguishing between OSPF virtual links (a control-plane construct used to connect disjoint parts of the backbone area) and tunnel interfaces (a regular interface from the OSPFv2/OSPFv3 perspective).

But wait, it gets better: Jeroen van Bemmel used the “let my AI talk to your AI” approach to get this masterpiece, which includes the following claims:

• In standard Junos OSPFv3 deployments on tunnel interfaces, Junos populates the DBD Interface MTU field using the interface’s actual payload MTU or IPv6 MTU.
• If you explicitly adjust the MTU (e.g., setting mtu under unit 0 or modifying family inet6 mtu), Junos updates the value placed in outgoing DBD packets accordingly.

The only problem with those claims: the reality, as represented by Wireshark captures (and FRR logs), disagrees with them³. The only thing that “helped” was disabling the OSPFv3 MTU check on the other device connected to the tunnel.

I have no idea whether we encountered a quirk specific to Junos virtual router implementation or whether the same behavior occurs in physical boxes (after all, it’s a control-plane behavior). If you know more, please leave a comment.