Managing network teaming devices
- WHAT?
Combine two or more network interfaces into a single teamed device.
- WHY?
Network teaming can increase bandwidth and/or provide redundancy.
- EFFORT
Approximately 15 minutes to read and understand the content.
- REQUIREMENTS
Network connection
Basic understanding of networking and IP addresses
Existing network interfaces to include in the teamed device
Switch support, depending on the teaming mode
The package libteam-tools is installed
This article is about network teaming. To configure network bonding, see Managing network bonding devices.
1 Configuring network teaming #
Network teaming combines two or more network interfaces into a single teamed device to increase bandwidth and/or provide redundancy. The behavior of the teamed device is configured using teaming modes.
1.1 Requirements #
Network connection
Basic understanding of networking and IP addresses
Existing network interfaces to include in the teamed device
Switch support, depending on the teaming mode
The package libteam-tools is installed
1.2 Restrictions #
- Do not split teams over multiple switches
In most hardware setups, all network interfaces in a teamed device must be connected to the same switch. For more information, consult your switch vendor documentation.
- No teaming in YaST
Currently, YaST cannot create a teamed device. You must configure network teaming manually.
- Teaming and virtualization
Teamed devices are made up of multiple network interfaces. In most configurations you should only configure teaming in the host. Virtual interfaces to guests are then created as a bridge with the teamed devices, simplifying guest creation and deployment.
It is possible, but not recommended, to configure teaming in a guest. When configuring teaming in a guest, you must assign multiple interfaces to the guest and configure the host without teaming. You must also be careful to configure the host and its network bridges so that you do not mix teaming in the host and guests.
1.3 Teaming modes #
The following teaming modes are available:
All traffic is broadcast on all interfaces. Provides fault tolerance. Requires switch support.
Packets are transmitted in round-robin fashion from the first to the last available interface. Provides fault tolerance and load balancing. Requires switch support.
Only one network interface is active. If it fails, a different interface becomes active. Provides fault tolerance.
The teamed device transmits packets via all its interfaces, performing load balancing (passive or active) with a use of hash functions. For passive load balancing, only the BPF hash function is used. For active load balancing, the runner finds the best balance by moving hashes between available interfaces. Provides fault tolerance and load balancing. No specific switch support is required.
All interfaces in the LACP group must share the same speed and duplex settings, and must be connected to the same switch. Provides fault tolerance and load balancing. Requires
ethtool
support in the interface drivers, and a switch that supports and is configured for IEEE 802.3ad Dynamic link aggregation. If your switch supports it, this is the preferred mode.
Consult your hardware manual to check which modes your switch supports.
1.4 Configuring network teaming with ifcfg
#
Create a configuration file named
/etc/sysconfig/network/ifcfg-team0
. If you need more than one teamed device, give them ascending numbers. For more information, seeman ifcfg
,man ifcfg-team
, and/etc/sysconfig/network/ifcfg.template
.In the configuration file, define the following parameters:
STARTMODE=MODE 1 BOOTPROTO=IP_ASSIGNMENT 2 IPADDR=IPv4_ADDRESS3 IPADDR6=IPv6_ADDRESS3 TEAM_RUNNER="TEAMING_MODE" 4 TEAM_PORT_DEVICE_0="FIRST_DEVICE_NAME" 5 TEAM_PORT_DEVICE_1="SECOND_DEVICE_NAME" 5 TEAM_LW_NAME="LINK_WATCHER" 6
Defines how the teamed device starts. Use
auto
to start the interface automatically on every reboot, or usemanual
to prevent the interface from starting automatically.Defines how IP addresses are assigned to the teamed device. Use
static
to manually assign static IP addresses, or usedhcp
to automatically assign dynamic IP addresses.Specifies the IPv4 and IPv6 addresses for the device, if you are manually assigning
static
IP addresses.Defines the teaming mode for this interface. Some teaming modes require additional variables. See
man ifcfg-team
for more information about mode-specific variables.Specifies two or more network interfaces to include in the teamed device.
Defines a link watcher to monitor the state of subordinate devices.
The default option
ethtool
only checks if the device is up and accessible. This option is fast, but does not check if the device can actually send or receive packets.If you need higher confidence in the connection, use the
arp_ping
option. This sends pings to a host specified by the variableTEAM_LW_ARP_PING_TARGET_HOST
. The teamed device is only considered to be up if replies are received.See
man ifcfg-team
for more information about watcher-specific variables.Example 1: Configuration for load balancing withlacp
#STARTMODE=auto BOOTPROTO=static IPADDR="192.168.1.1/24" IPADDR6="fd00:deca:fbad:50::1/64" TEAM_RUNNER="lacp" TEAM_LACP_SELECT_POLICY="lacp_prio" TEAM_LACP_TX_HASH="ipv4,ipv6,eth,vlan" TEAM_LACP_TX_BALANCER_NAME="basic" TEAM_LACP_TX_BALANCER_INTERVAL="100" TEAM_PORT_DEVICE_0="eth0" TEAM_PORT_DEVICE_1="eth1" TEAM_LW_NAME="ethtool" TEAM_LW_ETHTOOL_DELAY_UP="10" TEAM_LW_ETHTOOL_DELAY_DOWN="10"
Example 2: Configuration for failover withactivebackup
#STARTMODE=auto BOOTPROTO=static IPADDR="192.168.1.2/24" IPADDR6="fd00:deca:fbad:50::2/64" TEAM_RUNNER=activebackup TEAM_PORT_DEVICE_0="eth0" TEAM_PORT_DEVICE_1="eth1" TEAM_LW_NAME=ethtool TEAM_LW_ETHTOOL_DELAY_UP="10" TEAM_LW_ETHTOOL_DELAY_DOWN="10"
Back up the existing
ifcfg
files for the network interfaces that you included in the teamed device, in case you need to restore them later.Remove the
ifcfg
files of the network interfaces that you included in the teamed device. Do not remove the backup files.Check if everything is included in Wicked's configuration file:
>
sudo
wicked show-config
Start the teamed device:
>
sudo
wicked ifup all team0
If you need additional debug information, use the option
--debug all
after theall
subcommand.Do not use
systemctl
to start or stop the teamed device. Always use thewicked
command.Check the status of the teamed device:
Get the state of the
teamd
instance from Wicked:>
sudo
wicked ifstatus --verbose team0
Get the state of the entire instance:
>
sudo
teamdctl team0 state
Get the
systemd
state of theteamd
instance:>
sudo
systemctl status teamd@team0
Each command shows a slightly different view depending on your needs.
If you make changes to the ifcfg-team0
file after starting the device,
reload its configuration with the command wicked ifreload team0
.
2 Adding VLANS over a teamed device #
VLANs allow the running of multiple logical (virtual) Ethernets over one single physical Ethernet. They logically split the network into different broadcast domains so that packets are only switched between members that are designated for the same VLAN.
2.1 Requirements #
VLAN tags are enabled on the switch. Consult your hardware manual for details.
To use load balancing for the teamed device, the switch must support LACP (802.3ad).
A teamed device is already configured.
2.2 Adding VLANs over a teamed device #
The examples in this procedure use the IP addresses
192.168.10.1
and
192.168.20.1
.
Replace these with the actual IP addresses for your devices.
In
/etc/sysconfig/network
, create a file namedifcfg-vlan0
and add the following content:STARTMODE="auto" BOOTPROTO="static" 1 IPADDR='192.168.10.1/24' 2 ETHERDEVICE="team0" 3 VLAN_ID="0" 4 VLAN='yes'
Copy the file
/etc/sysconfig/network/ifcfg-vlan0
to/etc/sysconfig/network/ifcfg-vlan1
and change the following values:IPADDR='192.168.20.1/24'
.VLAN_ID='1'
.
Start the two VLANs:
>
sudo wicked ifup vlan0 vlan1
Check the status of the VLANs:
>
ip addr
You can check a specific device by using the
show
subcommand:>
ip addr show vlan0
3 Removing a teamed device #
Use this procedure to remove the configuration for a bonded or teamed device and restore the member interfaces to their original, separate configuration.
The following examples use the device name team0
.
Replace this with the actual name of your device.
Stop the device:
>
sudo
wicked ifdown team0
Hide the configuration file by renaming it from
/etc/sysconfig/network/ifcfg-team0
to/etc/sysconfig/network/.ifcfg-team0
.Alternatively, if you definitely do not need the configuration anymore, remove the file instead of renaming it.
To re-enable the network interfaces that were included in the device, restore their original configuration from the backup files.
Reload the network configuration:
>
sudo
wicked ifreload all
Check the status of the remaining network interfaces:
>
ip addr
4 Network bonding or network teaming: feature comparison #
Network bonding and network teaming
are different methods for combining network connections to provide a single combined
interface. Bonding is handled exclusively in the kernel. Teaming includes a small set of
kernel modules that provide an interface for teamd
instances,
but everything else is handled in user space.
Feature | Bonding | Teaming |
---|---|---|
broadcast, round-robin TX policy | yes | yes |
active-backup TX policy | yes | yes |
LACP (802.3ad) support | yes | yes |
hash-based TX policy | yes | yes |
user can set hash function | no | yes |
TX load-balancing support (TLB) | yes | yes |
TX load-balancing support for LACP | no | yes |
Ethtool link monitoring | yes | yes |
ARP link monitoring | yes | yes |
NS/NA (IPV6) link monitoring | no | yes |
RCU locking on TX/RX paths | no | yes |
port prio and stickiness | no | yes |
separate per-port link monitoring setup | no | yes |
multiple link monitoring setup | limited | yes |
VLAN support | yes | yes |
multiple device stacking | yes | yes |
5 Legal Notice #
Copyright© 2006–2024 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.