path: root/tools/testing/selftests/net/srv6_end_flavors_test.sh

#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
#
# author: Andrea Mayer <andrea.mayer@uniroma2.it>
# author: Paolo Lungaroni <paolo.lungaroni@uniroma2.it>
#
# 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.

# Kselftest framework requirement - SKIP code is 4.
readonly ksft_skip=4

readonly RDMSUFF="$(mktemp -u XXXXXXXX)"
readonly DUMMY_DEVNAME="dum0"
readonly RT2HS_DEVNAME="veth1"
readonly LOCALSID_TABLE_ID=90
readonly IPv6_RT_NETWORK=fcf0:0
readonly IPv6_HS_NETWORK=cafe
readonly IPv6_TESTS_ADDR=2001:db8::1
readonly LOCATOR_SERVICE=fcff
readonly END_FUNC=000e
readonly END_PSP_FUNC=0ef1

PING_TIMEOUT_SEC=4
PAUSE_ON_FAIL=${PAUSE_ON_FAIL:=no}

# IDs of routers and hosts are initialized during the setup of the testing
# network
ROUTERS=''
HOSTS=''

SETUP_ERR=1

ret=${ksft_skip}
nsuccess=0
nfail=0

log_test()
{
	local rc="$1"
	local expected="$2"
	local msg="$3"

	if [ "${rc}" -eq "${expected}" ]; then
		nsuccess=$((nsuccess+1))
		printf "\n    TEST: %-60s  [ OK ]\n" "${msg}"
	else
		ret=1
		nfail=$((nfail+1))
		printf "\n    TEST: %-60s  [FAIL]\n" "${msg}"
		if [ "${PAUSE_ON_FAIL}" = "yes" ]; then
			echo
			echo "hit enter to continue, 'q' to quit"
			read a
			[ "$a" = "q" ] && exit 1
		fi
	fi
}

print_log_test_results()
{
	printf "\nTests passed: %3d\n" "${nsuccess}"
	printf "Tests failed: %3d\n"   "${nfail}"

	# when a test fails, the value of 'ret' is set to 1 (error code).
	# Conversely, when all tests are passed successfully, the 'ret' value
	# is set to 0 (success code).
	if [ "${ret}" -ne 1 ]; then
		ret=0
	fi
}

log_section()
{
	echo
	echo "################################################################################"
	echo "TEST SECTION: $*"
	echo "################################################################################"
}

test_command_or_ksft_skip()
{
	local cmd="$1"

	if [ ! -x "$(command -v "${cmd}")" ]; then
		echo "SKIP: Could not run test without \"${cmd}\" tool";
		exit "${ksft_skip}"
	fi
}

get_nodename()
{
	local name="$1"

	echo "${name}-${RDMSUFF}"
}

get_rtname()
{
	local rtid="$1"

	get_nodename "rt-${rtid}"
}

get_hsname()
{
	local hsid="$1"

	get_nodename "hs-${hsid}"
}

__create_namespace()
{
	local name="$1"

	ip netns add "${name}"
}

create_router()
{
	local rtid="$1"
	local nsname

	nsname="$(get_rtname "${rtid}")"

	__create_namespace "${nsname}"
}

create_host()
{
	local hsid="$1"
	local nsname

	nsname="$(get_hsname "${hsid}")"

	__create_namespace "${nsname}"
}

cleanup()
{
	local nsname
	local i

	# destroy routers
	for i in ${ROUTERS}; do
		nsname="$(get_rtname "${i}")"

		ip netns del "${nsname}" &>/dev/null || true
	done

	# destroy hosts
	for i in ${HOSTS}; do
		nsname="$(get_hsname "${i}")"

		ip netns del "${nsname}" &>/dev/null || true
	done

	# check whether the setup phase was completed successfully or not. In
	# case of an error during the setup phase of the testing environment,
	# the selftest is considered as "skipped".
	if