Ethernet Checksums Are Not Good Enough for Storage

A while ago I described why some storage vendors require end-to-end layer-2 connectivity for iSCSI replication.

TL&DR version: among other things, they might have been too lazy to implement iSCSI checksums and rely on Ethernet checksums because TCP/IP checksums are not good enough.

It turns out even Ethernet checksums fail every now and then.

TCP and IP checksums are simple ones’ complement sums, and we know they’re weak. As Evan Jones explained in his blog, you might expect that one in ~65000 corrupt packets won’t be detected, which combined with pretty low error rates we see on Ethernet these days might be good enough… or not, if you’re Twitter and dealing with petabytes of traffic.

Ethernet CRC is supposed to save the day. After all, a switch receiving a packet checks the CRC regardless of whether the packet is subsequently bridged or routed. Ethernet CRC should reliably detect transmission errors, and the TCP/IP checksums should detect extremely rare intra-device data corruption errors… or so the theory goes.

In practice:

  • Store-and-forward switches drop packet with invalid CRC. Harm avoided.
  • Cut-through switches (becoming yet again ever more popular due to reduced latency) stomp the CRC if the incoming CRC is invalid (see also the excellent blog post by John Harrington)
  • However, layer-3 switches recalculate the CRC1, which thus no longer protects the integrity of Ethernet frame between end hosts.

Evan’s conclusion: if you care about data integrity, implement application-level checksum, preferably using CRC32C, which is implemented in hardware on recent CPUs.

Also note: Stretched VLAN is not a data protection feature for your iSCSI network, in particular if you use Ethernet-over-IP transport like VXLAN or OTV. If the iSCSI or NFS solution you’re using doesn’t support application-level checksums, your data is at risk no matter what.

Finally, how many application-level protocols apart from SSL/TLS and iSCSI (when implemented) implement an application-level checksum? Please write a comment!

Revision History

Rewrote the “what really happens” bit, and added mention of Ethernet-over-IP transport
I misunderstood the main technical argument in Evan’s post. The real problem is that switches recalculate CRC, so the Ethernet CRC is no longer end-to-end protection mechanism.
TCP/IP checksums are not XORs (thanks to Andrew Yourtchenko).

  1. They have to as they decrement TTL and change MAC address. ↩︎


  1. Criag Partridge, from BBN, published a couple of research papers around 2000 based on experiments discussing this issue and related ones
  2. How does cut-through introduce a correct CRC when the incoming one fails? If I understand correctly, the post by John Harrington says that cut-through switches ‘stomp’ the outbound FCS when the inbound CRC fails, meaning they forward a garbage (incorrect) FCS. It gets over all the network (since you cannot un-forward the frame by the time you detect a corrupt CRC), but it reaches the destination with an incorrect FCS. Shouldn't that be detected by the iSCSI endpoint to discard the frame? Or is it that switches actually calculate a new CRC when they route between different subnetworks, without 'stomping'?
  3. You are correct, CRC errors are detected even in case of cut-through switching.
  4. Yes, CRC errors are detected even in cut-through mode, at least on Cisco Nexus 9000:


    Maybe nexus works differently...
  6. Whereas a store-and-forward switch drops invalid packets, cut-through devices forward them because they do not get a chance to evaluate the FCS before transmitting the packet.
  7. Does anyone know how to tell if the switch you are configuring/using is a cut-through type?
  8. I wholeheartedly agree with the idea that one should not rely on the Ethernet or ip/tcp checksums to verify the integrity of your data. These things are very fast to check on a modern CPU and you can avoid incredibly hard bugs.

    It would be a serious bug for a cut-through switch to put a correct CRC on a frame that had an incorrect CRC upon reception and none of the cut through switches available since 2006 have had this bug. The real issue with cut-through and bad CRC is that they don't get dropped and keep using precious bandwidth, though in reality unless you have a lot of FCS errors in your network, this is not a big deal at all.

    Also note that Ip checksum is only on the header. TCP checksum covers the payload with a weak 16b ones complement checksum. So UDP packets basically rely only the ethernet CRC to protect the payload.

    What can happen very rarely is a piece of networking equipment could have some memory where some bits are stuck at 0 or 1. If that memory buffers packets after the CRC is checked and happens not to be protected with parity or ECC, packet payload is now corrupted and the networking equipment generates a new CRC that is correct for the corrupted payload. Here's a good description of such a failure from Edgecast ( Verizon CDN ):
    1. You (and everyone else) is absolutely right - I misunderstood the main technical argument in Evan's post. Fixed.
Add comment