Kitz Forum
Internet => General Internet => Topic started by: Weaver on February 13, 2020, 03:31:33 PM
-
Are you using an IP MTU below 1492 bytes? Is that for IPv4, IPv6 or both? What are the circumstances ? Any problems encountered in the Internet as a result?
I ask because if I were to start combining technologies, like DSL and LTE then I assume that would mean using L2TP and hence reduced MTU.
-
Are you using an IP MTU below 1492 bytes? Is that for IPv4, IPv6 or both? What are the circumstances ? Any problems encountered in the Internet as a result?
I ask because if I were to start combining technologies, like DSL and LTE then I assume that would mean using L2TP and hence reduced MTU.
i am using 1452 i tried using 1492 but i was getting pkt loss in my games and i also faced websites not loading properly when i tried different MTU sizes dont know it is related or not
and in my modem and router i can select 1492 as max and also i changed MTU size in windows settings too
-
Thanks Neil. You had certain problems with particular website before with MTU 1492 ?
-
Replying on behalf of neil . . .
He started a thread, "modem/router/PC MTU size (https://forum.kitz.co.uk/index.php/topic,24097.msg405860.html)", late last November (2019) and in Reply #10 posted the following --
i have turned on ping and other stats in game settings it shows pkt loss for upstream 1-10-15% and sometimes it hit 50% during start of game for downstream it is all fine
and i am getting fragmented after 1452
>ping bbc.co.uk -f -l 1453
Pinging bbc.co.uk [151.101.0.81] with 1453 bytes of data:
Reply from 192.168.1.1: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
-
Thank you my friends. One adds on 20+8 to that, is that correct? So what is the significance of 1452 + 20 + 8 = 1480 ?
-
I'm not sure as to the significance but the evidence is clear . . . with a MTU set greater than 1452 fragmentation would occur. Of course we do not have any knowledge of how the ISP/CP deploys a service in Pakistan.
-
Indeed
-
Thanks Neil. You had certain problems with particular website before with MTU 1492 ?
it was default 1400 in my modem before any changes. And in windows it was 1500. I will test again with 1492. Not just 1492 i tried different values randomly i think i also set very low value too less than 1000 Websites were not loading properly had to refresh a few times.
I am using 1452+28 header because it is default in my router. 1480 is mentioned in router settings
-
now i am using 1492 MTU size in router settings. And after windows update MTU size of windows has been reset to 1500
-
You should leave it set to the default (1500) in your PC and use one of the online MTU test (http://www.letmecheck.it/mtu-test.php) tools to find your internet connection’s MTU but you might have to temporarily increase the router MTU value to 1500 too to find out what the true bottleneck MTU is (MTU of the internet connection itself, not just your router). Now, someone can remind me what is wrong with the IPv6 function on that test?
-
You should leave it set to the default (1500) in your PC and use one of the online MTU test (http://www.letmecheck.it/mtu-test.php) tools to find your internet connection’s MTU but you might have to temporarily increase the router MTU value to 1500 too to find out what the true bottleneck MTU is (MTU of the internet connection itself, not just your router). Now, someone can remind me what is wrong with the IPv6 function on that test?
this test is showing 1500 MTU size but when i test on windows cmd using ping 8.8.8.8 -f -l 1464 then i get packets need to be fragmented after 1464
-
So 1464 + 28 = 1492 which is your IP MTU for PPPoEoE, which is the normal value you would expect for anyone using a PPPoEoE modem. The standard value for two-box systems with separate modem and router.
Now you probably know all this anyway, but if not: the value 1492 = 1500 - 8 is the IP MTU less the PPPoEoE header overhead of 8 bytes, an overhead which reduces the size of IP packets down from the standard 1500 bytes on the LAN. So you can set your MTU in your router to 1492 or lower, higher is better clearly. You probably don’t need to do anything as 1492 should by the default for any PPPoE user.
Unless that is you are fortunate to have a ‘baby jumbo’, larger MTU link with a PPP MTU of 1500+8=1508, as I do (my IP MTU is 1500=1508-8, not 1492=1500-8, for this reason). I can send/receive full size 1500 byte IP packets, not just 1492 bytes long. Gives me a microscopic edge in performance and a theoretical advantage on the internet which is rather unrealistic. :angel:
Neil’s MTU doesn’t have to be so low surely, at 1492 bytes it should be fine. I seem to remember some home routers that have really low default MTU settings for god knows what reason.
I was wanting to ask about people’s experience who have an MTU rather lower than 1492 though. If I start to consider a situation where I’m forced to live with a lower MTU because of L2TP say, then I would like to know what I’m getting into. ;D My 3G USB NIC ‘dongle’ has a really really low MTU.
-
Many years ago, TalkTalk required a silly-low MTU setting. Fortunately that has long been consigned to history.
As PPPoA user I can, with my ZyXEL VMG1312-B10A, have a full 1500 bytes MTU --
[bcat ~]$ ping -c1 -Mdo -s1473 forum.kitz.co.uk
PING forum.kitz.co.uk (185.24.98.37) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- forum.kitz.co.uk ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 999ms
[bcat ~]$ ping -c1 -Mdo -s1472 forum.kitz.co.uk
PING forum.kitz.co.uk (185.24.98.37) 1472(1500) bytes of data.
1480 bytes from kitz.servers.eqx.misp.co.uk (185.24.98.37): icmp_seq=1 ttl=55 time=56.5 ms
--- forum.kitz.co.uk ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 99ms
rtt min/avg/max/mdev = 56.592/56.592/56.592/0.000 ms
[bcat ~]$
-
I use an MTU of 1478, set on the wlan0 interface of my computer. It results in very slightly more usable bandwidth for larger bulk downloads due to less wastage on ATM cell padding. I've done this for the past few years and not noticed any problems due to it. I don't think an MTU of 1500 is advantageous on ADSL due to the aforementioned ATM cell padding.
-
@ejs Agreed. I would do better by using an optimal ATM cell multiple, but from my calculations it would seem that the difference is not that much. I do use an optimal value for ATM with IPv6 traffic of 1408, 1408+32 = 1440 = 48 * 30. This small IPv6 MTU is to do with failover to 3G using my USB 3G NIC which has a very low MTU, so I lowered it even further to get cell optimality.
I presume you’re using 1478+10=1488=48*31, am I correct ?
I haven’t noticed any weirdness anywhere from using this low value for IPv6 (only, IPv4 is 1500).
* I should have pointed out that in the above calculation regarding my own choice for packet size, 32 is the overhead in bytes that I have with PPPoEoA, and 1440 happens to be the MTU of my 3G NIC iirc, and coincidentally that value is also a perfect cell multiple.
-
Are you using an IP MTU below 1492 bytes? Is that for IPv4, IPv6 or both? What are the circumstances ? Any problems encountered in the Internet as a result
Not me but a customer, on their WAN they have MTU 1476, MSS 1360. They had some odd malfunctions until we forced that MSS. On their Internet VPN they have MTU 1434 with the same MSS over-ride. It's been a while so can't remember, maybe we set MSS deliberately low on the WAN so it's the same as the VPN. Wouldn't swear to that. I just remember we had to set that MSS over-ride when the started using DMVPN over the private WAN around 5 years ago.
-
I use an MTU of 1478, <snip>
I need a memory refresh, please.
I know that an ATM cell is 53 bytes, made up of a 5 byte header and a 48 byte payload. Dividing the "magic number", 1500, by 48 and rounding down to an integer gives 31. Multiplying 31 by 48 gives 1488.
So what is the reason for (or the significance of) the 10 byte difference? :help:
-
Should that MSS be the IP MTU minus the IPv6 and TCP headers = -60 ? Why isn’t TCP subtracting this automatically ? Presumably it doesn’t know about the tunnel, which comes later? And PMTUD isn’t helping, for whatever reason.
What happens if your TCP is with timestamps which adds another so many bytes? Need to adjust the MSS down even more in that case?
-
My example was all IPv4. As for why it wasn't done automatically I don't really know, all I know is that we've seen occasional funnies with tunnels or VPNs, for example, one customer everything worked except RDP. I'm going blame Microsoft IP stack and applications, given that I've seen Lync think it's a good idea to send video in 9K jumbo frames - with do not fragment set!
-
Lync doesn’t understand PMTUD properly then? MS only tested it across their own jumbo LAN, never through a router? ;D What a shower.
The thing is, if you go to work for Microsoft probably everyone wants to go and work on something prestigious like operating systems or Azure or even Word or Excel’s innards (which are really hard imho) and not on printer drivers or setup programs. That’s why such peripheral software items are often rubbish, because they don’t have the best people or most driven people maybe, just the B team who didn’t make the cut for the sexy teams. So much for my theory, I’ve never worked for Microsoft, just in another such o/s dev environment, albeit a minute version relatively speaking.
-
@burakkucat I was asleep so missed your post. The 10 bytes is I expect 2 bytes for PPP + 8 bytes for the ATM AAL5 CPCS trailer - an overhead at the end of the last cell. That 10 = 2 + 8 bytes is for the PPPoA case, so I assume that’s what our user is running.
One has to add the overhead including always the 8 bytes CPCS trailer and then round up as you divide by 48, either that or pre-add 47 and divide by 48 with the division rounding down. Then multiply by (48+5) to get the total number of bytes on the line. My PPPoEoA total overhead is 32 bytes :'( including everything and then calculate the number of cells required to hold that by division that rounds up.
-
@burakkucat I was asleep so missed your post. The 10 bytes is I expect 2 bytes for PPP + 8 bytes for the ATM AAL5 CPCS trailer - an overhead at the end of the last cell. That 10 = 2 + 8 bytes is for the PPPoA case, so I assume that’s what our user is running.
Thank you. I was just trying to understand the 1478 bytes MTU that ejs has set.
-
Ejs has presumably picked an optimal value 1488= 31 * 48 an integer multiple of 48 for the total on-line byte count, and then subtracted the PPPoA overhead of 10 bytes to get the PPPoA payload which is the correct optimal IP MTU. So IP MTU = n_bytes_on_line - header_overhead = 1488 - 10, where 10 bytes = 2 + 8. There’s always that one-off final-cell trailer overhead of 8 for the CPCS, and so the last cell can only hold 40 bytes of AAL5 payload, not 48. Any more and an additional cell is required.
Another example: My own numbers are 1440 - 32 = 1408 where 1440 instead of 1488 is an integer-multiple of 48 low enough to be within the MTU of my 3G USB NIC, including protocol overheads, and 32 bytes is my PPPoEoA overhead, instead of 10 bytes. Hugely bloated is PPPoEoA. This gives me 1408, the IPv6 MTU I use now.
See also Wikipedia on PPPoE overhead (https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_Ethernet#Protocol_overhead), which I wrote some years ago. ???
Does that make sense? I used to use this perfect MTU many years ago, perfect for one-box ATM ADSL users.
Should of course simply ask Ejs :)
-
Just out of interest I checked our LTE interface at home, never having done so before. It reports 1500 bytes MTU, and if I not losing my marbles that's confirmed by being able to ping with data length of 1472 without fragmentation. Are you factoring in L2TP for you 3G, or does it just have a low MTU for some reason?
-
The 3G USB NIC just has a really annoyingly low IP MTU anyway, 1440 iirc.