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).

Figure 5: Configure the Team daemon in the teamd.conf configuration file, with no manual tinkering – unlike bonding.ko.

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.