Can anyone clarify the question "why we need checksum in both layer-2 and layer-3 of OSI layer", Layer-2 would encapsulate the rest of OSI layers into a single unit.

  • If Layer-2 has a checksum, shouldn't this validation be enough?
  • Why we are having checksum validation in different OSI Layers ?
  • 4
    Hi, so far you've asked 15 questions, but you haven't accepted any answers. Please consider going through your old questions, and accepting the answers that were useful Nov 27, 2013 at 10:20
  • IPv6 actually removed some of this redundancy with similar arguments as yours. L3 no long has any form of checksum or CRC, however previously in UDP checksum was optional, with IPv6 it is not. Main argument why we need two, is that IP cannot know/trust that protocol it is running over guarantees data consistency. Indeed, ethernet does not. Ethernet inserts trash to any frame under 46B, which is still valid frame, if IP would rely on L2 delivering correct and only correct bits, IP would not work. (IP deals with this issue, by knowing size of the packet, and won't read extra trash in small ETH)
    – ytti
    Nov 27, 2013 at 15:41

1 Answer 1

  • If Layer-2 has a checksum, shouldn't this validation be enough?
  • Why we are having checksum validation in different OSI Layers?

Simply put, different layers of the OSI model have checksums so you can assign blame appropriately.

  • Suppose there is a webserver running on some system (assume TCP port 80, i.e. OSI Layer 4)
  • Suppose there is a software error in the Operating System of that webserver that corrupts certain IP payloads. (IPv4 OSI Layer 3)

Case 1: Only use Ethernet checksums

If we only rely on Ethernet (i.e. OSI Layer 2) checksums, then that error would go un-noticed until something crashes or throws an error, because the Ethernet NIC would simply transmit the (already corrupted) data that it received from the Operating System IP stack. For sake of argument, let's assume the TCP payload is corrupted, but the Ethernet checksum is fine.

When the IP stack on the other side receives the Ethernet frame, it unpacks the IP payload and delivers it to the webserver. However, the TCP payload in this packet is corrupted. When the web server crashes from data corruption, the developer has no way to isolate whether this was an IP-level failure or a TCP failure (or perhaps something else farther up the application stack).

Case 2: Layered checksums

However, if TCP, IP and Ethernet all have checksums, we can isolate the layer where the error occurred, and notify the appropriate Operating System or application component of the error.

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.