Link aggregation with kernel bonding and the Team daemon

Battle of Generations

Conclusions

The direct comparison of the bonding driver and teamd looks like a battle of two generations. On the one hand, the established kernel driver is firmly embedded in the kernel and thus suggests that you know what you are getting. To this day, the prejudice commonplace in the minds of many admins is that only the functionality implemented in the kernel is truly good and that functionality in kernel space is automatically better than that "only" present in user space.

This fallacy, however, has now clearly been disproved by various tools, and teamd is one of them, because this solution requires just a small kernel module that specializes only in moving packets back and forth in the kernel, with no negative effect whatsoever.

The many functions and features implemented in teamd are a plus. Basically, the bonding driver is not capable of any function that libteam and teamd cannot handle; however, the obverse is not true: You would miss the intuitive and easy-to-understand configuration file in JSON format as painfully as the ability to monitor bonding devices by the D-Bus interface.

The bonding driver can score directly in terms of availability, because both ifenslave and bonding.ko can be found in any flavor of Linux. In comparison, admins have to install the tools for teamd, although in many distributions, this turns out to be no problem thanks to comprehensive offerings of the required packages.

Smart add-ons, such as teamd talking directly to ZeroMQ, round off the overall picture. If you are a network aggregation enthusiast, you will thus want to test teamd and libteam exhaustively – or at least take a closer look.

Infos