Le 28/11/2025 à 18:49, azey a écrit :

On 2025-11-28 17:28:41 +0100  Nicolas Dichtel [off-list ref] wrote:

quoted

Le 28/11/2025 à 16:54, azey a écrit :

quoted

quoted

On 2025-11-28 09:38:07 +0100  Nicolas Dichtel [off-list ref] wrote:

quoted

With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit
doesn't allow this:

Hold on, I think I understand what you actually meant by this, sorry.
I got too focused on regressions from the discussion in v1, I'll make
a v3 of the patch that allows dev-only routes to be added via append.

Yes, that is what I pointed out.

Please, add some self-tests to show that there is no regression. You probably
have to test different combinations of NLM_F_* flags. See:

https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2418

Will do, thanks for the pointer.
One last thing I'd like to clarify though: would this behavior not also
itself be considered a regression?

Currently the add and append routes get added separately, and someone
could theoretically be relying on the kernel always picking the last
route instead of making them multipath - essentially still the same
v1 regression.

That's a good question. I let others speak.
But using the nexthop API would definitely close this question. I wonder why
using this API is not possible for you.

If not, would it also be acceptable for just any non-RTPROT_KERNEL
routes to automatically be made multipath like this? It's a simple fix,
it'd make appending work and it'd still prevent the specific v1
regression for the case of two interfaces on the same subnet - example
diff attached.

I don't think that the protocol field is reliable. The user can set it to
whatever he wants.