On Tue, Mar 17, 2026 at 11:54 AM Andrea Mayer <[email protected]> wrote: > > On Mon, 16 Mar 2026 17:29:55 +0100 > Justin Iurman <[email protected]> wrote: > > > Extend srv6_hencap_red_l3vpn_test.sh to include checks for the new > > "tunsrc" feature. > > > > Cc: Shuah Khan <[email protected]> > > Cc: [email protected] > > Signed-off-by: Justin Iurman <[email protected]> > > --- > > .../net/srv6_hencap_red_l3vpn_test.sh | 65 ++++++++++++++----- > > 1 file changed, 50 insertions(+), 15 deletions(-)
[snip] > > - # Direction hs-1 -> hs-2 (H.Encaps.Red) > > + # Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc) > > # - rt-2 (SRv6 End.DT46 behavior) > > # > > # Direction hs-2 -> hs-1 (H.Encaps.Red) > > # - rt-4,rt-3 (SRv6 End behaviors) > > # - rt-1 (SRv6 End.DT46 behavior) > > - setup_rt_policy_ipv4 2 1 "" 2 encap.red > > - setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red > > + setup_rt_policy_ipv4 2 1 "" 2 encap.red true > > + setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red false > > > > # create an IPv6 VPN between hosts hs-3 and hs-4 > > # the network path between hs-3 and hs-4 traverses several routers > > # depending on the direction of traffic. > > # > > - # Direction hs-3 -> hs-4 (H.Encaps.Red) > > + # Direction hs-3 -> hs-4 (H.Encaps.Red + tunsrc) > > # - rt-2 (SRv6 End Behavior) > > # - rt-4 (SRv6 End.DT46 behavior) > > # > > # Direction hs-4 -> hs-3 (H.Encaps.Red) > > # - rt-1 (SRv6 End behavior) > > # - rt-3 (SRv6 End.DT46 behavior) > > - setup_rt_policy_ipv6 4 3 "2" 4 encap.red > > - setup_rt_policy_ipv6 3 4 "1" 3 encap.red > > + setup_rt_policy_ipv6 4 3 "2" 4 encap.red true > > + setup_rt_policy_ipv6 3 4 "1" 3 encap.red false > > > > # testing environment was set up successfully > > SETUP_ERR=0 > > > The paths marked "true" here were testing the encap.red baseline before > this change. They need to stay exactly as they were originally. > Furthermore, if tunsrc is not supported by the kernel running the test, > the ip route command with tunsrc will fail during setup() (since > set -e is used), and the entire script dies before any test runs. I kinda disagree here: you're not supposed to run the updated selftests on an old kernel or with an old iproute2 version (versions are kept aligned). And I also concur with Jakub about degraded environments on your last comment below. > The idea here is to avoid duplicating the entire test suite, while still > providing dedicated test cases for the new per-route tunsrc. A reasonable > approach could be adding the tunsrc checks as new, separate test cases > that run after the baseline ones, leaving the existing paths completely > untouched. > > For example, a dedicated test_tunsrc() function could take care of the > whole thing for a given path: setting up the tunsrc address, installing > the route with tunsrc, verifying the behavior, cleaning up, and finally > restoring the original route. Well, I actually thought that this approach would be easier, and would specifically avoid adding too much code or having duplication. FWIW, I don't think providing dedicated test cases for the new per-route tunsrc really makes sense, as it's the same behavior as without "tunsrc". It doesn't impact the encap baseline by itself, since nothing in the selftests depends on the outer source address. I'm open to implement what you suggest, though, it's just that I'm not sure it's the best way forward. What I suggest as next step: I'll ship patch #1 alone, along with the iproute2-next companion series, so that we don't miss the merge window and have the feature in 7.1. In parallel, we keep discussing design choices for the selftest and ship it as soon as we settle. Would you agree with that plan? Cheers, Justin > > [snip] > > @@ -819,6 +853,7 @@ test_command_or_ksft_skip ip > > test_command_or_ksft_skip ping > > test_command_or_ksft_skip sysctl > > test_command_or_ksft_skip grep > > +test_command_or_ksft_skip ip6tables > > > > This will skip the entire script if ip6tables is not present, which > takes down the baseline tests too. > I think a probe at startup that checks for both tunsrc support and > ip6tables would work well here. If either is missing, we can > just gracefully skip the new tunsrc tests and let the rest of the script > run as usual. > > The bottom line is that the script needs to keep working exactly as > before when tunsrc is not supported or its dependencies are missing. > > Thanks, > Andrea
