Duplex Mismatch Explained (and How to Fix It)
A duplex mismatch occurs when two directly connected interfaces disagree about duplex: one runs full duplex, the other half duplex. The link still comes up, so it looks healthy — but throughput collapses, and you see late collisions on the half-duplex side and FCS/CRC errors on the full-duplex side. The fix is to make both ends agree.
Why the link still comes up
This is what makes duplex mismatch so nasty: it is not a hard failure. The interface shows up/up. Ping works. Small transfers succeed. Only under real load does the link fall apart — a gigabit port delivering a few megabits per second.
The cause is autonegotiation. When both ends autonegotiate, they exchange capabilities and agree correctly. But if one side is hardcoded and the other is left on auto, the auto side never receives negotiation signals. It falls back to a legacy rule: detect the speed by listening to the signal, and default duplex to half.
So the classic mismatch is:
- Switch port: hardcoded to
speed 100 / duplex full - Server NIC: left on autonegotiate → detects 100 Mbps, defaults to half
- Result: full on one end, half on the other. Mismatch.
The symptoms
Half duplex means the device must listen before it transmits, and it treats simultaneous transmission as a collision. Full duplex means the device transmits whenever it likes and ignores collision detection entirely. Put them on the same wire and each one breaks the other's assumptions.
| Side | Error you see | Why |
|---|---|---|
| Half-duplex side | Late collisions | The full-duplex side transmits while the half-duplex side is already transmitting, causing a collision after the 64-byte window. |
| Full-duplex side | FCS / CRC errors, runts | The half-duplex side aborts its own frames mid-transmission when it detects a collision, so fragments arrive corrupted. |
Other giveaways:
- Throughput far below the link speed, especially on large transfers.
- Performance that gets worse as traffic increases (more overlap, more collisions).
- TCP retransmissions and stalls; the network feels slow for no obvious reason.
- A
%CDP-4-DUPLEX_MISMATCHsyslog message — CDP compares the two ends and warns you directly.
How to confirm it
Check the interface counters on the switch:
Switch# show interfaces GigabitEthernet0/1
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
...
1247 input errors, 1198 CRC, 49 frame, 0 overrun
0 late collision, 0 deferredThen check both ends. The two decisive questions:
- Do the two ends report the same duplex? If one says full and one says half, you have your answer.
- Are late collisions incrementing? Late collisions on a modern switched link almost always mean duplex mismatch (the other possible cause is a cable run beyond spec).
- Are CRC errors climbing without any physical-layer problem? Rule out the cable first — but if the cable is good and CRCs keep rising, suspect duplex.
A quick check across every port:
Switch# show interfaces status
Port Name Status Vlan Duplex Speed Type
Gi0/1 connected 10 a-full a-100 10/100/1000BaseTX
Gi0/2 connected 10 full 100 10/100/1000BaseTXThe a- prefix means autonegotiated. A port showing full with no a- is hardcoded — that is where mismatches hide.
The fix
There are two valid strategies. Pick one and apply it to both ends.
Option 1 (recommended): autonegotiate on both ends. Modern autonegotiation is reliable and is mandatory for gigabit and above.
Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# duplex auto
Switch(config-if)# speed autoOption 2: hardcode both ends identically. Only do this if you have a documented reason, and only for 10/100 links.
Switch(config)# interface FastEthernet0/1
Switch(config-if)# speed 100
Switch(config-if)# duplex fullThe cardinal rule: never mix. Auto on one end and hardcoded on the other is exactly what creates the mismatch. After changing it, clear the counters and confirm the errors stop:
Switch# clear counters GigabitEthernet0/1
Switch# show interfaces GigabitEthernet0/1 | include duplex|error|collisionWhy gigabit changes things
At 1 Gbps and above, duplex mismatch essentially disappears — and it is worth understanding why.
Gigabit Ethernet over copper (1000BASE-T) requires autonegotiation as part of the standard. The two ends must negotiate master/slave timing before the link will even come up, and half duplex was never meaningfully deployed at gigabit speeds. So gigabit links either negotiate correctly or do not come up at all.
This is why duplex mismatch is largely a legacy 10/100 problem — but it is still very much alive on older access switches, IP phones, printers, out-of-band management ports and IoT devices, all of which frequently sit on 100 Mbps links. It also remains a favourite CCNA exam and interview question precisely because it teaches you to read interface counters properly. See our network troubleshooting guide for the wider methodology.
Frequently asked questions
What causes a duplex mismatch?
Hardcoding duplex on one end of a link while leaving the other end on autonegotiate. The auto side cannot negotiate, so it defaults to half duplex while the hardcoded side runs full duplex.
What are the symptoms of a duplex mismatch?
The link comes up and pings work, but throughput is far below the link speed. You see late collisions on the half-duplex side and CRC/FCS errors on the full-duplex side, plus TCP retransmissions and stalls.
Do late collisions always mean duplex mismatch?
On a modern switched link, almost always. The only other common cause is a cable run that exceeds the maximum length for the standard.
How do I fix a duplex mismatch?
Make both ends agree. Set both to autonegotiate (recommended), or hardcode both to the same speed and duplex. Never mix auto on one end with hardcoded on the other.
Can gigabit links have a duplex mismatch?
Essentially no. 1000BASE-T requires autonegotiation by standard, and half duplex was never deployed at gigabit speeds, so the link either negotiates correctly or does not come up.
Related articles
Want hands-on training?
Learn this on real Cisco lab devices with placement support at Attila Technologies, Ahmedabad.