CRC Errors at Gigabit — Duplex Mismatch vs Auto-Negotiation
Exhibit
SW1# show interfaces gigabitethernet 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is Gigabit Ethernet, address is aaaa.bbbb.cccc (bia aaaa.bbbb.cccc)
Description: Link to SW2
Internet address is 10.10.10.1/30
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 2000 bits/sec, 2 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
12345 packets input, 1234567 bytes
Received 1234 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 56789 multicast, 0 pause input
0 input packets with dribble condition detected
23456 packets output, 2345678 bytes, 0 underruns
0 output errors, 0 collisions, 1 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 outA network technician is troubleshooting a connectivity issue between two directly connected switches, SW1 and SW2. Hosts on VLAN 10 connected to SW1 can ping each other but cannot ping the default gateway or any host on VLAN 10 connected to SW2. The interface on SW1 is up/up, but the interface on SW2 is up/down. What is the most likely cause of the problem?
⚠ Common exam trap
Cisco often tests the distinction between up/down (Layer 1 issue like duplex mismatch) and down/down (cable or power issue) to trap candidates who assume any interface problem is a bad cable.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Ensure both switches are configured for the same duplex setting, preferably by enabling autonegotiation on both interfaces.
The interface on SW2 is up/down, which typically indicates a Layer 1 issue such as a duplex mismatch. Duplex mismatch occurs when one switch is manually set to full duplex and the other to half duplex or auto-negotiation fails, causing the side expecting full duplex to report up/down due to excessive errors. Option A is incorrect because MTU mismatch would cause connectivity issues but not an up/down interface state. Option C is incorrect because a faulty cable would likely cause both interfaces to be down/down, not up/down. Option D is incorrect because late collisions are a symptom of duplex mismatch, not a separate cause; increasing collision window size is not a standard troubleshooting step. The correct solution is to ensure both switches use the same duplex setting, preferably via autonegotiation (IEEE 802.3u).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure the interface on SW2 to use a different MTU value.
Why it's wrong here
Altering the MTU value on SW2 would affect Layer 3 packet handling (e.g., fragmentation thresholds) and would not change the physical or data-link layer state of an Ethernet interface. The line protocol status (up/down) is determined by Layer 1/2 factors such as carrier detection, duplex negotiation, and keepalive messaging; an MTU mismatch might cause large-frame drops or performance issues but would not force an interface to show down. In fact, even if an MTU mismatch were present, the interface would remain in an up/up state, so this command cannot resolve the reported symptom.
- ✓
Ensure both switches are configured for the same duplex setting, preferably by enabling autonegotiation on both interfaces.
Why this is correct
The output from SW1 shows the interface is full-duplex, but SW2's interface is up/down. This is a classic symptom of a duplex mismatch, where one side is full and the other half-duplex. Configuring both ends to the same duplex (or enabling autonegotiation) will resolve the issue.
- ✗
Replace the Ethernet cable connecting SW1 and SW2.
Why it's wrong here
A defective Ethernet cable would typically produce a loss of link on both switches simultaneously, resulting in both interfaces displaying down/down, or cause intermittent flapping on both ends if the fault is marginal. Here, SW1's interface is operational (full-duplex) while SW2 shows up/down, which is a one-sided condition that a physical cable fault does not create. A cable problem cannot selectively disable one side while leaving the other fully functional, so replacing the cable is irrelevant to correcting a duplex mismatch.
- ✗
Check for late collisions on the interface and increase the collision window size.
Why it's wrong here
Late collisions can be a symptom of a duplex mismatch, but the show output indicates 0 late collisions. Increasing collision window size is not a standard fix and would not address the underlying configuration mismatch.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓Ensure both switches are configured for the same duplex setting, preferably by enabling autonegotiation on both interfaces.Correct answer▾
Why this is correct
The output from SW1 shows the interface is full-duplex, but SW2's interface is up/down. This is a classic symptom of a duplex mismatch, where one side is full and the other half-duplex. Configuring both ends to the same duplex (or enabling autonegotiation) will resolve the issue.
✗Configure the interface on SW2 to use a different MTU value.Wrong answer — click to see why▾
Why this is wrong here
Changing MTU will not fix the duplex mismatch causing the interface to be up/down.
✗Replace the Ethernet cable connecting SW1 and SW2.Wrong answer — click to see why▾
Why this is wrong here
Cable issues usually affect both interfaces similarly, not causing a duplex mismatch scenario.
✗Check for late collisions on the interface and increase the collision window size.Wrong answer — click to see why▾
Why this is wrong here
The absence of late collisions in the output suggests this is not the immediate issue, and adjusting collision windows is not a recommended solution.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Go deeper
Related to this question
Learn chapter
IOS Upgrade Step-by-Step Process
Key term
Default gateway
A default gateway is a network device, typically a router, that acts as the exit point for traffic from a local network to other networks, including the internet.
Key term
VLAN
A VLAN (Virtual Local Area Network) is a logical grouping of network devices that behave as if they are on the same physical network segment, regardless of their actual physical location.
About these practice questions
Courseiva writes every 200-301 question from scratch — 1,450 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on 200-301
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are connected to R1. The network team reports intermittent connectivity between R1 and R2. Examine the following `show interface` output from R1 to identify the root cause of the issue. Then apply the necessary configuration commands on R1 to resolve the problem. GigabitEthernet0/0 is up, line protocol is up Internet address is 10.0.0.1/30 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 RJ45 output flow-control is unsupported, input flow-control is unsupported Last input 00:00:01, output 00:00:01, 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 100 packets input, 8000 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 100 input errors, 100 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out
hard- ✓ A.Enter interface configuration mode for the problematic interface and issue the 'no speed' and 'no duplex' commands to revert to auto-negotiation.
- B.Enter interface configuration mode and issue the 'speed 100' and 'duplex full' commands to ensure both sides are set to the same values.
- C.Enter interface configuration mode and issue the 'no shutdown' command to bring the interface up.
- D.Enter interface configuration mode and issue the 'duplex half' command to match the remote side's duplex setting.
Why A: The show interface output reveals 100 CRC errors and 100 input errors, indicating a physical layer problem. Additionally, the interface is manually configured for full-duplex and 100 Mb/s. CRC errors often point to a duplex mismatch or faulty cable. Since R1 is set to full-duplex, if R2 is set to auto-negotiation (or half-duplex), a mismatch occurs. The fix is to set both sides to auto-negotiation by removing manual speed and duplex settings. On R1, enter interface configuration mode and issue 'no speed' and 'no duplex' to revert to auto-negotiation, then verify with 'show interfaces' that the interface negotiates to full-duplex and errors stop incrementing.
Variation 2. You are connected to R1. The link between R1's GigabitEthernet0/0 and R2's GigabitEthernet0/0 should operate at 1 Gbps full duplex, but the interface is showing errors and only negotiating at 100 Mbps half duplex. Diagnose and fix the fault, then verify the link is stable at the correct speed and duplex.
hard- ✓ A.Remove the manual speed and duplex settings on R1's GigabitEthernet0/0 with 'no speed' and 'no duplex' to allow auto-negotiation.
- B.Change the duplex setting to 'full' and speed to '1000' on R1's GigabitEthernet0/0.
- C.Replace the cable between R1 and R2 with a crossover cable.
- D.Configure R2's GigabitEthernet0/0 with 'speed 100' and 'duplex half' to match R1's settings.
Why A: The interface was manually configured with 'duplex half' and 'speed 100', which forced the link to 100 Mbps half duplex, causing CRC errors due to duplex mismatch. The correct fix is to remove these manual settings and allow auto-negotiation, or explicitly set both sides to 'speed 1000' and 'duplex full'. Since the remote side (R2) is set to auto (default), the simplest correction is to use 'no duplex' and 'no speed' on R1 to re-enable auto-negotiation. After the commands are applied, the interface should show 'Full-duplex, 1000Mb/s' and CRC errors should stop incrementing.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.