[j-nsp] MX80 MPLS L3VPN Fragment drops

[Phil Mayers]

On 11/05/2012 11:48 PM, Leigh Porter wrote:

> Now, TCP will re-send the segment and it does but then of EVERY
> SINGLE re-transmission the very same half of the datagram is dropped
> inside the MX80 never to be seen again. Which is odd because the
> transfer just happily sent upto hundreds of MB in exactly the same
> way.
>
> Meanwhile the same base station and client is passing lots of other
> traffic without any issues.
>
> There is no packet loss, the interfaces are clean.  There are no odd
> flags on the datagrams in question, they look as though they are
> correctly formatted and wireshark correctly identifies the input to
> the MX80 as fragmented datagrams and reassembles them correctly.
>
> I have a case open for this, but has anybody ever heard of anything
> like this?


Hmm. Way back in the mists of time, I ran into this behaviour on other 
platforms that didn't handle 2nd and subsequent fragments properly; they 
just assumed the IP payload was another upper-layer header and read 
TCP/UDP port info from what were really bytes in the middle of the 
payload. This caused problems with ACLs with layer4 terms in them, and 
you'd get identical similar symptoms - a connection would run and run 
until suddenly the two bytes at that point in the packet were for a port 
blocked by an ACL term, and the packet would drop.

Now, obviously the MX80 shouldn't do that, but I'm wondering if, given 
the symptoms you describe, something similar is happening.

What does the IP payload of the fragments that aren't getting through 
look like if you "ignore" the fragments bits and try to decode it as a 
layer4 header?

Do you have any ACLs (firewall filters) in place?