Hi Andrea,
On Sun, Oct 11, 2026 at 09:23:09PM +0200, Andrea Mayer wrote:
> Extend srv6_end_flavors_test.sh with tests for the SRv6 End behavior
> with both the NEXT-C-SID and PSP flavors.
> 
> The tests use two SRv6 Policies with C-SID containers, where every
> router after the ingress one applies End with the NEXT-C-SID and PSP
> flavors. To check PSP, set net.ipv6.conf.all.seg6_enabled to 0 on the
> hosts in setup_hs(). The hosts then drop any packet that still carries
> an SRH, and a ping to an address on the loopback of a host succeeds
> only if the router connected to that host has removed the SRH. The tests
> fail when PSP is not applied together with NEXT-C-SID.
> 
> Signed-off-by: Andrea Mayer <[email protected]>
> ---
>  .../selftests/net/srv6_end_flavors_test.sh    | 229 +++++++++++++++++-
>  1 file changed, 226 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/testing/selftests/net/srv6_end_flavors_test.sh 
> b/tools/testing/selftests/net/srv6_end_flavors_test.sh
> index 30a939392eea..baa1b09a1aab 100755
> --- a/tools/testing/selftests/net/srv6_end_flavors_test.sh
> +++ b/tools/testing/selftests/net/srv6_end_flavors_test.sh
> @@ -439,6 +549,7 @@ setup_rt_local_sids()
>       local devname
>       local nsname
>       local neigh
> +     local csid
>  
>       nsname="$(get_rtname "${rt}")"
>  
> @@ -452,6 +563,14 @@ setup_rt_local_sids()
>                       add "${LOCATOR_SERVICE}:${neigh}::/32" \
>                       table "${LOCALSID_TABLE_ID}" \
>                       via "${net_prefix}::${neigh}" dev "${devname}"
> +
> +             # set underlay network routes to reach the C-SID containers
> +             # that start with a C-SID of the neighbor, for any Function.
> +             csid="$(build_csid "${neigh}" 00)"
> +             ip -netns "${nsname}" -6 route \
> +                     add "${LCBLOCK_ADDR}:${csid}::/${LCBLOCK_NODE_BLEN}" \
> +                     table "${LOCALSID_TABLE_ID}" \
> +                     via "${net_prefix}::${neigh}" dev "${devname}"
>       done
>  
>       # Local End behavior (note that "dev" is a dummy interface chosen for
> @@ -461,6 +580,17 @@ setup_rt_local_sids()
>               table "${LOCALSID_TABLE_ID}" \
>               encap seg6local action End dev "${DUMMY_DEVNAME}"
>  
> +     # Local End behavior with the NEXT-C-SID and PSP flavors, bound to the
> +     # C-SID of the router (e.g. fcbb:0:04a1::/48 on rt-4). The /48 prefix
> +     # covers every C-SID container whose first C-SID is this one, whatever
> +     # the Argument that follows.
> +     csid="$(build_csid "${rt}" "${END_CSID_PSP_FUNC}")"
> +     ip -netns "${nsname}" -6 route \
> +             add "${LCBLOCK_ADDR}:${csid}::/${LCBLOCK_NODEFUNC_BLEN}" \
> +             table "${LOCALSID_TABLE_ID}" \
> +             encap seg6local action End flavors next-csid,psp \
> +             lblen "${LCBLOCK_BLEN}" nflen "${LCNODEFUNC_BLEN}" \
> +             dev "${DUMMY_DEVNAME}"

This is a End + PSP specific encapsulation. If there is a new version patch,
can we move this block

> @@ -494,6 +634,7 @@ __setup_rt_policy()
>       local in_nsname
>       local rt_nsname
>       local policy=''
> +     local container
>       local function
>       local fullsid
>       local op_type
> @@ -520,6 +661,15 @@ __setup_rt_policy()
>                       behavior_cfg="End flavors psp"
>                       ;;
>  
> +             "next-csid,psp")
> +                     # the behavior is already set up on every router by
> +                     # setup_rt_local_sids.
> +                     container="$(build_csid_container "${node}" \
> +                             "${END_CSID_PSP_FUNC}")"
> +                     policy="${policy}${container},"
> +                     continue
> +                     ;;
> +

to here? So we can align with the other SRv6 Endpoint behavior?
Because later in the End.X PSP support we also need to cleanup and
re-setup with END.X.

If this version is applied (which is also good), I can do the modification
in my patch set.

Others looks good to me.

Tested-by: Hangbin Liu <[email protected]>
Reviewed-by: Hangbin Liu <[email protected]>

Thanks
Hangbin

Reply via email to