What value of MTU to set in router?

Topic

New Reply

The MTU value is not something I’d normally mess with, but finding a couple of articles about the preferred maximum setting caused me to do some experimenting. My work’s router MTU value is currently set to 1472.

The articles suggest using PING of any external website with the flags
-f Set ‘Don’t Fragment’ flag in packet (IPv4-only)
-l size The Send buffer size
and varying the buffer size value downwards from some value like 1500 until the packet does not fragment.

I had to change the buffer size all the way down to 1272 before I got the messages to change from:

ping bbc.co.uk -f -l 1274
Pinging bbc.co.uk [212.58.246.79] with 1274 bytes of data:
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.
Ping statistics for 212.58.246.79:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

to become:

ping bbc.co.uk -f -l 1272
Pinging bbc.co.uk [212.58.246.79] with 1272 bytes of data:
Reply from 212.58.246.79: bytes=1272 time=47ms TTL=51
Reply from 212.58.246.79: bytes=1272 time=48ms TTL=51
Reply from 212.58.246.79: bytes=1272 time=47ms TTL=51
Reply from 212.58.246.79: bytes=1272 time=48ms TTL=51
Ping statistics for 212.58.246.79:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 47ms, Maximum = 48ms, Average = 47ms

As a result of this, by adding the required 28 ‘header’ bytes the ‘best’ MTU value is supposedly 1300 bytes.

Does this low value surprise anyone? Should I change my router’s MTU value to 1300? Thanks!

BATcher

Plethora means a lot to me.

Reply | Quote

Replies

The only reason for reducing packet fragmentation would be to speed up a slow connection. Do you have one of those?

cheers, Paul

Reply | Quote

Surely the ‘other’ reason for reducing packet fragmentation would be to reduce the load on the router!

I’ve done a bit more work with NETSH (netsh int ipv4 show sub) and find that for some reason my Local Area Connection has its MTU value set to 1300 bytes. When I change this to 1500 (netsh int ipv4 “Local Area Connection 5” MTU=1500 store=persistent) the PING buffer size can go as high as 1472.
But when I reboot the PC, the Local Area Connection MTU size goes down to 1300 again…

BATcher

Plethora means a lot to me.

Reply | Quote

Surely the ‘other’ reason for reducing packet fragmentation would be to reduce the load on the router!

Yes it does that, but probably won’t make a perceptible difference on a modern router. On a modem / dial-up connection it makes a sufficient difference to be worth doing.
These days you are more likely to be waiting for traffic from a remote site than your router.

cheers, Paul

Reply | Quote

But when I reboot the PC, the Local Area Connection MTU size goes down to 1300 again…

I would wonder why the reversion takes place, any ideas?
:cheers:

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote

You can find your optimum MTU setting by using TCP Optimizer but your computer and router need to be set to 1500 before you start, although computers tend to be default set to 1500.

This program needs to be run as an admin so you’ll need to right click on the application/.exe file from where it is saved and select that option.

The instructions are included in the download page – http://www.speedguide.net/downloads.php

To change the MTU settings in the computer, run a command prompt as an administrator then enter these cmds –

netsh interface ipv4 show interfaces

The two you are interested in are those for WiFi and Ethernet and their Idx numbers.

If you need to change their settings after running the Optimizer then enter this cmd for each –

In my example I’m going to change the WiFi setting to 1492.

On mine the Idx Nos are 9 for WiFi and 18 for Ethernet.

netsh interface ipv4 set subinterface 9 mtu=1492 store=persistent

and then you would do the same for the Ethernet with its Idx No.

Redo the netsh/show interfaces cmd to confirm the changes and then you would need to log into the router to change its MTU setting.

Reply | Quote

Thanks, Sudo – that was more or less what I was doing but abbreviating the NETSH commands…

It comes up with the same maximum MTU figure as I found using the PING method – but automated!

BATcher

Plethora means a lot to me.

Reply | Quote

For that cmd I’ve always used interface instead of int as that was how I was taught.

The reason I’ve given the example is because a golden rule of instruction is that you never assume someone knows something unless you have taught them yourself – but I appreciate that you may have known those cmds but perhaps not about TCP Optimizer.

Reply | Quote

My router give me a warning message when setting the MTU to 1500, saying that this value may not be acceptable for PPPoE – but it is, since previous routers have used this value.

I last used TCP Optimiser in the heady days of XP, but not for the last ten or so years, so it’s nice to be reminded of it.

I have no idea why my PC ethernet adapter reverts to an MTU of 1300, even after it has been set to 1500. It is a standard Intel adapter built into the motherboard of a nearly ten-year-old HP Compaq 7700, so it’s a bit of a surprise.

BATcher

Plethora means a lot to me.

Reply | Quote

I assume you are adding store=persistent to the end of the cmd ?

Reply | Quote

Indeed yes! I will do some more testing today, I hope.

BATcher

Plethora means a lot to me.

Reply | Quote

Strange one that – if you are using Win 10 then you could see if using the elevated cmd necfg -d would sort that, otherwise see if uninstalling the adapter and a reboot would do it.

If you use the netcfg cmd you will have to reconnect to the SSID by entering the password again if the machine uses wireless.

That cmd installs a useless Win 10 wireless driver into my Realtek so I have to go into the store via Device Manager and reinstall an earlier Win 7 one.

Reply | Quote

Apparently (in Windows 7 at least) the NETSH command to change the MTU value for a network adapter doesn’t change the registry, even when store=persistent is used. (Information from Google on various forums.)

I had to do some slightly convoluted work in the registry to change the MTU value to 1500 for the Intel 82566DM Gigabit Network adapter on my PC, to get this value to persist across reboots…

I have no idea why the MTU was set to 1300 on this PC. Interrogating the other 25 local computers showed all those PCs had their MTUs set to 1500!

BATcher

Plethora means a lot to me.

Reply | Quote

I didn’t know that but I didn’t get any problems on ADSL with my Family Controller adapter – do the other machines have the same Intel Gb adapters ?

TalkTalk have their ADSL routers preset to 1432 as supposedly the optimum for their broadband, but MTU isn’t a one size fits all.

The TalkTalk Fibre package that I’m on now has their D-Link VDSL router preset to 1500 so I’ve just left things as they are.

Reply | Quote

An interesting observation for you!
When using PING 8.8.8.8 -f -l nnnn
for values of nnnn near 1472 (1500 – 28 bytes for headers) I get:
nnnn is 1474 or above – buffer fragments
nnnn is 1446 to 1472 – PING times out
nnnn is 1444 or below – expected response from PING

How could this be explained?

BATcher

Plethora means a lot to me.

Reply | Quote

An interesting observation for you!
When using PING 8.8.8.8 -f -l nnnn
for values of nnnn near 1472 (1500 – 28 bytes for headers) I get:
nnnn is 1474 or above – buffer fragments
nnnn is 1446 to 1472 – PING times out
nnnn is 1444 or below – expected response from PING

How could this be explained?

The 1474 will take that above 1500 so will need to be fragmented.

These are what I got –

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:WINDOWSsystem32>ping 8.8.8.8 -f -l 1472

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=1472 time=26ms TTL=57
Reply from 8.8.8.8: bytes=1472 time=23ms TTL=57
Reply from 8.8.8.8: bytes=1472 time=25ms TTL=57
Reply from 8.8.8.8: bytes=1472 time=23ms TTL=57

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

C:WINDOWSsystem32>ping 8.8.8.8 -f -l 1474

Pinging 8.8.8.8 with 1474 bytes of data:
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.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:WINDOWSsystem32>ping 8.8.8.8 -f -l 1446

Pinging 8.8.8.8 with 1446 bytes of data:
Reply from 8.8.8.8: bytes=1446 time=24ms TTL=57
Reply from 8.8.8.8: bytes=1446 time=29ms TTL=57
Reply from 8.8.8.8: bytes=1446 time=23ms TTL=57
Reply from 8.8.8.8: bytes=1446 time=28ms TTL=57

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

C:WINDOWSsystem32>ping 8.8.8.8 -f -l 1400

Pinging 8.8.8.8 with 1400 bytes of data:
Reply from 8.8.8.8: bytes=1400 time=24ms TTL=57
Reply from 8.8.8.8: bytes=1400 time=23ms TTL=57
Reply from 8.8.8.8: bytes=1400 time=24ms TTL=57
Reply from 8.8.8.8: bytes=1400 time=23ms TTL=57

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

C:WINDOWSsystem32>

Reply | Quote

Interesting…

BATcher

Plethora means a lot to me.

Reply | Quote

On the matter of routers, yesterday I changed the Draytek 2860s (ADSL2+ or VDSL2) to have an MTU of 1500, which matches the value set in ‘predecessor’ routers, with no obvious problems so far.

BATcher

Plethora means a lot to me.

Reply | Quote

Because of the distance I’m from the exchange, when I first started with TalkTalk I bought a Billion Bipac 7800N to replace the ISP supplied door stops.

It’s default setting was 1492 and that complained when I set that to 1500 as I wanted to see what TCP Optimizer would give.

Anyway, I just set the adapters to 1492 to match and it seemed okay, although for general browsing it would probably make little difference.

I suppose it could make a slight difference to the Latency for gamers, but they usually just asked TT to change their profile from Interleaved to Fast Path and usually increasing the SNRM from 6dB to 9dB to help with the stability.

Reply | Quote