tools/testing/selftests/net/forwarding/README

Source file repositories/reference/linux-study-clean/tools/testing/selftests/net/forwarding/README

File Facts

System
Linux kernel
Corpus path
tools/testing/selftests/net/forwarding/README
Extension
[no extension]
Size
4185 bytes
Lines
107
Domain
Support Tooling And Documentation
Bucket
tools
Inferred role
Support Tooling And Documentation: tools
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

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

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

Annotation

Implementation Notes