MTU settings

[#1]

Since switching to Windows 8 I am having problems with some web pages timing out, normally to fix this I turn off my router firewall. I have just been having a google and it says that my MTU settings could be too high. I have done the ping test with the equivalent parameters ping -f -l bbc.co.uk and I get fragmented packets untill I hit 1444.
My question is do I put 1444 as my MTU or do I add the 28 and put 1472 as my MTU ?
My previous MTU as set as default by my router was 1492, and in my router settings it says my MTU should be 1454 and not to change unless stated by my ISP.
Thanks for reading.
Edit :
ADSL2+

[#2]

For both ADSL and FTTC you can use a MTU of 1500.
You'll need to change it on the router and your Windows machine.

[#3]

Having tried probably ten or so different ADSL modem/routers, I found that MTU was dependent on the model of modem, and not on what the broadband line was capable of.
For example I can use 1500 with any Linksys or Billion device, 1492 on my DrayTek, although neither value gives optimum throughput.
My Netgear DG834GT didn't like an MTU above the high 1460s, and used to cause page load fails on particular websites.
I have found with PPPoA ADSL, when in doubt, use either 1458 or 1430, and see which one speedtests fastest.

[#4]

Thanks for your replies,
I tried 1444 and couldn't get speedtest to load, it just kept saying This page can't be displayed. I put it to 1472 and speedtest loaded, so I will let my profile settle down and then try the 1458 or 1430.
Kitz says the maximum MTU is 1500, so if I set my MTU to 1500, wouldn't that make it 1528 with the overhead ?
Sorry for all the questions, I am just trying to get my head around it.
Kitz website :
"In the example above it shows that my highest responsive ping is 1402.
From this we need to add on 28 to get the maximum MTU figure.
(28 being the header size for IP + ICMP)
Do not go above 1472. (1472 + 28 = 1500 MTU) since 1500 is the maximum MTU."
So in the above example, does Kitz put 1402 into the router MTU setting, or 1430 ?

EDIT:
This is the message I keep getting when pages don't load
This page can't be displayed
•Make sure the web address http://community.plus.net is correct.
•Look for the page with your search engine.
•Refresh the page in a few minutes.
Swap Plus.net with any website in the above situation as it doesn't discriminate.

Looks like I will have to turn off my router firewall again  

[#5]

The MTU setting should be the total size (i.e. payload + headers).

[#6]

I'm on fibre & have tested my MTU. It works out to 1464+28 which equals 1492.
My system is currently set to 1500.

[#7]

use 1492 on fttc, 1500 will work if you can take advantage of baby jumbo frames and rfc 4638
on adsl use 1500.

[#8]

Quote from: chrcoluk

baby jumbo frames and rfc 4638

Although BT's equipment does, PlusNet's doesn't support RFC 4638.
So the router's MTU for fibre needs to be 1492 because 'fibre' connections use PPPoE and the 8 bytes for the PPP header have to come out of the available 1500 in the ethernet frame, rather than being added to it.
For PPPoA, as used on ADSL connections, the correct router MTU is 1500, the same as normal ethernet.
If you've set your router lower than that, PitchBlack, and your Windows machine is set to the ethernet default of 1500 you may occasionally get problems with some sites. Mostly MSS clamping at the router will take care of it, but not always. On ADSL you should be able to avoid those problems by setting everything to 1500. On fibre products, that option isn't available.
So your problem, paradoxically, may not be that your MTU is too high, but that it is too low. It's all a question of which MTU - router or PC.
You're looking at the ping test the wrong way round. It's a way to discover the path MTU, not a way to set your router's MTU. By sending a large echo request with the Do Not Fragment bit set you can establish the largest ICMP payload which will get through (since you receive a reply). Since you know the ICMP header is 8 bytes and the IPv4 header adds a further 20 bytes, you can infer that the maximum transmission unit in bytes along the path from your PC to whatever site you are pinging is these three numbers added up.
If you reduce the MTU set on either your router or your PC then the path MTU will go down!
When TCP on your PC first establishes a connection to a web server it tells the server the maximum segment size (MSS) it can accept. MSS is a concept specific to TCP (so not ICMP or UDP). By default, the TCP stack calculates the figure to advertise by looking at its own link MTU (which will normally be 1500 bytes on an ethernet LAN) and subtracting the space needed in the packets which the server is being asked to send for the fixed headers for TCP itself (20 bytes) and for the Internet Protocol which will encapsulate them (a further 20 bytes for IPv4, just the same as with ICMP over IPv4 above). It's up to the sending server to then send the data you've requested in packets no bigger than that. It can send smaller ones and will also adjust the amount of actual payload data in the TCP packets to accommodate the space needed for variable headers like timestamps.
(The server also does the same in reverse, telling your PC the maximum size of packets it can accept, so there can actually be two different MSSs in operation for the same TCP connection - one for each direction. Generally the upstream one doesn't matter much because you will only be sending small acknowledgement packets to the server, way under the maximum size it can accept.)
The potential problem arises where your router has a lower WAN MTU than your PC's LAN MTU, from which the MSS has been calculated. Then the web server will think it can send bigger packets than it really can without them being fragmented - because that's what it has been told. On the occasions when the mechanisms for dealing with that don't work (usually because of a firewall issue,) you end up with a problem.
It may not happen that often (which is why fibre users aren't up in arms,) but it does happen. So life would be a bit simpler if home routers and ISPs implemented RFC 4638, which addresses this mismatch for PPPoE connections. However, in your case, since you are on ADSL, you can just set everything to 1500 and not worry about it.
Note that, by contrast, if you do reduce the MTU on your PC for whatever reason, as opposed to on your router, that shouldn't cause any huge problems. The potential  issue arises where the router's WAN MTU is lower than your PC's.

[#9]

Quote from: SuperZoom

Although BT's equipment does, PlusNet's doesn't support RFC 4638.

Are you sure about that?
I can send an unfragmented 1500 byte payload through PN's network.

[#10]

Haven't tested personally, I'm just going on what I was told by tech support in ticket #74073564 on 16/09/2013:

Quote

I have been in touch with our products team to clarify the question regarding the MTU and I have been told that our core supports an MTU higher than 1492 but the LNSs won't negotiate an MTU higher than 1492 on a PPPoE connection (or 1500 on PPPoA) so doesn't support RFC4638.

[#11]

I think they've changed it since then - I'm trying to dig out the thread post, but someone said that they support 1500 now.
I know for v6 I've had problems with the MTU being set to 1500. I don't think it was ever established what the cause was though.

[#12]

If your router has support for RFC 4638 and logs the PPP session setup, you could just gateway hop and post the log.
I never bothered doing anything about setting it up since I was told there was no support.
I presume PlusNet's own routers won't be able to do it because they don't have gigabit WAN ports even if the ppp on them were to be upgraded, so are unlikely to be able to handle the larger frames.
I'm not on the IPv6 trial, but of course fragmentation isn't allowed in the path in v6 and things get messy if key ICMPv6 packets are blocked anywhere.

[#13]

Quote

$ tracepath pingbox1.thinkbroadband.com 1:  192.168.1.100                                        0.155ms pmtu 1500 1:  router.asus.com                                      0.451ms 1:  router.asus.com                                      0.406ms 2:  lo0-central10.ptw-ag03.plus.net                      60.758ms asymm  3 3:  link-b-central10.ptw-gw02.plus.net                    5.514ms asymm  6 4:  xe-4-3-0.ptw-cr02.plus.net                            6.462ms 5:  lonap-gw1.thdo.ncuk.net                              5.663ms 6:  te1-1-1-31.core-rs2.thdo.ncuk.net                    6.055ms 7:  pingbox1.thinkbroadband.com                          5.653ms reached     Resume: pmtu 1500 hops 7 back 58

IPv6 is another issue....

[#14]

That's a funny looking PPP log!   
So you can ping the BBC with a 1472 byte payload and the DF bit set over IPv4 can you?
Would be interesting to see the PPP session setup log, if so.
Does it depend which gateway you connect to and whether or not you also have an IPv6 connection, or is this now a permanent change for everyone on PPPoE?
If it is, I'll look at using it.
The official word? Dave? Kelly?...

[#15]

Sorry, I am trying to figure out the PPP log (using RP-PPPoE). I've put it into debug mode but it's not showing anything. It does seem to crash three times daily at the moment though

Quote

~$ ping -c 3 -s 1472 -M do bbc.co.uk PING bbc.co.uk (212.58.244.20) 1472(1500) bytes of data. 1480 bytes from fmt-vip71.telhc.bbc.co.uk (212.58.244.20): icmp_req=1 ttl=55 time=5.69 ms 1480 bytes from fmt-vip71.telhc.bbc.co.uk (212.58.244.20): icmp_req=2 ttl=55 time=5.99 ms 1480 bytes from fmt-vip71.telhc.bbc.co.uk (212.58.244.20): icmp_req=3 ttl=55 time=5.78 ms --- bbc.co.uk ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 5.699/5.825/5.992/0.151 ms

Quote

~$ ping -c 3 -s 1473 -M do bbc.co.uk PING bbc.co.uk (212.58.246.104) 1473(1501) bytes of data. From 192.168.1.100 icmp_seq=1 Frag needed and DF set (mtu = 1500) From 192.168.1.100 icmp_seq=1 Frag needed and DF set (mtu = 1500) From 192.168.1.100 icmp_seq=1 Frag needed and DF set (mtu = 1500) --- bbc.co.uk ping statistics --- 0 packets transmitted, 0 received, +3 errors

I would think it's a change for everyone.
Edit: I should add - using an MTU of 1500 does seem to cause me issues. I get a lot of "waiting for xxx.com" on quite a few sites (not sure if this is v4 or v6 specific).