On Thu, Dec 18, 2025 at 5:04 PM Valent@MeshPoint <[email protected]> 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 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
