Ethernet Link Negotiation: Speed, Duplex, and Physical Evidence

Prerequisites: none. root note.

An Ethernet link is established between two physical ports before Kubernetes, an IP address, or an application can use it. The network interface and the switch port advertise the modes they support, then negotiate a common speed and duplex mode.

For the two devata workers, the healthy result is:

speed=1000
duplex=full
carrier=up

1000 means 1,000 megabits per second. full means both ends can transmit at the same time. A link can remain technically up at 100 or even 10 Mbps, so Ready=True on a Kubernetes node does not prove that the physical network is healthy.

What a downshift means

Autonegotiation normally chooses the fastest mode supported by both ends. A link that previously ran at 1 Gbps but returns at 100 or 10 Mbps has downshifted. Common causes include:

• a damaged or marginal cable pair;
• a loose connector;
• a bad switch port;
• an interface or physical transceiver problem;
• power interruption or repeated carrier loss during negotiation.

Gigabit Ethernet over copper needs all four wire pairs. Lower modes can work with fewer pairs. A damaged cable can therefore preserve connectivity while silently removing most of the bandwidth.

This distinction mattered on devata. The Dell OptiPlex worker returned at 10 Mbps while the Acer worker returned at 100 Mbps. Kubernetes could still exchange heartbeats, but storage replication and log traffic shared links that were one or two orders of magnitude slower than expected.

Read the live state on Talos

Talos exposes Linux network state through its API. First map the Kubernetes node to its physical machine and interface:

kubectl get nodes -o wide
talosctl -n 192.168.1.9 get systeminformation
talosctl -n 192.168.1.10 get systeminformation
talosctl -n 192.168.1.9 get links
talosctl -n 192.168.1.10 get links

On devata the mapping is:

Read the negotiated values directly:

talosctl -n 192.168.1.9 read /sys/class/net/enp3s0/speed
talosctl -n 192.168.1.9 read /sys/class/net/enp3s0/duplex
talosctl -n 192.168.1.10 read /sys/class/net/enp0s31f6/speed
talosctl -n 192.168.1.10 read /sys/class/net/enp0s31f6/duplex

The Linux kernel also exposes cumulative counters under /sys/class/net/<interface>/statistics/. The kernel interface-statistics documentation explains the available interfaces and counter semantics.

talosctl -n 192.168.1.9 read /sys/class/net/enp3s0/carrier_changes
talosctl -n 192.168.1.9 read /sys/class/net/enp3s0/statistics/rx_errors
talosctl -n 192.168.1.9 read /sys/class/net/enp3s0/statistics/tx_errors

These counters are cumulative. A nonzero value proves that something happened since the interface was created, not that it is still happening. Record a baseline, wait through the period being tested, then compare again. The delta is the evidence.

Separate link state from application state

The layers answer different questions:

When a hardware fault creates an application backlog, repairing the cable stops the trigger but does not remove the retained state. That is why the Loki incident continued after both links returned to 1 Gbps.