Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

8.13. Configure teamd Runners

Runners are units of code which are compiled into the Team daemon when an instance of the daemon is created. For an introduction to the teamd runners, see Section 8.4, “Understanding the Network Teaming Daemon and the "Runners"”.

8.13.1. Configure the broadcast Runner

To configure the broadcast runner, using an editor as root, add the following to the team JSON format configuration file: 
{
 "device": "team0",
 "runner": {"name": "broadcast"},
 "ports": {"em1": {}, "em2": {}}
}
Copy to Clipboard
Please see the teamd.conf(5) man page for more information.

8.13.2. Configure the random Runner

The random runner behaves similarly to the round-robin runner.
To configure the random runner, using an editor as root, add the following to the team JSON format configuration file: 
{
 "device": "team0",
 "runner": {"name": "random"},
 "ports": {"em1": {}, "em2": {}}
}
Copy to Clipboard
Please see the teamd.conf(5) man page for more information.

8.13.3. Configure the Round-robin Runner

To configure the round-robin runner, using an editor as root, add the following to the team JSON format configuration file: 
{
 "device": "team0",
 "runner": {"name": "roundrobin"},
 "ports": {"em1": {}, "em2": {}}
}
Copy to Clipboard
A very basic configuration for round-robin.
Please see the teamd.conf(5) man page for more information.

8.13.4. Configure the activebackup Runner

The active backup runner can use all of the link-watchers to determine the status of links in a team. Any one of the following examples can be added to the team JSON format configuration file: 
{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool"
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true
      },
      "em2": {
         "prio": 100
      }
   }
}
Copy to Clipboard
This example configuration uses the active-backup runner with ethtool as the link watcher. Port em2 has higher priority. The sticky flag ensures that if em1 becomes active, it stays active as long as the link remains up. 
{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool"
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true,
         "queue_id": 4
      },
      "em2": {
         "prio": 100
      }
   }
}
Copy to Clipboard
This example configuration adds a queue ID of 4. It uses active-backup runner with ethtool as the link watcher. Port em2 has higher priority. But the sticky flag ensures that if em1 becomes active, it will stay active as long as the link remains up.
To configure the activebackup runner using ethtool as the link watcher and applying a delay, using an editor as root, add the following to the team JSON format configuration file: 
{
   "device": "team0",
   "runner": {
      "name": "activebackup"
   },
   "link_watch": {
      "name": "ethtool",
      "delay_up": 2500,
      "delay_down": 1000
   },
   "ports": {
      "em1": {
         "prio": -10,
         "sticky": true
      },
      "em2": {
         "prio": 100
      }
   }
}
Copy to Clipboard
This example configuration uses the active-backup runner with ethtool as the link watcher. Port em2 has higher priority. But the sticky flag ensures that if em1 becomes active, it stays active while the link remains up. Link changes are not propagated to the runner immediately, but delays are applied.
Please see the teamd.conf(5) man page for more information.

8.13.5. Configure the loadbalance Runner

This runner can be used for two types of load balancing, active and passive. In active mode, constant re-balancing of traffic is done by using statistics of recent traffic to share out traffic as evenly as possible. In passive mode, streams of traffic are distributed randomly across the available links. This has a speed advantage due to lower processing overhead. In high volume traffic applications this is often preferred as traffic usually consists of multiple stream which will be distributed randomly between the available links, in this way load sharing is accomplished without intervention by teamd.
To configure the loadbalance runner for passive transmit (Tx) load balancing, using an editor as root, add the following to the team JSON format configuration file: 
{
 "device": "team0",
 "runner": {
   "name": "loadbalance",
   "tx_hash": ["eth", "ipv4", "ipv6"]
 },
 "ports": {"em1": {}, "em2": {}}
}
Copy to Clipboard
Configuration for hash-based passive transmit (Tx) load balancing.
To configure the loadbalance runner for active transmit (Tx) load balancing, using an editor as root, add the following to the team JSON format configuration file: 
{
   "device": "team0",
   "runner": {
     "name": "loadbalance",
     "tx_hash": ["eth", "ipv4", "ipv6"],
     "tx_balancer": {
       "name": "basic"
     }
   },
   "ports": {"em1": {}, "em2": {}}
}
Copy to Clipboard
Configuration for active transmit (Tx) load balancing using basic load balancer.
Please see the teamd.conf(5) man page for more information.

8.13.6. Configure the LACP (802.3ad) Runner

To configure the LACP runner using ethtool as a link watcher, using an editor as root, add the following to the team JSON format configuration file: 
{
   "device": "team0",
   "runner": {
       "name": "lacp",
       "active": true,
       "fast_rate": true,
       "tx_hash": ["eth", "ipv4", "ipv6"]
   },
     "link_watch": {"name": "ethtool"},
     "ports": {"em1": {}, "em2": {}}
}
Copy to Clipboard
Configuration for connection to a link aggregation control protocol (LACP) capable counterpart. The LACP runner should use ethtool to monitor the status of a link. Note that only ethtool can be used for link monitoring because, for example in the case of arp_ping, the link would never come up. The reason is that the link has to be established first and only after that can packets, ARP included, go through. Using ethtool prevents this because it monitors each link layer individually.
Active load balancing is possible with this runner in the same way as it is done for the loadbalance runner. To enable active transmit (Tx) load balancing, add the following section: 
"tx_balancer": {
       "name": "basic"
}
Copy to Clipboard
Please see the teamd.conf(5) man page for more information.

8.13.8. Configure Port Selection Override

The physical port which transmits a frame is normally selected by the kernel part of the team driver, and is not relevant to the user or system administrator. The output port is selected using the policies of the selected team mode (teamd runner). On occasion however, it is helpful to direct certain classes of outgoing traffic to certain physical interfaces to implement slightly more complex policies. By default the team driver is multiqueue aware and 16 queues are created when the driver initializes. If more or less queues are required, the Netlink attribute tx_queues can be used to change this value during the team driver instance creation.
The queue ID for a port can be set by the port configuration option queue_id as follows: 
{
  "queue_id": 3
}
Copy to Clipboard
These queue ID's can be used in conjunction with the tc utility to configure a multiqueue queue discipline and filters to bias certain traffic to be transmitted on certain port devices. For example, if using the above configuration and wanting to force all traffic bound to 192.168.1.100 to use enp1s0 in the team as its output device, issue commands as root in the following format: 
~]# tc qdisc add dev team0 handle 1 root multiq
~]# tc filter add dev team0 protocol ip parent 1: prio 1 u32 match ip dst \
  192.168.1.100 action skbedit queue_mapping 3
Copy to Clipboard
This mechanism of overriding runner selection logic in order to bind traffic to a specific port can be used with all runners.

8.13.9. Configure BPF-based Tx Port Selectors

The loadbalance and LACP runners uses hashes of packets to sort network traffic flow. The hash computation mechanism is based on the Berkeley Packet Filter (BPF) code. The BPF code is used to generate a hash rather than make a policy decision for outgoing packets. The hash length is 8 bits giving 256 variants. This means many different socket buffers (SKB) can have the same hash and therefore pass traffic over the same link. The use of a short hash is a quick way to sort traffic into different streams for the purposes of load balancing across multiple links. In static mode, the hash is only used to decide out of which port the traffic should be sent. In active mode, the runner will continually reassign hashes to different ports in an attempt to reach a perfect balance.
The following fragment types or strings can be used for packet Tx hash computation:
  • eth — Uses source and destination MAC addresses.
  • vlan — Uses VLAN ID.
  • ipv4 — Uses source and destination IPv4 addresses.
  • ipv6 — Uses source and destination IPv6 addresses.
  • ip — Uses source and destination IPv4 and IPv6 addresses.
  • l3 — Uses source and destination IPv4 and IPv6 addresses.
  • tcp — Uses source and destination TCP ports.
  • udp — Uses source and destination UDP ports.
  • sctp — Uses source and destination SCTP ports.
  • l4 — Uses source and destination TCP and UDP and SCTP ports.
These strings can be used by adding a line in the following format to the load balance runner: 
"tx_hash": ["eth", "ipv4", "ipv6"]
Copy to Clipboard
See Section 8.13.5, “Configure the loadbalance Runner” for an example.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat