[Babel-users] Babel instability in WLAN-SI

Juliusz Chroboczek jch at pps.univ-paris-diderot.fr
Mon Dec 14 16:33:53 UTC 2015


> I remember a case in Vienna where an Olsr daemon was its own neighbor,
> because (over a bridged connection) one of its 2.4 GHz neighbors
> bridged everything to a 5 GHz interface the local node could hear.

That's not the issue here -- a Babel node is allowed to be its own
neighbour, and this happens routinely on multi-radio nodes.  The loop
avoidance mechanism will ensure that such a looping link is never used for
routing.  (Interestingly, this was not planned -- it's yet another
pleasant consequence of having a loop-avoidance mechanism built into the
protocol core.)

The issue here is different -- when babeld thinks that a link is wired, it
disables link cost estimation in favour of 2-out-of-3 link sensing (see
Appendix A of RFC 6126).  2-out-of-3 is extremely unstable in the presence
of persistent packet loss, since it drops a link as soon as two packets in
a row are lost.  This spurious instability leads to increased control
traffic, which in turn leads to increased CPU usage.

-- Juliusz



More information about the Babel-users mailing list