[Babel-users] ECMP on endpoints [was: babeld slashes...]

[Toke Høiland-Jørgensen]

dxld at darkboxed.org writes:

> Hi Juliusz,
>
> On Fri, Apr 15, 2022 at 03:35:26PM +0200, Juliusz Chroboczek wrote:
>> >> I think for my use-case the loop avoidance point is moot though since I'm
>> >> mainly interested in using this on endpoints, not routers. So perhaps
>> >> calling this ECMP is not the right nomenclature?
>> 
>> > Not sure; what are you trying to do, exactly?
>> 
>> I'm interested too.  Could you please explain?
>
> Sure, just let me give you some context first.
>
> I've been frustrated with the performance (latency/throughput) of
> road-warrior style VPN setups for a while now. Essentially I want a way to
> always use wireguard tunnels to my network's edge routers except when the
> endpoint device is in my own physical network without having to remember to
> turn off the VPN manually.
>
> The problem thus far was always how can the network cryptographically proof
> that it's "my" network? However babel with MAC authentication seems to
> solve that problem nicely, well for small numbers of such clients
> anyway. Basically I run babel sessions over wireguard tunnels as well as
> the physical wifi/eth interfaces with metrics tuned to avoid the tunnels
> when I get routes from the physical interfaces.

I basically do this for my laptop, sans the MAC authentication (but I
really ought to get that rolled out as well). Works pretty seamlessly:
When I plug my laptop into the dock traffic shifts to the wired
interface, and when it's anywhere else it goes over wireguard. I don't
bother with Babel on the WiFi network, the wg tunnels go to the same
router in the building anyway, so there's no noticeable difference...

> Anyway that takes care of the latency problem as it avoids going
> through my VPN routers when the device is in my local network anway.
> Which brings us to the bandwidth bit. Since I use cheap hosting
> providers for my BGP connectivity the paths available on any
> particular one aren't always the best so I figured it might be good to
> have all possible paths available for applications to use. Many
> bandwidth intensive applications do support multi-stream tcp transfers
> anway so that would work out nicely with per-flow ecmp.
>
> All I have to do is run one wg tunnel per edge router to my clients
> (which I already do) and then have babel install a default
> route/nexthop for each tunnel (the bit I'm working on). Together with
> RTT metrics and CECMP this could even kick out edge routers where the
> underlay network path is performing too poorly fully automatically :)

How do you define "too poorly"? I guess that's the crux of the issue:
you could just install all feasible routes as ECMP paths, but that would
potentially give you wildly varying performance for each flow, which I
would imagine would be a pretty louse user experience. So what would you
do instead?

-Toke