Loading learning content...
After the payload data, every Ethernet frame ends with a 4-byte (32-bit) Frame Check Sequence (FCS). This field contains a Cyclic Redundancy Check (CRC) value calculated over the entire MAC frame—from the Destination MAC address through the end of the payload.
The FCS is Ethernet's primary mechanism for detecting transmission errors. In the noisy, imperfect world of physical media—whether copper cables susceptible to electromagnetic interference, optical fibers with signal degradation, or wireless channels with interference and fading—bits can and do get corrupted. The FCS ensures that corrupted frames are detected and discarded rather than delivered to upper-layer protocols.
By the end of this page, you will understand the mathematics behind CRC-32 polynomial division, which parts of the frame are covered by FCS, how the FCS is calculated and verified in hardware, the types of errors detected and limitations of CRC, and how to interpret FCS error statistics for network troubleshooting.
The FCS occupies the last 4 bytes of every Ethernet frame, immediately following the payload (including any padding).
Frame Structure with FCS:
┌─────────┬─────┬────────────┬────────────┬──────────┬───────────────┬─────────────┐
│Preamble │ SFD │ Dst MAC │ Src MAC │Type/Len │ Payload │ FCS │
│ 7 bytes │ 1B │ 6 bytes │ 6 bytes │ 2 bytes │ 46-1500 bytes │ 4 bytes │
└─────────┴─────┘────────────┴────────────┴──────────┴───────────────┴─────────────┘
↑ ↑
│ CRC Calculation Scope │
└──────────────────────────────────────────────────────────┘
What the FCS Covers:
| Included in FCS | Not Included in FCS |
|---|---|
| Destination MAC | Preamble |
| Source MAC | Start Frame Delimiter |
| Type/Length field | Inter-Packet Gap |
| Payload data | |
| Padding (if any) |
Why FCS Doesn't Cover Preamble/SFD:
The Preamble and SFD are physical layer synchronization fields—they're stripped by the receiving NIC's hardware before the frame enters the MAC layer. By the time the FCS is verified, the Preamble/SFD no longer exist in the frame buffer.
If the Preamble or SFD is corrupted:
This is an important distinction for troubleshooting: FCS errors indicate corruption within the frame, while missing frames (without FCS errors) may indicate physical layer synchronization failures.
Purpose of the FCS:
The FCS provides error detection, not error correction. When a frame fails FCS verification, it's simply discarded. Upper-layer protocols (TCP, application-level acknowledgments) are responsible for detecting the loss and requesting retransmission. Ethernet itself has no ARQ (Automatic Repeat Request) mechanism.
The Ethernet FCS uses a specific CRC algorithm: CRC-32 based on polynomial division over the finite field GF(2) (binary arithmetic without carries).
The Generator Polynomial
Ethernet uses the following 33-bit generator polynomial:
G(x) = x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1
In hexadecimal: 0x104C11DB7
In binary: 1 0000 0100 1100 0001 0001 1101 1011 0111
This polynomial was selected for its error-detection properties, particularly its ability to detect:
Conceptual CRC Calculation
The CRC is computed by treating the frame data as a large binary number and performing polynomial division:
Simplified Example (CRC-4):
Message: 1101 0110 1100
Generator (G): 10011
Divisor degree: 4 (so append 4 zeros)
Step 1: Append zeros
1101 0110 1100 0000
Step 2: Polynomial division with XOR
1101 0110 1100 0000
10011
─────
1001 0110 1100 0000
10011
─────
000 1010 1100 0000
10011
─────
0111 1100 0000
10011
─────
1101 0000 0000
10011
─────
1001 000 0000
10011
─────
0001 00 0000
10011
─────
0010 0000
10011
─────
0011 0
10011
─────
1110 ← CRC remainder
Step 3: Final frame = 1101 0110 1100 1110
For Ethernet's CRC-32, this same process operates on frames of up to ~12,000 bits (jumbo frame) with a 33-bit polynomial.
Actual CRC calculation uses Linear Feedback Shift Registers (LFSRs) that compute the CRC bit-by-bit or byte-by-byte as data streams through. NICs implement this in dedicated hardware circuits that calculate the CRC in real-time as the frame is transmitted or received, with zero software overhead.
Ethernet's CRC-32 implementation includes several additional steps beyond basic polynomial division. These enhance error detection and ensure proper operation with real-world data patterns.
Pre-Processing Steps:
Why These Steps?
Complete FCS Calculation Algorithm:
def ethernet_crc32(data: bytes) -> int:
"""
Calculate Ethernet CRC-32 (FCS) for given data.
Data should include: Dst MAC, Src MAC, Type/Length, Payload, Padding
"""
POLY = 0x04C11DB7 # CRC-32 polynomial (without leading 1)
# Initialize CRC to all 1s
crc = 0xFFFFFFFF
for byte in data:
# Bit-reverse the input byte (LSB-first processing)
byte = reverse_bits_8(byte)
# XOR byte into the high-order byte of CRC
crc ^= (byte << 24)
# Process 8 bits
for _ in range(8):
if crc & 0x80000000: # If MSB is 1
crc = ((crc << 1) ^ POLY) & 0xFFFFFFFF
else:
crc = (crc << 1) & 0xFFFFFFFF
# Post-inversion (complement)
crc ^= 0xFFFFFFFF
# Bit-reverse the 32-bit result
crc = reverse_bits_32(crc)
return crc
Transmission Order:
The 4-byte FCS is transmitted LSB-first, matching Ethernet's overall bit ordering:
FCS value: 0xDEADBEEF
Transmission order: EF BE AD DE (byte-reversed)
Each byte: LSB first
When CRC-32 is computed over a correct frame INCLUDING its FCS, the result is a constant 'magic' value: 0x38FB2284 (after post-processing). Hardware receivers use this property—if the final CRC equals the magic value, the frame is valid. No need to extract and compare the FCS separately.
CRC-32 provides powerful error detection, but it's important to understand both its strengths and limitations.
What CRC-32 Detects (100% guaranteed):
| Error Type | Detection Rate | Notes |
|---|---|---|
| Single-bit errors | 100% | Any single bit flip is detected |
| Double-bit errors | 100% | Any two bits flipped are detected |
| Odd-count errors | 100% | Any odd number of flipped bits |
| Burst errors ≤ 32 bits | 100% | Consecutive error bits within 32-bit window |
| Burst errors 33 bits | ~100% | Only one pattern escapes detection |
| Burst errors > 33 bits | 99.99999995% | Random chance of miss: 2⁻³² |
Understanding Burst Errors:
A burst error is a sequence of bits where the first and last bits are in error, with any pattern of errors in between:
Original: 1 0 1 1 0 1 0 0 1 1 0 1
↓ ↓ ↓
Corrupted: 1 0 1 0 1 1 0 0 0 1 0 1
└─────────┘
Burst length = 5 bits
In the physical world, burst errors are common:
Undetectable Errors (Extremely Rare):
CRC-32 can miss errors, but the probability is vanishingly small:
In practice, other factors (retransmissions, timeouts) usually catch any missed corruptions before they affect applications.
Comparison with Other Methods:
| Method | Size | Single-Bit | Double-Bit | Burst (≤n) | Overall Strength |
|---|---|---|---|---|---|
| Parity (1-bit) | 1 bit | Yes | No | n=1 | Very weak |
| Internet Checksum | 16 bits | Weak | Weak | Poor | Moderate |
| CRC-16 | 16 bits | Yes | Yes | n=16 | Good |
| CRC-32 (Ethernet) | 32 bits | Yes | Yes | n=32 | Excellent |
| CRC-64 | 64 bits | Yes | Yes | n=64 | Superior |
CRC-32 detects random errors, not malicious modifications. An attacker can deliberately modify data AND recalculate a valid CRC. For integrity against adversarial threats, use cryptographic mechanisms: MACs (Message Authentication Codes), digital signatures, or MACsec (802.1AE).
Modern NICs perform FCS calculation and verification entirely in hardware, with zero CPU involvement. This is essential for line-rate operation—a 10 Gbps NIC must process approximately 15 million minimum-size frames per second.
Transmit Path:
┌─────────────────────────────────────────────────────────────────┐
│ NIC Transmit │
│ │
│ Driver → DMA Read → CRC Generation → PHY → Cable │
│ ↓ ↓ ↓ │
│ Frame Data LFSR Circuit FCS Appended │
│ (parallel) │
└─────────────────────────────────────────────────────────────────┘
Receive Path:
┌─────────────────────────────────────────────────────────────────┐
│ NIC Receive │
│ │
│ Cable → PHY → CRC Check → DMA Write → Driver │
│ ↓ ↓ ↓ │
│ Frame Data LFSR Accept/Reject │
│ Check │
└─────────────────────────────────────────────────────────────────┘
LFSR Implementation:
Linear Feedback Shift Registers efficiently compute CRCs in hardware:
32-bit CRC LFSR (simplified conceptual view):
┌───┬───┬───┬───┬─ ... ─┬───┬───┬───┬───┐
│ 0 │ 1 │ 2 │ 3 │ │28 │29 │30 │31 │ CRC Register
└─┬─┴───┴───┴───┴─ ... ─┴───┴───┴───┴─┬─┘
│ │
│ ←───── Shift left ←──────────────←│
│ │
├──⊕── XOR with input data bit │
│ │
└──⊕── XOR at polynomial tap positions (26, 23, 22, 16, 12, 11, 10, 8, 7, 5, 4, 2, 1, 0)
Parallel implementations process 8, 32, or 64 bits per clock cycle by unrolling the shift-XOR operations across multiple bit positions.
Offload Features:
Modern NICs provide CRC offloading options:
| Feature | Description |
|---|---|
| TX CRC Offload | NIC calculates and appends FCS; driver sends without FCS |
| RX CRC Offload | NIC verifies FCS and strips it; driver receives without FCS |
| RX CRC Passthru | NIC verifies but preserves FCS in buffer for software inspection |
| Checksum Offload | NIC also calculates/verifies IP, TCP, UDP checksums |
When Wireshark captures on the local machine with TX CRC offload enabled, outgoing packets may show 'Checksum incorrect' because the driver passes frames to the NIC without FCS. The NIC adds FCS in hardware, but Wireshark captures before this happens. This is normal behavior, not actual corruption.
FCS errors are critical network health indicators. Understanding their causes enables effective troubleshooting of physical layer problems.
Viewing FCS Error Statistics:
Cisco IOS:
switch# show interfaces gigabitethernet 0/1 | include CRC
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
Linux:
$ ip -s link show eth0
RX: bytes packets errors dropped overrun mcast
123456 1234 5 0 0 100
TX: bytes packets errors dropped carrier collisions
654321 4321 0 0 0 0
$ ethtool -S eth0 | grep -i crc
rx_crc_errors: 5
Windows:
> netstat -e
Interface Statistics
Received Sent
Errors 5 0
Common Causes of FCS Errors:
| Step | Action | Expected Outcome |
|---|---|---|
| 1 | Check cable connections | Reseat or replace if loose/damaged |
| 2 | Swap to known-good cable | Eliminates cable as cause |
| 3 | Try different switch port | Identifies faulty port |
| 4 | Check duplex/speed settings | Both ends should match (preferably auto) |
| 5 | Verify cable routing | Move away from EMI sources |
| 6 | Test with different NIC | Identifies faulty NIC |
| 7 | Check cable certification | Use cable tester for Cat5e/6 spec compliance |
A well-functioning Ethernet link should have an error rate below 10⁻¹² (one error per trillion bits). At 1 Gbps, this means less than 1 error per ~278 hours of continuous full-rate traffic. Any noticeable error rate (errors visible in statistics without extended observation) indicates a problem requiring investigation.
FCS errors are often accompanied by other frame error types. Understanding the distinctions helps pinpoint root causes.
Error Type Definitions:
| Error Type | Condition | Common Causes | Relation to FCS |
|---|---|---|---|
| CRC Error | FCS verification failed | All physical layer issues | Direct detection |
| Runt | Frame < 64 bytes | Collision, NIC failure | Usually has CRC error too |
| Giant/Long | Frame > max size (1518/1522) | NIC bug, VLAN misconfiguration | May or may not have CRC error |
| Frame Error | Invalid alignment or length | Duplex mismatch, collisions | Often accompanies CRC error |
| Jabber | Oversized + CRC error | Faulty transmitter | Always has CRC error |
| Late Collision | Collision after slot time | Duplex mismatch, cable too long | Reported separately, causes damage |
Error Pattern Interpretation:
High CRC errors, normal size distribution:
CRC errors with runts:
CRC errors with giants/jabber:
Frame errors without CRC errors:
Isolated CRC errors (rare, intermittent):
Check if errors occur in one direction only. If Device A sees many CRC errors receiving from Device B, but B sees none from A, the problem is in B's transmitter, A's receiver, or the cable's transmit pair from B to A. This directional analysis narrows troubleshooting significantly.
The Frame Check Sequence is Ethernet's primary defense against transmission errors—the final verification that frames arrive intact despite the imperfections of physical media. Understanding FCS enables effective network troubleshooting and quality monitoring.
Module Summary
You have now completed the comprehensive exploration of the Ethernet frame format:
Together, these fields create the robust, self-describing packet format that enables Ethernet's plug-and-play operation and has made it the dominant LAN technology for over four decades.
You now have a comprehensive, expert-level understanding of the Ethernet frame format. This knowledge forms the foundation for deeper exploration of Ethernet switching, troubleshooting, and protocol analysis—skills essential for any network engineer working with LAN technologies.