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(-) > Hi Justin, Thanks for working on this! I'll focus on a couple of design aspects for now, and we can look at the details once we settle on those. > > [snip] > > setup_hs() > @@ -567,41 +601,41 @@ setup() > # the network path between hs-1 and hs-2 traverses several routers > # depending on the direction of traffic. > # > - # Direction hs-1 -> hs-2 (H.Encaps.Red) > + # Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc) > # - rt-3,rt-4 (SRv6 End behaviors) > # - rt-2 (SRv6 End.DT46 behavior) > # > # Direction hs-2 -> hs-1 (H.Encaps.Red) > # - rt-1 (SRv6 End.DT46 behavior) > - setup_rt_policy_ipv6 2 1 "3 4" 2 encap.red > - setup_rt_policy_ipv6 1 2 "" 1 encap.red > + setup_rt_policy_ipv6 2 1 "3 4" 2 encap.red true > + setup_rt_policy_ipv6 1 2 "" 1 encap.red false > > # create an IPv4 VPN between hosts hs-1 and hs-2 > # the network path between hs-1 and hs-2 traverses several routers > # depending on the direction of traffic. > # > - # 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. 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. > > [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
