Link speed and errors
An interface that negotiates badly produces a network that works and is inexplicably slow. The counters tell you in seconds.
What the link thinks it is
ethtool eno1
Check three lines: Speed, Duplex and
Auto-negotiation. You want the expected speed, Full duplex,
and auto-negotiation on at both ends.
Never hard-set the speed on one side only. A fixed setting on your side against auto-negotiation on the switch produces a half-duplex link: it works, it passes small packets, and throughput collapses under load with late collisions in the counters. It is the classic slow-network-nobody-can-explain.
The counters
ip -s link show eno1
ethtool -S eno1 | grep -iE 'err|drop|crc|discard'
- RX errors or CRC errors
- Frames arriving damaged. Cabling, an optic, or a port. Not something you can configure away.
- RX dropped
- Often the host, not the wire — ring buffers or a saturated core. See network cards and offloads.
- TX errors or carrier errors
- The link is flapping or the far end is unhappy.
- Collisions, on a modern link
- Should be zero. Anything else means half duplex somewhere.
What matters is whether they are increasing. A handful since boot is nothing; a hundred an hour is a fault.
Optics
On fibre, read the module directly:
ethtool -m eno1
Look at the transmit and receive power against the module's own thresholds. Receive power drifting towards the low warning is a dirty connector or a failing optic, and it shows up as CRC errors long before the link drops.
Watch for flapping
journalctl -k | grep -iE 'link (up|down)'
A link that goes down and up repeatedly is worse than one that stays down, because routing and bonding keep reconverging. On a bond, check both members are really up:
cat /proc/net/bonding/bond0
See bonding and LACP — a bond quietly running on one member is a common and invisible state.
When to open a ticket
Errors on the interface are not a tuning matter. Cabling, optics and switch ports are our hardware. Send us:
- The machine identifier
ethtool eno1andethtool -S eno1outputip -s link, ideally twice a few minutes apart so we can see the rate- Whether it is constant or follows load
We check the switch side, where the same counters exist from the other direction. A cable or an optic is replaced from stock in Amsterdam — see hardware failure.
Rule out the host first
If the counters are clean and it is still slow, the problem is above the interface: see speed testing, TCP tuning and latency and bandwidth.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base