What is the purpose of checking errors in almost every layer of a network?

For example, I don't see the purpose of using a checksum in TCP given that CRC has already been checked in lower layers. Or checking md5sum in application layer given that TCP has it's own checksum technique. Isn't it inefficient?

  • 4
    That is not guaranteed. TCP can run over other transmission media besides Ethernet. Also, the checksum at higher levels checks for errors at higher levels. Not doing that would assume that all processing from the channel up is 100% error free, which is not necessarily true either.
    – Daniel
    Commented Apr 7, 2016 at 16:11
  • FYI, ATM doesn't have any error checking/correction.
    – Ricky
    Commented Apr 7, 2016 at 19:40
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Commented Aug 8, 2017 at 2:39

4 Answers 4


If a packet gets corrupted on the wire, then the Ethernet FCS should catch that. However, many switches and routers will strip off the FCS, route the packet, and then compute a new FCS. If the packet gets corrupted while being shuffled around inside the switch (which happens occasionally), then you will end up with a corrupt packet that has a valid Ethernet FCS. This is why error detection is performed at multiple levels. It is also common to perform checks at even higher levels - say, checking the hash of a large downloaded file just in case something else about the transfer got screwed up (packet corrupted such that tcp missed the error, or perhaps the server sent the wrong data to the tcp stack in the first place, or the data got corrupted when read off of the disk or out of the server's RAM and the TCP segment offload engine on the NIC got bad data, etc.).


Remember that each layer is independent of every other layer, and the original design of each protocol in a layer is that my layer cannot depend on your layer doing any error detection, or the error detection which my layer requires. Also, if you have a datagram which is destined for a particular layer (e.g. ARP for layer-2, or ICMP for layer-3), the layer for which the datagram is destined wants to be sure the datagram is valid as received, and it wasn't mangled between layers.

To your point, IPv6 has actually dropped error detection on packets because it assumes that the layers above and below it will perform error detection.


You didn't specify what protocol or media TCPs running on in your case, but assuming IP, the checksums calculated by the sender and checked by the receiver only verify the packet headers, not the pay load.

As pointed out by others TCP can run on other protocols and media that may not provide data integrity, but TCP in accordance with RFC793, must guarantees data integrity, thus it does a check of the data itself.

  • It's true that the IPv4 Header Checksum only validates the IPv4 header, but the ethernet (most common layer-2 protocol where hosts connect) Frame Check Sequence validates the entire frame, including the frame payload (packet) and any padding. Other layer-2 protocols can do it differently.
    – Ron Maupin
    Commented Apr 7, 2016 at 23:07
  • @RonMaupin You are correct, I edited my post.
    – Brian Duke
    Commented Apr 8, 2016 at 0:19
  • 1
    It guarantees data integrity assuming that the TCP stack got good data in the first place. If the data gets corrupted on the PCIe bus while on the way to the TCP offload engine on the NIC, then the data integrity guarantees of TCP are pretty much moot. Commented Apr 8, 2016 at 3:03

As Daniel said:

The checksum at higher levels checks for errors at higher levels. Not doing that would assume that all processing from the channel up is 100% error free, which is not necessarily true either.

That pretty much sums it up. The multi-level error checking will also catch errors that occur during transmission between layers since no data line is noise-free.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.