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
- 2023-04-14
- Rewrote the “what really happens” bit, and added mention of Ethernet-over-IP transport
- 2015-12-06
- 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.
- 2015-11-15
- TCP/IP checksums are not XORs (thanks to Andrew Yourtchenko).
-
They have to as they decrement TTL and change MAC address. ↩︎
"http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5020-switch/white_paper_c11-465436.html"
Maybe nexus works differently...
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 ):
https://www.verizondigitalmedia.com/blog/2015/02/being-good-stewards-of-the-internet/