Exporting multipath link routes from Linux kernel

[Eugene Crosser]

On 21/01/2019 21:20, Ondrej Zajicek wrote:

>> https://gitlab.labs.nic.cz/labs/bird/blob/master/sysdep/linux/netlink.c#L528
>>
>> Questions:
>>
>> 1. What was the justification for disallowing gateway-less multipath
>> routes? Would it make sense to allow them (in the mainstream code)?
> 
> The code differentiated between gateway and gateway-less routes based on
> rta->dest (RTD_ROUTER for gateway, RTD_DEVICE for gateway-less). We
> extended that to have RTD_MULTIPATH, but there was no separate dest for
> each nexthop, so we restricted it to have all nexthops with gateways.
> Also, ECMP routes generated by protocols (e.g. OSPF) are always with
> nexthops, so it was generally not a big limitation.
> 
> In BIRD 2.0, we unified this, replaced RTD_ROUTER / RTD_DEVICE /
> RTD_MULTIPATH with RTD_UNICAST, which can handle ECMP routes with mixed
> gateway and gatewa-less nexthops.
> 
> 
>> 2. Would it be sufficient to simply drop the check for the presence of
>> the gateway address in the message, and return `first` even if gateway
>> address was not present?
> 
> Not sure what you mean by `first`. You cannot read RTA_GATEWAY field if

I was referring to the variable name in the code that I linked to.
I was looking at the code in the master branch, I assumed that it is 2.x?
The code _looks_ as if it will behave the same as in 1.6, but I did not try to
run it.

> there is none and you cannot call neigh_find2() for 0.0.0.0 address. You
> could set rv->gw to IPA_NONE, that would perhaps work in most cases, but
> it is untested.
> 
> Or just switch to BIRD 2.0

I will try that; I hope that I was wrong in my analysis.

Thank you,

Eugene

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190121/e811d6c5/attachment.sig>