Examkin

Interface and Cable Troubleshooting Issues

29 questions

All types29Multiple choice15Multiple select5Matching9
Question 1Question →

Match each Cisco IOS interface status or error counter symptom to its corresponding physical or data-link troubleshooting root cause.

Click a left item, then click its matching right item

Items

High number of late collisions recorded on a half-duplex configured interface
High number of CRC / FCS error counters increasing on the interface
Interface state shows 'GigabitEthernet0/1 is up, line protocol is down'
Interface state shows 'FastEthernet0/1 is administratively down, line protocol is down'

Matches

Show answer & explanation

Answer

Late collisions match duplex mismatch; CRC errors match physical cable corruption or noise; Interface up / line protocol down matches Layer 2 encapsulation mismatch; Interface administratively down matches the interface being disabled with the shutdown command.
Matching interface symptoms correctly pairs late collisions with duplex mismatches, CRC error increments with physical cabling damage or electrical noise, 'up/down' status with Layer 2 framing/encapsulation issues, and 'administratively down' status with the interface shutdown configuration command.

Step-by-Step Solution

1
Examine the Layer 1 physical symptoms and Cisco IOS interface counters.
Differentiate between physical layer errors (CRC, late collisions), interface operational states (up/down), and administrative states (administratively down).
Each Cisco IOS interface statistic isolates specific Layer 1 or Layer 2 network faults.
2
Map each interface symptom to its underlying root cause.
Pair late collisions with duplex mismatch, CRC errors with cable/interference issues, up/down line protocol with encapsulation/keepalive failures, and administratively down with the shutdown command.
Accurate pairing ensures effective troubleshooting of physical and data link layer issues.

Key Concept

Cisco IOS Interface Troubleshooting and Diagnostics
Question 2Question →

Match each Cisco IOS interface status or error symptom on the left to its most probable underlying root cause on the right.

Click a left item, then click its matching right item

Items

Interface is down, line protocol is down
Interface is up, line protocol is down
Interface is administratively down, line protocol is down
Interface is up, line protocol is up (with rapidly incrementing late collisions)

Matches

Show answer & explanation

Answer

Interface down/down matches physical Layer 1 failure; Interface up/down matches Layer 2 encapsulation or keepalive failure; Interface administratively down matches manual shutdown command; Interface up/up with late collisions matches duplex mismatch.
Interface diagnostic states directly correlate with specific OSI layers and configurations: physical cable disconnects cause 'down/down'; Layer 2 framing errors cause 'up/down'; the 'shutdown' command displays 'administratively down'; and late collisions on an active link indicate a duplex mismatch.

Step-by-Step Solution

1
Analyze 'Interface is down, line protocol is down'.
Identified physical Layer 1 signal loss.
When electrical/optical carrier signal is missing due to a disconnected or broken cable, both status and line protocol report down.
2
Analyze 'Interface is up, line protocol is down'.
Identified Layer 2 protocol/framing failure.
Physical carrier (Layer 1) is detected, but Data Link layer communication failed due to mismatched encapsulation or lost keepalives.
3
Analyze 'Interface is administratively down, line protocol is down'.
Identified manual administrative disablement.
This explicit status string appears only when an administrator applies the 'shutdown' configuration command.
4
Analyze 'Interface is up, line protocol is up (with rapidly incrementing late collisions)'.
Identified duplex mismatch error pattern.
Late collisions occur when an interface set to half-duplex transmits while a full-duplex remote end transmits without checking for collisions past the slot time window.

Key Concept

Cisco IOS Interface Status Diagnostics and Troubleshooting
Question 3Question →

An engineer is troubleshooting a degraded Ethernet connection on switch interface `FastEthernet0/8` connected to an end host. The interface output reveals high numbers of `late collisions` and `deferred` frames, while `input errors` remain at zero:

text
FastEthernet0/8 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000c.ce6b.a108
Full-duplex, 100Mb/s, media type is 100BaseTX
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 buffer
3842 late collisions, 1045 deferred, 0 lost carrier

Which TWO physical or data-link conditions are the most probable causes of these output statistics? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: A duplex mismatch where the switch port is forced to full-duplex and the connected device is operating in half-duplex; The copper cable segment length exceeds the maximum 100-meter limit defined by Ethernet standards

Answer

The most probable causes are a duplex mismatch where one side operates in full-duplex while the other operates in half-duplex, and an Ethernet copper cable run that exceeds the 100-meter maximum length specification.
Late collisions occur when a device detects a collision after transmitting the first 64 bytes of an Ethernet frame. The two primary causes are a duplex mismatch (where one end operates in full-duplex while the other operates in half-duplex, causing the half-duplex end to detect late collisions) and an over-length cable run (where cable propagation delay exceeds the slot time of 512 bit times).

Step-by-Step Solution

1
Analyze the interface statistics provided in the CLI output
Identified high numbers of late collisions (3842) and deferred frames (1045), with zero CRC or input errors.
Late collisions occur when a collision is detected after the first 64 bytes (512 bits) of a frame have been transmitted.
2
Evaluate potential causes of late collisions on Ethernet links
Duplex mismatches (full-duplex on switch, half-duplex on host) cause the half-duplex host to detect full-duplex transmissions as late collisions. Excessively long cable runs (>100m) delay collision detection past the 64-byte window.
Late collisions are exclusively associated with timing issues on half-duplex collision domains or duplex mismatches.
3
Eliminate invalid options based on Layer 1/Layer 2 symptom profiles
Native VLAN mismatches affect traffic routing/tagging across trunks rather than interface collision counters. Cable pinout mismatches without Auto-MDIX cause the link status to remain down/down.
Physical cabling pinout errors prevent link layer synchronization entirely.

Key Concept

Late Collision and Duplex Mismatch Troubleshooting
Question 4Question →

A network engineer is troubleshooting performance degradation on a link between Switch-A and Switch-B. The engineer executes the command `show interfaces fastEthernet 0/1` on Switch-A and observes the following CLI output:

text
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0007.eb78.8901 (bia 0007.eb78.8901)
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 100BaseTX
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
5 minute input rate 12000 bits/sec, 15 packets/sec
5 minute output rate 15000 bits/sec, 18 packets/sec
482910 packets input, 54910284 bytes, 0 no buffer
0 runts, 0 giants, 0 throttles
8942 input errors, 8942 CRC, 0 frame, 0 overrun, 0 ignored
512049 packets output, 61029481 bytes, 0 underruns
0 output errors, 0 collisions, 0 late collision, 0 deferred

Meanwhile, the connected interface on Switch-B reports `Half-duplex, 100Mb/s` and shows a rapidly incrementing counter for late collisions and deferred transmissions. Which of the following is the root cause of this troubleshooting issue?

Show answer & explanation

Answer: Switch-A is manually configured for full duplex while Switch-B relies on auto-negotiation, forcing Switch-B to default to half duplex.

Answer

Switch-A is manually configured for full duplex while Switch-B relies on auto-negotiation, forcing Switch-B to default to half duplex.
The correct answer identifies a classic duplex mismatch scenario. When Switch-A is manually set to full duplex, it stops participating in auto-negotiation. Switch-B, left on auto-negotiation, can sense the 100 Mbps link speed via fast link pulses (FLP) but cannot negotiate the duplex setting. Following IEEE rules, Switch-B falls back to half duplex. Switch-A transmits whenever it has data, while Switch-B attempts CSMA/CD. This causes Switch-B to see late collisions and Switch-A to record CRC input errors.

Step-by-Step Solution

1
Analyze the interface output on Switch-A
Switch-A is operating at Full-duplex 100Mb/s, has 0 collisions/late collisions recorded, but shows a high number of input errors and CRC errors.
Full-duplex interfaces do not perform carrier sense multiple access with collision detection (CSMA/CD), so they never register collisions. However, incoming frames from a half-duplex partner transmitting during local transmissions will be truncated or corrupted, resulting in CRC errors.
2
Analyze the counter symptoms on Switch-B
Switch-B operates at Half-duplex and increments late collisions and deferred packets.
Because Switch-B is in half-duplex mode, it uses CSMA/CD. When Switch-A transmits continuously in full duplex, Switch-B detects collisions past the 64-byte slot time (late collisions).
3
Determine the cause of the duplex asymmetry
Disabling auto-negotiation on one end (hardcoding Switch-A to Full) causes the auto-negotiating peer (Switch-B) to fall back to the standard default of Half-duplex.
Cisco and IEEE 802.3 standards require auto-negotiation on both ends or manual configuration on both ends. Mixing hardcoded settings with auto-negotiation results in a duplex mismatch.

Key Concept

Ethernet Auto-Negotiation and Duplex Mismatch Troubleshooting
Question 5Question →

Refer to the following Cisco IOS CLI output from a switch interface:

text
Switch# show interfaces gigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up (connected)
Hardware is GigabitEthernet, address is 0007.7d04.1a01
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)
Half-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:01, 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 12000 bits/sec, 15 packets/sec
5 minute output rate 45000 bits/sec, 32 packets/sec
41205 packets input, 5142091 bytes, 0 no buffer
Received 104 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
58912 packets output, 7120491 bytes, 0 underruns
3412 output errors, 3290 late collisions, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output

Based on the output, which condition is the most probable cause of the accumulated interface errors?

Show answer & explanation

Answer: The local interface is operating in half-duplex mode while the connected neighbor is hardcoded for full-duplex mode.

Answer

The local interface is operating in half-duplex mode while the connected neighbor is hardcoded for full-duplex mode.
The combination of an 'up/up' link status, half-duplex local operational mode, and high late collision counts specifically indicates a duplex mismatch. When the remote device is manually set to full-duplex, auto-negotiation on the local device fails to detect duplex and falls back to half-duplex. As the full-duplex neighbor transmits at will without checking carrier sense, it interrupts ongoing local transmissions after the 64-byte collision window, causing late collisions to increment on the half-duplex side.

Step-by-Step Solution

1
Analyze line status and line protocol state.
Interface status is 'up' and line protocol is 'up', confirming physical Layer 1 connectivity and Layer 2 framing operational state.
This rules out physical disconnection or complete cable pinout failures.
2
Examine operating duplex settings and interface error counters.
The interface operates at 'Half-duplex, 100Mb/s' and shows significant 'late collisions' (3,290) and 'output errors' (3,412), but 0 CRC/input errors.
Late collisions occur when a collision is detected after the first 64 bytes (512 bits) of a frame have been transmitted.
3
Correlate symptoms with duplex operation mechanics.
Late collisions on a half-duplex interface are a textbook symptom of a duplex mismatch, occurring because the remote full-duplex node transmits while the local half-duplex node is midway through sending a frame.
In auto-negotiation fallback, if one side is set manually to full-duplex, the auto-negotiating side defaults to half-duplex, creating this exact symptom pattern.

Key Concept

Duplex Mismatch Identification via Interface Counters
Estimated Time:2m 0s
Question 6Question →

A network engineer is troubleshooting various network interface issues on Cisco switches and routers. Match each interface status or error counter symptom on the left with its most likely physical or data-link layer root cause on the right.

Click a left item, then click its matching right item

Items

Interface status is down, line protocol is down
Interface status is up, line protocol is down
Interface status is up, line protocol is up, with rapidly incrementing late collisions
Interface status is up, line protocol is up, with rapidly incrementing giants and jabber errors

Matches

Show answer & explanation

Answer

The interface symptoms match as follows: 'down/down' corresponds to a Layer 1 physical fault; 'up/down' corresponds to a Layer 2 framing or keepalive failure; incrementing late collisions corresponds to a half-duplex/full-duplex mismatch; and incrementing giants/jabbers corresponds to oversized frames or a defective NIC.
Each status pattern and counter maps directly to standard Cisco IOS interface troubleshooting logic: Layer 1 physical link failures cause 'down/down'; Layer 2 framing/keepalive failures cause 'up/down'; half-duplex operating against full-duplex causes late collisions; and frames exceeding 1518 bytes with invalid FCS register as giants/jabber errors.

Step-by-Step Solution

1
Analyze interface states by differentiating Layer 1 (Line Status) from Layer 2 (Line Protocol).
Line status indicates physical carrier detection, whereas line protocol indicates data link layer framing and keepalive state.
A physical failure results in 'down/down', whereas a framing or encapsulation mismatch maintains physical link ('up') but drops data link signaling ('down').
2
Diagnose the cause of late collision error counters on Ethernet interfaces.
Late collisions indicate that collision detection occurred after transmitting 512 bits (64 bytes).
Because half-duplex expects collisions only during the slot time (first 64 bytes), late collisions uniquely signal that the remote peer is operating in full-duplex mode and ignoring CSMA/CD rules.
3
Evaluate framing error statistics such as giants and jabbers.
Giants represent frames larger than the standard Ethernet MTU (1518 bytes) with bad CRC, while jabbers represent invalid continuous signals.
These symptoms point directly to MTU misconfigurations or damaged Network Interface Cards (NICs) transmitting invalid frame sizes.

Key Concept

Interface Line Status Combinations and Error Counter Root Causes
Question 7Question →

A technician connects two legacy switch ports directly to each other using a standard straight-through Ethernet cable. Neither port supports Automatic Medium-Dependent Interface Crossover (Auto-MDIX). Running a status check on the local switch port yields the following CLI output:

text
FastEthernet0/1 is down, line protocol is down
Hardware is FastEthernet, address is 000d.bd2c.4a01 (bia 000d.bd2c.4a01)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set

Which physical cabling issue is the direct cause of the interface remaining in a down/down state?

Show answer & explanation

Answer: A straight-through Ethernet cable was used instead of a crossover Ethernet cable to connect two like switch devices.

Answer

Using a straight-through Ethernet cable instead of a crossover cable to connect two switch ports (like devices) without Auto-MDIX support prevents physical link establishment, resulting in a down/down interface state.
Switches are MDI-X devices that transmit on pins 3 and 6 and receive on pins 1 and 2. When connecting two switches together directly without Auto-MDIX functionality, a crossover cable must be used to map transmit pins on one switch to receive pins on the other switch. Using a straight-through cable connects transmit pins to transmit pins, resulting in no electrical link and keeping the interface state down/down.

Step-by-Step Solution

1
Analyze the CLI interface state
The interface status shows 'FastEthernet0/1 is down, line protocol is down', indicating a Layer 1 physical link failure.
When both line status and line protocol are down, the physical layer cannot detect electrical signaling or link integrity.
2
Evaluate device pinout roles and cable types
Switches use MDI-X pinouts (transmitting on pins 3/6 and receiving on pins 1/2). Connecting MDI-X to MDI-X requires a crossover cable to map transmit pins to receive pins.
Without Auto-MDIX to automatically adjust pin roles, a straight-through cable connects transmit pins directly to transmit pins, preventing link detection.

Key Concept

Ethernet cable pinouts and physical interface troubleshooting (straight-through vs crossover cable selection)
Question 8Question →

An administrator is configuring a direct point-to-point link between two router interfaces (Router1 GigabitEthernet0/0/0 and Router2 GigabitEthernet0/0/0) in a lab. Auto-MDIX has been manually disabled on both interfaces. After connecting the routers using a standard straight-through Ethernet cable, the administrator checks Router1 with the following command:

text
Router1# show interfaces gigabitEthernet 0/0/0
GigabitEthernet0/0/0 is down, line protocol is down (disabled)
Hardware is Gigabit Ethernet, address is 0050.56be.1a01 (bia 0050.56be.1a01)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255

Which physical layer issue is the primary cause of both the interface status and line protocol remaining in a down/down state?

Show answer & explanation

Answer: An incorrect pinout cable type is used between two like MDI devices when Auto-MDIX is disabled.

Answer

The primary cause is the use of a straight-through cable between like devices (router to router) when Auto-MDIX is disabled, which requires a crossover cable to complete the physical circuit.
The correct answer identifies that connecting two like devices (router to router) without Auto-MDIX enabled requires a crossover cable. A straight-through cable maps transmit pins to transmit pins and receive pins to receive pins, which prevents physical carrier detection and leaves the link in a down/down state.

Step-by-Step Solution

1
Analyze the CLI interface state
The output shows 'GigabitEthernet0/0/0 is down, line protocol is down', indicating a Layer 1 physical connectivity issue.
When both interface and line protocol are down, physical signal electrical detection has failed.
2
Evaluate cabling requirements for like devices
Routers are MDI devices. Connecting MDI to MDI directly requires pin 1/2 (Tx) to connect to pin 3/6 (Rx).
A straight-through cable connects pin 1 to 1 and pin 2 to 2, causing both routers to transmit on the same pins and receive on the same pins.
3
Factor in the Auto-MDIX setting
Because Auto-MDIX is disabled, the interfaces cannot automatically adjust pin assignments electronically, requiring a physical crossover cable.
Without Auto-MDIX or a crossover cable, no link pulse/signal is detected, keeping the link down/down.

Key Concept

Ethernet Cable Pinouts and Auto-MDIX Operation
Question 9Question →

A network engineer is troubleshooting performance degradation on switch interface FastEthernet0/1. The output of the `show interfaces fastethernet 0/1` command is shown below:

text
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is FastEthernet, address is 0019.e762.a801 (bia 0019.e762.a801)
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)
Half-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, 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 32000 bits/sec, 28 packets/sec
5 minute output rate 88000 bits/sec, 64 packets/sec
521098 packets input, 68191044 bytes, 0 underruns
Received 42 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
12480 input errors, 12472 CRC, 8 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
889123 packets output, 118129033 bytes, 0 underruns
0 output errors, 38102 collisions, 9841 late collision, 0 deferred

Based on the CLI output, which two underlying issues could be causing the observed interface counters? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: A duplex mismatch where the local interface is operating in half-duplex while the connected endpoint is operating in full-duplex; The Ethernet cable length exceeds the maximum 100-meter distance limit defined by Category 5e/6 specifications

Answer

The two probable causes are a duplex mismatch (where the local interface is operating in half-duplex while the remote end is in full-duplex) and an Ethernet cabling run that exceeds the maximum allowed 100-meter distance specification.
Late collisions are defined as collisions occurring after the first 64 bytes (512 bits) of a frame have been transmitted. The two primary causes of late collisions on an Ethernet link are: 1) A duplex mismatch where one end operates in half-duplex and the opposing end operates in full-duplex (the full-duplex side transmits without listening, interrupting ongoing transmissions after 64 bytes), and 2) Physical cable lengths exceeding the maximum specification (100 meters for UTP), which causes propagation delays longer than the 512-bit slot time.

Step-by-Step Solution

1
Analyze the interface operating mode and error counters from the CLI output
The interface is set to Half-duplex mode at 100 Mbps and shows significant late collision counters (9,841) and CRC errors (12,472).
Late collisions occur when a collision is detected after the first 64 bytes (512 bits) of a frame have already been transmitted.
2
Evaluate duplex mismatch mechanics
A full-duplex endpoint transmits at any time without performing carrier sensing, sending frames that collide with the half-duplex interface after its 64-byte transmission window has passed.
The full-duplex device ignores half-duplex collision domain rules, causing late collisions on the half-duplex receiver.
3
Evaluate physical cable distance limits
Exceeding the 100-meter UTP distance limit increases signal propagation delay beyond the standard Ethernet 512-bit slot time.
When propagation delay exceeds the slot time, normal collisions arrive too late to be handled as standard collisions, incrementing the late collision counter instead.

Key Concept

Late collisions on Ethernet interfaces are primarily caused by duplex mismatches or physical cable length limit violations (>100m).
Estimated Time:2m 0s
Question 10Question →

Match each Cisco IOS interface line status and line protocol state combination to its corresponding root cause.

Click a left item, then click its matching right item

Items

GigabitEthernet0/1 is down, line protocol is down
GigabitEthernet0/1 is administratively down, line protocol is down
GigabitEthernet0/1 is up, line protocol is down
GigabitEthernet0/1 is up, line protocol is up (disabled)

Matches

Show answer & explanation

Answer

The interface states map to their corresponding root causes based on Layer 1 vs. Layer 2 status: down/down indicates a Layer 1 physical connectivity issue; administratively down indicates the port is shut down by configuration; up/down indicates a Layer 2 encapsulation or keepalive failure; and up/up (disabled) indicates an err-disabled state triggered by switch security features.
Matching interface states to their root causes requires analyzing Layer 1 and Layer 2 status lines: 'down/down' corresponds to a Layer 1 physical failure like an unplugged cable; 'administratively down' corresponds to an interface disabled by the 'shutdown' command; 'up/down' indicates Layer 1 is operational while Layer 2 framing or keepalives failed; and 'up/up (disabled)' corresponds to a port placed in the err-disabled state due to security or protocol violations.

Step-by-Step Solution

1
Analyze 'down / down' interface output
Identified as a Layer 1 physical problem.
Lack of carrier signal or physical link pulse forces both the interface and protocol status to down.
2
Analyze 'administratively down / down' interface output
Identified as a software configuration shutdown state.
The 'shutdown' command explicitly disables the interface in software.
3
Analyze 'up / down' interface output
Identified as a Layer 2 Data Link problem.
Physical signal detection is successful ('up'), but protocol negotiation, keepalives, or encapsulation failed ('down').
4
Analyze 'up / up (disabled)' interface output
Identified as an error-disabled (err-disabled) port state.
Cisco IOS automatically disables active ports when severe error thresholds or port security limits are breached.

Key Concept

Cisco IOS Interface Status and Line Protocol Troubleshooting
Estimated Time:1m 0s
Question 11Question →

Match each Cisco IOS interface line status or counter symptom on the left to its most likely physical or data link layer cause on the right.

Click a left item, then click its matching right item

Items

Interface status is 'GigabitEthernet0/1 is down, line protocol is down'
Interface status is 'FastEthernet0/1 is up, line protocol is down'
Interface status is 'GigabitEthernet0/2 is up, line protocol is up' with rapidly incrementing late collisions
Interface status is 'FastEthernet0/2 is administratively down, line protocol is down'

Matches

Show answer & explanation

Answer

The interface conditions match as follows: 'down/down' indicates a Layer 1 physical carrier loss; 'up/down' indicates a Layer 2 framing or encapsulation failure; 'late collisions' on an operational interface indicate a duplex mismatch; and 'administratively down' indicates the port is disabled by configuration.
In Cisco IOS interface diagnostics: physical layer carrier loss generates 'down/down'; data-link framing or keepalive failures generate 'up/down'; duplex mismatches generate late collisions; and administrative shutdown settings generate 'administratively down'.

Step-by-Step Solution

1
Analyze the 'down/down' state symptom.
Identified Layer 1 Physical connection failure.
When both hardware and line protocol report down, physical signal detection has failed completely.
2
Analyze the 'up/down' state symptom.
Identified Layer 2 Data Link framing or protocol failure.
The physical medium is receiving carrier signals, but data link frames or keepalives are not being successfully negotiated.
3
Analyze late collisions on an up/up link.
Identified duplex mismatch condition.
Late collisions happen when a full-duplex port sends frames without checking for carrier sense while the connected half-duplex port transmits simultaneously.
4
Analyze the 'administratively down' state symptom.
Identified local software configuration state ('shutdown').
Cisco IOS explicitly marks interfaces that have not been enabled with 'no shutdown' as administratively down.

Key Concept

Cisco IOS interface line status, protocol states, and error counter interpretation
Question 12Question →

A network administrator is troubleshooting poor file transfer performance on a switch interface connected to an enterprise application server. The administrator executes the `show interfaces gigabitethernet 0/1` command on the switch and receives the following CLI output:

GigabitEthernet0/1 is up, line protocol is up
Hardware is GigabitEthernet, address is 0007.ec29.2101
Full-duplex, 100Mb/s, media type is 100BaseTX
12458 input errors, 12458 CRC, 0 frame, 0 overrun, 0 ignored
0 output errors, 45211 collisions, 1204 late collision, 0 deferred

Based on this output, what is the most likely cause of the interface errors?

Show answer & explanation

Answer: A duplex mismatch between the switch port and the connected server interface

Answer

A duplex mismatch between the switch port and the connected server interface
A duplex mismatch occurs when one end of an Ethernet segment is configured for full-duplex while the opposite end operates in half-duplex mode. Because full-duplex mode disables CSMA/CD collision detection, the full-duplex side transmits data whenever ready. The half-duplex side, which is actively listening for carrier sense, experiences collisions and late collisions during its transmissions. The full-duplex side receives colliding signals mid-transmission, registering them as input CRC errors.

Step-by-Step Solution

1
Analyze the interface status and line protocol state.
The link status is 'up/up', proving Layer 1 signaling and Layer 2 framing are established.
Eliminates total physical disconnection or wrong pinout issues that prevent link activation.
2
Examine the duplex settings and error counters in the CLI output.
The interface reports 'Full-duplex' along with non-zero 'collisions', 'late collision', and 'CRC' errors.
In true full-duplex operation, collisions should never occur because transmit and receive pathways are independent.
3
Correlate late collisions and CRC errors to physical layer operations.
Late collisions occur when the remote half-duplex side detects a collision after the slot time because the local full-duplex side transmits without checking CSMA/CD carrier sense.
This symptom pattern unequivocally points to a duplex mismatch between the two connected devices.

Key Concept

Duplex Mismatch Symptoms and Error Counters
Estimated Time:1m 30s
Question 13Question →

A network administrator is diagnosing physical layer and data link layer interface issues on Cisco Catalyst switches. Match each Cisco IOS interface state and CLI error counter signature on the left to its primary physical or configuration root cause on the right.

Click a left item, then click its matching right item

Items

Interface is up, line protocol is down, accompanied by rapidly incrementing runts, giants, and frame alignment errors on a copper Ethernet link.
Interface is up, line protocol is up, accumulating a high number of late collisions and FCS errors during high-volume data transmission.
Interface is down, line protocol is down (notconnect) on a 1000BASE-SX fiber link where transmit lasers are confirmed active at both ends.
Interface is up, line protocol is up, showing continuously incrementing deferred frame counters and normal collisions, with zero late collisions or FCS errors.

Matches

Show answer & explanation

Answer

The correct matches pair: (1) Runts, giants, and alignment errors with physical cable corruption or NEXT; (2) Late collisions and FCS errors with a local half-duplex mismatch; (3) Fiber link down despite active lasers with Tx/Rx polarity reversal; (4) Deferred frames without late collisions or FCS errors with standard half-duplex CSMA/CD backoff.
Each physical symptom maps to its exact root cause: distorted frame dimensions (runts/giants) result from signal corruption or bad cabling; late collisions stem from full/half duplex mismatch timing conflicts; down fiber links with active lasers indicate swapped Tx/Rx strands; and deferred frames without errors represent normal half-duplex CSMA/CD deferral behavior.

Step-by-Step Solution

1
Analyze symptom 1 (runts, giants, and frame alignment errors).
Corrupted frame sizes and framing errors reflect Layer 1 electrical noise, bad terminations, or cable length violations.
Damaged copper media distorts bits in flight, causing the receiving MAC layer to receive malformed frame lengths.
2
Analyze symptom 2 (late collisions and FCS errors).
Late collisions indicate a collision occurring after transmitting the first 64 bytes of a frame.
This symptom is indicative of a duplex mismatch where the opposite end is configured for full-duplex and transmits asynchronously.
3
Analyze symptom 3 (fiber link down/notconnect with active Tx lasers).
Optical transceivers require Tx-to-Rx cross-wiring.
If light is emitting from both ends but link is not established, the optical strands are connected Tx-to-Tx and Rx-to-Rx.
4
Analyze symptom 4 (high deferred transmission counter without late collisions).
Deferred frames count the number of times an interface delays sending a frame due to carrier detect on a half-duplex link.
This is normal CSMA/CD behavior on a busy segment and does not indicate physical cable or hardware failure.

Key Concept

Cisco IOS Interface Counters and Physical Layer Diagnostics
Question 14Question →

A network engineer is troubleshooting performance issues across several switch interfaces using Cisco IOS CLI outputs. Match each interface status or error counter symptom on the left to its corresponding Layer 1 or Layer 2 root cause on the right.

Click a left item, then click its matching right item

Items

Interface shows incrementing 'late collisions' and FCS errors on a local interface set to half-duplex while experiencing poor throughput.
Interface shows status 'GigabitEthernet0/1 is down, line protocol is down' when connecting two switch interfaces with Auto-MDIX disabled using a straight-through cable.
Interface shows status 'GigabitEthernet0/2 is up, line protocol is down (disabled)' accompanied by encapsulation error messages.
Interface shows incrementing 'giants' and CRC errors on an Ethernet port receiving traffic from a server.

Matches

Show answer & explanation

Answer

Each interface symptom matches its specific root cause based on Cisco IOS interface operation: Late collisions match a duplex mismatch; physical down/down with straight-through and disabled Auto-MDIX matches pinout misconfiguration requiring a crossover cable; up/down (disabled) matches Layer 2 framing or keepalive failure; incrementing giants with CRC errors matches oversized frame transmission exceeding MTU.
Each symptom accurately maps to its fundamental physical or data-link root cause: late collisions indicate duplex mismatch; down/down with straight-through cabling on switch-to-switch links without Auto-MDIX indicates incorrect pinout; up/down indicates Layer 2 framing/keepalive failure; and giants indicate frames received that exceed the allowable maximum frame size.

Step-by-Step Solution

1
Analyze the late collisions symptom
Identified duplex mismatch as the root cause
Late collisions happen when one side sends frames mid-transmission because it is configured as full-duplex while the local side is half-duplex.
2
Analyze the line status down / line protocol down scenario with Auto-MDIX disabled
Identified pinout misconfiguration requiring a crossover cable
Switch-to-switch links connect MDI-X to MDI-X. Without Auto-MDIX, a straight-through cable causes Tx-to-Tx mapping, resulting in Layer 1 link failure.
3
Analyze the up / line protocol down (disabled) state
Identified Layer 2 framing or encapsulation mismatch
Layer 1 is active (up), but Layer 2 fails to establish framing or keepalive communication, causing line protocol to be down.
4
Analyze incrementing 'giants' and CRC counters
Identified oversized frame transmission exceeding MTU limits
'Giants' explicitly refer to frames received over 1518 bytes (or configured MTU), typically caused by jabbering NICs or MTU mismatch.

Key Concept

Cisco IOS Interface Counter Analysis and Physical/Data-Link Troubleshooting
Question 15Question →

Refer to the following Cisco IOS CLI output from switch Switch-A:

text
Switch-A# show interfaces fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0007.ebaa.1101
Full-duplex, 100Mb/s, media type is 100BASE-TX
...
12540 input errors, 12538 CRC, 0 frame, 0 overrun, 0 ignored
0 output errors, 0 collisions, 0 late collisions, 0 deferred

Switch-A connects directly to Switch-B over a 10-meter Category 5e UTP cable. Switch-B reports high counts of late collisions on its corresponding interface. Which condition is the root cause of these interface symptoms?

Show answer & explanation

Answer: A duplex mismatch where Switch-A is operating in full-duplex mode and Switch-B is operating in half-duplex mode.

Answer

The root cause is a duplex mismatch where Switch-A is set to full-duplex and Switch-B is set to half-duplex.
A duplex mismatch occurs when one end of an Ethernet link operates in full-duplex mode while the opposite end operates in half-duplex mode. Because the full-duplex device (Switch-A) transmits data without performing carrier sensing, it frequently sends frames while the half-duplex device (Switch-B) is actively transmitting. This causes Switch-B to detect collisions after sending the initial 64 bytes of a frame (late collisions), while Switch-A receives aborted frame fragments from Switch-B, registering them as CRC and FCS input errors.

Step-by-Step Solution

1
Analyze the CLI output on Switch-A
The interface is operating in full-duplex mode with a high number of input errors dominated by CRC errors, while output errors and collisions remain at zero.
An interface configured for full-duplex never checks for carrier sensing or collisions, so its collision counters will always remain zero.
2
Analyze the reported symptoms on Switch-B
Switch-B reports high counts of late collisions.
Late collisions occur on half-duplex interfaces when another device transmits after the 64-byte slot time window has passed.
3
Correlate symptoms across both devices
Full-duplex on Switch-A + Half-duplex on Switch-B explains both CRC errors on Switch-A and late collisions on Switch-B.
Switch-A transmits whenever it has data without listening. When Switch-B is transmitting, Switch-A's concurrent transmission collides with Switch-B's frames, causing Switch-B to record late collisions and Switch-A to receive truncated/corrupted frame fragments resulting in CRC errors.

Key Concept

Duplex Mismatch Symptom Analysis
Estimated Time:2m 0s
Question 16Question →

An administrator observes intermittent data corruption and dropped frames on interface `GigabitEthernet0/1` of an enterprise switch. Executing the `show interfaces GigabitEthernet0/1` command yields the following output:

text
GigabitEthernet0/1 is up, line protocol is up (connected)
Hardware is GigabitEthernet, address is 0012.7f3e.a101
Full-duplex, 1000Mb/s, media type is 1000BaseTX
Input queue: 0/75/0/0; Total output drops: 0
5 minute input rate 12000 bits/sec, 15 packets/sec
5 minute output rate 11000 bits/sec, 14 packets/sec
124501 packets input, 15890123 bytes
0 runts, 0 giants, 0 throttles
4812 input errors, 4812 CRC, 0 frame, 0 overrun, 0 ignored
0 output errors, 0 collisions, 0 late collision

Based on the CLI output, what is the most likely root cause of the reported interface errors?

Show answer & explanation

Answer: Physical cable damage or electromagnetic interference causing signal corruption along the Ethernet run

Answer

Physical cable damage or electromagnetic interference causing signal corruption along the Ethernet run
The correct answer identifies physical cable damage or electromagnetic interference as the root cause. In Cisco IOS, Cyclic Redundancy Check (CRC) errors increment when a received frame fails its checksum verification. When CRC errors increase while collision and late collision counters remain at zero, the cause is physical layer corruption—such as defective copper wiring, faulty RJ-45 crimping, damaged cable shielding, or external electrical noise.

Step-by-Step Solution

1
Analyze the interface status and error counters in the CLI snippet.
The interface is operating in full-duplex at 1000 Mbps with `line protocol is up`. Input errors precisely match 4,812 Cyclic Redundancy Check (CRC) errors, while collision and late collision counters remain at 0.
CRC errors occur when the frame check sequence (FCS) calculated by the receiving interface does not match the FCS field attached by the sender.
2
Evaluate potential Layer 1 vs. Layer 2 failure modes.
Because late collisions are 0 and collisions are 0, duplex mismatch and excessive cable length issues are ruled out.
Duplex mismatches cause late collisions on full-duplex interfaces and collisions/runts on half-duplex interfaces.
3
Determine the physical cause of checksum failures.
Isolated CRC errors on an Ethernet interface are directly tied to physical media defects, bad shielding, loose RJ-45 connectors, or electrical noise (EMI).
Corrupted bits during transmission alter the mathematical CRC value without triggering collision detection circuits.

Key Concept

CRC errors in Cisco IOS indicate corrupt frames received over the physical link, most commonly caused by damaged cabling, improper shielding, EMI, or loose pin connections.
Question 17Question →

A network technician observes high counts of late collisions and Frame Check Sequence (FCS) errors on a switch interface connected to a server. A CLI check shows the interface output below:

text
FastEthernet0/1 is up, line protocol is up (connected)
Full-duplex, 100Mb/s, media type is 100BaseTX
542 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
1243 output errors, 891 late collisions

Which physical or data-link issue is the most likely cause of these interface error statistics?

Show answer & explanation

Answer: A duplex mismatch between the switch interface and the connected device

Answer

A duplex mismatch between the switch interface and the connected device is the primary cause of late collisions and FCS errors.
A duplex mismatch occurs when one end of an Ethernet link operates in full-duplex while the opposite end operates in half-duplex. The full-duplex device transmits data whenever ready without checking for carrier activity. When the half-duplex device is transmitting and receives data from the full-duplex device after sending its initial 64 bytes, it records a late collision.

Step-by-Step Solution

1
Analyze the interface error counters in the CLI output.
Identified high late collisions and output errors on an operational (up/up) link.
Late collisions occur when a collision is detected after the first 64 bytes (512 bits) of a frame have been transmitted.
2
Correlate late collision symptoms with duplex settings.
Determined that one end is operating in full-duplex while the remote end is operating in half-duplex.
The full-duplex end sends traffic without listening for carrier sense, causing the half-duplex end to transmit simultaneously and register late collisions.

Key Concept

Duplex Mismatch Symptoms and Interface Error Counters
Question 18Question →

An engineer is troubleshooting severe frame corruption and packet drops on a GigabitEthernet connection between a Catalyst switch and an enterprise router. Both interfaces are explicitly configured for 1000Mb/s Full-duplex. The CLI output from the switch is shown below:

text
GigabitEthernet0/1 is up, line protocol is up
Hardware is Gigabit Ethernet, address is 5006.ab12.cd34 (bia 5006.ab12.cd34)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
5 minute input rate 452000 bits/sec, 510 packets/sec
5 minute output rate 489000 bits/sec, 540 packets/sec
1245012 packets input, 1084201948 bytes, 0 no buffer
0 runts, 0 giants, 0 throttles
14205 input errors, 14205 CRC, 0 frame, 0 overrun, 0 ignored
1589022 packets output, 1482910244 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets

Physical inspection reveals that a custom UTP patch cable was wired using non-standard pin pairings where pins 3 and 6 were split across different wire pairs instead of sharing a single twisted pair. Which physical or data link issue is directly responsible for the high number of CRC errors observed on this full-duplex interface?

Show answer & explanation

Answer: Severe near-end crosstalk (NEXT) and electromagnetic interference caused by the split-pair Ethernet cable pinout mismatch.

Answer

Severe near-end crosstalk (NEXT) and electromagnetic interference caused by the split-pair Ethernet cable pinout mismatch.
The correct answer identifies signal degradation and crosstalk resulting from split-pair cabling as the root cause of the CRC errors. Twisted-pair Ethernet (such as 1000BASE-T) relies on differential signaling across twisted pairs to neutralize electromagnetic interference. Splitting pins 3 and 6 across separate pairs destroys signal cancellation, producing high rates of Near-End Crosstalk (NEXT). When frames arrive corrupted, the receiving NIC's Frame Check Sequence (FCS) calculation fails, incrementing the CRC input error counter while collision counters remain zero due to full-duplex operation.

Step-by-Step Solution

1
Analyze the interface statistics from the 'show interfaces' CLI snippet.
The interface is operating in Full-duplex at 1000Mb/s with line protocol up. There are 14,205 input errors, all of which are specifically CRC errors, while collision counts are 0.
Full-duplex interfaces disable collision detection mechanisms because transmission and reception occur over separate dedicated pairs. Therefore, collisions are not expected.
2
Evaluate the physical cabling scenario described in the stem.
The custom cable has split pairs across pins 3 and 6 (transmitting signals over wires from different twisted pairs).
Twisted pair cabling relies on balanced differential signaling to cancel out noise and crosstalk. When a pair is split, differential cancellation fails, creating massive Near-End Crosstalk (NEXT).
3
Correlate physical layer noise with interface error counters.
NEXT corrupts electrical signals during transit, causing the receiving interface to compute a Frame Check Sequence (FCS) that does not match the trailer, generating CRC errors.
CRC errors without collisions or late collisions on a full-duplex link are a classic sign of Layer 1 physical medium defects, such as cable damage or pinout/twist errors.

Key Concept

Twisted Pair Cable Pinout Mechanics & Interface Error Counter Diagnosis
Estimated Time:2m 0s
Question 19Question →

A network administrator is troubleshooting poor network performance on a switch interface connected to an end host. Executing the `show interfaces GigabitEthernet0/1` command produces the following output:

text
GigabitEthernet0/1 is up, line protocol is up
Hardware is Gigabit Ethernet, address is 0011.bb22.c334 (bia 0011.bb22.c334)
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)
Half-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, 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
5 minute input rate 32000 bits/sec, 24 packets/sec
5 minute output rate 98000 bits/sec, 65 packets/sec
521405 packets input, 68102948 bytes, 0 no buffer
Received 410 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
841920 packets output, 110482012 bytes, 0 underruns
2415 output errors, 2415 collisions, 582 late collisions, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output

Based on the CLI output, which of the following is the most likely cause of the interface performance degradation?

Show answer & explanation

Answer: A duplex mismatch between the switch port operating in half-duplex and the connected host operating in full-duplex.

Answer

A duplex mismatch between the switch interface operating in half-duplex and the connected end host operating in full-duplex is the primary cause of the late collisions and output errors.
Late collisions occur when a collision is detected after an interface has transmitted the first 64 bytes of a frame. In Ethernet networks, late collisions are most commonly caused by a duplex mismatch (where the local side is set to half-duplex and the remote side is set to full-duplex) or by cable length exceeding standard IEEE specifications. Because the remote full-duplex side does not listen before transmitting, it can send frames while the half-duplex side is mid-transmission, resulting in late collisions on the half-duplex interface.

Step-by-Step Solution

1
Analyze the operational status and duplex setting from the show interfaces output.
The interface is operating in 'up/up' state at 100Mb/s Half-duplex.
Verifies physical connectivity and operational mode of the local switch interface.
2
Examine the interface error counters.
Output error counters show 2415 output errors, 2415 collisions, and 582 late collisions.
Identifies specific Layer 1/2 error metrics that indicate frame transmission anomalies.
3
Correlate late collision counters with network operational characteristics.
Late collisions occur when a collision is detected after the first 64 bytes (512 bits) of a frame have been transmitted.
Standard collisions are expected in normal half-duplex operation within the slot time, but late collisions strongly indicate a duplex mismatch where one end is configured for full-duplex and sends data regardless of carrier sense.

Key Concept

Duplex Mismatch Troubleshooting and Collision Counters
Estimated Time:1m 30s
Question 20Question →

Two legacy FastEthernet switches are connected directly to each other using an Ethernet cable. The interface configuration on both ends explicitly has `no mdix auto` applied. Upon connecting the devices, execution of `show interfaces fastEthernet 0/12` reports that `FastEthernet0/12 is down, line protocol is down`. What physical cabling condition is the root cause of this interface status?

Show answer & explanation

Answer: A standard Category 5e straight-through cable is connected between the two like switch devices.

Answer

A standard Category 5e straight-through cable is connected between the two like switch devices.
When connecting two switches directly without Auto-MDIX enabled, a crossover cable must be used to cross the transmit pairs of one switch to the receive pairs of the other. Connecting them with a straight-through cable connects transmit pins to transmit pins and receive pins to receive pins, which prevents physical link negotiation and causes the interface status and line protocol to remain down.

Step-by-Step Solution

1
Analyze the interface status and line protocol state.
Both interface status and line protocol report 'down', indicating a Layer 1 (Physical layer) connectivity failure.
When an interface reports down/down, the device is not receiving physical signals or link pulses from the connected endpoint.
2
Evaluate the configuration context and device roles.
Two like devices (switch to switch) are connected, and automatic medium-dependent interface crossover (`no mdix auto`) is disabled.
Like devices transmit and receive on the exact same pin pairs (pins 1,2 for Tx and pins 3,6 for Rx on 10/100 Ethernet).
3
Determine the required cabling type.
A crossover cable must be used so that Transmit (Tx) pins on one switch connect to Receive (Rx) pins on the opposite switch.
If a straight-through cable is used without Auto-MDIX enabled, Tx connects to Tx and Rx connects to Rx, preventing physical link establishment.

Key Concept

Ethernet Cable Pinouts and Auto-MDIX Requirements
Page 1 / 2Next