Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 1.4 — Diagnose interface and cable faults

Interface counters become useful when tied to direction, time, and layer. Record a baseline, generate or observe controlled traffic, and inspect which counters increase. A large lifetime count with no current growth may describe an old fault.

Collision and duplex evidence

Collisions belonged to half-duplex shared Ethernet behavior. A modern switched full-duplex link should not experience normal collisions. Late collisions can indicate a duplex mismatch, excessive physical extent, or abnormal media. In a classic duplex mismatch, the full-duplex side may record input or frame-check errors while the half-duplex side records collisions. Performance can be very poor even though the interface remains up.

Compare both ends. One side configured full and the other relying on negotiation can produce an unintended result on older or mismatched systems. Align supported speed and duplex settings rather than forcing random values until counters stop.

Physical error patterns

CRC or frame-check errors mean received frames failed integrity checks. Causes can include damaged copper, dirty fiber, interference, failing optics, or faulty hardware. Input errors are a broader category and require the detailed counters underneath. Runts, giants, and alignment errors describe different malformed frame conditions.

Output drops often indicate queue congestion rather than a bad receive cable. No-carrier or link transitions point toward physical continuity, remote shutdown, power, or negotiation. Keep receive and transmit directions explicit.

Speed mismatch symptoms

Interfaces must share a supported speed. Autonegotiation normally finds common capability, but forced or unsupported combinations can keep the link down or settle at an unexpected rate. A 100-Mb/s segment inside a gigabit path can also be a congestion point without being a negotiation fault. Read operational speed at both ends and compare it with design intent.

Isolation workflow

1. Confirm the intended ports and physical path.
2. Read administrative and operational state at both ends.
3. Record speed, duplex, media, and transceiver details.
4. Clear counters only under an approved process, or record a timestamped baseline.
5. Observe which counters change under traffic.
6. Replace one suspect component at a time with known-good compatible material.
7. Verify stability and application behavior after repair.

Worked scenario

Users report slow file copies. Both ports are up. One end shows full duplex and CRC growth; the other shows half duplex and collision growth. That paired evidence supports a duplex mismatch more strongly than an IP routing hypothesis. Correct the negotiation or explicit settings on both ends, then confirm the operational mode and that error deltas remain flat during a retest.

Common traps

• Reading one end of a link only.
• Treating every input error as congestion.
• Treating every output drop as bad cabling.
• Using ping success to dismiss a physical fault.
• Replacing multiple components at once and losing causal evidence.

Readiness checklist

• I can distinguish receive errors, collisions, and output drops.
• I compare deltas and both link ends.
• I can explain duplex and speed mismatch symptoms.
• I verify the repair under representative load.