2.4. Interface and Cable Issues
💡 First Principle: Interface problems fall into two categories: physical layer issues (cables, connectors, optics) and configuration mismatches (speed, duplex). Think of it like car trouble: the symptoms might look similar, but you wouldn't replace the engine for a flat tire. The show interfaces command reveals which category you're dealing with.
Imagine this troubleshooting scenario: A user reports their network is "slow." You check their switchport and see: CRC: 2847, late collisions: 245. Your instinct says "bad cable"—you swap it. No improvement. You swap the patch panel port. No improvement. Finally you notice the switchport is stuck at half-duplex while the user's NIC negotiated full-duplex. Hours wasted because you didn't read the counters correctly. Note which side shows the evidence: collision counters only ever increment on the HALF-duplex end, because full duplex disables collision detection entirely.
What happens when you misdiagnose: Physical problems require hardware replacement. Configuration problems require settings changes. Replacing hardware for a configuration problem wastes time and money. Changing settings for a physical problem does nothing. The counters tell you which direction to go.
Common Issues and Indicators:
| Issue | Symptoms | show interfaces Evidence |
|---|---|---|
| Collisions | Shared media contention | High collision counter |
| Late collisions | Duplex mismatch, or a segment longer than the collision domain allows | Late collision counter > 0 on the half-duplex side |
| CRC errors | Bad cable, interference, bad NIC | CRC errors, input errors |
| Duplex mismatch | One side full, other half | High collisions + CRC errors |
| Speed mismatch | Interface down or errors | Interface may show down |
| Input/output queue drops | Congestion—more traffic than the interface or CPU can handle | Drop counters climb while CRC/collision counters stay at 0 |
Duplex Mismatch Scenario: When one side is set to full duplex and the other to half duplex, the full-duplex side transmits whenever it likes because it never checks for collisions. The half-duplex side therefore logs collisions—many of them late collisions—and aborts frames mid-transmission, and the full-duplex side receives those cut-off frames as runts and CRC/FCS errors.
Switch# show interfaces gigabitEthernet 0/1
Input errors: 153, CRC: 127, frame: 0
Output errors: 0, collisions: 2847, late collision: 245
⚠️ Exam Trap: If you see late collisions on a switched network (not a hub), suspect duplex mismatch. Normal collisions shouldn't occur on a full-duplex switched port.
Reading interface status (show interfaces, show ip interface brief):
| Status / Protocol | Meaning | Usual fix |
|---|---|---|
| administratively down / down | Port disabled with shutdown | no shutdown |
| down / down | Layer 1 problem: no or bad cable, far end off, speed mismatch | Check cabling and the far end |
| up / down | Layer 1 works but Layer 2 fails: encapsulation or keepalive mismatch (common on serial links) | Match encapsulation/keepalives on both ends |
| up / up | Working | — |
err-disabled (show interfaces status) | Switch shut the port automatically after a violation (port security, BPDU Guard, etc.) | Fix the cause, then shutdown/no shutdown or errdisable recovery |
show interfaces <name> shows status and error counters; show running-config interface <name> shows only that interface's configuration.
