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.

How CRC Errors Are Generated

Ethernet frames carry a 32-bit Frame Check Sequence computed by the transmitter over the frame contents. The receiver recalculates it and, if the two disagree, the frame is discarded and the interface's CRC counter increments. The frame never reaches the forwarding plane, so on IOS XR you will see the count under the input error block rather than in any queue or drop statistic.

Because the check is end-to-end across the link, a CRC error tells you that something altered the bits between the two transmitters - it does not tell you which end is at fault. That ambiguity is the reason the isolation workflow below swaps components one at a time rather than trusting intuition. Bit errors come from a shortlist of causes:

• Contaminated or scratched fibre end-faces, or a dirty connector in the patch panel.
• A marginal or failing optical transceiver, or a transceiver that is not the right type for the link budget.
• Excessive bend radius, a crushed cable, or a bad mechanical splice on the physical path.
• Marginal receive optical power - either too low (attenuation, long span) or too high (too-short span without an attenuator, which saturates the receiver).
• A failing line card port or PHY, or a speed/duplex mismatch on a copper link.
• Intermittent electrical faults, including a partially seated module or a backplane connector that has drifted.

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.

Read the numbers as a pair over time rather than as a snapshot. Clear the counters, wait a fixed interval, and read again - the rate of change is what distinguishes a dead patch cord (thousands per minute, immediately) from a marginal optic that only corrupts when the chassis warms up (a handful per hour). Interface state transitions are also worth noting: an interface that has bounced 39 times has a separate stability problem that may be feeding the CRC count.

RP/0/RP0/CPU0:router# clear counters TenGigE0/0/0/26
RP/0/RP0/CPU0:router# show interfaces TenGigE0/0/0/26 | include rate|CRC|input errors
RP/0/RP0/CPU0:router# show interfaces TenGigE0/0/0/26 accounting

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.

Two counters in particular deserve attention. PCS-level errors such as sync header errors or block lock losses indicate the SERDES cannot reliably recover the encoded stream, which is a signal-integrity problem well before it becomes a CRC problem. On higher-speed ports, the FEC counters are even more informative: corrected errors climbing with a small number of uncorrectable blocks means the link is on the edge of its error budget and will start producing CRCs the moment conditions change. Reading the pre-FEC error rate is the earliest possible warning that a link is degrading - our coherent optics pre-FEC BER, OSNR and DSP checks explains the same idea on the coherent side.

Checking the Optics Before Swapping Anything

Optical power is the fastest discriminator between a dirty connector and a dead transmitter. Pull the live diagnostics from the module and compare them with the specification for that optic type:

RP/0/RP0/CPU0:router# show controllers optics TenGigE0/0/0/26
RP/0/RP0/CPU0:router# show controllers optics TenGigE0/0/0/26 internal
RP/0/RP0/CPU0:router# show inventory | include TenGigE0/0/0/26

Interpret the output with these rules of thumb:

• Receive power at the low end of range: too much attenuation - long span, dirt, or a mis-mated connector. Clean and re-measure before ordering a replacement optic.
• Receive power above the maximum: the receiver is saturating. Short-reach links joined without an attenuator are the classic case; add attenuation rather than swapping hardware.
• Transmit power low or absent: the laser has failed. That module is done and the port will produce errors or stay down regardless of what you do at the far end.
• Receive power normal, CRC still climbing: the problem is not attenuation. Suspect a bad connector polish, a failing receiver, or the transmit side of the far-end module. Our optical power budget calculation guide helps you confirm whether the measured values are actually within the design margin for the link.

Type mismatch is worth checking explicitly: a module with the wrong reach (for example an LR optic on a short intra-rack link) will work, but without attenuation it can sit close enough to the receiver's saturation point that it degrades with temperature. show inventory gives you the Cisco part number and serial to compare against the far end.

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.

Run the swap in that order because it moves from cheapest and most likely to most disruptive. Cleaning and reseating costs nothing and fixes the majority of cases; a port swap means a maintenance window on a production router, so you want the earlier steps to have already eliminated the cable and the module.

Two field habits make this workflow far more reliable. First, write down what you changed and the counter reading after each step - otherwise a dual fault (bad cable and marginal optic) will look like the problem is moving around. Second, use a loopback or a spare port at the same speed to prove the line card side independently; a hard loopback on the port will surface PHY-level faults that a live link can hide.

Copper Ports and Bundle Members

Not every CRC is optical. A 1000BASE-T or 10GBASE-T port that is running on marginal structured cabling will also produce CRC errors, and the diagnostics are different: instead of optical power you look at cable length, pair skew and the negotiated speed. A 10GBASE-T port that keeps renegotiating down to 1G is telling you the cable plant does not support the higher rate. Check with:

RP/0/RP0/CPU0:router# show controllers GigabitEthernet0/0/0/1 phy
RP/0/RP0/CPU0:router# show interfaces GigabitEthernet0/0/0/1 | include duplex|speed|CRC
RP/0/RP0/CPU0:router# show interfaces GigabitEthernet0/0/0/1 phy

Bundle members need one extra step. When CRC errors appear on a link that is a member of a bundle or a port-channel, the counters are still per physical member, so always identify which member is dirty before you start swapping - the bundle as a whole will look healthy while one member quietly corrupts traffic:

RP/0/RP0/CPU0:router# show bundle Bundle-Ether10 | include Member|CRC|errors
RP/0/RP0/CPU0:router# show interfaces Bundle-Ether10 member
RP/0/RP0/CPU0:router# show lacp Bundle-Ether10

If you cannot take the member out of service immediately, remember that a member producing CRCs is worse than a member that is down: the LAG hashing will keep sending flows into it and TCP will repeatedly retransmit. Shutting the member administratively, even briefly, is often the lowest-risk mitigation while a replacement is sourced.

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.

It is also worth separating CRC from frame and alignment errors. A CRC counter alone with zero frame errors is the textbook dirty-connector signature. Frame errors alongside CRC can indicate that the far end is transmitting something malformed - a duplex mismatch on copper, or an MTU/encapsulation disagreement on a tunnel interface - and runts growing without CRC often means a speed mismatch rather than corruption. Our IOS XR input drops and NP counter troubleshooting covers the forwarding-plane side, SFP optical transceiver troubleshooting checklist is the module-level companion, and Junos show interfaces extensive error fields is useful if you run both vendors and want to map the field names.

Monitoring So the Next Fault Is Caught Early

CRC errors are far cheaper to handle when you see the trend rather than the outage. Poll the interface error counters on your routers with SNMP or streaming telemetry and alert on a delta rather than an absolute value - a counter that has been non-zero since the router was installed is history, whereas a counter that moved in the last five minutes is a fault. On IOS XR, the model-driven telemetry path exposes the same counters you read manually, so you can push them to Prometheus or a collector at a sane interval and graph them next to the optical power readings.

RP/0/RP0/CPU0:router# show interfaces TenGigE0/0/0/26 | include CRC|errors
RP/0/RP0/CPU0:router# show logging | include TenGigE0/0/0/26
RP/0/RP0/CPU0:router# show alarms brief system active

The last piece is operational discipline: when a field engineer cleans a connector, the counters should be cleared as part of the same change record. A cleared counter resets your baseline and makes the next trend unambiguous.

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