Question 1,530 of 1,389
CRC Errors at Gigabit — Duplex Mismatch vs Auto-Negotiation
Network Topology
You are connected to R1 via the console. The link between R1 and R2 is experiencing intermittent connectivity. A 'show interfaces GigabitEthernet0/0' output shows the interface is up/up, line protocol up, Full-duplex, 1000Mb/s, but there are 1234 input errors, including 567 CRC errors. Identify the root cause of the issue, and apply the necessary configuration fix to restore full connectivity.
Quick Answer
The correct answer is to configure the interface with 'duplex auto' and 'speed auto'. This resolves the CRC errors because, on a GigabitEthernet link operating at 1000 Mb/s, half-duplex is not supported by the 1000BASE-T standard, so a traditional duplex mismatch is impossible; instead, the high CRC errors indicate a negotiation mismatch where one side is using forced settings while the other is set to auto-negotiation, causing physical-layer instability and frame corruption. On the CCNA 200-301 v2 exam, this scenario tests your understanding that auto-negotiation is mandatory for Gigabit Ethernet to establish a stable link, and a common trap is assuming "full-duplex" and "1000 Mb/s" in the show output means the link is healthy—when in fact, forced settings can still show those values while generating errors. A key memory tip: at Gigabit, always trust auto, never force—if you see CRC errors on a 1000BASE-T link, the fix is to let both sides negotiate.
⚠ Common exam trap
Do not assume that high CRC errors on a GigabitEthernet link indicate a duplex mismatch; at 1000 Mbps, half-duplex is not supported, so look for mismatched forced versus auto-negotiation settings instead.
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
✓
Configure the interface with 'duplex auto' and 'speed auto'.
The output indicates high CRC errors on a GigabitEthernet interface operating at 1000 Mb/s and full-duplex. Since 1000BASE-T does not support half-duplex, a duplex mismatch is not possible. The CRC errors likely result from a speed or duplex negotiation mismatch where one side uses forced settings (e.g., speed 1000 duplex full) and the other uses auto-negotiation, causing physical layer instability. Setting both sides to auto-negotiation ('duplex auto' and 'speed auto') allows them to properly agree on the highest common speed and duplex, resolving the errors. Option A forces full and 1000, which may not match R2 if it is set to auto, so it is not a reliable fix. Option B uses 'duplex half', which is invalid on Gigabit links and would break connectivity. Option C's 'no shutdown' is irrelevant because the interface is already administratively up.
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 with 'duplex full' and 'speed 1000'.
Why it's wrong here
This is incorrect because forcing full-duplex and 1000 Mbps on R1 does not resolve the mismatch if R2 is set to half-duplex. The mismatch persists, causing continued CRC errors.
- ✗
Configure the interface with 'duplex half' and 'speed 100'.
Why it's wrong here
This is incorrect because reducing speed and setting half-duplex may reduce errors but does not address the root cause of duplex mismatch. It also degrades performance unnecessarily.
- ✗
Configure the interface with 'no shutdown' to re-enable the interface.
Why it's wrong here
This is incorrect because the interface is already up/up (as indicated by 'Full-duplex, 1000Mb/s'), so 'no shutdown' is unnecessary and does not fix the duplex mismatch.
- ✓
Configure the interface with 'duplex auto' and 'speed auto'.
Why this is correct
This is correct because enabling auto-negotiation on R1 allows both sides to negotiate a common duplex setting. Since R2 is likely set to half-duplex, auto-negotiation will result in half-duplex on both ends, eliminating the mismatch and CRC errors.
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.
✓Configure the interface with 'duplex auto' and 'speed auto'.Correct answer▾
Why this is correct
This is correct because enabling auto-negotiation on R1 allows both sides to negotiate a common duplex setting. Since R2 is likely set to half-duplex, auto-negotiation will result in half-duplex on both ends, eliminating the mismatch and CRC errors.
✗Configure the interface with 'duplex full' and 'speed 1000'.Wrong answer — click to see why▾
Why this is wrong here
Forcing the same settings on R1 does not change R2's configuration; the duplex mismatch remains.
Why candidates choose this
Candidates see the interface is already full-duplex/1000 and think forcing it will stabilize the link, but they overlook the need for matching settings on both ends.
✗Configure the interface with 'duplex half' and 'speed 100'.Wrong answer — click to see why▾
Why this is wrong here
Slowing down the link is a workaround, not a fix; the mismatch still exists if R2 is half-duplex at 1000 Mbps.
Why candidates choose this
Candidates think lowering speed can eliminate CRC errors, but the real issue is duplex mismatch, not speed.
✗Configure the interface with 'no shutdown' to re-enable the interface.Wrong answer — click to see why▾
Why this is wrong here
The interface is administratively up; the issue is physical layer errors, not administrative state.
Why candidates choose this
Candidates sometimes assume intermittent connectivity means the interface is down, but the output shows it is up.
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
Quick reference
OSI Model Reference
| Layer | Name | PDU | Key Protocols / Devices |
|---|---|---|---|
| 7 | Application | Data | HTTP, HTTPS, DNS, SMTP, FTP, SSH |
| 6 | Presentation | Data | TLS / SSL, JPEG, ASCII encoding |
| 5 | Session | Data | NetBIOS, RPC, SIP |
| 4 | Transport | Segment / Datagram | TCP, UDP |
| 3 | Network | Packet | IP, ICMP, OSPF — Routers |
| 2 | Data Link | Frame | Ethernet, Wi-Fi, PPP — Switches, Bridges |
| 1 | Physical | Bits | Cables, NICs, Hubs, Repeaters |
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 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.
Variation 3. A 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?
hard- A.Configure the interface on SW2 to use a different MTU value.
- ✓ B.Ensure both switches are configured for the same duplex setting, preferably by enabling autonegotiation on both interfaces.
- C.Replace the Ethernet cable connecting SW1 and SW2.
- D.Check for late collisions on the interface and increase the collision window size.
Why B: 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).
Last reviewed: Jun 6, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.