| 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/ |