8.4. Understanding the Network Teaming Daemon and the "Runners"

The Team daemon, teamd, uses libteam to control one instance of the team driver. This instance of the team driver adds instances of a hardware device driver to form a “team” of network links. The team driver presents a network interface, team0 for example, to the other parts of the kernel. The interfaces created by instances of the team driver are given names such as team0, team1, and so forth in the documentation. This is for ease of understanding and other names can be used. The logic common to all methods of teaming is implemented by teamd; those functions that are unique to the different load sharing and backup methods, such as round-robin, are implemented by separate units of code referred to as “runners”. Because words such as “module” and “mode” already have specific meanings in relation to the kernel, the word “runner” was chosen to refer to these units of code. The user specifies the runner in the JSON format configuration file and the code is then compiled into an instance of teamd when the instance is created. A runner is not a plug-in because the code for a runner is compiled into an instance of teamd as it is being created. Code could be created as a plug-in for teamd should the need arise.

The following runners are available at time of writing.

In addition, the following link-watchers are available: There are no restrictions in the code to prevent a particular link-watcher from being used with a particular runner, however when using the lacp runner, ethtool is the only recommended link-watcher.