Duplex Mismatch: The Counter Fingerprint and How to Confirm It

A duplex mismatch is a link where one end runs full duplex and the other runs half duplex. The link comes up and passes small amounts of traffic normally, so nothing looks broken at first glance. Under load it produces a distinctive split fingerprint: the full-duplex end accumulates CRC errors, input errors, and runts, while the half-duplex end accumulates collisions and late collisions. Because each end only sees its own half of the evidence, the diagnosis requires looking at both ends.

How the mismatch is created

Ethernet autonegotiation exchanges fast link pulse bursts that advertise every speed and duplex combination a port supports. When both ends negotiate, they pick the highest capability in common, and duplex agreement is guaranteed.

The problem starts when one end has autonegotiation turned off and its speed and duplex hard-coded, typically because an operator wanted to eliminate a variable. That port stops sending negotiation bursts and just transmits at its configured rate. The other end, still negotiating, receives no bursts and falls back to parallel detection: it inspects the incoming link signaling, recognizes the physical layer type, and derives the speed from it. Parallel detection cannot recover duplex, and the IEEE 802.3 specification says a port that arrives at a setting this way defaults to half duplex.

The result is deterministic. Hard-code one side to 100/full, leave the other on auto, and you get 100 Mb/s on both ends with full duplex on one and half duplex on the other. Speed matches, so the link goes up.

This is largely a 10/100 problem. 1000BASE-T requires autonegotiation as part of its master/slave clock resolution, and gigabit copper links effectively only run full duplex, so hard-coding a gigabit port more often produces no link at all than a mismatch.

Why the link still works

The half-duplex end obeys CSMA/CD: it listens before transmitting and treats any inbound signal arriving while it transmits as a collision. The full-duplex end has no such rule and transmits whenever it has a frame ready.

When traffic is light, the two ends rarely transmit at the same instant, so the half-duplex end never has to invoke its collision logic. Pings succeed, the interface shows up/up, and a file transfer of a few kilobytes completes cleanly.

Load changes that. Once both directions carry traffic simultaneously, every overlap is a collision from the half-duplex end’s point of view. It stops transmitting, sends a jam signal, and backs off, which leaves the far end holding a truncated frame with a broken frame check sequence. Meanwhile the full-duplex end never backs off, so the overlaps keep happening. TCP sees the loss, retransmits, and the retransmissions create more overlap. Throughput on a 100 Mb/s link commonly collapses to a few hundred kilobits per second while the port still reports itself as up.

The counter split

Each end records the failure differently, and that asymmetry is the identifying signature.

Symptom	Full-duplex end	Half-duplex end
Frames aborted mid-transmission by the far end	Counted as input errors, CRC, and runts	Not visible
Collisions	Always 0 (full duplex disables collision detection)	Collisions rising steadily
Late collisions	Not counted	Rising, the strongest single indicator
Output errors and deferred	Low	Deferred and output errors climbing
Interface state	up/up	up/up
Reported duplex	Full	Half, often shown as autonegotiated

A late collision is a collision detected after the first 64 bytes of a frame have already been transmitted. On a correctly built segment that should never happen, because the round-trip propagation delay is engineered to be shorter than the time it takes to send 64 bytes. Its other causes are a cable run beyond the standard length and a failing transceiver, both of which belong to cabling and transceiver selection rather than to duplex. On a modern switched network, a nonzero and increasing late collision counter with a full-duplex partner is a duplex mismatch until proven otherwise.

Runts and CRC errors alone are not conclusive, since bad cabling, electrical noise, and failing optics produce them too. The full interface counter set is where you separate those causes. What makes the mismatch distinctive is the pairing: errors on one end, collisions on the other, both rising in proportion to offered load.

Confirming it from both ends

Start by clearing the counters so that what you observe is current rather than accumulated since the last reload.

SW1# clear counters GigabitEthernet1/0/12
Clear "show interface" counters on this interface [confirm]

Then generate traffic and read both ends. The per-interface view names the duplex outright:

SW1# show interfaces GigabitEthernet1/0/12
GigabitEthernet1/0/12 is up, line protocol is up (connected)
  Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
     18422 packets input, 2914553 bytes, 0 no buffer
     Received 61 broadcasts (0 multicasts)
     412 runts, 0 giants, 0 throttles
     1183 input errors, 1121 CRC, 62 frame, 0 overrun, 0 ignored
     0 output errors, 0 collisions, 0 interface resets

The summary view is faster when you need to scan a closet:

SW1# show interfaces status
Port      Name       Status       Vlan   Duplex  Speed Type
Gi1/0/11             connected    20     a-full  a-100 10/100/1000BaseTX
Gi1/0/12             connected    20       full    100 10/100/1000BaseTX
Gi1/0/13             notconnect   20     a-full  a-100 10/100/1000BaseTX

The a- prefix means the value was arrived at by autonegotiation. A value without the prefix was configured. Two ports whose duplex differs, or one end showing a configured value while the other shows an autonegotiated one, is the pattern to look for.

If you cannot log into the far end, the neighbor tables help. CDP version 2 advertises the sender’s duplex, and IOS compares that advertisement against the local setting and logs the disagreement on its own:

%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/12
(not half duplex), with SW2 GigabitEthernet0/2 (half duplex).

That message is generated only when both ends run CDP, which is why CDP and LLDP neighbor detail is worth checking early on a Cisco-to-Cisco link.

Fixing it

Set both ends the same way. Autonegotiation on both ends is the default and the recommended configuration:

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

If a policy or a legacy device forces hard-coding, hard-code both ends to identical values and configure speed before duplex. Hard-setting duplex while leaving speed on auto leaves the port negotiating and reintroduces the same problem. Changing either setting bounces the interface, so treat it as a service-affecting change.

Interface status states

A mismatch never disables a port, and knowing what each status value actually means keeps you from chasing the wrong fault.

• connected: link is up and the port is forwarding. A duplex mismatch lives here, with error counters climbing.
• notconnect: the port is administratively enabled but no link partner is detected. Unplugged cable, far end powered off, or a speed the two ends cannot agree on.
• disabled: an operator issued shutdown on the interface.
• err-disabled: the switch itself shut the port down after one of its protection features detected a violation. Port security violations, BPDU guard and the other spanning-tree edge-port protections, link-flap detection, UDLD, and EtherChannel misconfiguration all react this way. The port stays down until an operator recovers it, and a %PM-4-ERR_DISABLE log message names the cause.
• inactive: the port belongs to a VLAN that does not exist or has been suspended.

Recovery from err-disable is manual by default: shutdown followed by no shutdown on the interface. Automatic recovery is opt-in per cause, with a 300-second default interval:

SW1(config)# errdisable recovery cause bpduguard
SW1(config)# errdisable recovery interval 300

Use show interfaces status err-disabled to list the affected ports and show errdisable recovery to see which causes are set to auto-recover.

How the 200-301 exam tests this

• Symptom to cause. A stem describes a link that pings fine but crawls during backups, with CRC errors on one switch and late collisions on the other. The answer is duplex mismatch, and the distractors are a bad cable (which produces errors on both ends without the collision split) or an oversubscribed uplink (which produces output drops, not errors).
• Counter attribution. You are given one end’s counters and asked what the other end will show. Late collisions on a port means the local port is the half-duplex end; CRC and runts with zero collisions means the local port is the full-duplex end.
• Interface state discrimination. A port is described as err-disabled and you must say why. The answer is that a protection feature triggered and the switch disabled the port itself. The traps are an administrative shutdown (which reports disabled), an unplugged cable (notconnect), and a duplex or speed problem, which never produces err-disable.
• The fix. Given a mismatch, the correct remediation is matching both ends, and the best-practice answer is autonegotiation on both ends rather than hard-coding both.

Counter attribution is the skill being tested, and it builds fastest by working exam-style questions that hand you one end and ask about the other.

Quick reference

• One end hard-set plus one end on auto equals full duplex on one side and half duplex on the other, because parallel detection defaults to half.
• Speed still matches, so the link comes up and only degrades under load.
• Full-duplex end: input errors, CRC, runts, zero collisions.
• Half-duplex end: collisions and late collisions, deferred, output errors.
• Late collisions with a full-duplex partner are the single strongest indicator.
• Gigabit copper requires autonegotiation, so mismatches are effectively a 10/100 issue.
• show interfaces status marks autonegotiated values with an a- prefix; %CDP-4-DUPLEX_MISMATCH flags the condition on Cisco-to-Cisco links.
• Interface states: connected, notconnect (no partner), disabled (shutdown), err-disabled (switch-imposed after a violation), inactive (dead VLAN).
• Recover an err-disabled port with shutdown then no shutdown, or configure errdisable recovery cause with a 300-second default interval.