Duplex Mismatch and Interface Errors on Cisco IOS XE

"The network is slow" tickets that turn out to be a duplex mismatch are a rite of passage. The link is up, pings work, and yet throughput is terrible and retransmissions are everywhere. This article shows you how to catch the problem in seconds - including the exact syslog message Cisco devices print when CDP spots a mismatch (captured live from our Network Fundamentals lab) - and how to read every error counter in show interfaces.

What a duplex mismatch actually is

Full duplex means both ends transmit whenever they like; half duplex means an end waits for silence and treats simultaneous transmission as a collision. When one side runs full and the other half, the full side transmits freely while the half side keeps detecting "collisions" and backing off, then retransmitting. Result: the link works, badly. Light traffic flows fine; under load, the half side logs collisions and late collisions while the full side counts CRC and runt errors from frames the other end aborted mid-transmission.

The classic cause is autonegotiation failing or being half-configured: one side hardcoded to full, the other left on auto. An auto side that can't negotiate falls back to half duplex (at 10/100 Mbps). Hardcoding one side only is how you manufacture this problem.

The 10-second diagnosis: let CDP tell you

We forced the mismatch in the lab: R1's Ethernet0/1 at full duplex, the switch port facing it set to half. Within one CDP cycle, both devices called it out by name:

R1# show logging | include DUPLEX
*Jul 10 18:24:36.246: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered
  on Ethernet0/1 (not half duplex), with SW1 Ethernet0/0 (half duplex).

SW1# show logging | include DUPLEX
*Jul 10 18:24:50.596: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered
  on Ethernet0/0 (not full duplex), with R1 Ethernet0/1 (full duplex).

Read that message carefully - it names the local interface, the neighbor, the neighbor's interface, and both duplex settings. If both ends are Cisco and CDP is on, the box literally hands you the diagnosis. Check show logging before you check anything else.

Verifying duplex directly

SW1# show interfaces status

Port    Name     Status       Vlan   Duplex  Speed  Type
Et0/0   TO-R1    connected    10     full    auto   10/100/1000BaseTX
Et0/1   TO-H1    connected    10     full    auto   10/100/1000BaseTX
Et0/2   TO-H2    connected    10     full    auto   10/100/1000BaseTX

One line per port with duplex and speed - this is the fastest inventory view. The mismatch case shows a-half or half on one side and full on the neighbor's. On the mismatched interface itself, show interfaces Ethernet0/0 prints the operational state in the first few lines (our lab port reported Half-duplex while misconfigured, Full-duplex, Auto-speed once fixed).

Reading the counters that matter

Here's the full counter block from R1's LAN interface, healthy, so you know the baseline:

R1# show interfaces Ethernet0/1
Ethernet0/1 is up, line protocol is up
  Hardware is AmdP2, address is aabb.cc00.1210 (bia aabb.cc00.1210)
  Internet address is 10.0.10.1/24
  MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  ...
     540 packets input, 283237 bytes, 0 no buffer
     Received 210 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     381 packets output, 268981 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier

The counters, decoded by what they usually mean:

CRC / input errorsCorrupted frames received. Bad cable, EMI, failing SFP, or the far side of a duplex mismatch.

runtsFrames under 64 bytes - collision fragments, classic on the full side of a mismatch.

giantsFrames over the MTU - usually an MTU/encapsulation config problem, not physics.

collisionsNormal on genuine half duplex; on a supposedly full-duplex link, a red flag.

late collisionCollision after the first 64 bytes. Almost always duplex mismatch (or a cable run beyond spec). The single most diagnostic counter.

deferredPort waited for silence before transmitting - the half side yielding under load.

interface resetsThe interface bounced - counts config changes (ours shows 2 from the duplex experiment) as well as carrier loss.

The signature pair to memorize: late collisions on the half-duplex side, CRC/runts on the full-duplex side. See both across one link and you're done diagnosing. (In our CML lab the virtual wire can't produce genuine electrical collisions, so we show you the healthy baseline and the CDP catch; on physical gear, load the mismatched link and watch those two counters climb.)

Fixing and preventing it

SW1(config)# interface Ethernet0/0
SW1(config-if)# speed auto
SW1(config-if)# duplex auto

Auto on both ends is the modern best practice - gigabit and faster require autonegotiation anyway, and it negotiates duplex correctly when both sides participate.
Never hardcode just one end. If policy demands hardcoding (some old server NICs), hardcode both ends identically.
A counter check means nothing without a time base: clear counters Ethernet0/0, generate traffic, re-check. "0 late collisions since Tuesday" and "0 since 30 seconds ago under load" are different facts.

FAQ

Why does a duplex mismatch still pass ping?

Ping is a trickle - one small frame at a time, with gaps. Collisions need simultaneous transmission, so light traffic mostly squeaks through. The pathology only shows under sustained bidirectional load (file transfers, backups, VoIP), which is exactly why users report "slow" rather than "down" and why the ticket survives the first tech's ping test.

Can gigabit links have duplex mismatches?

Effectively no - 1000BASE-T requires autonegotiation, and gigabit is full duplex in practice. The mismatch problem lives at 10/100 with hardcoded ports: old servers, door controllers, medical devices, industrial gear. That legacy tail is why the skill stays on the CCNA.

What causes late collisions besides duplex mismatch?

Cable runs beyond the 100m spec (or repeaters extending a collision domain beyond timing limits) and bad NICs that violate carrier sense. In a modern switched full-duplex network, though, a nonzero late-collision counter is a duplex mismatch until proven otherwise.

Do CRC errors always mean a bad cable?

No - CRC counts any corrupted frame. Bad or too-long cable, EMI (that run past the elevator motor room), a failing SFP, a dying NIC, or the far side of a duplex mismatch aborting frames mid-transmission. Correlate with the neighbor's counters: CRC on one side plus late collisions on the other = mismatch; CRC alone rising on both = physical medium.

Should I disable CDP if it reveals topology?

On untrusted/user-facing edges, many shops do (or use it selectively) for hardening. But note what you give up: this article's entire 10-second diagnosis. Common compromise: CDP/LLDP on infrastructure links where the mismatch alarm matters, disabled on user access ports. More in our CDP vs LLDP lab.

Key takeaways

Duplex mismatch = link up, ping fine, throughput awful. Suspect it early.
show logging | include DUPLEX - CDP names the mismatch, both interfaces included.
Late collisions point at the half side; CRC and runts point at the far side of the same problem.
Auto/auto everywhere, or hardcode both ends. Half-configured negotiation is the root cause.

Practice the full L1/L2 workflow in Lab nf-11 - Troubleshooting Layer 1/2/3 Symptoms, and find every fundamentals topic on the Network Fundamentals guide.

Duplex Mismatch and Interface Errors: Find It in 10 Seconds