Re: [net-next,v1,5/5] selftests: add selftest for the SRv6 End.DT4 behavior
On 11/3/20 5:52 AM, Andrea Mayer wrote: > this selftest is designed for evaluating the new SRv6 End.DT4 behavior > used, in this example, for implementing IPv4 L3 VPN use cases. > > Signed-off-by: Andrea Mayer > --- > .../selftests/net/srv6_end_dt4_l3vpn_test.sh | 494 ++ > 1 file changed, 494 insertions(+) > create mode 100755 tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh > > diff --git a/tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh > b/tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh > new file mode 100755 > index ..a5547fed5048 > --- /dev/null > +++ b/tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh > @@ -0,0 +1,494 @@ > +#!/bin/bash > +# SPDX-License-Identifier: GPL-2.0 > +# > +# author: Andrea Mayer > + > +# This test is designed for evaluating the new SRv6 End.DT4 behavior used for > +# implementing IPv4 L3 VPN use cases. > +# > +# Hereafter a network diagram is shown, where two different tenants (named > 100 > +# and 200) offer IPv4 L3 VPN services allowing hosts to communicate with each > +# other across an IPv6 network. > +# > +# Only hosts belonging to the same tenant (and to the same VPN) can > communicate > +# with each other. Instead, the communication among hosts of different > tenants > +# is forbidden. > +# In other words, hosts hs-t100-1 and hs-t100-2 are connected through the > IPv4 > +# L3 VPN of tenant 100 while hs-t200-3 and hs-t200-4 are connected using the > +# IPv4 L3 VPN of tenant 200. Cross connection between tenant 100 and tenant > 200 > +# is forbidden and thus, for example, hs-t100-1 cannot reach hs-t200-3 and > vice > +# versa. > +# > +# Routers rt-1 and rt-2 implement IPv4 L3 VPN services leveraging the SRv6 > +# architecture. The key components for such VPNs are: a) SRv6 Encap behavior, > +# b) SRv6 End.DT4 behavior and c) VRF. > +# > +# To explain how an IPv4 L3 VPN based on SRv6 works, let us briefly consider > an > +# example where, within the same domain of tenant 100, the host hs-t100-1 > pings > +# the host hs-t100-2. > +# > +# First of all, L2 reachability of the host hs-t100-2 is taken into account > by > +# the router rt-1 which acts as an arp proxy. > +# > +# When the host hs-t100-1 sends an IPv4 packet destined to hs-t100-2, the > +# router rt-1 receives the packet on the internal veth-t100 interface. Such > +# interface is enslaved to the VRF vrf-100 whose associated table contains > the > +# SRv6 Encap route for encapsulating any IPv4 packet in a IPv6 plus the > Segment > +# Routing Header (SRH) packet. This packet is sent through the (IPv6) core > +# network up to the router rt-2 that receives it on veth0 interface. > +# > +# The rt-2 router uses the 'localsid' routing table to process incoming > +# IPv6+SRH packets which belong to the VPN of the tenant 100. For each of > these > +# packets, the SRv6 End.DT4 behavior removes the outer IPv6+SRH headers and > +# performs the lookup on the vrf-100 table using the destination address of > +# the decapsulated IPv4 packet. Afterwards, the packet is sent to the host > +# hs-t100-2 through the veth-t100 interface. > +# > +# The ping response follows the same processing but this time the role of > rt-1 > +# and rt-2 are swapped. > +# > +# Of course, the IPv4 L3 VPN for tenant 200 works exactly as the IPv4 L3 VPN > +# for tenant 100. In this case, only hosts hs-t200-3 and hs-t200-4 are able > to > +# connect with each other. > +# > +# > +# +---+ > +---+ > +# | | | > | > +# | hs-t100-1 netns | | hs-t100-2 netns > | > +# | | | > | > +# | +-+ | | +-+ > | > +# | |veth0| | | |veth0| > | > +# | | 10.0.0.1/24 | | | | 10.0.0.2/24 | > | > +# | +-+ | | +-+ > | > +# |. | | . > | > +# +---+ > +---+ > +# .. > +# .. > +# .. > +# +---+ > +---+ > +# |. | | . > | > +# | +---+ | | > + | > +# | | veth-t100 | | | | veth-t100 > | | > +# | | 10.0.0.254/24 |+--+ | | +--+| 10.0.0.254/24 > | | > +# | +---+---+
[net-next,v1,5/5] selftests: add selftest for the SRv6 End.DT4 behavior
this selftest is designed for evaluating the new SRv6 End.DT4 behavior used, in this example, for implementing IPv4 L3 VPN use cases. Signed-off-by: Andrea Mayer --- .../selftests/net/srv6_end_dt4_l3vpn_test.sh | 494 ++ 1 file changed, 494 insertions(+) create mode 100755 tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh diff --git a/tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh b/tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh new file mode 100755 index ..a5547fed5048 --- /dev/null +++ b/tools/testing/selftests/net/srv6_end_dt4_l3vpn_test.sh @@ -0,0 +1,494 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0 +# +# author: Andrea Mayer + +# This test is designed for evaluating the new SRv6 End.DT4 behavior used for +# implementing IPv4 L3 VPN use cases. +# +# Hereafter a network diagram is shown, where two different tenants (named 100 +# and 200) offer IPv4 L3 VPN services allowing hosts to communicate with each +# other across an IPv6 network. +# +# Only hosts belonging to the same tenant (and to the same VPN) can communicate +# with each other. Instead, the communication among hosts of different tenants +# is forbidden. +# In other words, hosts hs-t100-1 and hs-t100-2 are connected through the IPv4 +# L3 VPN of tenant 100 while hs-t200-3 and hs-t200-4 are connected using the +# IPv4 L3 VPN of tenant 200. Cross connection between tenant 100 and tenant 200 +# is forbidden and thus, for example, hs-t100-1 cannot reach hs-t200-3 and vice +# versa. +# +# Routers rt-1 and rt-2 implement IPv4 L3 VPN services leveraging the SRv6 +# architecture. The key components for such VPNs are: a) SRv6 Encap behavior, +# b) SRv6 End.DT4 behavior and c) VRF. +# +# To explain how an IPv4 L3 VPN based on SRv6 works, let us briefly consider an +# example where, within the same domain of tenant 100, the host hs-t100-1 pings +# the host hs-t100-2. +# +# First of all, L2 reachability of the host hs-t100-2 is taken into account by +# the router rt-1 which acts as an arp proxy. +# +# When the host hs-t100-1 sends an IPv4 packet destined to hs-t100-2, the +# router rt-1 receives the packet on the internal veth-t100 interface. Such +# interface is enslaved to the VRF vrf-100 whose associated table contains the +# SRv6 Encap route for encapsulating any IPv4 packet in a IPv6 plus the Segment +# Routing Header (SRH) packet. This packet is sent through the (IPv6) core +# network up to the router rt-2 that receives it on veth0 interface. +# +# The rt-2 router uses the 'localsid' routing table to process incoming +# IPv6+SRH packets which belong to the VPN of the tenant 100. For each of these +# packets, the SRv6 End.DT4 behavior removes the outer IPv6+SRH headers and +# performs the lookup on the vrf-100 table using the destination address of +# the decapsulated IPv4 packet. Afterwards, the packet is sent to the host +# hs-t100-2 through the veth-t100 interface. +# +# The ping response follows the same processing but this time the role of rt-1 +# and rt-2 are swapped. +# +# Of course, the IPv4 L3 VPN for tenant 200 works exactly as the IPv4 L3 VPN +# for tenant 100. In this case, only hosts hs-t200-3 and hs-t200-4 are able to +# connect with each other. +# +# +# +---+ +---+ +# | | | | +# | hs-t100-1 netns | | hs-t100-2 netns | +# | | | | +# | +-+ | | +-+ | +# | |veth0| | | |veth0| | +# | | 10.0.0.1/24 | | | | 10.0.0.2/24 | | +# | +-+ | | +-+ | +# |. | | . | +# +---+ +---+ +# .. +# .. +# .. +# +---+ +---+ +# |. | | . | +# | +---+ | | + | +# | | veth-t100 | | | | veth-t100 | | +# | | 10.0.0.254/24 |+--+ | | +--+| 10.0.0.254/24 | | +# | +---+---+| localsid | | | | localsid |+---+ | +# | || table | | | | table || | +# |+++ +--+ | | +--+ +++| +# || vrf-100 || || vrf-100 || +# |
