CCNA Network Infrastructure and Connectivity Practice Question
Exhibit
R1# show interfaces GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is ISR4321-2x1GE, address is aabb.cc00.0100 (bia aabb.cc00.0100)
Internet address is 192.168.1.1/30
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, media type is RJ45
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 00:01:23
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 1000 bits/sec, 2 packets/sec
5 minute output rate 1000 bits/sec, 2 packets/sec
512 packets input, 51200 bytes, 0 no buffer
Received 512 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
150 input errors, 150 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
512 packets output, 51200 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 outYou are connected to R1. The link between R1 and R2 is experiencing intermittent connectivity and poor performance. Review the provided show interface output to identify the root cause(s) of the issue, then apply the necessary configuration changes to resolve the problem and restore full connectivity.
Output from R1: ``` GigabitEthernet0/0 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is aaaa.bbbb.cccc (bia aaaa.bbbb.cccc) Internet address is 192.168.1.1/30 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec) Half-duplex, 100Mb/s, link type is auto, media type is RJ45 output flow-control is unsupported, input flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:01, output 00:00:01, output hang never Last clearing of "show interface" counters 00:01:23 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 150 packets input, 1500 bytes, 0 no buffer Received 0 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 150 input errors, 150 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 200 packets output, 2000 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out ```
⚠ Common exam trap
CRC errors on a link are often misinterpreted as faulty cabling, but the presence of CRC errors on an interface that is up/up but operating at a mismatched speed or duplex strongly indicates a configuration mismatch between the two ends.
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 'speed 1000' and 'duplex full' to match R2's settings, then clear counters.
The show interface output reveals that R1's GigabitEthernet0/0 is operating at half-duplex, 100 Mb/s, yet it is accumulating a high number of CRC errors (150 in 1 minute 23 seconds). This indicates a speed/duplex mismatch with R2, which is likely set to full-duplex at 1000 Mb/s. To resolve, you must manually configure R1 to match R2's proper settings by issuing the 'speed 1000' and 'duplex full' commands, then clearing the counters to start fresh monitoring. The other options are incorrect because they do not address the mismatch: replacing the cable would not fix a configuration issue; disabling autonegotiation alone may not fix the mismatch if the hard-coded values are still wrong; and increasing the MTU does not affect CRC errors caused by duplex mismatch.
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 'speed 1000' and 'duplex full' to match R2's settings, then clear counters.
Why this is correct
The interface's CRC errors, combined with a full-duplex status on R1, strongly indicate a duplex mismatch—R2 is likely operating at half-duplex. Manually configuring 'speed 1000' and 'duplex full' removes any ambiguity from autonegotiation and forces both sides to identical physical parameters, which eliminates the late collisions and FCS failures that generate CRC errors. Clearing the counters afterward is essential to confirm that no new CRC errors appear after the change.
- ✗
Replace the faulty cable between R1 and R2 to eliminate CRC errors caused by physical layer issues.
Why it's wrong here
Although a faulty cable can produce CRC/alignment errors, the symptoms described—errors on a full-duplex interface while the remote side runs half-duplex—point to a duplex mismatch, not a physical medium failure. Replacing the cable would not change R2's duplex setting, so the out-of-window collisions and dribble-frame errors would persist. A damaged cable more typically causes input errors, discards, or link flaps, not the specific pattern seen with mismatch.
- ✗
Disable autonegotiation on the interface with 'no negotiation auto' to force the link to use the configured speed and duplex.
Why it's wrong here
Using 'no negotiation auto' only prevents the exchange of negotiation frames; the interface will then operate using whatever speed and duplex values are already configured or default to, which may still be inconsistent with R2. If R2 is left on autonegotiation (or has different forced settings), the mismatch remains, so CRC errors continue. To truly fix the issue, you must explicitly configure both speed and duplex to match, not just disable autonegotiation.
- ✗
Increase the interface MTU to reduce fragmentation and improve performance on the link.
Why it's wrong here
CRC errors occur at Layer 1/2 in the Ethernet frame's FCS, calculated over bits received from the wire, and are unrelated to the MTU, which is a Layer 3 payload-size parameter. Changing the MTU alters fragmentation and maximum frame size but does not affect signal timing, duplex negotiation, or bit-level corruption. In fact, increasing MTU on a mismatched link can produce more giants/overruns, making the problem worse rather than resolving it.
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 'speed 1000' and 'duplex full' to match R2's settings, then clear counters.Correct answer▾
Why this is correct
The interface's CRC errors, combined with a full-duplex status on R1, strongly indicate a duplex mismatch—R2 is likely operating at half-duplex. Manually configuring 'speed 1000' and 'duplex full' removes any ambiguity from autonegotiation and forces both sides to identical physical parameters, which eliminates the late collisions and FCS failures that generate CRC errors. Clearing the counters afterward is essential to confirm that no new CRC errors appear after the change.
✗Replace the faulty cable between R1 and R2 to eliminate CRC errors caused by physical layer issues.Wrong answer — click to see why▾
Why this is wrong here
The specific factual error is that CRC errors are primarily a duplex mismatch symptom, not a cable fault, especially when the interface is up and errors appear quickly.
Why candidates choose this
Candidates pick this because CRC errors can be caused by bad cabling, but the context of intermittent performance and full-duplex setting points to mismatch.
✗Disable autonegotiation on the interface with 'no negotiation auto' to force the link to use the configured speed and duplex.Wrong answer — click to see why▾
Why this is wrong here
The specific factual error is that disabling autonegotiation without setting speed/duplex can cause further mismatch or link failure.
Why candidates choose this
Candidates pick this because they know autonegotiation can cause issues, but they forget that manual configuration of both parameters is required.
✗Increase the interface MTU to reduce fragmentation and improve performance on the link.Wrong answer — click to see why▾
Why this is wrong here
The specific factual error is that MTU affects fragmentation and throughput, not error rates from duplex mismatch.
Why candidates choose this
Candidates pick this because they confuse performance issues with error causes, thinking larger MTU reduces overhead.
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
IPv4 Addressing and Address Classes
Key term
Frame
A frame is a unit of data at the Data Link layer of networking, containing header, payload, and trailer information for local network delivery.
Key term
Encapsulation
Encapsulation is the process of wrapping data with protocol headers and trailers before sending it across a network.
About these practice questions
One of 1,389 original 200-301 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.