Re: [PATCH 0/3] net: ioam6: makes IOAM insertion transparent to IPv6 ECMP

[Jakub Kicinski]

On Wed, 28 Oct 2026 16:01:13 +0800 Hangbin Liu wrote:
> On Wed, Oct 28, 2026 at 01:45:28PM +0800, Hangbin Liu wrote:
> > This series makes IOAM insertion transparent to IPv6 ECMP, as required
> > by RFC 9486 (C2): a packet carrying IOAM options must be forwarded
> > along the same path as the identical packet without them.  
> 
> Sorry, forgot to add target repo "net". I will add it in next version.

CI bot says:

The new selftest added alongside this series (tools/testing/selftests/net/ioam6_ecmp.sh)
is failing in our CI on the "Transit input ECMP with/without IOAM" scenario:

  TEST: Transit input ECMP with/without IOAM (diverged on seed 1: without IOAM via
        link A, with IOAM via link B)   [FAIL]
  TEST: Transit input ECMP with/without IOAM (seed 2..12)                [ OK ]
  TEST: Encapsulating node re-lookup ECMP with/without IOAM (seed 1..12) [ OK ]

11 of the 12 "transit input" seeds pass, and the whole "encapsulating node re-lookup"
scenario passes on all seeds, so this looks like an edge case in the Hop-by-Hop
nexthdr-recovery logic used for the policy-0 multipath hash, rather than a test
infra/flake issue. Could you take a look at whether the recovered "virtual" nexthdr
(or the padding/option-length walk used to compute it) is correct for all IOAM option
layouts/trace sizes, since one specific packet still ends up hashed to a different ECMP
sibling than the equivalent packet without IOAM?