Skip to content

Networking

Cable faults that look like software faults

02/10/2026 · 2 min read · updated 11/10/2026 · Tanveer Ahmed

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