92 lines · plain
1Motivation2==========3 4One of the nice things about network namespaces is that they allow one5to easily create and test complex environments.6 7Unfortunately, these namespaces can not be used with actual switching8ASICs, as their ports can not be migrated to other network namespaces9(dev->netns_local) and most of them probably do not support the10L1-separation provided by namespaces.11 12However, a similar kind of flexibility can be achieved by using VRFs and13by looping the switch ports together. For example:14 15 br016 +17 vrf-h1 | vrf-h218 + +---+----+ +19 | | | |20 192.0.2.1/24 + + + + 192.0.2.2/2421 swp1 swp2 swp3 swp422 + + + +23 | | | |24 +--------+ +--------+25 26The VRFs act as lightweight namespaces representing hosts connected to27the switch.28 29This approach for testing switch ASICs has several advantages over the30traditional method that requires multiple physical machines, to name a31few:32 331. Only the device under test (DUT) is being tested without noise from34other system.35 362. Ability to easily provision complex topologies. Testing bridging37between 4-ports LAGs or 8-way ECMP requires many physical links that are38not always available. With the VRF-based approach one merely needs to39loopback more ports.40 41These tests are written with switch ASICs in mind, but they can be run42on any Linux box using veth pairs to emulate physical loopbacks.43 44Guidelines for Writing Tests45============================46 47o Where possible, reuse an existing topology for different tests instead48 of recreating the same topology.49o Tests that use anything but the most trivial topologies should include50 an ASCII art showing the topology.51o Where possible, IPv6 and IPv4 addresses shall conform to RFC 3849 and52 RFC 5737, respectively.53o Where possible, tests shall be written so that they can be reused by54 multiple topologies and added to lib.sh.55o Checks shall be added to lib.sh for any external dependencies.56o Code shall be checked using ShellCheck [1] prior to submission.57 581. https://www.shellcheck.net/59 60Customization61=============62 63The forwarding selftests framework uses a number of variables that64influence its behavior and tools it invokes, and how it invokes them, in65various ways. A number of these variables can be overridden. The way these66overridable variables are specified is typically one of the following two67syntaxes:68 69 : "${VARIABLE:=default_value}"70 VARIABLE=${VARIABLE:=default_value}71 72Any of these variables can be overridden. Notably net/forwarding/lib.sh and73net/lib.sh contain a number of overridable variables.74 75One way of overriding these variables is through the environment:76 77 PAUSE_ON_FAIL=yes ./some_test.sh78 79The variable NETIFS is special. Since it is an array variable, there is no80way to pass it through the environment. Its value can instead be given as81consecutive arguments to the selftest:82 83 ./some_test.sh swp{1..8}84 85A way to customize variables in a persistent fashion is to create a file86named forwarding.config in this directory. lib.sh sources the file if87present, so it can contain any shell code. Typically it will contain88assignments of variables whose value should be overridden.89 90forwarding.config.sample is available in the directory as an example of91how forwarding.config might look.92