On Tue, Dec 15, 2020 at 01:05:22PM +0100, Toke Høiland-Jørgensen wrote: > Andreas Rammhold <[email protected]> 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:[email protected] @ 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. 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. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
