> On Dec 14, 2015, at 12:59 PM, Saku Ytti <saku@xxxxxxx> wrote: > > On 14 December 2015 at 17:38, Alexey Eromenko <al4321@xxxxxxxxx> wrote: > > Hey, > >> * Slow-down of Core Routers. > > Citation needed. I believe checksum and CRC are linerate and pretty > much free in terms of pincount, transistor and thermal. Yes, most hardware has offload in silicon for your desktop/wifi/ethernet chipsets so the host doesn’t even do this. >> Any advantages ? >> * prevents single mis-routed packets, or a bad option from getting through. > > Prevents packet mangling, if done right. If there is L3 CRC (not > checksum, it's too weak) which excludes changing data (hop count) and > specification mandates that it's not recalculated on egress, but > ingress value is reused. Then it will guarantee that router or switch > does not mangle the data. > >> Quick result: besides ATM, everybody else seems to cover both headers >> and all data. > > Arbitrarily strong guarantee at L2 does not guarantee integrity at L3. > Routers and switches (not fibres/copper!) mangle data and calculate > correct L2 CRC on the broken data. > I've unfortunately seen[0] this several times in real networks and I > know other[1] networks who've seen it as well . I got lucky and was > using IPv4, which made the error visible in egress LER's, had I been > running IPv6 only, I would have never known that I'm mangling some > packets. > > [0] http://mailman.nanog.org/pipermail/nanog/2014-January/063654.html > https://www.ietf.org/mail-archive/web/tsvwg/current/msg12457.html > [1] http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html I’ve also seen this mangling in production, specifically with an employee with backhaul over wireless equipment that corrupted the body of a packet triggering downstream application bugs, eg: https://www.debian.org/security/2011/dsa-2276 This is not that common, but does occur. I’ve also seen similar issues in OTN hardware that is unhappy with ethernet frames of certain sizes. - jared