Link aggregation with kernel bonding and the Team daemon
Battle of Generations
Configuration
One central question from the admin's point of view is how the bonding or teaming solution can be configured and how practical administration works in everyday life. Earlier, you already saw that bonding.ko
in particular is deeply integrated into the kernel and that support for bonding is therefore part of the standard scope of delivery in current distributions.
However, this does not mean that the configuration is automatically intuitive, simple, or easy to understand. Anyone who has ever locked themselves out of a newly installed CentOS system by putting a wrong bonding configuration into operation, which could only be corrected through the BMC interface afterward, will be familiar with the problem.
As with the architecture, libteam and bonding are fundamentally different when it comes to configuration and handling. On the one hand, the kernel bonding driver has to be processed in userland by ifenslave
. The configuration in CentOS and related distros is generally not much more intuitive than this tool, and not many admins will be able to edit the necessary configuration files to achieve a working bonding configuration at the end of the day without referring to the documentation.
Ubuntu, Debian, and SLES are not much smarter. Admins can get into a terrible mess if they don't want to operate the bonding modules with the standard parameters but attempt to define custom values (e.g., for the MII link monitoring frequency). In the worst case, only a modinfo
against the bonding module will help you find the required parameter – combined with the system documentation to find out where to write the parameter for the bonding driver to actually use it.
All told, the user experience for configuring bonding in Linux is about the same as the standard 20 years ago, which is mainly because it was created about 20 years ago.
JSON Configuration
The Team daemon works in a completely different way. The administrator stores the configuration for the service in the form of a JSON file in the /etc
folder, although the path can change depending on the distribution. In the teamd.conf
file, you then add everything that teamd
needs to know to create the team devices after it starts up.
Parameters desired by the user, such as the Team mode or the ARP monitoring mode, can be defined in teamd.conf
for each device. A nice man page (man 5 teamd.conf
) for the file explains all relevant parameters in detail, including the respective default values (Figure 5).
If you configure your team devices in this way, it's almost boring: Gone are the days when restarting the network configuration was associated with the inherent risk of locking yourself out of the system. Team daemon configuration in JSON format is well structured, equipped with understandable keywords, and excellently documented. Again, a point clearly goes to libteam and teamd
, putting the score at 2 to 1.
Basic Functions
The most beautiful architecture and the greatest configuration is completely useless if you cannot use the respective solution because of a lack of functionality. The question then arises as to whether and to what extent the basic bonding modes are implemented and with which functions the developers equip their charges.
The Team daemon supports five bonding modes out the box: In addition to broadcast
, roundrobin
, and activebackup
runners, lacp
and loadbalancer
runners are also available. The lacp
runner provides support for the link aggregation control protocol (LACP, per IEEE 802.3ad), and loadbalancer
is based on the Berkeley Packet Filter (BPF) and comes with various options that are defined in the configuration file. Among other things, it is also possible to influence the hash algorithm used in the teamd
load balancer runner with specific parameters.
Configuration options are not limited to the load balancer runner, by the way. Each of the runners that can be selected in teamd.conf
comes with specific options – all of which are reliably listed in the man page. Some of the runner options provide information about certain teamd
features. LACP can also be used with round robin runners; the Team daemon is thus a few steps ahead of its Linux kernel counterpart, especially when it comes to monitoring Ethernet links.
Buy this article as PDF
(incl. VAT)