Dear Junos, Tunnels Are Not Virtual Links

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)1.

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 Junos2, 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 them3. 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.

  1. You don’t have to believe me; the GitHub issue linked above includes a Wireshark screen capture. ↩︎

  2. I wonder what Juniper HP marketing thinks about that ;) ↩︎

  3. Also known as “never let the truth get in the way of a good story persuasive AI response” ↩︎

Recent posts in the same categories

2 comments:

  1. Stefano Sasso 26 August 2026 10:03

    > I wonder what HP marketing thinks about that ;)

    I think HP wouldn't care less ;) - HPE is not HP since more than 10 years :)

  2. Aleksey Popov 26 August 2026 06:18

    I think it is useful to look at the exact RFC language here. RFC 5340 largely refers back to RFC 2328 for Database Description packet processing. In particular, RFC 2328 says: 1) in 10.8. Sending Database Description Packets “ The Database Description packet's Interface MTU field is set to the size of the largest IP datagram that can be sent out the sending interface, without fragmentation. [...] Interface MTU should be set to 0 in Database Description packets sent over virtual links.”

    2) in 10.6. Receiving Database Description Packets “ If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected.”

    Part (1) is relatively straightforward for a physical interface. Part (2) is more interesting, because the rejection threshold specified by the RFC is not explicitly the local MTU; it is the largest datagram that the router can accept on the receiving interface without fragmentation. Many implementations appear to assume that this is equivalent to the interface MTU, which leads to the somewhat misleading statement that “OSPF MTUs must match.”

    Tunnel interfaces such as GRE make this more problematic. The MTU configured, calculated, or inferred independently at the two tunnel endpoints need not necessarily be identical, and it is not necessarily a reliable representation of the end-to-end tunnel path MTU or receive capability. If we nevertheless assume MRU = MTU, then strict application of the RFC receive rule means that unequal tunnel MTUs will prevent the adjacency from completing: the endpoint with the smaller MTU will reject the larger value advertised by its peer. Conversely, advertising zero in the DBD can never cause rejection by this particular RFC MTU test, since zero cannot exceed the receiving router's capability.

    That does not necessarily make advertising zero on a GRE interface compliant with the transmit-side definition—the RFC associates zero with OSPF virtual links—but it does make the behavior understandable as a way of avoiding an unreliable MTU comparison on a multi-hop tunnel.

    There is also a rejected erratum for RFC 5838 on exactly this subject. Acee Lindem commented: “An OSPF virtual link and a tunnel (e.g., GRE tunnel) are totally different constructs. The vendor is incorrect in arguing that this text specifics operation over a GRE tunnel. Rather, they should be arguing that OSPF doesn’t have any path MTU capabilities and since a tunnel can be multi-hop, OSPF doesn’t know the MTU.” https://mailarchive.ietf.org/arch/msg/lsr/vUyvzp5zohq3dgET31DEFm6Fhso/

Add comment
Home
Sidebar