Subject: [babel] Example configuration

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 25 Jul 2019 16:53:33 -0400

Hi Babel,

In my presentation on the YANG model for Babel, I asked for help in trying to improve the example configuration of Babel. The example was shown in XML, but that does not mean I am expecting anyone to help me improve the example in XML.

You can describe what you see as a potential configuration of Babel. If you feel even more motivated you can use the attribute names from the information model to describe which parameters you see configured. If you feel even more motivated, you can use the attribute names from the YANG data model, but by now I am really pushing the boundary, so I will stop.

Thanks in advance. 

Mahesh Jethanandani
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 25 Jul 2019 23:51:39 +0200

> In my presentation on the YANG model for Babel, I asked for help in
> trying to improve the example configuration of Babel. The example was
> shown in XML, but that does not mean I am expecting anyone to help me
> improve the example in XML.

I'll use the syntax of the babeld configuration file.

Here's a pretty minimal config:

  interface eth0
  interface wlan0

This says to run Babel on interfaces eth0 and wlan0.  Babeld will
automatically detect that eth0 is wired and wlan0 is wireless, and will
configure the right parameters automatically.

Here's a slightly less minimal configuration:

  interface eth0
  interface eth1 type wireless
  interface tun0 type tunnel

Here, interface eth1 is an Ethernet bridged to a wireless radio, so
babeld's autodetection fails, and the interface type needs to be
configured manually.  Tunnels are not detected automatically, so this
needs to be specified.

This is equivalent to the following:

  interface eth0
  interface eth1 link-quality true split-horizon false
  interface tun0 enable-timestamps true max-rtt-penalty 96

Here's another configuration:

  interface eth0
  interface ppp0 hello-interval 30 update-interval 120
  in if ppp0 metric 1024
  out if ppp0 metric 1024

Here, ppp0 is a metered 3G link used for fallback connectivity.  It runs
with much higher than default time constants in order to avoid control
traffic as much as possible, and the metric of routes through that link
are increased so that they are not used unless all other options fail.

Here's a configuration for David:

  interface eth0
  interface wlan0 unicast true

This requests that all control traffic other than Hellos on the wlan0
interface be sent as unicast.  This can be useful when wlan0 uses
a technology on which multicast is prohibitively expensive.

Another one:

  interface atm0 split-horizon false unicast true

Here, atm0 is an NBMA interface.  Transitive connectivity is not
guaranteed, so we disable the split-horizon optimisation.  Unicast is to
be preferred to multicast whenever possible.

Here is a configuration that is not yet implemented, but planned for
a future version:

  interface wg0 unicast-only true
  neighbour fe80::1234 if wg0

Here, wg0 is a Wireguard tunnel, and doesn't support multicast at all.
All traffic over that interface is sent as unicast, so automatic discovery
is not possible.  Thus, we need to specify the link-local addresses of
neighbours manually.

Hope this helps,

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 26 Jul 2019 14:08:52 -0400

Hi Juliusz,

Yes, this is very helpful. Let me get back to you if I have any questions about any of these examples.

Thanks.

Mahesh Jethanandani
[email-masked]