CRC and the Frame Check Sequence: Error Detection and What It Tells You

A cyclic redundancy check is a short value computed from a block of data and sent alongside it. The receiver recomputes the value and compares. If they differ, the data changed in transit and the frame is discarded. Every Ethernet frame carries one, and on the Network+ exam the useful knowledge is less about the mathematics than about what a rising CRC error counter is telling you.

How it works

CRC treats the data as a large binary number and divides it by a fixed generator polynomial, keeping the remainder. That remainder is transmitted with the data. The receiver performs the same division over the data and the remainder together; a result of zero means no detected error.

It is chosen over a simple checksum because it catches the error patterns that actually occur on physical links. A CRC-32 detects all single-bit errors, all double-bit errors, any odd number of bit errors, and every burst error shorter than 33 bits — and burst errors are exactly what electrical noise and marginal cabling produce. A plain additive checksum misses many of these, including any pair of errors that happens to cancel.

Detection is not correction. Ethernet simply discards a bad frame and leaves recovery to a higher layer, which is why TCP retransmits and UDP does not. Forward error correction, used on wireless and long-haul links, adds enough redundancy to repair errors rather than only spotting them, at the cost of bandwidth.

Where you meet it

In Ethernet the CRC lives in the four-byte frame check sequence at the end of every frame. Storage systems, archive formats, and many protocols use the same technique at their own layers, so a single piece of data may be checked several times on its way from disk to application.

A switch validates the FCS on receipt. In store-and-forward mode it buffers the whole frame and checks before forwarding, so corrupt frames stop there. In cut-through mode it begins forwarding as soon as it has read the destination address, which lowers latency but propagates bad frames downstream — a useful detail when errors appear on a port with no local cause.

What CRC errors actually mean

This is the practical payoff. CRC errors on an interface are a physical layer symptom, essentially always. The usual causes, roughly in order of how often they turn out to be the answer:

Duplex mismatch — one side at full duplex and the other at half. The half-duplex side detects collisions the full-duplex side does not respect, producing late collisions and CRC errors that scale with traffic. Classically caused by hard-coding speed and duplex on one end and leaving the other on autonegotiation.

Cable faults — damaged, kinked, or out-of-spec cable, a run exceeding 100 metres, a badly terminated jack, or a patch cord crushed under a desk leg.

Electromagnetic interference — copper run alongside fluorescent lighting, motors, or power cable. Errors that correlate with equipment switching on are a strong hint.

Failing hardware — a dying transceiver, a bad switch port, a failing NIC. Moving the cable to another port separates port from cable quickly.

Troubleshoot in that order: check duplex settings on both ends first because it costs nothing, then swap the patch cable, then move ports, then test the permanent link. A toner and probe traces the run when the fault is somewhere in the walls, and a cable certifier is what proves the run is in spec.

Monitoring the counters

Interface error counters are cumulative, so the absolute number means little without a baseline — what matters is the rate of increase and the ratio of errors to total frames. A handful accumulated over a year is noise; a hundred per minute is a fault in progress.

Poll the counters over SNMP and alert on rate rather than total. Interface state changes and error thresholds reported to a central collector follow the usual syslog severity levels, so a link going down can be routed differently from a slowly rising error count. Catching a degrading link before it fails is the whole point.

CRC is not a security control

Worth being explicit, because the exam tests it. CRC detects accidental corruption. It does not detect deliberate modification, because an attacker who alters the data simply recomputes the CRC — the algorithm is public and unkeyed.

Integrity against an adversary requires a cryptographic hash or, better, a keyed construction such as an HMAC or an authenticated encryption mode, where an attacker without the key cannot produce a valid tag. CRC for accidents, cryptography for adversaries.

Exam angles

Know CRC as error detection using polynomial division, carried in the Ethernet frame check sequence, and that it detects rather than corrects. Recognize CRC errors as a physical layer problem and name duplex mismatch, cable faults, interference, and failing hardware as the causes. Distinguish store-and-forward from cut-through switching by whether the FCS is validated before forwarding. And never select CRC as the answer to a question about protecting data from tampering.