This chapter covers duplex mismatch troubleshooting, a common and often misdiagnosed network issue that appears in the N10-009 exam under Objective 5.2 (Given a scenario, troubleshoot common network problems). Duplex mismatches cause severe performance degradation, including high error rates and connectivity drops, and are responsible for approximately 5–10% of exam questions on troubleshooting. Mastering this topic will help you identify the symptoms, understand the underlying Ethernet mechanisms, and apply systematic resolution steps that the exam explicitly tests.
Jump to a section
Imagine two people communicating using walkie-talkies on a single frequency. One person (Device A) has a modern walkie-talkie that can both send and receive simultaneously (full-duplex). The other person (Device B) has an older model that can only either talk or listen at any given moment (half-duplex). When A speaks continuously while B is also trying to speak, B's radio cannot hear A because it is in transmit mode. B's radio then keeps pressing the push-to-talk button, waiting for a pause, but A never pauses. A hears nothing from B because B is always transmitting when A listens. Meanwhile, A assumes the channel is clear and keeps talking. This is exactly a duplex mismatch: one side assumes both can talk and listen simultaneously (full-duplex), while the other side assumes only one can talk at a time (half-duplex). The result is a catastrophic failure of communication—collisions, retransmissions, and timeouts—even though the physical connection is intact. In networking, this manifests as high CRC errors, late collisions, and extremely poor throughput, often mistaken for a cabling fault.
What is a Duplex Mismatch?
A duplex mismatch occurs when two connected Ethernet devices are configured with different duplex settings—one operating in full-duplex and the other in half-duplex. Full-duplex allows simultaneous transmission and reception on the same link, while half-duplex requires devices to take turns using CSMA/CD (Carrier Sense Multiple Access with Collision Detection). The mismatch breaks the fundamental assumptions each device makes about the link behavior, leading to collisions, frame errors, and retransmissions.
How Ethernet Duplex Works Internally
In half-duplex mode, a device must listen for carrier sense before transmitting. If the medium is busy, it defers. If two devices transmit simultaneously, a collision occurs, and both stop, wait a random backoff time (using the truncated binary exponential backoff algorithm), and retry. The collision domain includes both devices and any repeaters. The slot time (512 bit times for 10/100 Mbps Ethernet) defines the maximum round-trip delay for collision detection.
In full-duplex mode, the device uses separate transmit and receive pairs (or separate fibers) and can send and receive simultaneously. CSMA/CD is disabled because collisions cannot occur—there is no shared medium. The device transmits frames without deferring and never detects a collision. The link must be point-to-point with no repeaters or hubs.
The Mechanism of a Duplex Mismatch
Consider Device A (full-duplex) connected to Device B (half-duplex).
Device A transmits a frame to Device B. A does not sense the medium because it is full-duplex. Simultaneously, Device B may be transmitting a frame to A. Since B is half-duplex, it listens before sending. If B hears carrier from A, it defers. But if B starts transmitting just before A's frame arrives, a collision occurs on B's side. B detects the collision (because it sees its own transmission and simultaneous energy from A), stops, and sends a 32-bit jam signal. B then backs off and retries.
Device A never detects the collision because full-duplex does not monitor for collisions. A assumes the frame was successfully delivered. Meanwhile, B's frame was corrupted by the collision, so B retransmits after backoff. This pattern repeats: A keeps sending without deferring, B keeps colliding and retransmitting. The result is that B experiences many late collisions (collisions detected after the first 512 bits), which are fatal—B discards the frame without retry, leading to lost frames.
Frame Check Sequence (FCS) errors occur on B when it receives partial or overlapping frames from A. A may receive runt frames (frames shorter than 64 bytes) from B due to truncated transmissions. Both sides report CRC errors, alignment errors, and runts.
Key Symptoms and Indicators
Late collisions: Collisions occurring after the 64th byte (512 bits) of transmission. This is a definitive sign of a duplex mismatch because late collisions do not occur in properly operating half-duplex networks.
CRC errors: Frames that fail the Ethernet FCS check, caused by corrupted data from collisions or partial reception.
Runts: Frames shorter than 64 bytes, often resulting from collisions that abort transmission.
High input/output errors on the interface: Counters like input errors, CRC errors, collisions, and late collisions increase.
Very poor throughput: Effective throughput may drop to below 10% of link speed due to constant retransmissions and backoff.
Intermittent connectivity: Applications time out or experience high latency, but the link status remains up.
Common Causes of Duplex Mismatch
Auto-negotiation failure: One side is set to auto-negotiate, but the other is manually set to a specific duplex (e.g., 100/full). Auto-negotiation uses Fast Link Pulses (FLPs) to exchange capabilities. If one side does not send FLPs (because it is hard-set), the auto-negotiating side may fall back to half-duplex (the default when auto-negotiation fails). This creates a mismatch if the hard-set side is full-duplex.
Misconfiguration during network changes: An administrator hard-codes duplex on one switch port but forgets to update the other end.
Legacy or incompatible hardware: Some older NICs or switches do not support auto-negotiation or have buggy implementations.
Cable faults: Faulty cabling can cause auto-negotiation to fail, leading to a half-duplex fallback on one side while the other remains full-duplex.
Defaults and Standards
IEEE 802.3 Clause 28 defines auto-negotiation. If auto-negotiation fails, the device must default to half-duplex (10/100 Mbps) or the highest common speed with half-duplex (for gigabit, the fallback is 100 Mbps half-duplex).
For 10/100 Mbps Ethernet, the default when auto-negotiation fails is 10 Mbps half-duplex.
For 1000BASE-T (Gigabit), auto-negotiation is mandatory—there is no standard for manual configuration. However, some vendors allow manual gigabit settings, which can cause mismatches.
Verification Commands (Cisco IOS)
show interfaces [interface] – Look for Full-duplex or Half-duplex in the output, and check Input errors, CRC errors, Collisions, Late collisions.
show interfaces status – Displays duplex and speed for all ports.
show interfaces [interface] counters errors – Detailed error counters.
show interfaces [interface] | include Duplex – Quick view of duplex setting.
Example output snippet:
Router# show interfaces gigabitethernet 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 0011.2233.4455
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s
input errors 0, CRC errors 0, collisions 0, late collisions 0How Duplex Mismatch Interacts with Related Technologies
Spanning Tree Protocol (STP): STP operates independently of duplex, but a duplex mismatch can cause BPDU loss, leading to STP reconvergence or loops. For example, if a switch in half-duplex loses a BPDU due to collision, it may transition a port to forwarding prematurely.
EtherChannel: Duplex mismatch on any member link of an EtherChannel will cause the entire channel to malfunction, as the load-balancing algorithm does not account for duplex mismatches.
QoS: QoS marking and queuing are unaffected by duplex, but the retransmissions caused by a mismatch can lead to buffer overflow and tail drop, exacerbating latency.
Flow Control (IEEE 802.3x): Full-duplex links can use PAUSE frames to throttle traffic. In a mismatch, the half-duplex side does not understand PAUSE frames, so flow control fails.
Troubleshooting Steps
Identify symptoms: Check interface counters for CRC errors, late collisions, and runts. Verify throughput is low despite link speed.
Check duplex settings on both ends: Use show interfaces or equivalent on both devices. Ensure both are set to the same duplex (both full or both half). If one is auto and the other is hard-set, that is a likely cause.
Force auto-negotiation on both ends: Ideally, both sides should be set to auto-negotiate. This is the recommended best practice for all modern Ethernet links.
If manual configuration is required: Set both sides to the same manual duplex and speed. Never mix auto and manual settings.
Verify cable integrity: Use a cable tester or swap the cable to rule out faulty wiring causing auto-negotiation failure.
Monitor after change: Clear counters (clear counters [interface] on Cisco) and re-check for errors.
Identify Duplex Mismatch Symptoms
Begin by gathering data from network monitoring tools or directly from device interfaces. Look for high CRC errors, late collisions, runts, and input/output errors on one side of the link. Compare the number of collisions on each end—typically, the half-duplex side will show many collisions while the full-duplex side shows none. Also check for slow performance, timeouts, or application complaints. These symptoms often mimic a bad cable or overloaded link, but the presence of late collisions is a strong indicator of duplex mismatch.
Check Duplex Settings on Both Ends
Log into both devices (switch, router, NIC) and examine the duplex configuration. Use commands like `show interfaces` (Cisco), `ethtool eth0` (Linux), or `netsh interface ip show interfaces` (Windows). Look for the duplex mode displayed: full or half. Note any speed mismatches as well. If one side says 'Auto-negotiation' and the other shows a hard-set value (e.g., 100/full), that is a red flag. Document the settings for comparison.
Force Auto-Negotiation on Both Ends
The preferred fix is to set both ends to auto-negotiate. On Cisco switches, use `duplex auto` and `speed auto` under interface configuration. On Linux, use `ethtool -s eth0 autoneg on`. On Windows, set the NIC to 'Auto Negotiation' in the driver properties. After enabling auto-neg, verify that both sides negotiate to the same speed and duplex (typically full-duplex for modern devices). This step resolves most mismatches because auto-negotiation uses FLPs to agree on parameters.
If Auto-Negotiation Fails, Hard-Set Both Ends
If auto-negotiation is not possible due to legacy hardware or policy, manually configure both ends identically. Use the same speed and duplex (e.g., 100/full). On Cisco: `speed 100` and `duplex full`. On Linux: `ethtool -s eth0 speed 100 duplex full autoneg off`. Ensure both sides match exactly. This eliminates the mismatch but requires administrative discipline to keep consistent. Note that gigabit Ethernet requires auto-negotiation per IEEE 802.3ab; manual gigabit settings are non-standard and may cause issues.
Verify and Monitor the Link
After configuration changes, clear the interface counters to get a fresh baseline: `clear counters` on Cisco, or `ethtool -S eth0` reset on Linux. Then monitor the interface for new errors. Check that late collisions drop to zero, CRC errors stop incrementing, and throughput returns to normal. Use tools like `ping` with large packets and `iperf` to test performance. If errors persist, investigate the cable or hardware compatibility.
Scenario 1: Mismatch in a Data Center ToR Switch
A Tier 3 data center had a Top-of-Rack (ToR) switch connected to a storage array. The network engineer noticed intermittent iSCSI timeouts and slow backups. Interface counters on the ToR switch showed thousands of CRC errors and late collisions on the storage link, but the storage array reported no errors. The engineer initially suspected a bad SFP+ cable. After swapping cables without improvement, he checked duplex settings. The switch port was set to auto-negotiation, but the storage array had been manually configured to 10 Gbps full-duplex by a previous admin. Auto-negotiation failed (the storage did not send FLPs), and the switch fell back to half-duplex. The mismatch caused the storage array to transmit continuously while the switch collided. Fix: Set both ends to auto-negotiation. Problem solved, throughput returned to 900 MB/s.
Scenario 2: Legacy Hardware in a Branch Office
A branch office had a 10/100 Mbps switch connecting to an older router. Users experienced frequent drops and slow web browsing. The network admin ran show interfaces and saw high collision counts on the router end but none on the switch. The switch was auto-negotiating to 100/full, but the router (a legacy model) had a hard-set 100/half configuration. The mismatch caused the router to defer to the switch's continuous transmissions, leading to many late collisions on the router. Fix: The admin set the switch port to 100/half to match the router. Collisions dropped, and performance stabilized. Best practice would have been to upgrade the router, but hard-setting both ends was the immediate solution.
Scenario 3: Auto-Negotiation Failure Due to Cable Fault
A network engineer deployed a new server with a 1 GbE NIC connected to a managed switch. The link came up, but throughput was only 10 Mbps. Interface counters showed many FCS errors and runts on the switch port. The engineer checked duplex: switch showed 100/half, server showed 1000/full. The cable was a Cat5e patch cord that was poorly terminated. The faulty cable caused intermittent loss of FLPs, leading to auto-negotiation failure. The switch fell back to 10/half (default for failed auto-neg), while the server continued to advertise gigabit full-duplex. Fix: Re-terminated the cable, auto-negotiation succeeded, and the link ran at 1 Gbps full-duplex with zero errors. This scenario highlights that duplex mismatch can be a symptom of a physical layer problem.
N10-009 Objective 5.2: Troubleshoot common network problems specifically includes 'Duplex mismatch' as a sub-topic. The exam expects you to:
Identify symptoms: late collisions, CRC errors, runts, low throughput.
Explain the mechanism: how CSMA/CD behaves in half-duplex vs. full-duplex.
Determine the cause: auto-negotiation failure or manual misconfiguration.
Apply the fix: set both ends to auto-negotiation or both to the same manual setting.
Common Wrong Answers and Why Candidates Choose Them: 1. 'Replace the cable' – Many candidates see CRC errors and assume a physical fault. However, duplex mismatch produces CRC errors without cable issues. The key differentiator is late collisions, which do not occur with bad cabling. 2. 'Increase the MTU' – Some think jumbo frames cause errors. But jumbo frames do not cause late collisions or duplex mismatches. 3. 'Disable auto-negotiation on both ends' – While this can fix the mismatch, the exam often tests that auto-negotiation is the preferred solution. Disabling auto-negotiation is a workaround, not a best practice. 4. 'Check for speed mismatch' – Speed mismatch causes link failure or errors, but duplex mismatch can occur even if speeds match (e.g., both at 100 Mbps but one full, one half).
Specific Numbers and Values: - Default fallback when auto-negotiation fails: 10 Mbps half-duplex for 10/100 Ethernet. - Late collision definition: collision detected after the 64th byte (512 bit times). - Slot time: 512 bit times for 10/100 Mbps Ethernet. - Jam signal: 32 bits transmitted after collision detection.
Edge Cases: - Gigabit Ethernet (1000BASE-T) requires auto-negotiation. Manual gigabit settings are not standardized; if used, they can cause mismatches that behave differently. - Some older switches implement 'auto-negotiation' but only advertise half-duplex capabilities, leading to a mismatch if the other side expects full-duplex. - Flow control (PAUSE frames) is only valid on full-duplex links. In a mismatch, the half-duplex side ignores PAUSE, causing buffer overflow on the full-duplex side.
How to Eliminate Wrong Answers: - If the question mentions 'late collisions', the answer must involve duplex mismatch, not cabling. - If both sides show 'up/up' but throughput is poor, suspect duplex mismatch before cabling. - If the question says 'auto-negotiation is enabled on both ends', the mismatch is still possible if one side fails to negotiate (e.g., due to faulty cable). - Always choose the answer that sets both sides to auto-negotiate (if possible) or both to the same manual setting.
Duplex mismatch occurs when one device operates in full-duplex and the other in half-duplex.
Symptoms include late collisions, CRC errors, runts, and very low throughput despite link being up.
Auto-negotiation failure is the primary cause; default fallback is 10 Mbps half-duplex.
Late collisions are the definitive indicator—they only occur in duplex mismatch or excessive cable length.
The fix is to set both ends to auto-negotiate or both to the same manual setting.
Gigabit Ethernet requires auto-negotiation; manual gigabit settings are non-standard.
Always verify duplex settings on both ends of the link when troubleshooting poor performance.
These come up on the exam all the time. Here's how to tell them apart.
Auto-Negotiation
Uses Fast Link Pulses (FLPs) to exchange capabilities automatically.
Defaults to half-duplex if negotiation fails (IEEE 802.3).
Preferred best practice for all modern Ethernet links.
Can be affected by faulty cables that disrupt FLPs.
Supports speed and duplex advertisement and negotiation.
Manual Configuration
Requires administrator to set speed and duplex on both ends.
No fallback mechanism; if set incorrectly, mismatch occurs.
Useful for legacy devices that do not support auto-negotiation.
Eliminates negotiation time, but risks human error.
Not supported for Gigabit Ethernet (1000BASE-T) per IEEE standard.
Mistake
Duplex mismatch only occurs when one side is set to half and the other to full.
Correct
While that is the classic case, a mismatch can also occur if both sides are set to auto-negotiation but one fails to negotiate correctly due to a faulty cable, resulting in one side falling back to half-duplex while the other remains full-duplex.
Mistake
CRC errors always indicate a bad cable.
Correct
CRC errors can be caused by duplex mismatch, faulty transceivers, electromagnetic interference, or even a mismatch in speed (e.g., one side at 100 Mbps and the other at 10 Mbps). Duplex mismatch should be ruled out before replacing cables.
Mistake
Late collisions are normal in a busy network.
Correct
Late collisions are never normal in a properly functioning Ethernet network. They indicate a duplex mismatch or an excessively long cable length (exceeding the collision domain diameter). In half-duplex, collisions should only occur within the first 512 bit times; any later is a late collision.
Mistake
Setting both ends to full-duplex manually is better than using auto-negotiation.
Correct
Auto-negotiation is the IEEE standard and is generally more reliable because it automatically adapts to changes and ensures both ends agree. Manual configuration can lead to mismatches if not consistently applied. The exam favors auto-negotiation as the best practice.
Mistake
A duplex mismatch will cause the link to go down.
Correct
The link will remain up (both line protocol and physical layer show up), but the link will have high error rates and poor performance. This is why it is often overlooked—administrators assume the link is healthy because it is 'up'.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A collision occurs when two devices transmit simultaneously within the first 512 bit times (64 bytes) of a frame. In half-duplex, devices detect collisions early and retransmit. A late collision occurs after the 512th bit time, meaning the frame is already being transmitted beyond the slot time. Late collisions are fatal—the device does not retransmit the frame, resulting in lost data. Late collisions are a hallmark of duplex mismatch because the full-duplex device transmits without deferring, causing collisions to occur late on the half-duplex side.
CRC errors occur when the frame's integrity is compromised. In a duplex mismatch, the half-duplex device may receive a frame that is partially overwritten by a collision, or it may receive a truncated runt frame. The frame's FCS will not match the computed checksum, resulting in a CRC error. The full-duplex side may also receive corrupted frames if the half-duplex device transmits a jam signal or truncated frame. Thus, both sides can report CRC errors.
Yes, if auto-negotiation fails on one end due to a faulty cable or hardware issue. For example, if a cable is damaged, FLPs may not be received correctly, causing one side to fall back to half-duplex while the other side remains full-duplex (if it had previously negotiated or is set to full). This is why it is important to check the actual negotiated duplex, not just the configured mode.
Check the interface error counters first. If you see late collisions, it is almost certainly a duplex mismatch. If you see only CRC errors and no late collisions, it could be a cable fault, but duplex mismatch is still possible. The most efficient approach is to verify duplex settings on both ends before swapping cables, as duplex mismatch is easier to fix.
On Cisco devices, use the command `clear counters [interface]` in privileged EXEC mode. On Linux, use `ethtool -S eth0` to reset statistics (some drivers reset on read). On Windows, you may need to disable and re-enable the NIC. After clearing, monitor the counters for new errors. If the fix is correct, late collisions and CRC errors should remain at zero.
If both ends are set to half-duplex, the link will work correctly, but performance will be limited to half-duplex operation (CSMA/CD active, no simultaneous send/receive). This is acceptable for legacy devices but inefficient compared to full-duplex. The exam expects you to know that full-duplex is preferred for point-to-point links.
Yes. Fiber optic Ethernet (100BASE-FX, 1000BASE-LX, etc.) also uses duplex settings. A mismatch can occur if one transceiver is configured for full-duplex and the other for half-duplex. Symptoms are similar: CRC errors, late collisions (if half-duplex), and poor throughput. Auto-negotiation is less common on some fiber standards (e.g., 100BASE-FX often uses manual settings), so mismatches are more likely.
You've just covered Duplex Mismatch Troubleshooting — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?