A CRC error means a device received an Ethernet frame whose data no longer matches the CRC value the sender attached. The frame is discarded and a counter increments on the receiving interface. The cause is physical: a cable, a connector, an SFP module, or a duplex mismatch.
- Every frame ends with a 4-byte frame check sequence holding a CRC-32
- The check runs per link, so the counter names the faulty link
- The frame is discarded, never repaired. TCP does the recovery
- A duplex mismatch shows CRC and runts on one end, late collisions on the other
- Clear the counters first: a rate is a diagnosis, a lifetime total is not
On this page
The mechanismWhat the frame check sequence actually checks
The last four bytes of every Ethernet frame are the frame check sequence, and they hold a CRC-32 computed over the destination address, the source address, the type field and the payload.
CRC is short for cyclic redundancy check, and the mechanism is arithmetic rather than cryptography. The transmitting device treats the frame as one very long binary number, divides it by a fixed polynomial, and puts the remainder in the FCS field as the CRC value.
The receiver performs the same division over the data it received, FCS included, and an uncorrupted frame produces a remainder of zero. Any other value means at least one bit is different from what was sent.
Three consequences of that design decide how these errors behave.
The check is per link, not end to end. Each switch on the path recomputes the FCS value on receipt and generates a fresh one when it transmits. So a CRC error identifies the one link the data was corrupted on, out of all the links the packet crossed, which is precisely what makes the counter useful.
The corrupted frame is discarded, not repaired. CRC-32 detects data corruption and cannot correct it. The frame never reaches the operating system, and nothing on the receiving device ever sees it. Recovery, if any, happens at a higher layer when TCP notices a missing segment and retransmits the data.
The detection is very good but not perfect. CRC-32 catches every burst error up to 32 bits and the overwhelming majority of longer ones. A packet whose value checks out is not proven intact, it is merely extremely unlikely to be corrupted, which is a distinction that matters only at enormous scale.
The five causesWhere CRC errors come from
Almost every CRC error on a production network comes from one of five places, and they are worth working through in the order below because the list runs from the commonest to the rarest.
A damaged or unsuitable copper cable. A crushed cable, a kinked one, a badly terminated end, a patch lead that has been pulled out of the wall a hundred times, or a run longer than one hundred meters.
Cable damage produces intermittent CRC errors that get worse under load, which is why the problem so often presents as a network that is fine in the morning.
Interference on a copper run. A cable routed alongside fluorescent lighting, motors, or high-voltage power picks up electrical noise. Shielded cable and better routing are the fix, not a new switch. This is the one to suspect when errors start after somebody installed something in the ceiling.
A dirty, damaged or mismatched SFP module on fiber. Contaminated connector ends are the single most common fiber fault, and they are invisible without a scope.
Bend radius, a broken strand, an SFP transmitting outside its power range, or a single-mode module on multi-mode fiber all produce the same counter. Any switch that supports digital optical monitoring reports the received power, and a value near the receiver sensitivity floor is your answer.
A duplex mismatch between the two devices. One side hard-set to full duplex and the other auto-negotiating to half is the classic case. The half-duplex device treats incoming frames as collisions, stops transmitting mid-frame, and the full-duplex device receives truncated packets whose CRC value cannot match.
The signature is CRC errors and runts on one side, late collisions on the other, and the counters disagreeing between the two ends of one link.
A failing switch port, SFP module or network card. Once the cable and the settings are eliminated, the hardware in one of the two devices is what is left. This is the least common cause on the list and the one people check first.
The countersReading the counters properly
On most platforms show interfaces prints CRC errors inside a broader block of receive counters, and reading the block together is what turns a number into a diagnosis.
GigabitEthernet1/0/12 is up, line protocol is up
2847 input errors, 2811 CRC, 36 frame, 0 overrun, 0 ignored
0 watchdog, 1204 multicast, 0 pause input
0 output errors, 0 collisions, 14 late collision| Counter | What it means | What it points at |
|---|---|---|
| CRC | The computed value did not match | The physical link into this port |
| Input errors | The total, of which CRC is one kind | Read the breakdown, never the total |
| Runts | A frame shorter than 64 bytes | Duplex mismatch, or a truncating transmitter |
| Giants | A frame longer than the allowed size | An MTU or tagging mismatch |
| Frame | A CRC failure on a frame that is not a whole number of bytes | Nearly always the same physical fault |
| Late collision | A collision after the first 64 bytes | Duplex mismatch, or a run over length |
| Overrun, ignored | The interface could not buffer the frame | Load or a hardware limit, not cabling |
Two habits separate a useful reading from a misleading one.
Clear the counters and measure a rate. A port that has been up for two years and shows four thousand CRC errors may have collected all of them during one bad week in 2024. Run clear counters on the interface, wait, and look again.
What matters is whether the number is still moving and how fast, not how large it is. Monitoring systems that poll interface counters will give you that rate without the wait, if the switches on the network are already polled.
Read both ends of the link. CRC errors count where the frame is received, so a fault in one direction shows up on one interface only.
Errors on one device and none on the other is a real and useful signal, because it narrows the problem to that direction of transmission: the transmitter in the far device, that pair or strand, or the local receiver.
Isolating itThe four moves that isolate it
This is a physical layer problem, so the technique is substitution. Change one thing at a time and watch whether the counter follows.
Move the cable to a different switch port. If the errors follow the cable to the new port, the original port is fine and the problem is the cable or the device on the other end. If the errors stay behind, that switch port is the fault.
Swap the cable for a known good one. Known good means a cable you have used and trust, not a new one from a bag. This one step resolves most copper cases, and it is worth doing before anything is configured.
Check speed and duplex on both ends. Both auto, or both hard-set to the same values. One of each is the mismatch that generates these errors, and it is the one cause on the list that is free to fix.
On fiber, read the optical power before touching anything. show interface transceiver or the equivalent gives the received power value in dBm against the SFP module's sensitivity. A value close to the floor means attenuation, and the connector ends are the first thing to clean.
If all four leave the counter climbing, the remaining candidates are the network card in the far device and the switch receiver itself, and by then you have eliminated everything cheaper on both links of the path.
The captureWhy the capture shows nothing
A frame that fails the CRC check is discarded by the interface, so it is never handed to the operating system and never appears in a packet capture on that device.
On top of that, nearly every network card strips the frame check sequence before passing packets up, so even uncorrupted frames arrive at Wireshark without the field the error is about.
The practical consequence is worth stating plainly. A clean capture does not mean a clean link. If the switch counter says CRC and the capture says nothing is wrong, the switch is right, and the corrupted packets it is complaining about are the ones that never made it into the capture.
Some network cards can be told to pass error frames up for exactly this reason, and a tap or a switch port mirror configured to forward errored frames is the more reliable way to see the data.
The symptomWhat it looks like to users
A link with a low rate of CRC errors does not fail. It gets slow, and it gets slow in a way that resists explanation.
TCP retransmits the data it loses, so a corrupted packet becomes a delay rather than a broken transfer. Enough of them and throughput collapses well before any device reports an outage, because every loss also drives the congestion window down. Small interactive sessions feel fine, large file transfers crawl, and a bandwidth test gives a value nobody believes.
That mismatch between a working network and an unusably slow one is the signature worth recognizing, and it is the reason interface counters belong early in any investigation of a slow network rather than at the end of one.
Same nameThe other things called a CRC error
CRC is short for cyclic redundancy check, and those three words turn up in places that have nothing to do with a switch port. Working out which one is in front of you saves a lot of wasted testing.
Windows uses the same phrase when a read from a disk or an optical drive fails to verify. The Microsoft system error code list gives error 23, ERROR_CRC, as a data error, cyclic redundancy check.
That is a storage fault. A file that will not copy, a disk that reports it on the same sector every time, and a drive that logs it under load all point at the media or its controller, and these are checksum errors of a different kind. No amount of cable swapping helps.
Storage networks count them as well. Fibre Channel switches and the storage systems behind them keep the same class of counter on their ports, and the causes are the ones from the network list: the cabling, the connectors and the transceiver modules between the host and the array. A SAN is a network, and it has the physical layer problems of one.
On the network side the physical part varies more than the counter does. Copper links end in RJ45 connectors, and a bad termination or a crushed pair is the usual answer there.
Fiber links end in transceiver modules, SFP, SFP+ or QSFP depending on the speed, and contamination on the connector face is the usual answer there. Both produce an identical cyclic redundancy check failure on the receiving port, and the counter cannot tell you which one it was.
So read the source before you read the number. A switch reporting CRC errors, a storage array reporting them, and a file that will not copy are three different investigations that happen to share a name.
PitfallsWhere people go wrong
Reading a lifetime total as a current problem. Counters accumulate from the last reset. Clear them, wait, and read the rate.
Replacing the switch first. The switch is the most expensive device on the link and the least likely cause. Cable, connector, SFP module, then duplex, then hardware.
Trusting a new cable because it is new. Factory terminations fail, and a cable that has been in a drawer under a toolbox is not new in the way that matters. Test with a lead you have personally used.
Treating a duplex mismatch as a cabling fault. If one end shows CRC errors and runts while the other shows late collisions, stop testing cables and read the speed and duplex settings.
Ignoring errors because the link is up. Links stay up at any error rate short of total failure. Up is not healthy, and the counter is the only thing that distinguishes them.
Checking one device only. Errors count where frames are received. Half the information about the link is on the device you did not look at.
ComparisonFour receive counters, and which layer each one sends you to
| Criterion | CRC errors | Runts | Giants | Overruns |
|---|---|---|---|---|
| What the frame did | Failed its checksum | Arrived under 64 bytes | Exceeded the allowed size | Arrived faster than the buffer |
| Usual cause | Cable, SFP module, duplex | Duplex mismatch, truncation | MTU or VLAN tag mismatch | Load, or a hardware limit |
| Layer to look at | Physical | Physical and configuration | Configuration | Hardware |
| Fixed by | Replacing something physical | Matching duplex settings | Matching MTU | Reducing load or upgrading |
| Sign of a bad cable | Yes | Sometimes | No | No |
The first two columns often move together, which is the fact worth carrying away: runts and CRC errors climbing on the same interface point at a duplex mismatch far more often than at a cable, and that is the cheapest fault on the list to fix.
FAQFrequently asked questions
What is a CRC error?
A received Ethernet frame whose recomputed CRC value does not match the frame check sequence the sending device attached. The receiver discards the corrupted packet and increments a counter, and the cause is almost always physical.
What causes CRC errors?
In order of how often they turn out to be the answer: a damaged or unsuitable cable, electrical interference on a copper run, a dirty or failing SFP module on fiber, a duplex mismatch between the two devices, and finally a failing switch port or network card.
Are CRC errors and FCS errors the same thing?
Yes. The frame check sequence is the field, the CRC is the value in it, and different vendors name the counter after one or the other.
How many CRC errors are acceptable?
On a healthy link, effectively none. Any counter that is still incrementing after you clear it is worth investigating, whatever the absolute number looks like.
Do CRC errors cause packet loss?
Yes, directly. The corrupted packet is discarded at the interface, so the data is lost, and whatever recovery happens is TCP retransmitting it later.
Why do CRC errors only appear on one side of a link?
Because the counter increments where a frame is received. Errors on one side alone narrow the fault to that direction of transmission, which is useful rather than strange.
Can a duplex mismatch cause CRC errors?
Yes, and it is the commonest non-physical cause. The half-duplex side sees late collisions while the full-duplex side sees CRC errors and runts, and the two ends disagreeing is the signature.
Why does Wireshark not show the corrupted frames?
Because the interface discards them before the operating system sees them, and most network cards strip the frame check sequence from the frames they do pass up.
Does a bad cable always cause CRC errors?
No. A cable can fail in ways that bring the link down or drop it intermittently without corrupting frames. CRC errors are one failure mode among several.
Should I replace the switch?
Not first. Move the cable to another port, swap the cable, check duplex on both ends, and read the optical power on fiber. The switch is the last thing to suspect and the most expensive to change.
What is the difference between input errors and CRC errors?
Input errors is the total of every receive error, and CRC is one category inside it. Reading the breakdown tells you which kind you have; reading the total tells you very little.
Do CRC errors affect fiber and copper links differently?
The counter is the same and the causes differ. On copper links suspect the cable, the terminations and interference. On fiber suspect connector contamination first, then bend radius and the optical power value the SFP module reports.
How do I clear the counters?
clear counters on the interface on most platforms. Do it before you measure, because a rate is a diagnosis and a lifetime total is not.
Keep readingRelated concepts
Read next · Diagnostics Reading a Wireshark Capture Without Drowning in Packets The corrupted frames never reach the capture, which is why a clean capture and an unhappy switch are not a contradiction. Open this next12 min- Diagnostics · 11 min Packet Loss vs Latency, and Why They Feel the Same to Users A low rate of these errors does not break anything, it just makes the network slow in a way nobody can explain.
- Diagnostics · 11 min A Network Troubleshooting Checklist, in the Order That Saves Time Interface counters belong near the start of an investigation into a slow network rather than at the end of one.
- Firmware and boot · 10 min Checksum Errors, and Why the Battery Is Usually the Answer The other checksum error, and a different investigation.
- Cabling and connectivity · 9 min What UTP Cable Is, and Why the Twist Does the Shielding How the fault shows up.
- Network fundamentals · 10 min Layer 1 Networking, the Physical Layer, and Why It Is Where Most Faults Start What a climbing error count says about the physical layer underneath.