On 2/15/23 6:46 AM, Andrea Mayer wrote: > This selftest is designed for testing the PSP flavor in SRv6 End behavior. > It instantiates a virtual network composed of several nodes: hosts and > SRv6 routers. Each node is realized using a network namespace that is > properly interconnected to others through veth pairs. > The test makes use of the SRv6 End behavior and of the PSP flavor needed > for removing the SRH from the IPv6 header at the penultimate node. > > The correct execution of the behavior is verified through reachability > tests carried out between hosts. > > Signed-off-by: Andrea Mayer <andrea.mayer@xxxxxxxxxxx> > Signed-off-by: Paolo Lungaroni <paolo.lungaroni@xxxxxxxxxxx> > --- > tools/testing/selftests/net/Makefile | 1 + > .../selftests/net/srv6_end_flavors_test.sh | 869 ++++++++++++++++++ > 2 files changed, 870 insertions(+) > create mode 100755 tools/testing/selftests/net/srv6_end_flavors_test.sh > > diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile > index 3364c548a23b..6cd8993454d7 100644 > --- a/tools/testing/selftests/net/Makefile > +++ b/tools/testing/selftests/net/Makefile > @@ -38,6 +38,7 @@ TEST_PROGS += srv6_end_dt6_l3vpn_test.sh > TEST_PROGS += srv6_hencap_red_l3vpn_test.sh > TEST_PROGS += srv6_hl2encap_red_l2vpn_test.sh > TEST_PROGS += srv6_end_next_csid_l3vpn_test.sh > +TEST_PROGS += srv6_end_flavors_test.sh > TEST_PROGS += vrf_strict_mode_test.sh > TEST_PROGS += arp_ndisc_evict_nocarrier.sh > TEST_PROGS += ndisc_unsolicited_na_test.sh > diff --git a/tools/testing/selftests/net/srv6_end_flavors_test.sh b/tools/testing/selftests/net/srv6_end_flavors_test.sh > new file mode 100755 > index 000000000000..50563443a4ad > --- /dev/null > +++ b/tools/testing/selftests/net/srv6_end_flavors_test.sh > @@ -0,0 +1,869 @@ > +#!/bin/bash > +# SPDX-License-Identifier: GPL-2.0 > +# > +# author: Andrea Mayer <andrea.mayer@xxxxxxxxxxx> > +# author: Paolo Lungaroni <paolo.lungaroni@xxxxxxxxxxx> > +# > +# This script is designed to test the support for "flavors" in the SRv6 End > +# behavior. > +# > +# Flavors defined in RFC8986 [1] represent additional operations that can modify > +# or extend the existing SRv6 End, End.X and End.T behaviors. For the sake of > +# convenience, we report the list of flavors described in [1] hereafter: > +# - Penultimate Segment Pop (PSP); > +# - Ultimate Segment Pop (USP); > +# - Ultimate Segment Decapsulation (USD). > +# > +# The End, End.X, and End.T behaviors can support these flavors either > +# individually or in combinations. > +# Currently in this selftest we consider only the PSP flavor for the SRv6 End > +# behavior. However, it is possible to extend the script as soon as other > +# flavors will be supported in the kernel. > +# > +# The purpose of the PSP flavor consists in instructing the penultimate node > +# listed in the SRv6 policy to remove (i.e. pop) the outermost SRH from the IPv6 > +# header. > +# A PSP enabled SRv6 End behavior instance processes the SRH by: > +# - decrementing the Segment Left (SL) value from 1 to 0; > +# - copying the last SID from the SID List into the IPv6 Destination Address > +# (DA); > +# - removing the SRH from the extension headers following the IPv6 header. > +# > +# Once the SRH is removed, the IPv6 packet is forwarded to the destination using > +# the IPv6 DA updated during the PSP operation (i.e. the IPv6 DA corresponding > +# to the last SID carried by the removed SRH). > +# > +# Although the PSP flavor can be set for any SRv6 End behavior instance on any > +# SR node, it will be active only on such behaviors bound to a penultimate SID > +# for a given SRv6 policy. > +# SL=2 SL=1 SL=0 > +# | | | > +# For example, given the SRv6 policy (SID List := <X, Y, Z>): > +# - a PSP enabled SRv6 End behavior bound to SID Y will apply the PSP operation > +# as Segment Left (SL) is 1, corresponding to the Penultimate Segment of the > +# SID List; > +# - a PSP enabled SRv6 End behavior bound to SID X will *NOT* apply the PSP > +# operation as the Segment Left is 2. This behavior instance will apply the > +# "standard" End packet processing, ignoring the configured PSP flavor at > +# all. > +# > +# [1] RFC8986: https://datatracker.ietf.org/doc/html/rfc8986 > +# > +# Network topology > +# ================ > +# > +# The network topology used in this selftest is depicted hereafter, composed by > +# two hosts (hs-1, hs-2) and four routers (rt-1, rt-2, rt-3, rt-4). > +# Hosts hs-1 and hs-2 are connected to routers rt-1 and rt-2, respectively, > +# allowing them to communicate with each other. > +# Traffic exchanged between hs-1 and hs-2 can follow different network paths. > +# The network operator, through specific SRv6 Policies can steer traffic to one > +# path rather than another. In this selftest this is implemented as follows: > +# > +# i) The SRv6 H.Insert behavior applies SRv6 Policies on traffic received by > +# connected hosts. It pushes the Segment Routing Header (SRH) after the > +# IPv6 header. The SRH contains the SID List (i.e. SRv6 Policy) needed for > +# steering traffic across the segments/waypoints specified in that list; > +# > +# ii) The SRv6 End behavior advances the active SID in the SID List carried by > +# the SRH; > +# > +# iii) The PSP enabled SRv6 End behavior is used to remove the SRH when such > +# behavior is configured on a node bound to the Penultimate Segment carried > +# by the SID List. > +# > +# cafe::1 cafe::2 > +# +--------+ +--------+ > +# | | | | > +# | hs-1 | | hs-2 | > +# | | | | > +# +---+----+ +--- +---+ > +# cafe::/64 | | cafe::/64 > +# | | > +# +---+----+ +----+---+ > +# | | fcf0:0:1:2::/64 | | > +# | rt-1 +-------------------+ rt-2 | > +# | | | | > +# +---+----+ +----+---+ > +# | . . | > +# | fcf0:0:1:3::/64 . | > +# | . . | > +# | . . | > +# fcf0:0:1:4::/64 | . | fcf0:0:2:3::/64 > +# | . . | > +# | . . | > +# | fcf0:0:2:4::/64 . | > +# | . . | > +# +---+----+ +----+---+ > +# | | | | > +# | rt-4 +-------------------+ rt-3 | > +# | | fcf0:0:3:4::/64 | | > +# +---+----+ +----+---+ > +# > +# Every fcf0:0:x:y::/64 network interconnects the SRv6 routers rt-x with rt-y in > +# the IPv6 operator network. > +# > +# > +# Local SID table > +# =============== > +# > +# Each SRv6 router is configured with a Local SID table in which SIDs are > +# stored. Considering the given SRv6 router rt-x, at least two SIDs are > +# configured in the Local SID table: > +# > +# Local SID table for SRv6 router rt-x > +# +---------------------------------------------------------------------+ > +# |fcff:x::e is associated with the SRv6 End behavior | > +# |fcff:x::ef1 is associated with the SRv6 End behavior with PSP flavor | > +# +---------------------------------------------------------------------+ > +# > +# The fcff::/16 prefix is reserved by the operator for the SIDs. Reachability of > +# SIDs is ensured by proper configuration of the IPv6 operator's network and > +# SRv6 routers. > +# > +# > +# SRv6 Policies > +# ============= > +# > +# An SRv6 ingress router applies different SRv6 Policies to the traffic received > +# from connected hosts on the basis of the destination addresses. > +# In case of SRv6 H.Insert behavior, the SRv6 Policy enforcement consists of > +# pushing the SRH (carrying a given SID List) after the existing IPv6 header. > +# Note that in the inserting mode, there is no encapsulation at all. > +# > +# Before applying an SRv6 Policy using the SRv6 H.Insert behavior > +# +------+---------+ > +# | IPv6 | Payload | > +# +------+---------+ > +# > +# After applying an SRv6 Policy using the SRv6 H.Insert behavior > +# +------+-----+---------+ > +# | IPv6 | SRH | Payload | > +# +------+-----+---------+ > +# > +# Traffic from hs-1 to hs-2 > +# ------------------------- > +# > +# Packets generated from hs-1 and directed towards hs-2 are > +# handled by rt-1 which applies the following SRv6 Policy: > +# > +# i.a) IPv6 traffic, SID List=fcff:3::e,fcff:4::ef1,fcff:2::ef1,cafe::2 > +# > +# Router rt-1 is configured to enforce the Policy (i.a) through the SRv6 > +# H.Insert behavior which pushes the SRH after the existing IPv6 header. This > +# Policy steers the traffic from hs-1 across rt-3, rt-4, rt-2 and finally to the > +# destination hs-2. > +# > +# As the packet reaches the router rt-3, the SRv6 End behavior bound to SID > +# fcff:3::e is triggered. The behavior updates the Segment Left (from SL=3 to > +# SL=2) in the SRH, the IPv6 DA with fcff:4::ef1 and forwards the packet to the > +# next router on the path, i.e. rt-4. > +# > +# When router rt-4 receives the packet, the PSP enabled SRv6 End behavior bound > +# to SID fcff:4::ef1 is executed. Since the SL=2, the PSP operation is *NOT* > +# kicked in and the behavior applies the default End processing: the Segment > +# Left is decreased (from SL=2 to SL=1), the IPv6 DA is updated with the SID > +# fcff:2::ef1 and the packet is forwarded to router rt-2. > +# > +# The PSP enabled SRv6 End behavior on rt-2 is associated with SID fcff:2::ef1 > +# and is executed as the packet is received. Because SL=1, the behavior applies > +# the PSP processing on the packet as follows: i) SL is decreased, i.e. from > +# SL=1 to SL=0; ii) last SID (cafe::2) is copied into the IPv6 DA; iii) the > +# outermost SRH is removed from the extension headers following the IPv6 header. > +# Once the PSP processing is completed, the packet is forwarded to the host hs-2 > +# (destination). > +# > +# Traffic from hs-2 to hs-1 > +# ------------------------- > +# > +# Packets generated from hs-2 and directed to hs-1 are handled by rt-2 which > +# applies the following SRv6 Policy: > +# > +# i.b) IPv6 traffic, SID List=fcff:1::ef1,cafe::1 > +# > +# Router rt-2 is configured to enforce the Policy (i.b) through the SRv6 > +# H.Insert behavior which pushes the SRH after the existing IPv6 header. This > +# Policy steers the traffic from hs-2 across rt-1 and finally to the > +# destination hs-1 > +# > +# > +# When the router rt-1 receives the packet, the PSP enabled SRv6 End behavior > +# associated with the SID fcff:1::ef1 is triggered. Since the SL=1, > +# the PSP operation takes place: i) the SL is decremented; ii) the IPv6 DA is > +# set with the last SID; iii) the SRH is removed from the extension headers > +# after the IPv6 header. At this point, the packet with IPv6 DA=cafe::1 is sent > +# to the destination, i.e. hs-1. > + Once again, thank you for taking the time to write a detailed description of the test and its setup. Documenting intent is such an important part of the tests. Reviewed-by: David Ahern <dsahern@xxxxxxxxxx>