Rising CRC errors and interfaces that repeatedly go up and down are among the most common network faults. They also cause secondary alerts elsewhere: routing sessions reset, LAG members drop out, latency rises and applications time out. Getting to the physical cause quickly prevents a chain of downstream tickets.
What CRC errors mean
A CRC or frame check sequence error means a received frame arrived corrupted. Corruption usually originates in the physical path: a degraded transceiver, a dirty or damaged fiber, a poor patch cable, a failing port or a speed and duplex mismatch. It is less often a software problem. Because the interface is receiving damaged frames, the error counter is on the side that received them, so the fault may be in the cable, the far-end transmitter or the local receiver.
Read counters as rates, not totals
Interface error counters are cumulative. A large lifetime number may be old history. What matters is the rate over a recent window and whether it is increasing. Record the counter values and timestamps, calculate the change over time and compare it against the interface’s traffic. Clearing counters at the start of an investigation gives a clean baseline, but note the time you cleared them.
Check both ends of the link
- Errors on one end only often implicate that end’s receiver or the opposite transmitter
- Errors on both ends point at the shared path: cable, patch panel or fiber
- Compare input errors, output errors, drops and resets on each side
- Look at the peer device’s view, not just the device that alerted
Did the errors come before the flaps?
A common pattern is CRC errors rising for a period, then the link dropping and returning. That sequence supports a degrading physical component. If the flaps appear with no earlier errors, look at power, administrative changes, remote-side restarts or a negotiation problem instead. Timestamps that are accurate to the second make this distinction possible, so keep event time separate from ingest time.
Inspect optics and cabling
For transceivers that report digital optical monitoring values, check transmit and receive power against the module’s stated range and compare both ends. Confirm the transceiver type, wavelength and fiber type match. Clean and inspect fiber connectors before replacing hardware. For copper, replace the patch cable and try a different port to separate the cable from the port.
Rule out speed and duplex mismatch
When one side is fixed and the other auto-negotiates, they can settle on different duplex settings. The half-duplex side commonly shows collisions, while the full-duplex side shows CRC errors and short frames. Configuring both ends consistently, or leaving both on auto-negotiation where the hardware supports it, usually resolves it.
Understand the blast radius
A flapping link can reset BGP or OSPF adjacencies, remove LAG members and trigger spanning tree changes. Those alerts are consequences, not separate faults. Treat them as part of one incident with a physical root cause. See alert correlation for how to group them without hiding independent failures.
Verify the repair
- Clear or baseline counters after the change
- Watch error rate and link state over a meaningful window
- Confirm dependent routing sessions and services recovered
- Record what was replaced so a recurrence is easy to spot
Related: BGP session down troubleshooting.