Actually, given the nature of browsers these days, it is not at all unlikely that your request to the Juniper web server contains 1280+ octets of HTTP header data and thus is the largest packet. I think if you investigate further you will find that most flows stall at the point of a TCP packet larger than N octets payload hitting the Juniper from the LAN side and being small enough that it doesn't generate a PTB message, so it gets silently dropped. At least that's what happened in my environment before I reduced the tcp-mss as described in my earlier message. And to Warren, yes, not fragmenting in the network _IS_ actually better. Owen On Oct 1, 2014, at 09:30 , Chuck Anderson via Outages <outages@outages.org> wrote:
On Wed, Oct 01, 2014 at 08:14:52AM -0700, joel jaeggli via Outages wrote:
On 10/1/14 6:50 AM, Chuck Anderson via Outages wrote:
While on my Hurricane Electric IPv6 tunnel, I cannot access juniper.net unless I change my local interface MTU. 1500 fails, but 1280 works. I noticed this a few days ago. Before that I had no problems with a 1500 MTU. Is anyone else seeing this issue?
The MTU of your tunnel is lower than 1500.
Chances are the service on the other end isn't able to recieve pmtud messages because it's load-balanced... and the first packet that triggers that (ptb) is sent towards your tunnel ingress.
Chances are the first large packet is from the server end, not my client end. So if www.juniper.net sends a 1500-byte packet, it should arrive at the HE.net tunnel router and that router should send a PTB back to the server. Are you saying the PTB might not be received by the server because it is behind a load-balancer? Shouldn't the load-balancer handle the PTB directly in that case since it terminates the TCP connection? _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages