The terms bonding and teaming are quite often used interchangeably, especially when wearing both Linux and Microsoft hats. And that term is further confused once you start wearing your network admin hat as well.
However, in the world of Linux (in my case Fedora/CentOS/RHEL) there are distinct differences between the terms. One is the future of network interface collaboration, whilst the other is still very much capable, it lacks some of the features people may find useful going forward.
And to quote the Red Hat Enterprise Linux 7 Networking Guide;
“The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as “channel bonding”, “Ethernet bonding”, “port trunking”, “channel teaming”, “NIC teaming”, “link aggregation”, and so on. This concept as originally implemented in the Linux kernel is widely referred to as “bonding”. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in Red Hat Enterprise Linux 7. “
So why should you consider adopting teaming rather than the bonding method?
If you are looking for a complete comparison from the horses mouth, then may I suggest the; Red Hat Enterprise Linux Networking Guide: Comparison of Network Teaming to Bonding.
The key reasons why you might want to use teaming rather than bonding are;
- Teaming has a small kernel module which implements fast handling of packets flowing through your teamed interfaces
- support for IPv6 (NS/NA) link monitoring
- Capable of working with D-Bus and Unix Domain Sockets (the default)
- It provides an extensible and scale-able solution for your teaming requirements
- load balancing for LACP support
- It makes use of NetworkManager and its associates tools (the modern way) to manage your network connections
For me, I see teamd as ultimately the replacement for bonding in the coming years. Especially given that you can make use of tools such as nmcli which means that automation and repeatable configuration becomes much simper as the cli tools remove a lot of the checking and verification steps you would ultimately want when developing your own scripts to do the same job in a more manual fashion.
Obviously, NetworkManager has been around for a while so standard configurations could be applied using the likes of nmcli, but for anything more involved (see above reasons why you might consider teamd) then it becomes a no-brainer!
Anyway, I would highly recommend reading the Red Hat Enterprise Linux 7 documentation, there are some amazing nuggets of information in there.