ietf
[Top] [All Lists]

Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)

2014-01-21 09:59:32

In message <20140117163307(_dot_)GA4577(_at_)pob(_dot_)ytti(_dot_)fi>
Saku Ytti writes:
 
On (2014-01-13 14:11 -0500), Curtis Villamizar wrote:
 
One of the reasons that IPv6 (rfc2460) dropped the header checksum
that was in IPv4 is that with link layers all doing FCS it served no
purpose.  For the same reason TCP and UDP checksums server no purpose.
 
One datapoint from today. Peering router has 4xLACP to core and in one of
these LACP members it is sometimes mangling packets during send and FCS is
being calculated for this mangled data.
All egress PE boxes start logging errors (maybe 1 error per 30min), because
they check IP checksum, which is now incorrect.
 
Router is latest generation service provider router from major vendor running
recent software and affected router is logging no errors.  Can't imagine
when, if ever, would this issue have been found without IP checksums.
 
-- 
  ++ytti
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls


This sounds like a router acting as a host for the given packet.  The
forwarding data paths in routers are usually protected.  If the router
was forwarding and mangled packets, that speak well for the router
vendor since the major vendors claim to protect their data paths from
this sort of thing.  Less so for the path from the route processor.

If this was originated at the router it would also be caught if AH was
enabled.  Were these unauthenticated control plane packets?

You've made a good anecdotal case for keeping TCP and UDP checksums.

Curtis

<Prev in Thread] Current Thread [Next in Thread>