I suspect the only way that we can count "misdelivered" MPLS packets is by looking for missing packets at the receiver, such as by using the sequence number in the PW control word, TCP, or UDP header, depending on the MPLS LSP payload. Thinking about the consequences of an MPLS label somehow becoming corrupted in transit, nothing will happen until the corrupted label reaches the top of the stack. At that time, either the packet will be dropped because the corrupted label isn't in the local LIB, or it is in the database and the packet will be most likely forwarded out of the wrong interface, to be dropped at the next label pop because the label now at the top of the stack is most likely not in that router's LIB. Eventually, the packet will most likely be dropped in the network, or there is a small but nonzero probability that it will be delivered to an incorrect non-MPLS external interface after the last label has been popped. If the payload was a globally routable IP packet (not in an IP VPN) and PHP is in use, then the IP forwarding lookup in the LER may get the packet to the right place (which will most probably be not on that particular LER). Even if PHP isn't in use, if the external interface happens to be to another router in the same IP address space, then again IP forwarding may get the packet to the right place. Of course, it could be a PW control word that gets corrupted, in which case the packets would reach the PW termination point, but would fail the sequence number check if the sequence number is in use and that's the part of the CW that was corrupted. I don't think anything really bad happens if an entropy label is corrupted. An interesting thought experiment. Cheers, Andy On Thu, Jan 9, 2014 at 7:36 AM, Mark Tinka <mark.tinka@xxxxxxxxx> wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled > MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted > MPLS frames so operators can glean this data. This isn't > something I've come across, but it would be good to find > some kind of way to count this across interfaces, if the > routers can detect and report them. > > The known issue about mis-delivery of MPLS frames is poorly- > sized MTU interfaces. I have no empirical data as to how > this can corrupt successive MPLS frames that may fit into > the transit MTU. But in this case, as with any Layer 2 > traffic, not enough MTU = dropped frame. > > Mark. > > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls >