selftests: forwarding: vxlan_bridge_1d: Reconfigure & rerun tests

The ordering of the topology creation can have impact on whether a
driver is successful in offloading VXLAN. Therefore add a pseudo-test
that reshuffles bits of the topology, and then reruns the same suite of
tests again to make sure that the new setup is supported as well.

Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
Petr Machata 2018-11-19 16:11:19 +00:00 committed by David S. Miller
parent bfd1e27038
commit 50a02b0825

View file

@ -68,6 +68,10 @@ export VXPORT
ping_ipv4
test_flood
test_unicast
reapply_config
ping_ipv4
test_flood
test_unicast
"}
NUM_NETIFS=6
@ -288,6 +292,28 @@ cleanup()
vrf_cleanup
}
# For the first round of tests, vx1 is the first device to get attached to the
# bridge, and that at the point that the local IP is already configured. Try the
# other scenario of attaching the device to an already-offloaded bridge, and
# only then attach the local IP.
reapply_config()
{
echo "Reapplying configuration"
bridge fdb del dev vx1 00:00:00:00:00:00 dst 192.0.2.50 self
bridge fdb del dev vx1 00:00:00:00:00:00 dst 192.0.2.34 self
rp1_unset_addr
ip link set dev vx1 nomaster
sleep 5
ip link set dev vx1 master br1
bridge fdb append dev vx1 00:00:00:00:00:00 dst 192.0.2.34 self
bridge fdb append dev vx1 00:00:00:00:00:00 dst 192.0.2.50 self
sleep 1
rp1_set_addr
sleep 5
}
ping_ipv4()
{
ping_test $h1 192.0.2.2 ": local->local"