Managing Network Bonding Devices
- WHAT?
Combine two or more network interfaces into a single bonded device.
- WHY?
Network bonding 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 bonded device
Switch support, depending on the bonding mode
This article is about network bonding. To configure network teaming, see Managing network teaming devices.
1 Configuring network bonding #
Network bonding combines two or more network interfaces into a single bonded device to
increase bandwidth and/or provide redundancy. You can configure network bonding with YaST
or by manually creating ifcfg
files. The behavior of the bonded device
is configured using bonding modes.
1.1 Requirements #
Network connection
Basic understanding of networking and IP addresses
Existing network interfaces to include in the bonded device
Switch support, depending on the bonding mode
1.2 Restrictions #
- Do not split bonds over multiple switches
In most hardware setups, all network interfaces in a bonded device must be connected to the same switch. For more information, consult your switch vendor documentation.
- IBM POWER: Bonding modes 5 and 6 (
balance-tlb
andbalance-alb
) unsupported by ibmveth The bonding drivers in
tlb
mode andalb
mode send Ethernet Loopback packets with both the source and destination MAC addresses listed as the Virtual Ethernet MAC address. These packets are not supported by Power firmware. Therefore, bonding modes 5 and 6 are unsupported by ibmveth.- Bonding and virtualization
Bonded devices are made up of multiple network interfaces. In most configurations you should only configure bonding in the host. Virtual interfaces to guests are then created as a bridge with the bonded devices, simplifying guest creation and deployment.
It is possible, but not recommended, to configure bonding in a guest. When configuring bonding in a guest, you must assign multiple interfaces to the guest and configure the host without bonding. You must also be careful to configure the host and its network bridges so that you do not mix bonding in the host and guests.
1.3 Bonding modes #
The following bonding modes are available:
- ( )
Packets are transmitted in round-robin fashion from the first to the last available interface. Provides fault tolerance and load balancing. Requires switch support. Certain switches might fail with this mode.
- ( )
Only one network interface is active. If it fails, a different interface becomes active. Provides fault tolerance. This is the default mode. No specific switch support is required.
- ( )
Traffic is split between all available interfaces based on the number of interfaces included in the bonded device. Provides fault tolerance and load balancing. Requires switch support. Certain switches might fail with this mode.
- ( )
All traffic is broadcast on all interfaces. Provides fault tolerance. Requires switch support. Certain switches might fail with this mode. If possible, use mode
instead, or use this mode to provide sniffing capability by connecting each member of the bond to a different switch or device.- ( )
Also called LACP. 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.- ( )
Adaptive transmit load balancing. Provides fault tolerance and load balancing. Requires
ethtool
support in the interface drivers. No specific switch support is required, but certain switches might fail with this mode.- ( )
Adaptive load balancing. Provides fault tolerance and load balancing. Requires
ethtool
support in the interface drivers. No specific switch support is required, but certain switches might fail with this mode.
Consult your hardware manual to check which modes your switch supports.
For a more detailed description of the modes, see https://www.kernel.org/doc/Documentation/networking/bonding.txt.
1.4 Configuring network bonding with YaST #
Start the graphical version of YaST, or run the command
yast2
to start YaST in text mode.Select
› .Select
and change the to .Select
to open the menu.In the
tab, select how to assign an IP address to the bonded device:Do not use
. This option is only used for individual network interfaces that will be added to a bonded device.
In the
tab, select the network interfaces to include in the bonded device by activating the check boxes.From the
drop-down box, choose a bonding mode. The default mode isactive-backup
.Do not remove
miimon=100
. Without this parameter, data integrity is not checked regularly.Select
.If you are prompted to adapt the existing configuration for bonding, select
.Select
to create the bonded device.Select F9 to close YaST.
or press
1.5 Configuring network bonding with ifcfg
#
Create a configuration file named
/etc/sysconfig/network/ifcfg-bond0
. If you need more than one bonded device, give them ascending numbers. For more information, seeman ifcfg
,man ifcfg-bonding
, and/etc/sysconfig/network/ifcfg.template
.In the configuration file, define the following parameters:
STARTMODE=MODE1 BOOTPROTO=IP_ASSIGNMENT2 IPADDR=IPv4_ADDRESS3 IPADDR6=IPv6_ADDRESS3 BONDING_MASTER="yes"4 BONDING_SLAVE0="FIRST_DEVICE_NAME"5 BONDING_SLAVE1="SECOND_DEVICE_NAME"5 BONDING_MODULE_OPTS="mode=BONDING_MODE6 miimon=100"7
Defines how the bonded 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 bonded 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.Identifies this interface as a bonded device.
Specifies two or more network interfaces to include in the bonded device.
Defines the bonding mode for this interface.
Specifies how often, in milliseconds, each bond member is inspected for link failures.
Example 1: Bond configuration #STARTMODE=auto BOOTPROTO=static IPADDR="192.168.1.2/24" IPADDR6="fd00:deca:fbad:50::2/64" BONDING_MASTER="yes" BONDING_SLAVE0="eth0" BONDING_SLAVE1="eth1" BONDING_MODULE_OPTS="mode=802.3ad miimon=100"
Back up the existing
ifcfg
files for the bond member interfaces, in case you need to restore them later.Adjust the
ifcfg
files for both bond member interfaces so that they contain only the following content:BOOTPROTO='none' 1 STARTMODE='hotplug' 2
Check if everything is included in Wicked's configuration file:
>
sudo
wicked show-config
Start the bonded device:
>
sudo
wicked ifup all bond0
If you need additional debug information, use the option
--debug all
after theall
subcommand.Do not use
systemctl
to start or stop the bonded device. Always use thewicked
command.Check the status of the bonded device:
Get the state of the bonded device from Wicked:
>
sudo
wicked ifstatus --verbose bond0
Get the state of the bonded device and the bond members:
>
ip addr
Each command shows a slightly different view depending on your needs.
If you make changes to the ifcfg-bond0
file after starting the device,
reload its configuration with the command wicked ifreload bond0
.
2 Enabling hotplugging for network bond members #
In some network environments (such as High Availability), you might need to replace a bond member interface with a new one, for example, if a network interface has a fault. However, before you can replace the interface, you must configure the networking setup to recognize when a new device is added.
You can enable hotplugging either manually or with YaST.
2.1 Requirements #
A bonded device is already configured.
2.2 Enabling hotplugging for network bond members with YaST #
Start the graphical version of YaST, or run the command
yast2
to start YaST in text mode.Select
› . The tab shows the existing devices. If devices are already configured in a bond, this is stated in the column.Select one of the bond members, then select
. The menu opens.Switch to the
tab.Under
, select . A dialog box opens.In the dialog box, choose the
option, then select .Make sure that
is set toOn Hotplug
.Select
to return to the menu. When you select the bond member now, the bottom pane shows the device's details, including the bus ID.Select
to confirm your changes.Select F9 to close YaST.
or press
2.3 Enabling hotplugging for network bond members manually #
Check that the bond members are configured with
BOOTPROTO=none
andSTARTMODE=hotplug
. If you configured the bonded device with YaST, this is the default setting.List the hardware information for the network interfaces. You can use
grep
to show only the information required for this procedure:>
sudo hwinfo --netcard | grep -E "SysFS BusID|Device File"
SysFS BusID: 0000:00:17.0 Device File: eth0 SysFS BusID: 0000:00:19.0 Device File: eth1For each bond member, make a note of the associated
SysFS BusID
.Open the file
/etc/udev/rules.d/70-persistent-net.rules
. For each bond member, change the value ofKERNELS
to match theSysFS BusID
from the previous step. For example:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:00:17.0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:00:19.0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
This configures the
udev
rules to match the device by bus ID instead of by MAC address, allowing the bond to detect a new device in the same slot but with a different MAC address.
2.4 Summary #
When one of the bond member interfaces is removed from the system, the kernel removes it from
the bond automatically. When a new card is added to the system, udev
uses the bus-based persistent name rule to rename the interface to the name of the bond member,
and calls ifup
for it. The ifup
call automatically joins
the new interface into the bond.
At boot time, network.service
does not wait for the hotplugged
bond members, but for the bond to become ready, which only requires one available bond member.
3 Removing a bonded 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.