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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <20140117163307.GA4577@xxxxxxxxxxx>
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@xxxxxxxx
> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]