Skip to content

How To Change The TCP/IP MTU On Windows Server 2016

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

1,544,000 bits/sec.

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).

 

The smaller packets will be transmitted faster because of the throughput limitation of the line. However, with large transfers it doesn’t matter.  Smaller packets tend to travel faster.

 

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).”

 

right-click-server-2016-start-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.

windows-server-2016-netsh-idx

 

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.

 

windows-server-packet-needs-fragmented-df-set

 

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!