Duplex mismatch: the fault that hides in plain sight

A duplex mismatch does not take the link down. It does something worse: it leaves everything looking healthy while quietly destroying throughput. Link light on, speed negotiated, interface up. And a file copy that should take a minute takes an hour.

What is actually happening

One side is running full duplex and transmits whenever it likes. The other is running half duplex and expects to listen before transmitting. When the full-duplex side sends during a frame the half-duplex side is sending, the half-duplex side sees a collision. It backs off, retransmits, and reports late collisions. The full-duplex side sees runts and CRC errors.

Neither side reports “duplex mismatch”. You have to infer it from the counters.

What to look for

On the half-duplex side: late collisions. Not ordinary collisions, which are normal on a shared segment, but late ones. On the full-duplex side: FCS errors, runts, alignment errors.

show interface GigabitEthernet0/1 | include duplex|collision|error|CRC
ethtool eth0 | grep -i duplex
ip -s link show eth0

How it happens

Almost always because one side was hard-coded and the other left on auto-negotiation. Auto-negotiation needs both ends participating. When one side is fixed, the other cannot negotiate, falls back to its default — half duplex — and the mismatch is created.

The rule

Either both ends auto-negotiate, or both ends are hard-coded identically. Never one of each. Modern gigabit links require auto-negotiation by specification, which has made this rarer, but it persists anywhere older equipment, media converters or management ports are involved.

When throughput is poor and everything looks fine, read the error counters before you believe the status line. The status line is telling you the link exists. The counters are telling you how well it works.