Over the year’s I’ve had numerous occasions arise when I needed to change the MTU on a Windows based computer. There are a million reasons why this is needed, such as the following.
- Windows Servers deployed in an OpenStack environment require the MTU to be decreased to 1454 in order to work correctly with Neutron.
- DSL very commonly uses a smaller 1492 byte MTU when deployed with PPPoE encapsulation, so performance can be significantly degraded if the router and computers are not decreased to match.
- VPN connections over DSL and some WIFI networks are notorious for failing unless the MTU is adjusted.
What Affect Does MTU Have?
Packet size, also known as MTU or Maximum Transmission Unit, is the largest amount of data that can be transferred in one packet at the physical layer (OSI Layer 1) of the network. Ethernet’s default MTU is 1500 bytes without using Jumbo Frames. For PPPoE the MTU is 1492 and dial-up connections typically used 576 back in the day.
Each transmission unit contains of header and actual data. This data is called the MSS, or Maximum Segment Size. MSS defines the largest segment of TCP data that can be transmitted in a packet. In a more summarized manner,
MTU=MSS + TCP & IP headers.
Now, let’s assume the following:
- MSS = MTU -40 (a standard 40 byte header, which consists of 20 byte IP and 20 byte TCP)
- No packet fragmentation is taking place
- No packet loss on any hops
- No congestion on any routes
Let’s look at the transfer of 1,500,000 bytes of data, in different packet sizes, over a 1.54mb line (a T1 = 1,544,000 bits/sec) using this standard formula:
( MSS + header ) * 8 bits/byte
__________________________ = Delay at each hop
Using this formula and different MTU values, we can calculate the correlation of packet size to latency.
If MTU = 1500, then: (1460+40) * 8 / 1,544,000 = 7.772 ms additional delay per hop
If MTU = 576, then: (536+40) * 8 / 1,544,000 = 2.924 ms additional delay per hop
Let’s say on average each packet traverses 10 hops, a 1500 MTU would see 77.72 ms delay, but a 576 MTU would only experience 29.24 ms of delay (keep in mind, x2 for round trip).
Despite this data, you would think one could achieve higher throughput with larger packets. You might think if there are less headers (because of larger packets), less processing at the protocol level (for the client) and less route processing, that this would achieve a “faster” connection. And you would be right in many regards, a larger packet size would yield higher overall throughput. However, if responsiveness is the goal (think gaming, chat, smaller websites, etc) you might yield better results with a smaller packet size.
It boils down to the desired result, and protocol limitations. More than likely, you are reading this article because something isn’t working and therefore you’re experiencing a protocol limitation of some sort. Food for thought.
In my case, I deployed some Windows 2016 virtual machines in an OpenStack environment. In an OpenStack environment, the MTU is supposed to be set via DHCP and handled by the VirtIO driver. Well that didn’t really happen and I had to change it manually.
How To Change The MTU
To change the MTU on Windows Server 2016, the first thing you need to do is open an Administrative command prompt.
Right-Click on the start button and select “Command Prompt (Admin).”
Next, you need to determine the IDX # of your Ethernet Adapter. You can do so using the netsh command.
netsh interface ipv4 show interfaces
As you can see, the IDX of my Ethernet adapter is 5.
Now, we will once again use netsh to set the MTU of the interface. Replace 1454 with your desired MTU.
netsh interface ipv4 set subinterface "10" mtu=1454 store=persistent
Done. After a simple reboot, your new MTU will take effect.
What If I Don’t Know?
If you are having an issue with fragmentation or degredation of service, and you need to figure out the highest MTU you can set to achieve optimal performance, use the ping command. To start with, run this from the command prompt.
ping google.com -f -l 1500
This command sends a ping using a 1500 byte packet size (MTU). You can slowly decrease the packet size, in increments of 10 , until you stop getting fragmented packet results. If the packet is too large, you will get “Packet needs to be fragmented but DF is set.” If it’s not to large you will get a successful ping (as long as the destination isn’t restricting ICMP ping packet size. Here is an example of both.
In the case above, the MTU needed to be set to 1454 because this was the largest packet ping could send without fragmentation. Go through this process and use the packet size with the netsh command earlier in this post to set your MTU.
I hope this has helped you resolve the problem you were having with MTU. If you have any problems or need help, please feel free to post in the comments below. Thanks!