Does Clear linux natively support the use of the network team driver (and teamd utility) now?
Background:
I’ve been away from Clear Linux project for a bit, but I’m almost in a position to start again. I notice that it seems Clear has moved from native systemd management of hardware NICs, to Network Manager for management of bare metal NICs.
I was quickly playing around with a fresh server install a few days ago, and figured I would setup the network with two interfaces as a LACP 802.3ad LAG. I did this using the team option, rather than the linux bond, under NMTUI.
It all seemed to work from a config standpoint, but failed when I attempted to bring the interface up. Not sure if I screwed up somewhere, if NMTU/NMCLI supports team config fine, but something is missing from my Clear Kernel (nothing fancy, just a default Clear native kernel) or userspace to run it correctly (I know I didn’t have teamd available and with a 3 second look I couldn’t locate that with a swupd search either…)
The error was:
Could not activate connection: NetworkManager plugin for ‘team’ unavailable.
Have edited the first post. Basically it seems to be missing a plugin. Guides for various RHEL/Fedora distro’s suggest just adding the plugin via the package manager, but that couldn’t be found in a swupd search, at least not under the suggested name, with the basic advice being:
‘Install NetworkManager-team and restart NetworkManager to enable the plugin.’
I also tried configuring it via nmcli, that basically produced the same error:
“Error: Connection activation failed: NetworkManager plugin for ‘team’ unavailable”
These are the steps I took, more or less:
nmcli connection add type team con-name mgmt-team ifname mgmt-team0 config ‘{“runner”: {“name”: “lacp”}, “link_watch”: {“name”: “ethtool”}}’
Thanks for looking into it and for the confirmation, I’ll run with bonds for now and try playing with teams once some of those changes make their way into a release.
I use CL servers, but none of them are on metal so Ive never run into this. You might try opening and issue on github and ask that it not be disabled. It should be fairly painless for them to support. Thanks for mentioning this here though. Might’ve save me a few hours one day tinkering in the lab. Should have read all the posts before making that suggestion. Guess I’ll just go +1 it
I might post this in a separate thread if preferred, but I’m pretty sure there is some sort of bug in NetworkManagers bonding implementation. It’s proving to be extremely hard to capture to confirm the issue though. In essence though, it appears that with a mode 4 (802.3ad LACP) bond and (despite what /proc/net/bonding/<bond> says), NetworkManager seems to be sending incorrect keys (it appears to be sending the partner port numbers, rather than its key). This prevents the bond coming up as the partner device (a Brocade ICX 6610 in this case) is seeing the Partner Key as the port numbers the partner is connected to the switch on (and since the keys don’t match each other, the switch blocks the LAG). I was suspicious of a problem in the switch at first, but…
This does not happen when the bond is created on the Clear Linux side using iproute2 package commands rather than NetworkManager (i.e. ip link add bond0 type bond … ).
I tried making NetworkManager bonds with both nmcli and nmtui, but it results in the same problem with both tools. I also tried doing this on a live USB as well, just in case the underlying OS install was the problem, but the outcome is the same, iproute2 bond commands work, NetworkManager built bond does not.
This is with nothing fancy whatsoever, just default everything except for mode is set to 802.3ad. I have played with all versions of bond.options xmit_hash_policy= but it doesn’t stabilise the bond under NetworkManager. The default option of xmit_hash_policy=layer2 is what works with an iproute2 built bond.
Should have read all the posts before making that suggestion. Guess I’ll just go +1 it