Network bond vs network teams

[JustSomeone]

Hello everyone

could someone explain why they deprecated network teams in rhel 9

while in the following table network teams support more feature and it’s Extensibility much easier than network bonds

Chapter 9. Configuring network teams using the web console Red Hat...

what was the issue in network team so they bring the bonds in the table ?

thanks for your time and have a nice day

[jlehtone]

@JustSomeone

could someone explain why they deprecated network teams in rhel 9

Red Hat might explain it in As teaming is deprecated in RHEL 9, what is a suitable replacement? - Red Hat Customer Portal
(I won’t subscribe, so can’t read.)

[JustSomeone]

thanks but i was not looking for replacement as i already mention network bond

i was asking why they did so despite the reason i give before

[iwalker]

I logged in, they don’t explain why there either. Nor even the bugzilla for it. It still exists in 9 though, but will disappear in RHEL10 apparently. I expect they are just wanting to get everyone to start moving away from it. But weird that they deprecate and don’t explain their reason for it.

[iwalker]

Found this:

What is the difference between bonding and teaming?
The main difference between bonding and teaming is that 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.

One big reason for using bonding because it’s in the kernel rather than user-space which could be slower. An explanation between the two:

Kernel space is strictly reserved for running a privileged operating system kernel, kernel extensions, and most device drivers. In contrast, user space is the memory area where application software and some drivers execute.

I would prefer to use in kernel space, I remember some things like zfs suffering in user-space, there was also something else that a few years back I used in user-space which wasn’t so good either - could have been ntfs-3g.

[JustSomeone]

thanks for that @iwalker that make sense

i get hit so hard by ntfs-3g it supported in kernel 5.15 if i remember the version

thanks again

[jlehtone]

The URL in ‘teamd’ package is http://www.libteam.org
That page claims:

Note that there is no performance overhead added with the fact that the control logic happens in userspace. Packets never leave kernel.

The upstream code is in GitHub - jpirko/libteam: team netdevice library
where latest release (v1.3.1) was in July 2020 and latest commit in February 2021.

Could it be that since the upstream does not have much activity, Red Hat does not want to commit maintaining untold years (beyond 2032)? Surely, if there were no alternatives, then the cost analysis could be different.

@iwalker Thanks for peeking into KB. IME, we do often wonder RH’s reasons.

[olista]

Also some information in this document (Chapter 11.2):

Considerations in adopting RHEL 9 Red Hat Enterprise Linux 9 | Red Hat...

Red Hat focuses its efforts on kernel-based bonding to avoid maintaining two features, bonds and teams, that have similar functions. The bonding code has a high customer adoption, is robust, and has an active community development. As a result, the bonding code receives enhancements and updates.

[iwalker]

@jlehtone

Thanks for peeking into KB. IME, we do often wonder RH’s reasons.

@jlehtone yeah not the first time RH dropped something without explanation, sadly.

[JustSomeone]

thanks @olista and have a nice day

[bobar]

@jlehtone

(I won’t subscribe, so can’t read.)

Why not ? it’s free !

[synack2]

My guess is with the proliferation of 10/25/100GB ethernet, there aren’t as many people doing teaming anymore. I guess there is still the redundancy issue, but a lot of that is being handled by hardware type solutions on the back end of VM’s in the data centers these days. I guessing there just isn’t as much of a call for it these days.