[RFC] Babel: add v4viav6 support

[andreas at rammhold.de]

On 18:14 15.12.20, Ondrej Zajicek wrote:
> On Tue, Dec 15, 2020 at 01:05:22PM +0100, Toke Høiland-Jørgensen wrote:
> > Andreas Rammhold <andreas at rammhold.de> writes:
> > 
> > >  * What if the kernel doesn't accept the RTA_VIA value we gave it?
> > >    Does BIRD generally handle this already?
> > >    One example is hitting: "ipv4: use IS_ENABLED instead of ifdef"
> > >    (id:20201115224509.2020651-1-flokli at flokli.de @ linux-netdev) Where
> > >    the kernel does support it but due to a bug fails to add those routes
> > >    when CONFIG_IPV6=m.
> > >    Kernel version comparison is probably a bad idea. Which kind of route
> > >    can we attempt to install to test this functionality without breaking
> > >    any setup?
> > 
> > Can't we just have Bird do the equivalent of:
> > 
> > ip r add 192.0.2.1/32 via inet6 ::2 dev lo onlink
> > ip r del 192.0.2.1/32 via inet6 ::2 dev lo onlink
> > 
> > on startup, and set a system flag depending on whether the operation
> > fails or not?
> 
> Well, i would prefer to just add Babel protocol option to accept these
> extended next hops, make it disabled by default, and left it to the user.
> 
> It is similar to ECMP, which may not be supported by kernel (if its
> support is disabled). We also had it disabled by default in BIRD 1.x, but
> changed the default in BIRD 2, as it is now widely supported.

In the ECMP case was there some breakage when the system didn't support
it but Bird tried to install those routes?

> We could perhaps implement later some generic mechanism later to detect
> global system properties during start, so they can be accessed during
> configuration processing to have different defaults based on system
> abilities.
> 
> Note that even if Kernel supports this feature, there is no surety that
> such route is used for forwarding. For example, Kernel protocol may not
> be even configured, or export filter on it may filter out routes with
> such next hops.

Arguably Bird2 always supports it internally and the user can always
(re)export them via another protocol (BGP) without having to install
them locally. In that case the kernel version doesn't actually matter
and enabling this by default would probably not break any setup.

Even if the kernel supports v4-via-v6 there is no new breakage when this
feature is enabled as a "surprise" as v4-via-v4 is still preferred.
v4-via-v6 only "breaks" your setup if you relied on the absence of v4
addresses on some interfaces to stop propagation of some route/path
(e.g. a script adding/removing the address on the interface).