Networking
Cable faults that look like software faults
Applies to Any platform Cisco IOS / IOS-XE Linux This applies to any Ethernet link; the counter and cable-diagnostic commands are Cisco IOS, with Linux ethtool for the host end.
The physical layer is unfashionable, and it is where a surprising share of faults live. The reason they are hard is that a degraded cable does not fail cleanly. It produces symptoms that look like anything else.
What a marginal cable looks like from above
Intermittent packet loss under load but not at idle. Throughput far below the negotiated speed. A link that flaps every few hours. A connection that works at 100 Mbps but not at gigabit, because gigabit uses all four pairs and 100 Mbps uses two — so a single damaged pair produces a link that works perfectly until someone “fixes” the speed setting.
The counters that expose it
show interface Gi0/12 | include error|CRC|collision|flap
ethtool -S eth0 | grep -iE 'err|crc|drop'
ip -s link show eth0
CRC errors mean frames arrived corrupted. That is physical: a cable, a connector, a transceiver, or interference. Almost no configuration causes CRC errors; the one exception is a duplex mismatch, which produces them on the full-duplex side. If they are incrementing, stop reading configuration.
Testing without a tester
Many switches include cable diagnostics that will tell you the fault distance:
test cable-diagnostics tdr interface Gi0/12
show cable-diagnostics tdr interface Gi0/12
That will often report an open or short on a specific pair at a specific distance, which turns a vague fault into a location.
The usual culprits
Patch leads that have been walked on, crimped under a desk leg, or terminated by hand years ago. Cable runs near fluorescent lighting or motors. A fibre connector that was never cleaned. An SFP seated but not quite. Runs that exceed 100 metres because somebody routed the long way round.
The rule
When a fault is intermittent and load-related, check the error counters before the configuration. Swapping a patch lead takes thirty seconds and eliminates the most common cause in networking. Do it early, not after the third configuration change.
Related reading