BIRD and ECMP on Linux seems flaky

[Ondrej Zajicek]

On Tue, Jan 19, 2016 at 04:11:10PM +0100, Arno Töll wrote:
> Hi,
> 
> On Tuesday 12 January 2016 00:09:34 Wilco Baan Hofman wrote:
> 
> > In this case, the API is not symmetrical. You can set routes via the
> > multipath structures, but the Linux kernel splits this up into separate
> > routes internally, because with IPv6 you can now have multiple routes to
> > the same destination that are not linked together (why? Maybe to
> > remove/add one of the nexthops independently or something).
> 
> arguably I think bird should adapt to whatever the public APIs of
> Linux provide, and not the other way around as long as Linux is a
> supported platform to bird.
> 
> This makes me wonder if you guys would accept patches working around
> this asymmetry for ECMP route in bird in order to have compliant ECMP
> support in bird for IPv6 based on Ondrej Z.'s patch? If so, do you
> have any constraints? What about bird 2?

Hi

Sorry for a late answer. Patches for handling IPv6 ECMP support in Linux
with current API could be accepted if they are not too crazy. Unfortunately
the API has several problems that complicates its usage from BIRD.

E.g.: 1. when asynchronous updates are received, they do not contain the
whole route, just the modified next hop. 2. when a new ECMP route
appears, it is announced as a sequence of next hops, but there is AFAIK
no flag for 'this is last next hop'.

Seems to me that there are several options how to workaround that. For
start, we could support IPv6 ECMP only in non-learn mode. Or we could
support learn/import (for IPv6 ECMP) during periodic scans only.

Using RTA_MULTIPATH in IPv6 Linux API is for backwards compatibility
(although it does not really provide it), so it would make sense to not
use that and just send muliple routes.

The patch could be against int-new branch for BIRD 2. Or you could send
two patches, one against master for BIRD 1.x and one against int-new for
BIRD 2.

-- 
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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160127/faf7a3e5/attachment.asc>