[Babel-users] tunnels

[Justin Kilpatrick]

On Sat, Oct 13, 2018, at 11:04 AM, Juliusz Chroboczek wrote:
> (You mean every Babel neighbour association.  Babel is an unconnected protocol.)

I should be more explicit, for every Wireguard tunnel you wish to run Babel over, for example if you want to setup 3 tunnels and run Babel on each of them they will need to have different ports. Versus simply adding new endpoints on a single tunnel which is in theory possible if you used Unicast Babel (I've never tried it).

> That shouldn't make any difference -- Babel should route around the
> failure after 2 Hellos in a row are lost.  (Assuming you don't use
> link-quality estimation on your tunnels, just RTT estimation.)

WireGuard tunnel convergence, although I guess 'convergence' might not be the best phrase since it implies a routing of some kind. Without keepalives WireGuard can take as much as 30 seconds to perform key exchange and get a tunnel working right. In the 'traditional' vpn usecase tunnels are very long lived and this doesn't matter. For Althea we use transient tunnels for peers so WireGuard 'convergence' is often the limiting factor on how long it takes a peer to 'show up'. 

Yes you are reading that right we have two layers of peer discovery going on, not ideal. We're kinda on the fence about keeping RFC compatible Babel versus building our own tightly integrated protocol based on Babel.


-- 
  Justin Kilpatrick
  justin at altheamesh.com

On Sat, Oct 13, 2018, at 11:04 AM, Juliusz Chroboczek wrote:
> > * Unless you want to setup unicast Babel you need an individual port and
> >   tunnel for every Babel connection.
> 
> (You mean every Babel neighbour association.  Babel is an unconnected protocol.)
> 
> > Wireguard's secure IP's feature won't allow you to use the peer
> > discovery broadcast address twice on the same tunnel.
> 
> Yeah, it makes sense to use point-to-point tunnels only and let Babel do
> the routing without any interference from Wireguard's routing.
> 
> > * To dramatically reduce convergence time configure endpoints on both
> >   ends of the tunnel and enable the keepalive feature at an aggressive
> >   sub 10 seconds.
> 
> That shouldn't make any difference -- Babel should route around the
> failure after 2 Hellos in a row are lost.  (Assuming you don't use
> link-quality estimation on your tunnels, just RTT estimation.)
> 
> > End conclusion there is that mips devices struggle a bit with the
> > encryption but modern ARM devices are very well optimized
> 
> Yeah.  A pity MIPS has been stagnating, it's a nice arch.  (But then,
> Aarch64 looks more like MIPS than ARM.)
> 
> -- Juliusz