[Babel-users] MTU based routing for tunnel based babel networks?

[Daniel Gröber]

On Sun, Jul 16, 2023 at 11:43:44PM +0200, Juliusz Chroboczek wrote:
> IP does not support variable MTU links.

Excuse me, but that's plain false. IP was designed in an environment where
(non-ethernet) networks with various MTU standards were commonplace and
this is very much supported. Why else would we have standards for Path MTU
discovery cf. RFC1191/RFC1981 that have become mandatory for IPv6?

> And every tunnel is able to carry packets up to its MTU?  If that's not
> the case, then there's no way your network can work,

There is a way: My routing protocol just has to stop picking links that are
obviously going to cause a problem. The way my network is structured
(remember: mesh network) there always is a path that avoids the tunnel
overhead stacking problem but since babel is blind to it it can and does
pick problematic paths sometimes.

> > Enable a config option for "minimum path MTU" on each babel node. Nodes
> > then pad all hello packets to this size and set appropriate sockopts to
> > stop the kernel from doing PMTUdisc behind our backs (on IPv6) and setting
> > DF=1 (on IPv4).
>
> We can only control fragmentation in the overlay.

True, but controlling fragmentation in the underlay is simply not
necessary. If the tunnel underlay were to fragment[1] my tunnel MTU
wouldn't be impacted so it doesn't break anything and babel can feel free
to use that path. Only the case where the underlay drops packets instead of
fragmenting is relevant.

[1]: Which has pps performance implications and is hence usually
avoided. Wireguard in particular doesn't allow fragmentation.

FYI: Do note that with IPv6 in-network fragmentation is not a "thing"
anymore, this is IPv4 legacy think :) Endpoints fragment nobody else.

> Can you explain what the tunnelling protocol will do, and whether it will
> prevent fragmantation in the underlay?

>From what I observed it's clear Wireguard never fragmentsw it's UDP packets
so it likely sets DF=1 when run on top of v4 and ignores PMTU on v6. IMO
that's a reasonable behaviour for a tunnel protocol.

Thanks,
--Daniel