[Babel-users] MTU based routing for tunnel based babel networks?
Daniel Gröber
dxld at darkboxed.org
Sun Jul 16 19:51:25 BST 2023
Hi babelers,
I've been running babel on top of my wireguard IPv6 network for a while now
and I have a problem that keeps biting me and I can't find a good solution
for: babel is oblivious to a link's MTU and picks paths that involve
wireguard-in-wireguard tunnels even though paths without this stacking are
available.
The stacking (and subsequent path MTU reduction) is I belive not even
bounded, so there is no static MTU I could configure on all my hosts to
take care of this like one would do with a plain wireguard setup.
I was able to fix this on my routers by configuring the firewall to drop
UDP tunnel packets that are going to traverse interfaces with
MTU<=1440. This works alright but I also have babel running on workstations
that are behind these routers and there is no good way to classify which
UDP packets are part of my network's wireguard tunnels and which aren't.
So this got me thinking (for the hundreth time) perhaps this should be
something the routing protocol takes care of? Babeld would essentially have
to pad it's hello packets to a (configurable) size to detect if
fragmentation is required (or they are being blackholed outright).
My use-case would be well served if I could just specify a minimum MTU all
paths must satisfy though more elaborate things could be done I suppose
(metric based on MTU?).
Opinions? Anybody have any better ideas on how to prevent this sort of
tunnel stacking?
Thanks,
--Daniel
PS: Just to clarify why the tunnel stacking happens in my setup: my network
tunnels IPv6 over IPv4 (most of the time), but I want to support IPv6-only
underlay networks so I have wireguard tunnels with IPv6 endpoints which can
in turn get routed over V6-over-V4 wg tunnels (when the ether is flowing
just right).
More information about the Babel-users
mailing list