Imagine your network is running fine, but users complain of slow file transfers and intermittent connectivity. You check interface counters and see a ton of CRC errors and collisions on a link that's supposed to be full duplex. Chances are, you're dealing with a duplex mismatch—one of the most common and insidious Layer 1/2 issues. On the CCNA 200-301 exam (Objective 1.3: Troubleshoot Layer 1 and Layer 2 issues), duplex mismatch is a frequent topic, and understanding how to identify and fix it is essential for both the test and real-world networking.
Jump to a section
Think of a network link like a conversation between two people using radios. Full duplex is like a telephone call: both people can talk and listen at the same time, so the conversation flows naturally without interruption. Half duplex is like a walkie-talkie: only one person can talk at a time; you press a button to transmit and release it to listen. If one person uses a telephone (full duplex) and the other uses a walkie-talkie (half duplex), chaos ensues. The walkie-talkie user expects silence before transmitting, but the telephone user keeps talking while listening. Every time the walkie-talkie user presses the transmit button while the telephone user is speaking, the telephone user hears a burst of noise (collision) and has to say, 'What? Say that again?' (retransmission). The telephone user, hearing the noise, might also stop talking and wait, causing delays. Meanwhile, the walkie-talkie user, not hearing anything, assumes the line is clear and transmits again, causing more collisions. The result is a frustrating, inefficient conversation with constant interruptions and repeats—exactly what happens with a duplex mismatch: one side sends while the other is transmitting, causing collisions, CRC errors, and severe performance degradation. The key insight is that the half-duplex side follows CSMA/CD rules (listen before talk, back off on collision), while the full-duplex side ignores those rules because it assumes no collisions are possible. This fundamental incompatibility is the root cause of all duplex mismatch problems.
What is Duplex Mismatch and Why Does It Happen?
Duplex mismatch occurs when two connected devices are configured with different duplex settings—one full duplex and one half duplex. Ethernet originally operated in half-duplex mode, using CSMA/CD (Carrier Sense Multiple Access with Collision Detection) to manage access to the shared medium. As networks evolved to switched topologies, full duplex became the norm, allowing simultaneous send and receive on dedicated switch ports. However, misconfiguration or failure of auto-negotiation can leave one side in half-duplex while the other is in full-duplex.
How Duplex Mismatch Causes Errors: Step by Step
Let's walk through what happens when a switch port is set to full duplex (100 Mbps) and the connected PC is set to half duplex (100 Mbps).
Full-duplex side (switch): The switch assumes it can transmit and receive simultaneously. It does not perform carrier sense before sending—it just sends frames whenever it wants. It also ignores collisions because it expects no collisions on a point-to-point full-duplex link.
Half-duplex side (PC): The PC follows CSMA/CD. It listens to the medium before transmitting. If it senses no carrier, it starts sending. However, while it is transmitting, the switch may also start sending a frame. The PC detects a collision (because it hears its own transmission garbled by the switch's transmission) and sends a jam signal (32-bit sequence) to ensure all stations detect the collision. The PC then stops transmitting, waits a random backoff time (using the truncated binary exponential backoff algorithm), and tries again.
Effect on the switch: The switch, being full-duplex, does not expect collisions. When the PC sends a jam signal, the switch may interpret it as a valid frame preamble or as a collision event, depending on the timing. Typically, the switch will detect a late collision (a collision that occurs after the first 64 bytes of the frame) because the PC's transmission is already in progress. Late collisions are not retried by the switch; instead, the frame is simply dropped. This results in CRC errors on the switch side because the frame is truncated or corrupted.
Resulting errors: On the half-duplex side (PC), you'll see collisions (both normal and late) and possibly CRC errors. On the full-duplex side (switch), you'll see CRC errors and runts (frames shorter than 64 bytes) because the switch may receive partial frames before the collision truncates them. The interface counters tell the story.
Key Defaults and Timers
Auto-negotiation: By default, Cisco switches have duplex auto and speed auto on all ports. Auto-negotiation uses Fast Link Pulses (FLPs) to exchange capabilities. If auto-negotiation fails (e.g., due to cable faults or one side having hard-coded settings), the switch may fall back to half-duplex (based on the IEEE 802.3 standard for parallel detection).
Speed: If speed is hard-coded on one side but not the other, auto-negotiation fails, and the duplex defaults to half-duplex (for 10/100 Mbps). For 1 Gbps and above, auto-negotiation is mandatory; disabling it forces half-duplex, which is not supported at 1 Gbps, so the link may not come up.
Backoff time: For half-duplex, after a collision, the station waits a random time from 0 to (2^n -1) slot times, where n is the retransmission attempt number (capped at 10). A slot time is 512 bit times (51.2 µs for 10 Mbps, 5.12 µs for 100 Mbps).
IOS CLI Verification Commands
To check duplex settings and errors, use:
show interfaces <interface>
show interfaces status
show interfaces <interface> | include duplexExample output for a mismatched port:
Switch# show interfaces gigabitethernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is Gigabit Ethernet, address is aabb.cc00.0100 (bia aabb.cc00.0100)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped outNotice the line Full-duplex, 100Mb/s. The counters show no errors, but if there were a mismatch, you'd see high CRC and input errors on the full-duplex side, and high collisions and late collisions on the half-duplex side.
Interaction with Related Protocols
STP: Duplex mismatch can cause STP issues because BPDUs may be corrupted or dropped, leading to loops.
EtherChannel: All member ports must have identical duplex and speed settings. A mismatch can cause EtherChannel to fail or cause instability.
QoS: Duplex mismatch can cause frame drops that QoS mechanisms try to mitigate, but the underlying problem remains.
Identify symptoms of duplex mismatch
Users report slow performance, timeouts, or connectivity issues. On the network, you may notice high error rates on interfaces, especially CRC errors and late collisions. Use `show interfaces` to check counters. If you see many CRC errors on one side and many collisions on the other, suspect mismatch. Also, check if the interface is using auto-negotiation or hard-coded settings with `show interfaces status`.
Verify duplex and speed settings on both ends
On the switch, use `show interfaces <interface> | include duplex` to see the current duplex. For the connected device (PC, server, router), check its network adapter settings. In a lab, you can simulate by hard-coding one side to full and the other to half. On Cisco devices, use `show interfaces <interface>` and look for 'Full-duplex' or 'Half-duplex'. Also, verify speed matches; a speed mismatch can prevent the link from coming up.
Check error counters on both interfaces
On the suspected mismatched link, run `show interfaces <interface>` on both devices. On the full-duplex side, look for high `input errors` and `CRC` counts. On the half-duplex side, look for high `collisions` (especially `late collisions`) and `output errors`. Late collisions are a dead giveaway because they occur after the first 64 bytes, which should not happen in a properly operating half-duplex network.
Determine the root cause of the mismatch
Common causes: (1) One side has hard-coded duplex, the other is set to auto. (2) Auto-negotiation failed due to cable issues or incompatible hardware. (3) Misconfiguration by an administrator. Check the configuration of both devices. On Cisco switches, `show running-config interface <interface>` shows if `duplex` and `speed` are explicitly set. If not, they are using auto-negotiation.
Resolve the mismatch by aligning duplex settings
The best practice is to set both sides to auto-negotiate (default). If you must hard-code, set both sides identically. On a Cisco switch, configure: `interface <interface>` -> `duplex full` (or half) -> `speed 100` (or 10/1000). Then verify with `show interfaces`. Avoid mixing auto and hard-coded settings. If the link is still problematic, check the cable and try a different port.
Verify resolution by monitoring error counters
After correcting the settings, clear the interface counters with `clear counters <interface>` to get a fresh baseline. Then monitor the link under load. Use `show interfaces <interface>` to confirm that error counters are not increasing. Also, test connectivity with ping and file transfers to ensure performance is normal.
In a typical enterprise network, duplex mismatch often occurs after a hardware refresh or when connecting older devices to new switches. For example, a legacy printer with a 10/100 NIC that has auto-negotiation disabled (hard-coded to 100 half) is connected to a modern Cisco switch with default auto-negotiation. The switch, using parallel detection, may negotiate speed but fall back to half-duplex—but if the switch's auto-negotiation works correctly, it may end up full-duplex while the printer is half-duplex. The result: the printer is slow and generates errors, but since it's a low-traffic device, the problem may be intermittent and hard to diagnose.
Another common scenario: a server with a hard-coded full-duplex setting is connected to a switch port that is set to auto. The switch auto-negotiates to full-duplex (if both sides advertise) but if the server fails to send FLPs, the switch may default to half-duplex. The server, expecting full-duplex, sends frames without carrier sense, causing collisions on the switch side. The server sees no errors (because it's full-duplex and ignores collisions), but the switch logs CRC errors. This is a classic 'asymmetric' mismatch where only one side sees errors.
In data centers, where high throughput is critical, duplex mismatch can cripple performance. Network engineers must ensure consistent configuration across all access ports. Best practices include: (1) Always use auto-negotiation for 1 Gbps and above (it's mandatory). (2) For 10/100 Mbps, if you must hard-code, hard-code both speed and duplex identically on both ends. (3) Use interface templates or scripts to enforce consistent settings. (4) Monitor interface error counters proactively with SNMP or syslog. (5) Document all non-auto ports for troubleshooting.
When misconfigured, duplex mismatch can cause up to 50% packet loss, increased latency, and application timeouts. In severe cases, it can bring down entire network segments because STP BPDUs are lost, leading to loops. Always check duplex before assuming a hardware fault.
On the CCNA 200-301 exam, Objective 1.3 specifically includes troubleshooting Layer 1 and Layer 2 issues, and duplex mismatch is a classic problem. Expect scenario-based questions where you are given interface error counters and must identify the issue. Key points tested:
Error types: On full-duplex side: CRC errors, runts. On half-duplex side: collisions, late collisions. Know that late collisions are a hallmark of duplex mismatch.
Auto-negotiation failure: If speed is hard-coded on one side and auto on the other, the auto side may use parallel detection to get speed but defaults to half-duplex. The hard-coded side may be full-duplex, causing mismatch.
Common wrong answers: Candidates often think that CRC errors are always caused by bad cabling or that collisions are normal on full-duplex. They also confuse 'late collisions' with 'excessive collisions' (which occur after 16 retries). Another trap: believing that setting both sides to full-duplex always fixes the problem—but if speed doesn't match, the link won't come up.
Elimination strategy: When given a scenario with errors, check the duplex settings first. If one side is full and the other half, that's likely the root cause. If both are full, look at cable issues or hardware. If both are half, look for collisions (normal for half-duplex but excessive collisions indicate other issues like a loop).
Specific values: Slot time for 10 Mbps is 51.2 µs; for 100 Mbps, 5.12 µs. Backoff algorithm: random from 0 to (2^n-1) slot times, n up to 10. These are not directly tested but help understand collision behavior.
Commands: Be familiar with show interfaces, show interfaces status, and show running-config interface. Know how to interpret the output, especially the duplex line and error counters.
Duplex mismatch occurs when one side is full-duplex and the other is half-duplex.
Full-duplex side sees CRC errors and runts; half-duplex side sees collisions and late collisions.
Late collisions (after 64 bytes) are a definitive sign of duplex mismatch.
Auto-negotiation is default; hard-coding duplex on one side while auto on the other often causes mismatch.
For 10/100 Mbps, parallel detection can set speed but defaults to half-duplex.
Use 'show interfaces' to check duplex and error counters; 'show interfaces status' for a quick overview.
Best practice: use auto-negotiation on both ends; if hard-coding, set both ends identically.
These come up on the exam all the time. Here's how to tell them apart.
Full Duplex
Simultaneous send and receive
No collisions expected
No CSMA/CD; no carrier sense
Typically used in switched networks
Sees CRC errors in mismatch
Half Duplex
Only one direction at a time
Uses CSMA/CD
Listens before transmitting; detects collisions
Used with hubs or older networks
Sees collisions and late collisions in mismatch
Mistake
CRC errors always indicate a bad cable or hardware problem.
Correct
CRC errors can also be caused by duplex mismatch. In a mismatch, the full-duplex side receives corrupted frames due to collisions on the half-duplex side, resulting in CRC errors.
Candidates often jump to cable faults because CRC errors are associated with signal integrity, but the mechanism of collision-induced corruption is less obvious.
Mistake
Collisions are normal on a full-duplex link.
Correct
Collisions should never occur on a full-duplex link because the medium is dedicated. If collisions appear on a full-duplex interface, it indicates a duplex mismatch or a hardware loop.
Candidates may think collisions are a normal part of Ethernet, but full-duplex eliminates them.
Mistake
Setting both sides to full-duplex always fixes duplex mismatch.
Correct
If both sides are set to full-duplex but the speed is mismatched (e.g., one 100 Mbps, the other 10 Mbps), the link may not come up at all. Speed must also match. Additionally, if one side is auto and the other full, the auto side may still negotiate to half.
Candidates focus on duplex alone, forgetting that speed and auto-negotiation interplay.
Mistake
Auto-negotiation always results in the best duplex setting.
Correct
Auto-negotiation is reliable, but if one side has hard-coded settings, the auto side may fall back to half-duplex via parallel detection, causing mismatch. Also, faulty cables or interference can cause negotiation failures.
Candidates trust auto-negotiation blindly, but it has failure modes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A collision occurs when two devices transmit at the same time on a half-duplex medium. A late collision is a collision that happens after the first 64 bytes of a frame have been transmitted. In a properly functioning network, collisions should only occur within the first 64 bytes (the collision window). Late collisions indicate a duplex mismatch or that the network diameter is too large. Late collisions are not automatically retried; the frame is simply dropped, causing higher-layer retransmissions.
Generally, no. The link remains up (both line protocol and physical layer are up) because the physical signaling is still working. However, the high error rate can cause the interface to flap if error thresholds are exceeded (e.g., excessive CRC errors may cause the switch to errdisable the port). In practice, the link stays up but performance is severely degraded.
Auto-negotiation uses Fast Link Pulses (FLPs) to exchange capabilities between devices. Each device advertises its supported speeds and duplex modes. The best common mode is selected: full duplex is preferred over half duplex at the same speed. If one side does not support auto-negotiation (e.g., hard-coded), the other side uses parallel detection to sense the speed but defaults to half-duplex for 10/100 Mbps.
On the full-duplex side, look for 'CRC errors', 'input errors', and 'runts'. On the half-duplex side, look for 'collisions', 'late collisions', and 'output errors'. Also, 'deferred' frames may increase on the half-duplex side because it has to wait before transmitting. Use 'show interfaces' to see these counters.
For modern networks (1 Gbps and above), auto-negotiation is mandatory and must be enabled. For 10/100 Mbps, auto-negotiation is reliable if both ends support it. Hard-coding should only be used if auto-negotiation is not supported or is known to be problematic, and then both ends must be set identically. Mixing auto and hard-coded is the most common cause of duplex mismatch.
Yes, fiber links also use auto-negotiation (for speeds like 1000BASE-X) and can suffer from duplex mismatch. However, fiber links are typically full-duplex only; half-duplex over fiber is rare. Mismatch can still occur if one side is forced to half-duplex (some older fiber transceivers). The symptoms are the same: CRC errors on one side and collisions on the other.
If you see collisions on a switch port configured as full-duplex, it indicates a duplex mismatch. The switch port is actually operating in half-duplex because the connected device is half-duplex, but the configuration says full-duplex. The 'show interfaces' output shows the operational duplex, not the configured duplex. Check the operational status with 'show interfaces'.
You've just covered Troubleshoot: Duplex Mismatch Causing Errors — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?