> > >> > >> > On the first point, there are scenarios where a BGP nexthop can be >> > resolved over a BGP route. One example would be with BGP >> > labeled-unicast. draft-ietf-rtgwg-bgp-routing-large-dc mentions a >> > use-case too. >> > >> > On the second point, it is a somewhat artificial scenario as you say. It >> > is possible that the right change is to walk up the tree as done in >> > zebra_rib.c. We'll get back on this. >> >> Okay cool. You may want to look into the nexthop_active_ipv4/ipv6 >> methods whichever way you go because they really need to match the >> semantics of the nexthop tracking. E.g. when the nexthop tracking comes >> up with a nexthop that is resolved via BGP, it will currently not result >> in a working FIB route, because bgpd will send the route to zebra, but >> nexthop_active_ipv4/ipv6 won't resolve over the BGP route. >> > > On this point, I believe there isn't any real need to restrict BGP > nexthops to be resolved only over non-BGP routes. Our patch (on Donald's > 'take X' branch) has also removed this check from nexthop_active_ipv4/ipv6. > I think my colleague Daniel also had more to add on this aspect. >
I used to work with a large ISP that intentionally resolved BGP nexthops via BGP. Instead of doing nexthop-self on their iBGP peers they would do "redistribute connected" to make the customer facing /30s routeable. I wasn't a big fan of the approach (why carry all of those /30s when you could just do nexthop-self) but it was legit and did work. None of the specs call for nexthops to be resolved via a non-bgp route...I think it is safe to remove the restriction. Daniel
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
