Commit Graph

5 Commits

Author SHA1 Message Date
Amit Cohen
36ed81bcad selftests: vxlan_bridge: Test flood with unresolved FDB entry
Extend flood test to configure FDB entry with unresolved destination IP,
check that packets are not sent twice.

Without the previous patch which handles such scenario in mlxsw, the
tests fail:

$ TESTS='test_flood' ./vxlan_bridge_1d.sh
Running tests with UDP port 4789
TEST: VXLAN: flood                                                  [ OK ]
TEST: VXLAN: flood, unresolved FDB entry                            [FAIL]
        vx2 ns2: Expected to capture 10 packets, got 20.

$ TESTS='test_flood' ./vxlan_bridge_1q.sh
INFO: Running tests with UDP port 4789
TEST: VXLAN: flood vlan 10                                          [ OK ]
TEST: VXLAN: flood vlan 20                                          [ OK ]
TEST: VXLAN: flood vlan 10, unresolved FDB entry                    [FAIL]
        vx10 ns2: Expected to capture 10 packets, got 20.
TEST: VXLAN: flood vlan 20, unresolved FDB entry                    [FAIL]
        vx20 ns2: Expected to capture 10 packets, got 20.

With the previous patch, the tests pass.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/7bc96e317531f3bf06319fb2ea447bd8666f29fa.1742224300.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-24 15:09:31 -07:00
Ido Schimmel
dfbab74044 selftests: forwarding: Make vxlan-bridge-1q pass on debug kernels
The ageing time used by the test is too short for debug kernels and
results in entries being aged out prematurely [1].

Fix by increasing the ageing time.

[1]
 # ./vxlan_bridge_1q.sh
 [...]
 INFO: learning vlan 10
 TEST: VXLAN: flood before learning                                  [ OK ]
 TEST: VXLAN: show learned FDB entry                                 [ OK ]
 TEST: VXLAN: learned FDB entry                                      [FAIL]
         swp4: Expected to capture 0 packets, got 10.
 RTNETLINK answers: No such file or directory
 TEST: VXLAN: deletion of learned FDB entry                          [ OK ]
 TEST: VXLAN: Ageing of learned FDB entry                            [FAIL]
         swp4: Expected to capture 0 packets, got 10.
 TEST: VXLAN: learning toggling on bridge port                       [ OK ]
 [...]

Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/20240304095612.462900-5-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-05 09:18:10 -08:00
Amit Cohen
dc498cdda0 selftests: forwarding: vxlan_bridge_1q: Remove unused function
Remove `vxlan_ping_test()` which is not used and probably was copied
mistakenly from vxlan_bridge_1d.sh.

This was found while adding an equivalent test for IPv6.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22 17:14:33 -08:00
Ido Schimmel
55939b262a selftests: forwarding: Add PVID test case for VXLAN with VLAN-aware bridges
When using VLAN-aware bridges with VXLAN, the VLAN that is mapped to the
VNI of the VXLAN device is that which is configured as "pvid untagged"
on the corresponding bridge port.

When these flags are toggled or when the VLAN is deleted entirely,
remote hosts should not be able to receive packets from the VTEP.

Add a test case for above mentioned scenarios.

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>
2018-12-07 12:59:08 -08:00
Ido Schimmel
b5166d7a92 selftests: forwarding: Add VxLAN test with a VLAN-aware bridge
The test is very similar to its VLAN-unaware counterpart
(vxlan_bridge_1d.sh), but instead of using multiple VLAN-unaware
bridges, a single VLAN-aware bridge is used with multiple VLANs.

Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-30 17:06:29 -08:00