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 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
