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
signature.asc
Description: OpenPGP digital signature
