4 ms·
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 netwo
by crispyambulance 8y ago
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)?
- extrapickles 8y agoThey 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.
- kijiki 8y agoIf 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.
- loeg 8y agoIt is really unfortunate that the checksum is on the opposite end of the frame from the routing information on Ethernet frames.
- topranks 8y agoWhy? 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.
- kiallmacinnes 8y agoIt 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.
- X-Istence 8y agoIt'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.
- swinglock 8y agoIn 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.