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?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
