1Motivation
2==========
3
4One of the nice things about network namespaces is that they allow one
5to easily create and test complex environments.
6
7Unfortunately, these namespaces can not be used with actual switching
8ASICs, as their ports can not be migrated to other network namespaces
9(NETIF_F_NETNS_LOCAL) and most of them probably do not support the
10L1-separation provided by namespaces.
11
12However, a similar kind of flexibility can be achieved by using VRFs and
13by looping the switch ports together. For example:
14
15                             br0
16                              +
17               vrf-h1         |           vrf-h2
18                 +        +---+----+        +
19                 |        |        |        |
20    192.0.2.1/24 +        +        +        + 192.0.2.2/24
21               swp1     swp2     swp3     swp4
22                 +        +        +        +
23                 |        |        |        |
24                 +--------+        +--------+
25
26The VRFs act as lightweight namespaces representing hosts connected to
27the switch.
28
29This approach for testing switch ASICs has several advantages over the
30traditional method that requires multiple physical machines, to name a
31few:
32
331. Only the device under test (DUT) is being tested without noise from
34other system.
35
362. Ability to easily provision complex topologies. Testing bridging
37between 4-ports LAGs or 8-way ECMP requires many physical links that are
38not always available. With the VRF-based approach one merely needs to
39loopback more ports.
40
41These tests are written with switch ASICs in mind, but they can be run
42on any Linux box using veth pairs to emulate physical loopbacks.
43
44Guidelines for Writing Tests
45============================
46
47o Where possible, reuse an existing topology for different tests instead
48  of recreating the same topology.
49o Where possible, IPv6 and IPv4 addresses shall conform to RFC 3849 and
50  RFC 5737, respectively.
51o Where possible, tests shall be written so that they can be reused by
52  multiple topologies and added to lib.sh.
53o Checks shall be added to lib.sh for any external dependencies.
54o Code shall be checked using ShellCheck [1] prior to submission.
55
561. https://www.shellcheck.net/
57