Baby jumbo packets and Draytek Vigor 130 modem

[tomp]

Hi All

I am trying to get baby jumbo packets working over my VDSL connection. I am using the Draytek Vigor 130 modem that supports them.

This has allowed me to set my firewall's ethernet interface that is handing PPPoE to MTU of 1508, and in turn set the PPPoE interface to 1500.

This is working OK, I have proved that baby jumbo packets are working because I can ping hosts on the internet using a payload size of 1472 bytes (which plus the 28 byte overhead for ICMP and IP) means I'm getting an MTU of 1500 to the Internet.

However my TCP connections appear to be having their MSS clamped to 1420 upstream of my modem.

I've ensure that MSS clamping is disabled in rp-ppoe and in iptables and have used TCPDUMP on the ethernet interface to prove that packets are leaving my firewall with an MSS of 1460.

However using tcpdump on the far end server too, I can see that the MSS is being converted to 1420.

I dont thing this is the farside ISP running the server as I see it happening from all IPs and I've done a server-to-server transfer when MSS of 1460 was preserved.

I believe something in BT/IDNET network is clamping the MSS upstream of my modem.

Has anyone any experience with this?

Thanks
Tom

[L2020]

Sorry to bump up this topic but I found it when Googling and thought if others come across it then it would be useful to add to it.

It isn't possible to get MTU above 1460 on IDNet as they are indeed clamping the MSS by modifying the TCP SYN.  There will be no problem pinging servers with packets up to 1472 (so 1500 when headers added) if all configured correctly our end, but connections via TCP are modified to advertise a lower MSS with the result the maximum MTU is 1460, no tweaking can change that from our end.

Packets at 1500 (1472 + 28 Headers) traverse IDNet absolutely fine

Code Select Expand


Pinging speedguide.net [68.67.73.20] with 1472 bytes of data:
Reply from 68.67.73.20: bytes=1472 time=103ms TTL=53
Reply from 68.67.73.20: bytes=1472 time=103ms TTL=53
Reply from 68.67.73.20: bytes=1472 time=103ms TTL=53
Reply from 68.67.73.20: bytes=1472 time=103ms TTL=53

Ping statistics for 68.67.73.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 103ms, Maximum = 103ms, Average = 103ms


However, with a TCP connection the MTU will be a maximum of 1460, this will be seen by visiting https://www.speedguide.net/analyzer.php to check the actual MTU being used.  What is happening is that Speedguide.net starts a connection saying it can accept up to an MTU of 1500, however IDNet intercepts this conversation and makes it look like speedguide.net is saying it only accepts a max MTU of 1460, so that is what is negotiated.  Doing this is known as MSS Clamping, not sure why they need to do that in 2020 on a standard Internet connection 

[tomp]

Thanks for confirming. I don't know why they clamp the MSS either. Weird.

[nowster]

Is it iDNet's routers or is it within the OpenReach backhaul?

[L2020]

Is it iDNet's routers or is it within the OpenReach backhaul?

It's not Openreach, I've been with various ISPs and never seen MSS Clamping before.  I've moved from one ISP to IDNet and everything else remained identical my end, I just changed the user name and password and went from MTU @ 1500 to seeing 1460.  I'd say it is IDNet's routers, possibly something done way back to overcome a particular problem some were having with a website and it's stayed ever since.

[robinc]

It's not Openreach, I've been with various ISPs and never seen MSS Clamping before.  I've moved from one ISP to IDNet and everything else remained identical my end, I just changed the user name and password and went from MTU @ 1500 to seeing 1460.  I'd say it is IDNet's routers, possibly something done way back to overcome a particular problem some were having with a website and it's stayed ever since.

This may be of interest https://forum.kitz.co.uk/index.php?topic=19140.0

Perhaps it is worth asking iDnet as they are most likely to know the answer ?