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