Re: [PATCH v2 3/3] Optimize route dependency solver.
On Sat, 19 Sep 2026 14:56:56 +0200
Martin Schitter
On 9/17/26 21:08, Stefano Brivio wrote:
Never make more resolution attempts than there are still unresolved dependency errors.
In the context of my current mesh network with ~700 route entries these changes reduce the required processing time from 5.5s to 15ms.
Ouch. Nice.
After searching for answers, how these ENETUNREACH and EHOSTUNREACH in the dependency solver routines are actually caused, I finally looked into the iproute2 code for the save and restore commands:
https://github.com/iproute2/iproute2/blob/e6471d772f3e15a813e6c9a81b4b7adcfa...
Now I finally see that this task can be handled without all this stupid trial-and-error play and doesn't require a limit of route entries if we just reassemble the routing tables in three successive steps resp. loops:
/* Restore routes in correct order: * 0. ones for local addresses, * 1. ones for local networks, * 2. others (remote networks/hosts). */
Just a quick comment before you risk losing a lot of time (I'm really not sure though): there *might* be interdependencies between routes in 1. and between routes in 2., especially with 'nexthop' objects. And IPv6 has several scopes. Maybe it all works thought, I haven't checked your iproute reference yet. -- Stefano
On 9/19/26 15:07, Stefano Brivio wrote:
Just a quick comment before you risk losing a lot of time (I'm really not sure though): there*might* be interdependencies between routes in 1. and between routes in 2., especially with 'nexthop' objects. And IPv6 has several scopes. Maybe it all works thought, I haven't checked your iproute reference yet.
This alternative approach is looking for route table entries in exactly the same tables and scopes. There is no difference in this regard. It's just using a more rational strategy to minimize dependency errors. The most common cause for EHOSTUNREACH and ENETUNREACH errors are related to attempts adding a route without having defined the local exit capabilities first. There are still a few other possible reasons causing these particular errors (policy routing, disabled interfaces, etc.), but those cases are also not solved by any of our previous solutions! The errors just got ignored after many useless loops and costly operations. You can iterate as often as you like over this list of route entries and try to add them, but the amount of dependency errors will stay the same after just a few attempts (those, which define the elementary local host and network route connectivity information). We don't have to solve a complex network of transitive dependency relations, but only respect the much simpler order of dependency relations between very few different classes of entries. Well, that's at least my current understanding of this issue. But I still have to further think about it and test it in practice...
participants (2)
-
Martin Schitter
-
Stefano Brivio