BIRD 1.6.2 removes IPv6 kernel routes

[Ondrej Zajicek]

On Wed, Dec 21, 2016 at 02:53:33PM +0000, Israel G. Lugo wrote:
> On 11/13/2016 07:59 PM, Ondrej Zajicek wrote:
> >> It looks like bird6 1.6.2 is eating IPv6 routes set by the kernel.
> >> I have not encountered this issue with the IPv4 bird daemon.
> > Hi

> I understand that the kernel itself seems to be inconsistent between
> IPv4 and IPv6, causing this problem. However, whatever you were doing
> back in 1.5.0 was working. I assume the change in behavior is due to the
> new features in 1.6 (e.g. ECMP on IPv6), and it's not practical to go
> back to the old way.

Hi

That is true. We found later that the old code worked by some unspecified
kernel behavior and probably was not reliable either. There were several
ways to workaround it, but each one breaks in some circumstances.

In retrospect, the best way would be to have both old code and new code
(with ECMP) and require an option to enable ECMP (and use some metric in
that case). But now, that would break configs that depend on ECMP enabled
by default.


> That said, would it be possible to have a default kernel metric that
> already prevents this from happening? So that people aren't bit
> unexpectedly. Even if it's just metric 1 or something. I set mine to 20,
> following your suggestion, and it works as expected.

That is something we plan for the next major release (2.0, or 1.7 if we
will have that). Unfortunately having default kernel metric also could
break some configs (as then krt_metric route attribute is ignored).


> Failing that, perhaps it would be a good idea to mention this behavior
> in the documentation, for the benefit of those who did not read this
> thread (or, like me, did read it but forgot).

Well, it is mentioned in description of 'metric' option, but perhaps not
emphasized enough. I will add it to FAQ.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."