Introductory Guide

1. About

LNST stands for Linux Network Stack Test. The project is trying to create a framework for portable automatic testing of the Linux Network Stack. Currently we support bonding, team, vlan, bridge, macvlan and other network drivers.

Motivation behind the project is to extend our current network code coverage in Tier tests, and to create a tool/test environment that allows us to easily catch regressions in network stack during development.

Our main audience are therefore developers - to catch regressions and quality engineers - to develop new tests.

2. Design

LNST is split into two applications: the controller and the slave. The controller is usually running on the users machine, serving as an interface for the user, while the slave applications manipulates the test machines and executes tests.

Testing with LNST requires you to describe the test in the form of a recipe and using it as input for the controller application. From this point on the user is not required to do anything anymore. The recipe contains all the necessary information for the test execution and the controller does it for you.

One of the main features of LNST is that recipes contain only the necessary information about the test and no information specific to the test machines. Instead recipes only describe what the test environment should look like and the controller is able to automatically select slave machines, from your configured machine pool, to match your description. This makes the created recipes highly portable while maintaining a high degree of automation.

3. Working with LNST

Once properly set-up LNST is very easy to use. The resulting workflow is therefore very simple:

1. Design a test scenario. This incorporates deciding what machines and what topology you need, combined with individual actions executed on these machines.
2. If necessary, create a suitable test module and prepare required test tools.
3. Describe the test scenario in the form of a recipe
4. Run the test

As you can see a test scenario, from the perspective of LNST, consists of two main parts- an environment description and the actions performed inside this environment. The recipe format used by LNST directly reflects this:

• first part of the recipe describes what machines does the test environment contain, what topology they create and how should they be configured with regards to networking
• after that you define command sequences executed on these machines

4. Example use case

When designing network tests, we are mostly considering:

• the network topology required for the test
• the hardware specifications of the slave machines
• the operating system running on the machines
• and finally the actions needed to test a certain feature

At the moment LNST recipes allow you to specify the network topology and selection of machines can be restricted by the use of parameters that you can define yourself in your custom test machine pool. An example topology for the test can look something like this:

In the recipe this test scenario will be described as having two machines, each with two testing interfaces. These testing interfaces are all connected to the same L2 network creating the topology depicted by red lines. Then you can create several command sequences that will be executed sequentially, with the environment returning to the state described in the first part of the recipe.

In addition you can see the role of the controller which uses a dedicated control path (in green) to communicate with the testing environment. Communication is delivered with the use of xml-rpc, where slaves are running an rpc server, by default on port 9999, and the controller is the RPC client.