Hacker News Reader

Comment by crispyambulance | Hacker News Reader

The descriptions so far about this problem are either at 30000 foot vagueness or they're in technical shorthand that just assumes the audience is 100% pro network engineers.

Don't "bad packets" get dropped at the first switch? Isn't that one of the main benefits of packet based switching?

Was this even an ethernet packet or something else like an optical transport protocol (eg OTN)?

View on HN

They generally only get dropped if they have an invalid checksum.

Since checksums are hardware accelerated, the invalid packet probably had a valid checksum applied to it.

If cut-through is enabled in the switch, it won't even drop on bad checksum, since by the time the switch can tell the checksum is wrong, it has already forwarded the entire packet.

It is really unfortunate that the checksum is on the opposite end of the frame from the routing information on Ethernet frames.

Why? If it was at the start it’d remain useless until the whole frame was received anyway.

Makes sense to have it at the end.

It also allows you to calculate the checksum as your serialising the packet data onto the send buffer, without having to get the whole packet in memory, checksum it, write the checksum, then finally write the packet data.

It'll just log it... and then you get to play "let's find where it's coming from" as each switch just forwards that bad boy on as fast as possible.

In addition, a valid checksum is no guarantee that the packet is valid. They are very weak hashes, not cryptographic. If a NIC goes haywire and sends "random" data at wire speed, there will be bad packets with valid checksums.

Reply on news.ycombinator.com