Re: bgp add paths to select only equal routes
Hello, We aggregate routes learnt from bgp peers into multipath routes (ECMP) and need to pass some of them to other peer. And there are complexities now because we export not only the components of the best multipath routes, but all others too, with lower local preference, for example. If that peer is EBGP, the local preference is usually lost and those routes become equal. I think we can now overcome this limitation for our setup with some additional pain. But I think feature like that would eventually be useful somewhere. Though, I am not sure there is high demand for it from others. :) On Thu, May 16, 2019 at 6:08 PM Ondrej Zajicek wrote: > > On Wed, May 15, 2019 at 07:51:55PM +0200, Alexander Zubkov wrote: > > Hello, > > > > If "add paths" config option is enabled for a bgp protocol than it > > sends every route matching the filter on export. But I would like to > > have an option to send only the best route with routes similar to it > > (equal localpref, aspath length, ...). Like it is done in the kernel > > protocol and its "merge paths" option. So for example if I had 2 > > routes for the same prefix with different bgp_local_pref or bgp_path > > length, than only the route with better attributes would be announced > > to the peer. Currently both routes would be announced. > > Hello > > That is true. For BGP ADD_PATH, all routes that pass filters are > exported. We prefer to not add more export modes (like one for "merge > paths") as that significantly complicates a part of code that is already > too complicated. We plan to do some redesign there that should make it > much simpler, so perhaps after that. > > Also, how such mode should behave and how much should be configurable? > For example, "merge paths" applies to routes that are the same up to > (including) IGP metric, on the contrary a basic use case for BGP ADD_PATH > is to exchange feasible routes to/from route reflector and avoid issue > with inconsistency and route hiding due to IGP metric being different on > different speakers. For this case it would make sense to export routes > with inferior IGP metric (and less important attributes), but not ones > with inferior bgp_local_pref or bgp_path length. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: bgp add paths to select only equal routes
On Wed, May 15, 2019 at 07:51:55PM +0200, Alexander Zubkov wrote: > Hello, > > If "add paths" config option is enabled for a bgp protocol than it > sends every route matching the filter on export. But I would like to > have an option to send only the best route with routes similar to it > (equal localpref, aspath length, ...). Like it is done in the kernel > protocol and its "merge paths" option. So for example if I had 2 > routes for the same prefix with different bgp_local_pref or bgp_path > length, than only the route with better attributes would be announced > to the peer. Currently both routes would be announced. Hello That is true. For BGP ADD_PATH, all routes that pass filters are exported. We prefer to not add more export modes (like one for "merge paths") as that significantly complicates a part of code that is already too complicated. We plan to do some redesign there that should make it much simpler, so perhaps after that. Also, how such mode should behave and how much should be configurable? For example, "merge paths" applies to routes that are the same up to (including) IGP metric, on the contrary a basic use case for BGP ADD_PATH is to exchange feasible routes to/from route reflector and avoid issue with inconsistency and route hiding due to IGP metric being different on different speakers. For this case it would make sense to export routes with inferior IGP metric (and less important attributes), but not ones with inferior bgp_local_pref or bgp_path length. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Received route with strange next-hop
On Wed, May 15, 2019 at 09:09:34AM +, Adrichem, N.L.M. (Niels) van wrote: > Hello, > > Additionally, the bird.log file throws the following error: > 2019-05-15 10:27:21.869 Started > 2019-05-15 10:27:21.902 Missing broadcast address for interface vxlan0 > 2019-05-15 10:27:29.329 KRT: Received route 10.0.1.3/32 with strange > next-hop 10.0.1.4 > > It may be that kernel protocol rejects the route because the next-hop > is not in the interface its regular netmask (which is set to /32), though > I am not familiar enough with the source code to determine the exact > cause except that the error gets thrown from sysdep/linux/netlink.c line > 1643. However, I think the line should be accepted since there is another > routing rule confirming that the next-hop is directly attached to device > eth1. Given the explicit error I don't think this is a configuration > error (though I am open to learn more), so I hope BIRD can be patched to > solve this. Hello BIRD generally expects that next hop is resolvable through an address range associated with interfaces, not just through another direct/device route. This is limitation compared to the Linux kernel which allows next hop resolvable through another direct/device route (but not through another regular route with next-hop). We have some plans to redesign it in a more generic manner, but it is not a simple fix. As a workaround, attached patch (untested) should disable next hop checking for all alien routes. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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." diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index d773743d..d5d64b6b 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -1632,7 +1632,7 @@ nl_parse_route(struct nl_parse_state *s, struct nlmsghdr *h) if ((i->rtm_family == AF_INET6) && ipa_in_netX(ra->nh.gw, (net_addr *) )) return; - if (i->rtm_flags & RTNH_F_ONLINK) + if ((i->rtm_flags & RTNH_F_ONLINK) || (krt_src == KRT_SRC_ALIEN)) ra->nh.flags |= RNF_ONLINK; neighbor *nbr;
