Junos OS

Hi,

I initially completed tests for MSS and thought it was resolved, but it has started happening again. Certain websites are loading very quickly and other websites are taking a while and some are not responding at all. I expect this is to do with MSS is some form or another. I have set our MSS to be 1410 which, as I have mentioned, seemed to resolve the issue, but it has started again.

Here is the route the traffic will take and where I have configured the MSS:

CPE --> LAC --> LNS (BNG si interface) --> LNS (BNG ae1 interface) --> Core MX ae1 interface --> Core MX eBGP xe-1/2/5 interface --> upstream ISP.

I have configured MSS on the eBGP interface xe-1/2/5 interface (directly on the interface and not the eBGP group)

Is there anything I can do to test this to ensure that the MSS is okay?

rom 17.1, you can configure TCP-MSS under dynamic-profile. You can pick 17.3R3 once available.

set dynamic-profiles dyn-lns-profile3 interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" dial-options l2tp-interface-id l2tp-encapsulation

set dynamic-profiles dyn-lns-profile3 interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" dial-options dedicated

set dynamic-profiles dyn-lns-profile3 interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" keepalives interval 30

set dynamic-profiles dyn-lns-profile3 interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" family inet tcp-mss 1460

set dynamic-profiles dyn-lns-profile3 interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" family inet unnumbered-address lo0.0

set dynamic-profiles dyn-lns-profile3 interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" family inet6 tcp-mss 1460

Regards,

Rahul

In your scenario, you fix mss only in one direction(from client), configuration from Rahul's example will change mss for both direction and should work fine. 

P.S. this will work for l2tp traffic only

If this is one direction only, how do other ISPs get around this issue with older versions of Junos?

Thanks

it is depends ... In most cases this work is done on  CPE

I have completed a check with the following website: www.bbc.co.uk.....

I also completed a wireshark trace while connecting to the website. So, the actual writing data appears immediately but any Pictures etc take approximately 25 seconds to appear, even though the site should be cached. 

So, from my wireshark trace it seems that Windows sends, default, an MSS of 1460. The website is responding to the SYN with a SYN,ACK of 1410. This would, at first glance, seem to be okay. So, it will negotiate at 1410 which is what I have configured on the interface of the PE Router. This is why the initial writing appears immediately. But then, when I look further down the trace to the point where I believe the images should beappearing I see the following:

ACK - Length = 1300 and sometime even less than that for the saem ack number. This would appear to me, maybe, like fragmentation occuring? Here is a seciton of the trace I mean:

Initial SYN/SYN ACK

46 2.382020 192.168.1.11 212.58.244.70 TCP 66 50783 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 SACK_PERM=1
54 2.420046 212.58.244.70 192.168.1.11 TCP 58 443 → 50783 [SYN, ACK] Seq=0 Ack=1 Win=0 Len=0 MSS=1410

Possible Fragmentation occuring:

624 2.941001 212.58.244.70 192.168.1.11 TLSv1.2 1354 Application Data [TCP segment of a reassembled PDU]
625 2.941042 192.168.1.11 212.58.244.70 TCP 54 50783 → 443 [ACK] Seq=1038 Ack=282907 Win=64235 Len=0
626 2.941375 212.58.244.70 192.168.1.11 TCP 819 443 → 50783 [ACK] Seq=282907 Ack=1038 Win=30952 Len=765 [TCP segment of a reassembled PDU]
627 2.941406 192.168.1.11 212.58.244.70 TCP 54 50783 → 443 [ACK] Seq=1038 Ack=283672 Win=65535 Len=0
628 2.943089 212.58.244.70 192.168.1.11 TCP 1354 443 → 50783 [ACK] Seq=283672 Ack=1038 Win=30952 Len=1300 [TCP segment of a reassembled PDU]
629 2.943136 192.168.1.11 212.58.244.70 TCP 54 50783 → 443 [ACK] Seq=1038 Ack=284972 Win=64235 Len=0
630 2.943494 212.58.244.70 192.168.1.11 TCP 1354 443 → 50783 [ACK] Seq=284972 Ack=1038 Win=30952 Len=1300 [TCP segment of a reassembled PDU]

Is this correct operation or should the length still = 1410?

The above information I posted could be false readings.

From my understanding, the MSS is negotiated during the SYN and SYN/ACK stage and is never changed during the whole TCP connection conversation. The segment size has nothing to do with it as that is to do with the windowing itself and does not have to conform as such. As long as the Window size is under 65535 then it should be okay.

So, if this is the case, then I guess the only question I really need to ask is:

Why does the text appear immediately and the images (even small ones) can take 15 to 20 seconds and in some cases longer (even when they are supposedly cached)?

Okay, I have narrowed it down.

If I turn off the IPv6 on the CPE, all websites work perfectly. It does appear that some websites use IPv6 for their image storage area, although that would not explain why no images are downloaded, or take a long time to download, when IPv6 is turned on.

Any ideas to investigate further?

Okay.

I'll close this off as resolved.

I re-enabled IPv6 on the CPE and retested and all worked fine.

This will reuqire ongoing investigation when we come across "problem" sites.

Thanks