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