Read increasing interface counters and a duplex mismatch

short · 45 min · Objective 5.2

Task

Learn the skill this objective actually tests: reading interface counters as a live measurement rather than a static number, and recognising the counter signature of a duplex mismatch. You will force a mismatch you can create on a VM and read what it does to the error counters.

Steps

  1. Establish the baseline. Clear or record the current counters: ip -s link show eth1 shows RX and TX with errors, dropped, and — under the detailed view — CRC and collision figures. Note the numbers and the time.
  2. Generate traffic and watch. From another host, run a sustained ping flood or an iperf stream to this interface, then read ip -s link show eth1 again. The crucial question is not whether a counter is non-zero but whether it is increasing between two readings — a value that has not moved is history.
  3. Read the negotiated settings: sudo ethtool eth1 reports speed, duplex and whether auto-negotiation is on. On a healthy link this shows full duplex.
  4. Force a mismatch to see the signature. Fix one end to half duplex: sudo ethtool -s eth1 speed 100 duplex half autoneg off. On a link the other end still runs at full duplex, this is exactly the misconfiguration that produces late collisions — a collision detected after the frame should have finished, which cannot happen on a correctly negotiated full-duplex link.
  5. Re-read the counters under load and identify the late collisions and rising errors, then restore autonegotiation: sudo ethtool -s eth1 autoneg on.

Verify

ip -s link show eth1
sudo ethtool eth1 | grep -E "Speed|Duplex|Auto-negotiation"
sudo ethtool -S eth1 2>/dev/null | grep -iE "collision|crc|error" | head

Two readings of ip -s link a minute apart, with a rising error count between them, is the proof you are looking at a live fault and not an old scar. The ethtool line naming Duplex as Half while the far end is Full is the root cause made visible — the counter symptom and the configuration cause, side by side.

Notes

The distinction the objective hangs on: a counter's value tells you something happened; a counter that is climbing while you watch tells you it is happening now. Always read twice. "Clear the counters, generate traffic, and watch" turns a historical record into a measurement, and it is the habit that separates diagnosing a cable from replacing one on a hunch.

The counters sort faults into families. CRC errors rising means layer 1 — cable, connector, interference, a failing transceiver. Late collisions mean a duplex mismatch specifically. Drops mean a full queue, which is congestion, not corruption. Reading which counter is climbing tells you which family you are in, and that decides whether you reach for a new cable or for QoS — confusing them sends you to replace hardware that works.