Duplex Mismatch: The Link That Works Badly
An uplink stays up and forwards badly, with each end disagreeing about duplex. Diagnose it and fix it yourself, live, right below.
Symptom
The uplink is up, forwarding, and dreadful. No alarm has fired because nothing has failed, and only one of the two settings people reach for is actually to blame.
Your mission
Prove the cause, then fix it
Format
Guided CLI investigation
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: SW1 · SW2
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
Users report that file transfers across the SW1 to SW2 uplink are painfully slow. The link is up, no interface has flapped, and no alarm has fired. Both switches were recently worked on.
What you'll practice
- Recognise a duplex mismatch from its error signature rather than from an outage
- Attribute late collisions and CRC errors to the correct end of a link
- Read the a- prefix in show interfaces status to see which end negotiated
- Restore autonegotiation, and know why matching the speed changes nothing
1. The fault that never pages anyone
A duplex mismatch leaves the link up and forwarding, so nothing alerts. You will learn to reach for interface counters when the complaint is performance rather than reachability, which is where this class of fault always hides.
2. Which end shows which error
Late collisions appear on the half-duplex end, because that end is the one that believes it must wait. CRC errors and runts appear on the full-duplex end, which sees the other side's aborted frames. Knowing which is which tells you which end is misconfigured before you read a single config.
3. Speed is not the problem
Parallel detection recovers speed even when the far end has stopped negotiating, so both ends usually agree on speed. Duplex has no such fallback and drops to half. You will try matching the speed, watch it change nothing, and learn why.
The topology
SW1 and SW2 are joined by a single Gi0/1 uplink. SW1's port has been hardcoded; SW2's is left on autonegotiation.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show interfaces GigabitEthernet0/1show interfaces statusshow running-config interface GigabitEthernet0/1Topology diagram
Frequently asked
Why does the link stay up if the two ends disagree?
Because duplex is not part of establishing link. The physical layer comes up as soon as both ends see each other electrically, and the switches only disagree about when they are allowed to transmit. That produces collisions and corrupted frames rather than a down interface, which is exactly why the fault presents as slowness and never as an alarm.
What does the a- prefix in show interfaces status mean?
It marks a value that the port arrived at through autonegotiation rather than one you configured. It is applied per column, so a port can legitimately show a bare duplex beside an a- speed. Seeing one bare value and one a- value on opposite ends of the same link is the fastest way to spot this fault.
Should I fix it by hardcoding both ends to match?
It works, but it is the weaker answer. A hardcoded pair breaks silently the next time somebody replaces a switch or moves the cable, because the new device will autonegotiate against a partner that has stopped negotiating and you are straight back here. Returning both ends to auto is self-correcting and is what modern gigabit links require anyway.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.