[Babel-users] Detecting bridges

[Juliusz Chroboczek]

Added Mikael and the Homenet list to CC.

Homenet, the issue we're dealing with is that babeld performs badly when
there is a transparent wireless bridge connected to a wired interface: the
interface is treated as a lossless wired interface, and if it suffers
packet loss, there is repeated link flapping.  The issue surfaced in the
Slovenian community mesh, but it is likely to occur in a Homenet setting.

> the resulting nanog conversation on detecting wireless bridged ended
> up interesting - with several clever techniques proposed - all
> probably futile.

Yes.  Anoop Ghanwani is the one who gets it:

> bridges are supposed to be "transparent," so there is no way to know
> they are present by using user data frames.

Radia Perlman once said "Bridges don't make sense.  If you do packet
forwarding, you should do it on layer 3."  And then she went on to design
TRILL.

> I fear the default for babel should become etx or rtt as most of the
> world bridges wifi to ethernet.

It's not as bad as you make it.  Babeld automatically detects Linux
software bridges (which takes care of the default OpenWRT configuration)
as well as BATMAN intefaces (which takes care of the Italian community
meshes).  In 1.7.0, I'm planning to add a third interface type to babeld,
the "tunnel" type, and automatically enable it on tun/tap interfaces --
this should take care of OpenVPN tunnels.  (If you're interested, the
tunnel type will use a slightly different link-quality estimator, one that
is not bound to the 802.11 MAC, disable split horizon, and enable RTT
estimation.)

(Why disable split horizon?  People are running Babel over tap interfaces
in a point-to-multipoint topology.  Which is somewhat inefficient but
simpler to configure than multiple point-to-point tuns.)

The question remains about what to do with interfaces that appear as
normal wired interfaces, but could be bridged to wireless.  We currently
treat them as lossless wired interfaces, which gives fast reaction to link
failures (just 1.5 hello intervals on average) and no cost fluctuations,
which reduces the amount of control traffic.  However, this causes very
bad behaviour when there is a wireless bridge in the way -- it causes
repeated link failures, which causes massive instability --, and
suboptimal routing due to split horizon processing.

I can see the following possibilites:

 0. ignore the issue;

 1. use the wireless type by default (as with -w), people who have
    lossless wired links will need to configure them manually; this is bad
    for Homenet, which is expected to use wired links extensively, but
    perhaps it doesn't matter, Homenet can accept 15 seconds instead of 6;

 2. use the tunnel type by default; similar to the above, but perhaps
    slightly less drastic;

 3. find a way to make babeld less sensitive to links flapping in
    non-redundant networks (it already behaves well when the flapping link
    is redundant, but in a non-redundant topology it advertises every link
    flap across the routing domain).

Opinions?

-- Juliusz