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.
- 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!
- 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).
They have to as they decrement TTL and change MAC address. ↩︎