6db4831e98
Android 14
59 lines
2.3 KiB
Plaintext
59 lines
2.3 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
|
|
(NETIF_F_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/
|