[Babel-users] Restarting MeshPoint – seeking advice on routing for crisis/disaster scenarios

[Henning Rogge]

On Thu, Dec 18, 2025 at 5:04 PM Valent at MeshPoint
<valent at meshpointone.com> wrote:
>
> Good point on the pulsed jamming and routing update churn.
>
> I have a rough idea how this can go wrong, but I am not deeply familiar
> with how different protocols try to mitigate it in practice. Have you
> looked into how Babel, BATMAN adv, or OLSRv2 handle this today? For
> example whether they bias toward stability explicitly, damp updates, or
> treat flapping links differently under load or attack.

That's why I said you would need a good routing metric for this...
that's independent from the protocol. Both Babel and OLSRv2 support
(in theory) any kind of metric.

> I am especially curious whether any of them have mechanisms specifically
> meant to avoid being driven into constant recomputation by intermittent
> interference rather than genuine topology change.

I think both OLSR, Batman AND Babel would not deal well with this...
OLSR(v1/v2) would most likely still "work", but giving you highly
unstable dijkstra results that would lead to a LOT of routing loops
(which will kill your network)... Babel (Juliusz, correct me if I am
wrong) would most likely drown in new iterations of the getting path
metric and blackholing a lot of routes... if the input of the routing
protocol (link up/down and metric) changes faster than your protocol
can update its global state, you are in trouble (at best).

That's why I think more work on the metric would be necessary...
Instead of torturing your routing protocol with constantly updating
the metrics, you need to filter... if a link gives you all kinds of
values, you need to mark it as "that's a bad link" and keep it that
way until it doesn't misbehave anymore.

Henning Rogge