[PATCH 2/3] babel: Short-circuit route selection for routes we originate ourselves
Routes that are originated by this Babel instance doesn't have an entry in e->selected, which means that the best route selection logic will always pick another route when an update arrives for the same prefix. This will be rejected by Bird core, which will cause a nice looping selection procedure (depending on filters, of course). To avoid this problem, simply short-circuit the route selection procedure if the entry has our own router ID set. Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> --- proto/babel/babel.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index a8eb5ea8..f7981333 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -727,6 +727,9 @@ babel_select_route(struct babel_proto *p, struct babel_entry *e, struct babel_ro { struct babel_route *r, *best = e->selected; + if (e->router_id == p->router_id) + return; + /* Shortcut if only non-best was modified */ if (mod && (mod != best)) { -- 2.17.0
On Mon, Apr 30, 2018 at 05:15:18PM +0200, Toke Høiland-Jørgensen wrote:
Routes that are originated by this Babel instance doesn't have an entry in e->selected, which means that the best route selection logic will always pick another route when an update arrives for the same prefix. This will be rejected by Bird core, which will cause a nice looping selection procedure (depending on filters, of course).
Hi I don't see the problem. Condition (e->router_id == p->router_id) means that the router propagates a locally originated route for given prefix. Even in this case it is necessary to select best incoming route (for the same prefix) and propagate it to nest. Then nest decides (based on filters, priority) whether received route is better than locally originated route. If so, best incoming route is propagated back to Babel instead of locally originated one (and also to other protocols including kernel routing table) and is announced by Babel further. Otherwise, nothing happens (locally originated is still selected as best and announced by Babel). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On 30 April 2018 22:32:18 CEST, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Apr 30, 2018 at 05:15:18PM +0200, Toke Høiland-Jørgensen wrote:
Routes that are originated by this Babel instance doesn't have an entry in e->selected, which means that the best route selection logic will always pick another route when an update arrives for the same prefix. This will be rejected by Bird core, which will cause a nice looping selection procedure (depending on filters, of course).
Hi
I don't see the problem. Condition (e->router_id == p->router_id) means that the router propagates a locally originated route for given prefix. Even in this case it is necessary to select best incoming route (for the same prefix) and propagate it to nest. Then nest decides (based on filters, priority) whether received route is better than locally originated route. If so, best incoming route is propagated back to Babel instead of locally originated one (and also to other protocols including kernel routing table) and is announced by Babel further. Otherwise, nothing happens (locally originated is still selected as best and announced by Babel).
Hmm, it may be that I was just treating a symptom. I'll look at it again and possibly return with another patch :) -Toke
Toke Høiland-Jørgensen <toke@toke.dk> writes:
On 30 April 2018 22:32:18 CEST, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Apr 30, 2018 at 05:15:18PM +0200, Toke Høiland-Jørgensen wrote:
Routes that are originated by this Babel instance doesn't have an entry in e->selected, which means that the best route selection logic will always pick another route when an update arrives for the same prefix. This will be rejected by Bird core, which will cause a nice looping selection procedure (depending on filters, of course).
Hi
I don't see the problem. Condition (e->router_id == p->router_id) means that the router propagates a locally originated route for given prefix. Even in this case it is necessary to select best incoming route (for the same prefix) and propagate it to nest. Then nest decides (based on filters, priority) whether received route is better than locally originated route. If so, best incoming route is propagated back to Babel instead of locally originated one (and also to other protocols including kernel routing table) and is announced by Babel further. Otherwise, nothing happens (locally originated is still selected as best and announced by Babel).
Hmm, it may be that I was just treating a symptom. I'll look at it again and possibly return with another patch :)
Right, after investigating this, I think the behaviour I am seeing is pathological but not necessarily something that needs to be fixed. What happened was, I was turning on the router ID randomisation feature, but running with a peer that still had the u64/uint router ID bug. So that peer would zero out the upper 32 bits of the router ID and echo the routes back; which would cause the originating babel note to switch the route, and issue a triggered update with the truncated router ID, that would be unfeasible from the misbehaving router's perspective, causing a retraction. This will then end up oscillating back and forth indefinitely. This behaviour relies on the fact that the route was initially learned from the kernel, so from the nest's perspective it has very low preference. I'm not sure that is actually desirable in Babel's case? Why are routes learned from the kernel assigned the lowest preference? Anyway, I don't think it's something that needs fixing in the Babel code, so feel free to drop this patch :) -Toke
On Tue, May 01, 2018 at 01:22:47PM +0200, Toke Høiland-Jørgensen wrote:
This behaviour relies on the fact that the route was initially learned from the kernel, so from the nest's perspective it has very low preference. I'm not sure that is actually desirable in Babel's case? Why are routes learned from the kernel assigned the lowest preference?
I think that it is some legacy issue. Perhaps the original idea was that routes learned from kernel were some initial routes used during boot, which were later replaced by routes from dynamic routing. But as BIRD (on Linux) currently do not allow to overwrite alien routes anyway, it would make sense that these routes would have higher priority, like static routes. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Tue, May 01, 2018 at 01:22:47PM +0200, Toke Høiland-Jørgensen wrote:
This behaviour relies on the fact that the route was initially learned from the kernel, so from the nest's perspective it has very low preference. I'm not sure that is actually desirable in Babel's case? Why are routes learned from the kernel assigned the lowest preference?
I think that it is some legacy issue. Perhaps the original idea was that routes learned from kernel were some initial routes used during boot, which were later replaced by routes from dynamic routing. But as BIRD (on Linux) currently do not allow to overwrite alien routes anyway, it would make sense that these routes would have higher priority, like static routes.
Yeah, I agree. The current behaviour was certainly surprising to me ;) -Toke
participants (2)
-
Ondrej Zajicek -
Toke Høiland-Jørgensen