[PATCH 2/3] babel: Short-circuit route selection for routes we originate ourselves

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <toke at toke.dk> writes:

> On 30 April 2018 22:32:18 CEST, Ondrej Zajicek <santiago at 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