This message was deleted.

Hi @red-king-19196, do you have any idea for this? Thank you.

We don’t support setting the AutoNeg or link speed for cluster networks’ uplink. And it seems the underlying netlink library doesn’t support them either. So currently the best shot I can think of is to configure the link via

ethtool

(for runtime) and

/etc/sysconfig/network/ifcfg-<nic>

(for persistence). Because Harvester is based on the immutable OS, making the configuration persistent requires more steps. Basically you’ll need to modify the

/oem/90_custom.yaml

to update the network config upon every boot. This is quite similar to the steps updating the bonding slaves. However, please note that the above persistent method is only suitable for the management network’s NIC. The Harvester network controller completely manages other NICs. The runtime changes will work. This could be an enhancement for the network controller. @faint-art-23779 Do you have any insight into this? Thanks.

As @red-king-19196 mentioned, we can use

ethtool

to verify if change linkspeed works or not. But the AutoNeg is pretty basic and mostly it's hardware problem. It could be the problem of the other end which the cable connects to, or the cable, or the cable is too long for the connection stability. Please verify this before looking for ways to persist the config. Thanks.

Thanks. It probably is a hardware problem either with the specific NICs (Intel x710 onboard) or the cables or the switch configuration but with this official answer I can put the ball again in their corner. Changing the link speed at runtime with ethtool was not possible because the "operation not supported". I wasnt sure if that was a consequence of the immutable nature of Harvester-OS

sudo ethtool -s [device_name] autoneg [on/off] speed [10/100/1000] duplex [half/full]

doesn't work?

No unfortunately not. I will try again and post the error as a screenshot. One moment

I don't think so. But it's only 100/Full. It probably indicate the signal is too weak. Might be cable's problem and the other end's problem.

Yes we pleaded with Infra-Team to please make sure L1 or misconfiguration on the switches is not to blame, but we only have limited access and influence over the Hardware 😕

The modern NIC has offload the basic feature to the FW. So it's not linux problem....But of course we can't really fight for ourselves.....

Yeah, it is what it is. I was just being extra diligent with tracking all avenues for a solution, but it probably is just a bad cable, but that is really hard to "prove" to some people

to rule out Harvester specifically perhaps try a Linux live OS?