selftests: forwarding: Tests redirects between L3 and L2 devices
Subsystems (4)
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
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
@@ -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
@@ -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
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@@ -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.
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@@ -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/.
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_mdmode).
if you hit a problem with the test not working, send me the test script and I will take a look.
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_mdmode).if you hit a problem with the test not working, send me the test script and I will take a look.
Okay, thanks.
Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet
In reply to David AhernQuoted 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_mdmode).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 <-> H2setup_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_netsetup_vxlan_gpe
ip vrf exec "${VRF_H1}" ping 198.51.100.2
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_mdmode).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_mdtunnel interfaces in different VRFs, if the VRFs are part of the same netns.Most tunnels explicitely refuse to create a
collect_mddevice if another one already exists in the netns, no matter the rest of the tunnel parameters. This is the behaviour ofip_gre, ipip,ip6_greandip6_tunnel.Then there's sit, which allows the creation of the second
collect_mddevice in the other VRF. However, iproute2 doesn't set theIFLA_IPTUN_LINKattribute 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_LINKattributes to be created, but only whenVXLAN_F_IPV6_LINKLOCALis set. Removing theVXLAN_F_IPV6_LINKLOCALtest at the end ofvxlan_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.
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_mdmode).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_mdtunnel interfaces in different VRFs, if the VRFs are part of the same netns.Most tunnels explicitely refuse to create a
collect_mddevice if another one already exists in the netns, no matter the rest of the tunnel parameters. This is the behaviour ofip_gre, ipip,ip6_greandip6_tunnel.Then there's sit, which allows the creation of the second
collect_mddevice in the other VRF. However, iproute2 doesn't set theIFLA_IPTUN_LINKattribute 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_LINKattributes to be created, but only whenVXLAN_F_IPV6_LINKLOCALis set. Removing theVXLAN_F_IPV6_LINKLOCALtest at the end ofvxlan_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.
Re: [PATCH net-next 1/4] selftests: forwarding: Test redirecting gre or ipip packets to Ethernet
In reply to Guillaume Naultdrivers/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?
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
-0NL_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).
PATCH 2/4 selftests: forwarding: Test redirecting sit packets to Ethernet
In reply to Guillaume NaultAdd 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
@@ -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
PATCH 3/4 selftests: forwarding: Test redirecting ip6gre and ip6tnl packets to Ethernet
In reply to Guillaume NaultAdd 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
@@ -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
@@ -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
PATCH 4/4 selftests: forwarding: Test redirecting vxlan and bareudp packets to Ethernet
In reply to Guillaume NaultAdd 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
@@ -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