Cisco IOS-XR Interface CRC Errors: How to Troubleshoot

CRC errors on a Cisco IOS XR interface are almost always a physical-layer problem - a faulty cable, a dirty or incompatible optical module, a marginal connector, or a failing port. Because XR routers (ASR 9000, NCS 540/5500/5600 and others) put the CRC counters on the physical interface, the troubleshooting path is refreshingly direct: read the counters, isolate the component, and replace it. This guide explains how to interpret the error counters in show interfaces output, how to correlate CRC with other errors, and what to check next in the field.

Reading the CRC and Error Counters

Run show interfaces on the affected physical interface and look at the input error block. A typical output looks like this:

RP/0/RP0/CPU0:router# show interfaces TenGigE0/0/0/26
TenGigE0/0/0/26 is up, line protocol is up
Interface state transitions: 39
...
152403495 packets input, 172646518724 bytes, 0 total input drops
0 drops for unrecognized upper-level protocol
Received 0 broadcast packets, 84723 multicast packets
13 runts, 0 giants, 0 throttles, 0 parity
3731 input errors, 3718 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

The fields to focus on:

• CRC: frames that failed the cyclic redundancy check - the definitive signature of a Layer-1 problem.
• Input errors: the aggregate counter; compare it with CRC to see whether CRC dominates (physical layer) or other error types are also climbing (possibly a different fault class).
• Runts/frame/overrun/abort: runt frames near the CRC count suggest physical corruption; overruns would point toward internal buffering instead.
• Total input drops: separate from CRC - these are forwarding-plane drops (for example NP drops) and not physical-layer errors.

Correlating with Controller-Level Counters

When the interface counter climbs but you need finer detail, or when the error is on a port that does not expose everything at interface level, drill into the controller statistics:

RP/0/RP0/CPU0:router# show controllers TenGigE0/0/0/26 stats
RP/0/RP0/CPU0:router# show controllers optics TenGigE0/0/0/26

The controller stats often reveal which counter moves at the same rate as the interface CRC counter - for example symbol errors or PCS errors that point at the optics or the cable rather than the switch ASIC.

Physical-Layer Isolation Workflow

1. Clean and reseat: clean the fiber end-faces and reseat both the patch cord and the optics; dirty connectors are the single most common cause of CRC errors.
2. Swap the patch cable with a known-good one and watch the counter. If CRC stops climbing, the cable was at fault.
3. Swap the optic (SFP/QSFP) with a known-good module of the same type and speed.
4. Swap the port: move the same optics and cable to a different port. If the error follows the port, suspect the hardware port itself.
5. Check negotiated speed/duplex and verify the far end is not the source of the corruption (a marginal link partner can generate errors on your receiver).
6. Clear counters and re-test after each change: clear counters TenGigE0/0/0/26.

What CRC Errors Are Not

Do not confuse CRC errors with input drops or output drops on IOS XR. Input drops are usually forwarding-plane events (NP microcode, unknown destination MAC, feature drops) and need a completely different troubleshooting path through show controllers np counters. If your CRC count is stable and only the drop counters grow, you are looking at a software/forwarding issue, not a cable issue.

Related reading: Cisco IOS-XR input drops and NP counter troubleshooting and SFP optical transceiver troubleshooting checklist.

Original article: Cisco: Troubleshoot Interface CRC Errors on IOS XR Routers