Product SiteDocumentation Site

Chapter 5. Configure Network Teaming

5.1. Understanding Network Teaming
5.2. Comparison of Network Teaming to Bonding
5.3. Understanding the Default Behavior of Master and Slave Interfaces
5.4. Understanding the Network Teaming Daemon and the "Runners"
5.5. Install the Network Teaming Daemon
5.6. Converting a Bond to a Team
5.7. Selecting Interfaces to Use as Ports for a Network Team
5.8. Selecting Network Team Configuration Methods
5.9. Creating a Network Team Using a GUI
5.9.1. Establishing a Team Connection
5.10. Configure a Network Team Using the Command Line
5.10.1. Creating a Network Team Using teamd
5.10.2. Creating a Network Team Using ifcfg Files
5.10.3. Add a Port to a Network Team Using iputils
5.10.4. Listing the ports of a Team Using teamnl
5.10.5. Configuring Options of a Team Using teamnl
5.10.6. Add an Address to a Network Team Using iputils
5.10.7. Bring up an Interface to a Network Team Using iputils
5.10.8. Viewing the Active Port Options of a Team Using teamnl
5.10.9. Setting the Active Port Options of a Team Using teamnl
5.11. Controlling teamd with teamdctl
5.11.1. Add a Port to a Network Team
5.11.2. Remove a Port From a Network Team
5.11.3. Apply a Configuration to a Port in a Network Team
5.11.4. View the Configuration of a Port in a Network Team
5.12. Configure teamd Runners
5.12.1. Configure the broadcast Runner
5.12.2. Configure the random Runner
5.12.3. Configure the roundrobin Runner
5.12.4. Configure the activebackup Runner
5.12.5. Configure the loadbalance Runner
5.12.6. Configure the LACP (802.3ad) Runner
5.12.7. Configure Monitoring of the Link State
5.12.8. Configure Port Selection Override
5.12.9. Configure BPF-based Tx Port Selectors
5.13. Configure Network Teaming Using nmcli
5.14. Additional Resources
5.14.1. Installed Documentation
5.14.2. Online Documentation


The use of direct cable connections without network switches is not supported for teaming. The failover mechanisms described here will not work as expected without the presence of network switches.


The active-backup, balance-tlb and balance-alb modes do not require any specific configuration of the switch. Other bonding modes require configuring the switch to aggregate the links. For example, a Cisco switch requires EtherChannel for Modes 0, 2, and 3, but for Mode 4 LACP and EtherChannel are required. See the documentation supplied with your switch and see
Unlike bonding, if a team interface is configured to use link aggregation but LACP is not correctly configured and working on the network switch, no routable connection will be formed.

5.1. Understanding Network Teaming

The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as channel bonding, Ethernet bonding, port trunking, channel teaming, NIC teaming, link aggregation, and so on. This concept as originally implemented in the Linux kernel is widely referred to as bonding. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in Fedora.
Network Teaming, or Team, is designed to implement the concept in a different way by providing a small kernel driver to implement the fast handling of packet flows, and various user-space applications to do everything else in user space. The driver has an Application Programming Interface (API), referred to as Team Netlink API, which implements Netlink communications. User-space applications can use this API to communicate with the driver. A library, referred to as lib, has been provided to do user space wrapping of Team Netlink communications and RT Netlink messages. An application daemon, teamd, which uses Libteam lib is also provided. One instance of teamd can control one instance of the Team driver. The daemon implements the load-balancing and active-backup logic, such as round-robin, by using additional code referred to as runners. By separating the code in this way, the Network Teaming implementation presents an easily extensible and scalable solution for load-balancing and redundancy requirements. For example, custom runners can be relatively easily written to implement new logic via teamd, and even teamd is optional, users can write their own application to use libteam.
A tool to control a running instance of teamd using D-bus is provided by teamdctl. It provides a D-Bus wrapper around the teamd D-Bus API. By default, teamd listens and communicates using Unix Domain Sockets but still monitors D-Bus. This is to ensure that teamd can be used in environments where D-Bus is not present or not yet loaded. For example, when booting over teamd links D-Bus would not yet be loaded. The teamdctl tool can be used during run time to read the configuration, the state of link-watchers, check and change the state of ports, add and remove ports, and to change ports between active and backup states.
Team Netlink API communicates with user-space applications using Netlink messages. The user-space library libteam does not directly interact with the API, but uses libnl or teamnl to interact with the driver API.
To sum up, the instances of Team driver, running in the kernel, do not get configured or controlled directly. All configuration is done with the aid of user space applications, such as the teamd application. The application then directs the kernel driver part accordingly.