Skip to contentSkip to conversation

selftests: forwarding: Tests redirects between L3 and L2 devices

PATCH In review Guillaume Nault 3 participants 14 messages Jun 30, 2021 – Jul 9, 2021

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

cover selftests: forwarding: Tests redirects between L3 and L2 devices

Following merge commit 8eb517a2a4ae ("Merge branch 'reset-mac'"), which made several L3 tunnels reset the skb's mac header pointer after decap, here's a selftest that validates this new behaviour.

Patch 1 adds a reusable script for setting up the base network and tests ipip and gre tunnels. The following patches extend the selftest to cover more tunnel types (sit, ip6gre, ip6tnl, vxlan-gpe and bareudp).

Guillaume Nault (4):
selftests: forwarding: Test redirecting gre or ipip packets to
Ethernet
selftests: forwarding: Test redirecting sit packets to Ethernet
selftests: forwarding: Test redirecting ip6gre and ip6tnl packets to
Ethernet
selftests: forwarding: Test redirecting vxlan and bareudp packets to
Ethernet

 .../testing/selftests/net/forwarding/Makefile |   1 +
 tools/testing/selftests/net/forwarding/config |   7 +
 .../net/forwarding/tc_redirect_l2l3.sh        | 438 ++++++++++++++++++
 .../net/forwarding/topo_nschain_lib.sh        | 267 +++++++++++
 4 files changed, 713 insertions(+)
 create mode 100755 tools/testing/selftests/net/forwarding/tc_redirect_l2l3.sh
 create mode 100644 tools/testing/selftests/net/forwarding/topo_nschain_lib.sh
Signature · 1 line
2.21.3
#1 lore raw

PATCH 1/4 selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

Add selftests for the following commits:
* aab1e898c26c ("gre: let mac_header point to outer header only when necessary"),
* 7ad136fd288c ("ipip: allow redirecting ipip and mplsip packets to eth devices").

Two end hosts ping each other, but they're separated by two routers. The routers encapsulate the end host packets into gre or ipip packets. On decap, the routers add an Ethernet header to the inner L3 packet and forward the resulting frame to the end host.

A new topo_nschain_lib.sh file is created, to make the base network settings reusable. The actual tests are implemented in tc_redirect_l2l3.sh.

---
 .../testing/selftests/net/forwarding/Makefile |   1 +
 tools/testing/selftests/net/forwarding/config |   2 +
 .../net/forwarding/tc_redirect_l2l3.sh        | 287 ++++++++++++++++++
 .../net/forwarding/topo_nschain_lib.sh        | 267 ++++++++++++++++
 4 files changed, 557 insertions(+)
 create mode 100755 tools/testing/selftests/net/forwarding/tc_redirect_l2l3.sh
 create mode 100644 tools/testing/selftests/net/forwarding/topo_nschain_lib.sh
tools/testing/selftests/net/forwarding/Makefile +1 -0
index d97bd6889446..a5005b01f14c 100644
@@ -49,6 +49,7 @@ TEST_PROGS = bridge_igmp.sh \
 	tc_flower_router.sh \
 	tc_flower.sh \
 	tc_mpls_l2vpn.sh \
+	tc_redirect_l2l3.sh \
 	tc_shblocks.sh \
 	tc_vlan_modify.sh \
 	vxlan_asymmetric.sh \
tools/testing/selftests/net/forwarding/config +2 -0
index a4bd1b087303..9d28f801866f 100644
@@ -16,3 +16,5 @@ CONFIG_NET_ACT_GACT=m
 CONFIG_VETH=m
 CONFIG_NAMESPACES=y
 CONFIG_NET_NS=y
+CONFIG_NET_IPGRE=m
+CONFIG_NET_IPIP=m
tools/testing/selftests/net/forwarding/tc_redirect_l2l3.sh new file +287 -0

287 lines not on this page · raw message

tools/testing/selftests/net/forwarding/topo_nschain_lib.sh new file +267 -0

267 lines not on this page · raw message

Signature · 1 line
2.21.3
#2 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

tools/testing/selftests/net/forwarding/topo_nschain_lib.sh line 5

Quoted 11 lines · Guillaume Nault
tools/testing/selftests/net/forwarding/topo_nschain_lib.sh new file +5 -0
new file mode 100644
index 000000000000..4c0bf2d7328a
@@ -0,0 +1,267 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# A chain of 4 nodes connected with veth pairs.
+# Each node lives in its own network namespace.

Hi,

The tests under tools/testing/selftests/net/forwarding/ are meant to use VRFs as lightweight namespaces. This allows us to run the tests on both physical switches with loopback cables and veth pairs, thereby validating both the hardware and software datapaths.

See tools/testing/selftests/net/forwarding/README

If the tests cannot be converted to VRFs, then I suggest moving them to tools/testing/selftests/net/

Quoted 90 lines
tools/testing/selftests/net/forwarding/topo_nschain_lib.sh new file +90 -0
+# Each veth interface has an IPv4 and an IPv6 address. A host route provides
+# connectivity to the adjacent node. This base network only allows nodes to
+# communicate with their immediate neighbours.
+#
+# The two nodes at the extremities of the chain also have 4 host IPs on their
+# loopback device:
+#   * An IPv4 address, routed as is to the adjacent router.
+#   * An IPv4 address, routed over MPLS to the adjacent router.
+#   * An IPv6 address, routed as is to the adjacent router.
+#   * An IPv6 address, routed over MPLS to the adjacent router.
+#
+# This topology doesn't define how RTA and RTB handle these packets: users of
+# this script are responsible for the plumbing between RTA and RTB.
+#
+# As each veth connects two different namespaces, their MAC and IP addresses
+# are defined depending on the local and remote namespaces. For example
+# veth-h1-rta, which sits in H1 and links to RTA, has MAC address
+# 00:00:5e:00:53:1a, IPv4 192.0.2.0x1a and IPv6 2001:db8::1a, where "1a" means
+# that it's in H1 and links to RTA (the rest of each address is always built
+# from a IANA documentation prefix).
+#
+# Routed addresses in H1 and H2 on the other hand encode the routing type (with
+# or without MPLS encapsulation) and the namespace the address resides in. For
+# example H2 has 198.51.100.2 and 2001:db8::1:2, that are routed as is through
+# RTB. It also has 198.51.100.0x12 and 2001:db8::1:12, that are routed through
+# RTB with MPLS encapsulation.
+#
+# For clarity, the prefixes used for host IPs are different from the ones used
+# on the veths.
+#
+# The MPLS labels follow a similar principle: the first digit represents the
+# IP version of the encapsulated packet ("4" for IPv4, "6" for IPv6), the
+# second digit represents the destination host ("1" for H1, "2" for H2).
+#
+# +----------------------------------------------------+
+# |                    Host 1 (H1)                     |
+# |                                                    |
+# |   lo                                               |
+# |     198.51.100.1    (for plain IPv4)               |
+# |     2001:db8::1:1   (for plain IPv6)               |
+# |     198.51.100.0x11 (for IPv4 over MPLS, label 42) |
+# |     2001:db8::1:11  (for IPv6 over MPLS, label 62) |
+# |                                                    |
+# | + veth-h1-rta                                      |
+# | |   192.0.2.0x1a                                   |
+# | |   2001:db8::1a                                   |
+# +-|--------------------------------------------------+
+#   |
+# +-|--------------------+
+# | |  Router A (RTA)    |
+# | |                    |
+# | + veth-rta-h1        |
+# |     192.0.2.0xa1     |
+# |     2001:db8::a1     |
+# |                      |
+# | + veth-rta-rtb       |
+# | |   192.0.2.0xab     |
+# | |   2001:db8::ab     |
+# +-|--------------------+
+#   |
+# +-|--------------------+
+# | |  Router B (RTB)    |
+# | |                    |
+# | + veth-rtb-rta       |
+# |     192.0.2.0xba     |
+# |     2001:db8::ba     |
+# |                      |
+# | + veth-rtb-h2        |
+# | |   192.0.2.0xb2     |
+# | |   2001:db8::b2     |
+# +-|--------------------+
+#   |
+# +-|--------------------------------------------------+
+# | |                  Host 2 (H2)                     |
+# | |                                                  |
+# | + veth-h2-rtb                                      |
+# |     192.0.2.0x2b                                   |
+# |     2001:db8::2b                                   |
+# |                                                    |
+# |   lo                                               |
+# |     198.51.100.2    (for plain IPv4)               |
+# |     2001:db8::1:2   (for plain IPv6)               |
+# |     198.51.100.0x12 (for IPv4 over MPLS, label 41) |
+# |     2001:db8::1:12  (for IPv6 over MPLS, label 61) |
+# +----------------------------------------------------+
+#
+# This topology can be used for testing different routing or switching
+# scenarios, as H1 and H2 are pre-configured for sending different kinds of
+# packets (IPv4, IPv6, with or without MPLS encapsulation), which RTA and RTB
+# can easily match and process according to the forwarding mechanism to test.
#3 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

Quoted 15 lines · Ido Schimmel

tools/testing/selftests/net/forwarding/topo_nschain_lib.sh line 5

Quoted 11 lines · Guillaume Nault
tools/testing/selftests/net/forwarding/topo_nschain_lib.sh new file +5 -0
new file mode 100644
index 000000000000..4c0bf2d7328a
@@ -0,0 +1,267 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# A chain of 4 nodes connected with veth pairs.
+# Each node lives in its own network namespace.

Hi,

Quoted 6 lines

The tests under tools/testing/selftests/net/forwarding/ are meant to use VRFs as lightweight namespaces. This allows us to run the tests on both physical switches with loopback cables and veth pairs, thereby validating both the hardware and software datapaths.

See tools/testing/selftests/net/forwarding/README

It wasn't clear to me that net/forwarding was _only_ for VRF-based tests.

Quoted 2 lines

If the tests cannot be converted to VRFs, then I suggest moving them to tools/testing/selftests/net/

I first tried to write this selftest using VRFs, but there were some problems that made me switch to namespaces (I don't remember precisely which ones, probably virtual tunnel devices in collect_md mode).

I'll give VRF another try. And if I can't get to a satisfying solution, I'll move the selftest under net/.

#4 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

Quoted 3 lines · Guillaume Nault

I first tried to write this selftest using VRFs, but there were some problems that made me switch to namespaces (I don't remember precisely which ones, probably virtual tunnel devices in collect_md mode).

if you hit a problem with the test not working, send me the test script and I will take a look.

#5 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

Quoted 7 lines · David Ahern
Quoted 3 lines · Guillaume Nault

I first tried to write this selftest using VRFs, but there were some problems that made me switch to namespaces (I don't remember precisely which ones, probably virtual tunnel devices in collect_md mode).

if you hit a problem with the test not working, send me the test script and I will take a look.

Okay, thanks.

#6 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

In reply to David Ahern
Quoted 7 lines · David Ahern
Quoted 3 lines · Guillaume Nault

I first tried to write this selftest using VRFs, but there were some problems that made me switch to namespaces (I don't remember precisely which ones, probably virtual tunnel devices in collect_md mode).

if you hit a problem with the test not working, send me the test script and I will take a look.

So I've looked again at what it'd take to make a VRF-based selftest. The problem is that we currently can't create collect_md tunnel interfaces in different VRFs, if the VRFs are part of the same netns.

Most tunnels explicitely refuse to create a collect_md device if another one already exists in the netns, no matter the rest of the tunnel parameters. This is the behaviour of ip_gre, ipip, ip6_gre and ip6_tunnel.

Then there's sit, which allows the creation of the second collect_md device in the other VRF. However, iproute2 doesn't set the IFLA_IPTUN_LINK attribute when it creates an external device, so it can't set up such a configuration.

Bareudp simply doesn't support VRF.

Finally, vxlan allows devices with different IFLA_VXLAN_LINK attributes to be created, but only when VXLAN_F_IPV6_LINKLOCAL is set. Removing the VXLAN_F_IPV6_LINKLOCAL test at the end of vxlan_config_validate() is enough to make two VXLAN-GPE devices work in a multi-VRF setup:

drivers/net/vxlan.c +1 -2
@@ -3767,8 +3767,7 @@ static int vxlan_config_validate(struct net *src_net, struct vxlan_config *conf,
 		    (conf->flags & (VXLAN_F_RCV_FLAGS | VXLAN_F_IPV6)))
 			continue;
 
-		if ((conf->flags & VXLAN_F_IPV6_LINKLOCAL) &&
-		    tmp->cfg.remote_ifindex != conf->remote_ifindex)
+		if (tmp->cfg.remote_ifindex != conf->remote_ifindex)
 			continue;
 
 		NL_SET_ERR_MSG(extack,

Here's an example of what a full selftests looks like using VXLAN-GPE. Without the patch above, creating the second vxlan interface fails (EEXIST).

#!/bin/bash
# SPDX-License-Identifier: GPL-2.0

NUM_NETIFS=6

source lib.sh

VETH_H1_RTA=${NETIFS[p1]}
VETH_RTA_H1=${NETIFS[p2]}
VETH_RTA_RTB=${NETIFS[p3]}
VETH_RTB_RTA=${NETIFS[p4]}
VETH_RTB_H2=${NETIFS[p5]}
VETH_H2_RTB=${NETIFS[p6]}

MAC_H1_RTA=$(mac_get "${VETH_H1_RTA}")
MAC_RTA_H1=$(mac_get "${VETH_RTA_H1}")
MAC_RTB_H2=$(mac_get "${VETH_RTB_H2}")
MAC_H2_RTB=$(mac_get "${VETH_H2_RTB}")

VRF_H1="vrf-h1"
VRF_RTA="vrf-rta"
VRF_RTB="vrf-rtb"
VRF_H2="vrf-h2"

# Set up a chain of 4 VRFs connected with the veth interfaces:
# H1 <-> RTA <-> RTB <-> H2
setup_base_net()

{
	# Initialise VRFs

	vrf_prepare

	for VRF in "${VRF_H1}" "${VRF_RTA}" "${VRF_RTB}" "${VRF_H2}"; do
		vrf_create "${VRF}"
		ip link set dev "${VRF}" up
	done

	# Assign each veth to its VRF

	__simple_if_init "${VETH_H1_RTA}" "${VRF_H1}"

	__simple_if_init "${VETH_RTA_H1}" "${VRF_RTA}"
	__simple_if_init "${VETH_RTA_RTB}" "${VRF_RTA}"

	__simple_if_init "${VETH_RTB_RTA}" "${VRF_RTB}"
	__simple_if_init "${VETH_RTB_H2}" "${VRF_RTB}"

	__simple_if_init "${VETH_H2_RTB}" "${VRF_H2}"

	# Let each veth communicate with its peer

	ip address add dev "${VETH_H1_RTA}" 192.0.2.0x1a peer 192.0.2.0xa1/32
	ip address add dev "${VETH_RTA_H1}" 192.0.2.0xa1 peer 192.0.2.0x1a/32

	ip address add dev "${VETH_RTA_RTB}" 192.0.2.0xab peer 192.0.2.0xba/32
	ip address add dev "${VETH_RTB_RTA}" 192.0.2.0xba peer 192.0.2.0xab/32

	ip address add dev "${VETH_RTB_H2}" 192.0.2.0xb2 peer 192.0.2.0x2b/32
	ip address add dev "${VETH_H2_RTB}" 192.0.2.0x2b peer 192.0.2.0xb2/32

	# Define host IPs for H1 and H2 and route them through RTA and RTB.
	# Don't set up routing inside RTA and RTB yet.

	ip address add 198.51.100.1/32 dev "${VETH_H1_RTA}"
	ip address add 198.51.100.2/32 dev "${VETH_H2_RTB}"

	ip route add 198.51.100.2/32 src 198.51.100.1 via 192.0.2.0xa1	\
		vrf "${VRF_H1}"
	ip route add 198.51.100.1/32 src 198.51.100.2 via 192.0.2.0xb2	\
		vrf "${VRF_H2}"
}

# Route H1 and H2 host IPs inside RTA and RTB using VXLAN-GPE encapsulation. setup_vxlan_gpe()

{
	# Create an external VXLAN-GPE device in the intermediate VRFs

	ip link add name tunnel-rta up type vxlan	\
		dev "${VRF_RTA}" gpe external
	ip link add name tunnel-rtb up type vxlan	\
		dev "${VRF_RTB}" gpe external

	# Forward packets received from the end hosts through the tunnels

	tc qdisc add dev "${VETH_RTA_H1}" ingress
	tc filter add dev "${VETH_RTA_H1}" ingress		\
		protocol ipv4 flower dst_ip 198.51.100.2	\
		action tunnel_key set src_ip 192.0.2.0xab	\
			dst_ip 192.0.2.0xba id 10		\
		action mirred egress redirect dev tunnel-rta

	tc qdisc add dev "${VETH_RTB_H2}" ingress
	tc filter add dev "${VETH_RTB_H2}" ingress		\
		protocol ipv4 flower dst_ip 198.51.100.1	\
		action tunnel_key set src_ip 192.0.2.0xba	\
			dst_ip 192.0.2.0xab id 10		\
		action mirred egress redirect dev tunnel-rtb

	# Decapsulate packets received from the tunnels and send them to the
	# end hosts

	tc qdisc add dev tunnel-rta ingress
	tc filter add dev tunnel-rta ingress matchall			\
		action vlan push_eth dst_mac "${MAC_H1_RTA}"		\
			src_mac "${MAC_RTA_H1}"				\
		action mirred egress redirect dev "${VETH_RTA_H1}"

	tc qdisc add dev tunnel-rtb ingress
	tc filter add dev tunnel-rtb ingress matchall			\
		action vlan push_eth dst_mac "${MAC_H2_RTB}"		\
			src_mac "${MAC_RTB_H2}"				\
		action mirred egress redirect dev "${VETH_RTB_H2}"
}

setup_base_net
setup_vxlan_gpe

ip vrf exec "${VRF_H1}" ping 198.51.100.2

#7 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

Quoted 23 lines · Guillaume Nault
Quoted 7 lines · David Ahern
Quoted 3 lines · Guillaume Nault

I first tried to write this selftest using VRFs, but there were some problems that made me switch to namespaces (I don't remember precisely which ones, probably virtual tunnel devices in collect_md mode).

if you hit a problem with the test not working, send me the test script and I will take a look.

So I've looked again at what it'd take to make a VRF-based selftest. The problem is that we currently can't create collect_md tunnel interfaces in different VRFs, if the VRFs are part of the same netns.

Most tunnels explicitely refuse to create a collect_md device if another one already exists in the netns, no matter the rest of the tunnel parameters. This is the behaviour of ip_gre, ipip, ip6_gre and ip6_tunnel.

Then there's sit, which allows the creation of the second collect_md device in the other VRF. However, iproute2 doesn't set the IFLA_IPTUN_LINK attribute when it creates an external device, so it can't set up such a configuration.

Quoted 6 lines

Bareudp simply doesn't support VRF.

Finally, vxlan allows devices with different IFLA_VXLAN_LINK attributes to be created, but only when VXLAN_F_IPV6_LINKLOCAL is set. Removing the VXLAN_F_IPV6_LINKLOCAL test at the end of vxlan_config_validate() is enough to make two VXLAN-GPE devices work in a multi-VRF setup:

Thanks for the details. In short, some work is needed to extend VRF support to these tunnels. That is worth doing if you have the time.

#8 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

Quoted 26 lines · David Ahern
Quoted 25 lines · Guillaume Nault
Quoted 7 lines · David Ahern
Quoted 3 lines · Guillaume Nault

I first tried to write this selftest using VRFs, but there were some problems that made me switch to namespaces (I don't remember precisely which ones, probably virtual tunnel devices in collect_md mode).

if you hit a problem with the test not working, send me the test script and I will take a look.

So I've looked again at what it'd take to make a VRF-based selftest. The problem is that we currently can't create collect_md tunnel interfaces in different VRFs, if the VRFs are part of the same netns.

Most tunnels explicitely refuse to create a collect_md device if another one already exists in the netns, no matter the rest of the tunnel parameters. This is the behaviour of ip_gre, ipip, ip6_gre and ip6_tunnel.

Then there's sit, which allows the creation of the second collect_md device in the other VRF. However, iproute2 doesn't set the IFLA_IPTUN_LINK attribute when it creates an external device, so it can't set up such a configuration.

Bareudp simply doesn't support VRF.

Quoted 7 lines
Quoted 4 lines

Finally, vxlan allows devices with different IFLA_VXLAN_LINK attributes to be created, but only when VXLAN_F_IPV6_LINKLOCAL is set. Removing the VXLAN_F_IPV6_LINKLOCAL test at the end of vxlan_config_validate() is enough to make two VXLAN-GPE devices work in a multi-VRF setup:

Thanks for the details. In short, some work is needed to extend VRF support to these tunnels. That is worth doing if you have the time.

I probably won't have the time in the immediate future, but I've added this work to my todo list. Meanwhile, I'll move the selftests to net/ and repost when net-next reopens.

#9 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

In reply to Guillaume Nault

drivers/net/vxlan.c static int vxlan_config_validate(struct net *src_net, struct vxlan_config *conf, · line 3773

Quoted 12 lines · Guillaume Nault
drivers/net/vxlan.c +1 -2
@@ -3767,8 +3767,7 @@ static int vxlan_config_validate(struct net *src_net, struct vxlan_config *conf,
 		    (conf->flags & (VXLAN_F_RCV_FLAGS | VXLAN_F_IPV6)))
 			continue;
 
-		if ((conf->flags & VXLAN_F_IPV6_LINKLOCAL) &&
-		    tmp->cfg.remote_ifindex != conf->remote_ifindex)
+		if (tmp->cfg.remote_ifindex != conf->remote_ifindex)
 			continue;
 
 		NL_SET_ERR_MSG(extack,

Looking at the vxlan driver and that restriction is unnecessary. While IPv6 LLA requires a device index, allowing separate LINK attributes is a legit use case - as VRF shows.

Do you want to send a formal patch to fix this one since you have it diagnosed?

#10 lore raw

Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet

Quoted 12 lines · David Ahern
Quoted 11 lines · Guillaume Nault
drivers/net/vxlan.c +1 -2
@@ -3767,8 +3767,7 @@ static int vxlan_config_validate(struct net *src_net, struct vxlan_config *conf,
 		    (conf->flags & (VXLAN_F_RCV_FLAGS | VXLAN_F_IPV6)))
 			continue;
 
-		if ((conf->flags & VXLAN_F_IPV6_LINKLOCAL) &&
-		    tmp->cfg.remote_ifindex != conf->remote_ifindex)
+		if (tmp->cfg.remote_ifindex != conf->remote_ifindex)
 			continue;
 
Quoted 5 lines

drivers/net/vxlan.c static int vxlan_config_validate(struct net *src_net, struct vxlan_config *conf, · line 3773

Quoted 1 line
drivers/net/vxlan.c +0 -0
 		NL_SET_ERR_MSG(extack,

Looking at the vxlan driver and that restriction is unnecessary. While IPv6 LLA requires a device index, allowing separate LINK attributes is a legit use case - as VRF shows.

I believe there's more to do than just my quick hack patch. At least vxlan_vs_find_vni() probably needs to be modified too. At which point VXLAN_F_IPV6_LINKLOCAL would become essentially unused and should be removed.

Quoted 2 lines

Do you want to send a formal patch to fix this one since you have it diagnosed?

I'll work on that after net-next reopens. I might try to make bareudp compatible with VRF too, if time allows. If I get at least VXLAN and bareudp to work in a multi-VRF setup, then I'll rebase the selftests on the VRF infrastructure (and just remove the tests for tunnels still incompatible with this setup).

#11 lore raw

PATCH 2/4 selftests: forwarding: Test redirecting sit packets to Ethernet

In reply to Guillaume Nault

Add selftests for the following commit:
* 730eed2772e7 ("sit: allow redirecting ip6ip, ipip and mplsip packets to eth devices").

In collect_md mode, if a fallback sit tunnel is already created, the script can't create its own sit device (EEXIST). Therefore, we have to skip this test when such fallback tunnels are created automatically in new network namespaces.

Also, sit devices in ip6ip mode don't work in collect_md mode. Skip the test for the moment.

---
 tools/testing/selftests/net/forwarding/config |  1 +
 .../net/forwarding/tc_redirect_l2l3.sh        | 60 +++++++++++++++++++
 2 files changed, 61 insertions(+)
tools/testing/selftests/net/forwarding/config +1 -0
index 9d28f801866f..c543b441a8b5 100644
@@ -18,3 +18,4 @@ CONFIG_NAMESPACES=y
 CONFIG_NET_NS=y
 CONFIG_NET_IPGRE=m
 CONFIG_NET_IPIP=m
+CONFIG_IPV6_SIT=m
tools/testing/selftests/net/forwarding/tc_redirect_l2l3.sh +60 -0

78 lines not on this page · raw message

Signature · 1 line
2.21.3
#12 lore raw

PATCH 3/4 selftests: forwarding: Test redirecting ip6gre and ip6tnl packets to Ethernet

In reply to Guillaume Nault

Add selftests for the following commit:
* da5a2e49f064 ("ip6_tunnel: allow redirecting ip6gre and ipxip6 packets to eth devices").

Like with the previous tc_redirect_l2l3.sh tests, verify that the following tc filter works on the ingress qdisc of ip6gre and ip6tnl devices:

  $ tc filter add dev tunnel0 ingress matchall       \
      action vlan push_eth dst_mac 00:00:5e:00:53:01 \
                           src_mac 00:00:5e:00:53:00 \
      action mirred egress redirect dev eth0
---
 tools/testing/selftests/net/forwarding/config |  2 ++
 .../net/forwarding/tc_redirect_l2l3.sh        | 36 +++++++++++++++++++
 2 files changed, 38 insertions(+)
tools/testing/selftests/net/forwarding/config +2 -0
index c543b441a8b5..5d3ab2b63c53 100644
@@ -19,3 +19,5 @@ CONFIG_NET_NS=y
 CONFIG_NET_IPGRE=m
 CONFIG_NET_IPIP=m
 CONFIG_IPV6_SIT=m
+CONFIG_IPV6_GRE=m
+CONFIG_IPV6_TUNNEL=m
tools/testing/selftests/net/forwarding/tc_redirect_l2l3.sh +36 -0
index fd9e15a6417b..207b92775a6c 100755
@@ -25,6 +25,8 @@ ALL_TESTS="
 	redir_gre
 	redir_ipip
 	redir_sit
+	redir_ip6gre
+	redir_ip6tnl
 "
 
 NUM_NETIFS=0
@@ -318,6 +320,40 @@ redir_sit()
 	cleanup_tunnel
 }
 
+redir_ip6gre()
+{
+	setup_tunnel "ipv6" "classical" "ip6gre"
+	ping_test ipv4 "IP6GRE, classical mode: IPv6 / GRE / IPv4"
+	ping_test ipv6 "IP6GRE, classical mode: IPv6 / GRE / IPv6"
+	ping_test ipv4-mpls "IP6GRE, classical mode: IPv6 / GRE / MPLS / IPv4"
+	ping_test ipv6-mpls "IP6GRE, classical mode: IPv6 / GRE / MPLS / IPv6"
+	cleanup_tunnel
+
+	setup_tunnel "ipv6" "collect_md" "ip6gre" "external" "nocsum"
+	ping_test ipv4 "IP6GRE, external mode: IPv6 / GRE / IPv4"
+	ping_test ipv6 "IP6GRE, external mode: IPv6 / GRE / IPv6"
+	ping_test ipv4-mpls "IP6GRE, external mode: IPv6 / GRE / MPLS / IPv4"
+	ping_test ipv6-mpls "IP6GRE, external mode: IPv6 / GRE / MPLS / IPv6"
+	cleanup_tunnel
+}
+
+redir_ip6tnl()
+{
+	setup_tunnel "ipv6" "classical" "ip6tnl" "mode any"
+	ping_test ipv4 "IP6TNL, classical mode: IPv6 / IPv4"
+	ping_test ipv6 "IP6TNL, classical mode: IPv6 / IPv6"
+	ping_test ipv4-mpls "IP6TNL, classical mode: IPv6 / MPLS / IPv4"
+	ping_test ipv6-mpls "IP6TNL, classical mode: IPv6 / MPLS / IPv6"
+	cleanup_tunnel
+
+	setup_tunnel "ipv6" "collect_md" "ip6tnl" "mode any external"
+	ping_test ipv4 "IP6TNL, external mode: IPv6 / IPv4"
+	ping_test ipv6 "IP6TNL, external mode: IPv6 / IPv6"
+	ping_test ipv4-mpls "IP6TNL, external mode: IPv6 / MPLS / IPv4"
+	ping_test ipv6-mpls "IP6TNL, external mode: IPv6 / MPLS / IPv6"
+	cleanup_tunnel
+}
+
 exit_cleanup()
 {
 	if [ "${TESTS_COMPLETED}" = "no" ]; then
Signature · 1 line
2.21.3
#13 lore raw

PATCH 4/4 selftests: forwarding: Test redirecting vxlan and bareudp packets to Ethernet

In reply to Guillaume Nault

Add selftests for the following commit:
* 99c8719b7981 ("bareudp: allow redirecting bareudp packets to eth

    devices").

(no commit for VXLAN-GPE, which has always worked in this configuration).

Only test collect-md mode as both bareudp and vxlan-gpe devices don't currently implement classical mode.

---
 tools/testing/selftests/net/forwarding/config |  2 +
 .../net/forwarding/tc_redirect_l2l3.sh        | 55 +++++++++++++++++++
 2 files changed, 57 insertions(+)
tools/testing/selftests/net/forwarding/config +2 -0
index 5d3ab2b63c53..ec49660ee808 100644
@@ -21,3 +21,5 @@ CONFIG_NET_IPIP=m
 CONFIG_IPV6_SIT=m
 CONFIG_IPV6_GRE=m
 CONFIG_IPV6_TUNNEL=m
+CONFIG_VXLAN=m
+CONFIG_BAREUDP=m
tools/testing/selftests/net/forwarding/tc_redirect_l2l3.sh +55 -0

67 lines not on this page · raw message

Signature · 1 line
2.21.3