Something went wrong. Try again.
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Something went wrong. Try again.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107Motivation==========
One of the nice things about network namespaces is that they allow oneto easily create and test complex environments.
Unfortunately, these namespaces can not be used with actual switchingASICs, as their ports can not be migrated to other network namespaces(dev->netns_immutable) and most of them probably do not support theL1-separation provided by namespaces.
However, a similar kind of flexibility can be achieved by using VRFs andby looping the switch ports together. For example:
br0 + vrf-h1 | vrf-h2 + +---+----+ + | | | | 192.0.2.1/24 + + + + 192.0.2.2/24 swp1 swp2 swp3 swp4 + + + + | | | | +--------+ +--------+
The VRFs act as lightweight namespaces representing hosts connected tothe switch.
This approach for testing switch ASICs has several advantages over thetraditional method that requires multiple physical machines, to name afew:
1. Only the device under test (DUT) is being tested without noise fromother system.
2. Ability to easily provision complex topologies. Testing bridgingbetween 4-ports LAGs or 8-way ECMP requires many physical links that arenot always available. With the VRF-based approach one merely needs toloopback more ports.
These tests are written with switch ASICs in mind, but they can be runon any Linux box using veth pairs to emulate physical loopbacks.
Guidelines for Writing Tests============================
o Where possible, reuse an existing topology for different tests instead of recreating the same topology.o Tests that use anything but the most trivial topologies should include an ASCII art showing the topology.o Where possible, IPv6 and IPv4 addresses shall conform to RFC 3849 and RFC 5737, respectively.o Where possible, tests shall be written so that they can be reused by multiple topologies and added to lib.sh.o Checks shall be added to lib.sh for any external dependencies.o Code shall be checked using ShellCheck [1] prior to submission.
1. https://www.shellcheck.net/
Cleanups--------
o lib.sh brings in defer.sh (by way of ../lib.sh) by default. Consider making use of the defer primitive to schedule automatic cleanups. This makes it harder to forget to remove a temporary netdevice, kill a running process or perform other cleanup when the test script is interrupted.
o When adding a helper that dirties the environment, but schedules all necessary cleanups through defer, consider prefixing it adf_ for consistency with lib.sh and ../lib.sh helpers. This serves as an immediately visible bit of documentation about the helper API.
o Definitely do the above for any new code in lib.sh, if practical.
Customization=============
The forwarding selftests framework uses a number of variables thatinfluence its behavior and tools it invokes, and how it invokes them, invarious ways. A number of these variables can be overridden. The way theseoverridable variables are specified is typically one of the following twosyntaxes:
: "${VARIABLE:=default_value}" VARIABLE=${VARIABLE:=default_value}
Any of these variables can be overridden. Notably net/forwarding/lib.sh andnet/lib.sh contain a number of overridable variables.
One way of overriding these variables is through the environment:
PAUSE_ON_FAIL=yes ./some_test.sh
The variable NETIFS is special. Since it is an array variable, there is noway to pass it through the environment. Its value can instead be given asconsecutive arguments to the selftest:
./some_test.sh swp{1..8}
A way to customize variables in a persistent fashion is to create a filenamed forwarding.config in this directory. lib.sh sources the file ifpresent, so it can contain any shell code. Typically it will containassignments of variables whose value should be overridden.
forwarding.config.sample is available in the directory as an example ofhow forwarding.config might look.