92 lines
3.4 KiB
Plaintext
92 lines
3.4 KiB
Plaintext
Motivation
|
|
==========
|
|
|
|
One of the nice things about network namespaces is that they allow one
|
|
to easily create and test complex environments.
|
|
|
|
Unfortunately, these namespaces can not be used with actual switching
|
|
ASICs, as their ports can not be migrated to other network namespaces
|
|
(dev->netns_local) and most of them probably do not support the
|
|
L1-separation provided by namespaces.
|
|
|
|
However, a similar kind of flexibility can be achieved by using VRFs and
|
|
by 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 to
|
|
the switch.
|
|
|
|
This approach for testing switch ASICs has several advantages over the
|
|
traditional method that requires multiple physical machines, to name a
|
|
few:
|
|
|
|
1. Only the device under test (DUT) is being tested without noise from
|
|
other system.
|
|
|
|
2. Ability to easily provision complex topologies. Testing bridging
|
|
between 4-ports LAGs or 8-way ECMP requires many physical links that are
|
|
not always available. With the VRF-based approach one merely needs to
|
|
loopback more ports.
|
|
|
|
These tests are written with switch ASICs in mind, but they can be run
|
|
on 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/
|
|
|
|
Customization
|
|
=============
|
|
|
|
The forwarding selftests framework uses a number of variables that
|
|
influence its behavior and tools it invokes, and how it invokes them, in
|
|
various ways. A number of these variables can be overridden. The way these
|
|
overridable variables are specified is typically one of the following two
|
|
syntaxes:
|
|
|
|
: "${VARIABLE:=default_value}"
|
|
VARIABLE=${VARIABLE:=default_value}
|
|
|
|
Any of these variables can be overridden. Notably net/forwarding/lib.sh and
|
|
net/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 no
|
|
way to pass it through the environment. Its value can instead be given as
|
|
consecutive arguments to the selftest:
|
|
|
|
./some_test.sh swp{1..8}
|
|
|
|
A way to customize variables in a persistent fashion is to create a file
|
|
named forwarding.config in this directory. lib.sh sources the file if
|
|
present, so it can contain any shell code. Typically it will contain
|
|
assignments of variables whose value should be overridden.
|
|
|
|
forwarding.config.sample is available in the directory as an example of
|
|
how forwarding.config might look.
|