Windows | MTU


A maximum transmission unit (MTU) is the largest packet or frame size, specified in octets (eight-bit bytes) that can be sent in a packet- or frame-based network such as the internet. The internet's transmission control protocol (TCP) uses the MTU to determine the maximum size of each packet in any transmission.

Check The MTU Setting On Your Computer

If you have connectivity to the Internet in general, but not to some servers, if some web sites load slowly, or if various problems come and go, you may have a problem with the size of the messages that pass between you and the web site in question. The Maximum Transmission Unit, aka MTU, is a setting on your computer, that controls the size of the messages.

Depending upon what networks are accessed, between your computer and a given web site, the MTU that you can use will vary. If you make your MTU exceedingly small, you'll be able to avoid an MTU related problem, but loading a complete web page will take a long time. If you make the MTU too large, you'll see a variety of symptoms.
Some web pages may load incompletely.
Some web pages will give you a white screen.
Some web pages may return the old familiar

404 Not Found
Some web pages may return another old favourite

The connection has timed out.

The server at xxxxxxx.blogspot.com is taking too long to respond.

Determining your MTU will be a matter of patience and persistence. I start by verifying that I have connectivity - period. I target the problem web site - in this example, www.yahoo.com. You should target the specific web site that you are having a problem accessing. If you can access "www.blogspot.com", but not "xxxxxx.blogspot.com", target "xxxxxx.blogspot.com".

I use the "ping" command, run in a command window.

C:\>ping www.yahoo.com Pinging www.yahoo-ht3.akadns.net [209.131.36.158] with 32 bytes of data: Reply from 209.131.36.158: bytes=32 time=13ms TTL=58 Reply from 209.131.36.158: bytes=32 time=14ms TTL=57 Reply from 209.131.36.158: bytes=32 time=14ms TTL=57 Reply from 209.131.36.158: bytes=32 time=14ms TTL=57 Ping statistics for 209.131.36.158: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 13ms, Maximum = 14ms, Average = 13ms

OK, that's good. I know that the IP address, in this case, is 209.131.36.158. And I know that www.yahoo.com (in this case www.yahoo-ht3.akadns.net) will respond to me, with 32 bytes of data. But 32 data bytes is way too small.

If I see anything different,

C:\>ping www.yahoo.com Ping request could not find host www.yahoo.com. Please check the name and try again.

Then, I know that I have a different problem - maybe a DNS problem, or even LSP / Winsock / TCP/IP corruption.

Hoping that I'm seeing the first example above, I'll see what MTU I can use. The maximum that anybody can use is 1500, which includes a 28 byte header. When you ping, you specify the amount of data to ping with, not including the header. The maximum MTU for anybody is 1500, so I start with a data size of 1472.

And I'll ping using the IP address, so I don't involve DNS. I'll deal with DNS problems, separately.

Now, I use the "ping" command, run in a command window, with the options "-f" (lower case of "-F" = "Do not fragment"), and "-l" (lower case of "-L" = "Send buffer (data) of this size").

C:\>ping -f -l 1472 209.131.36.158 Pinging 209.131.36.158 with 1472 bytes of data: Reply from 209.131.36.158: bytes=1472 time=83ms TTL=58 Reply from 209.131.36.158: bytes=1472 time=84ms TTL=57 Reply from 209.131.36.158: bytes=1472 time=87ms TTL=57 Reply from 209.131.36.158: bytes=1472 time=84ms TTL=57 Ping statistics for 209.131.36.158: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 83ms, Maximum = 87ms, Average = 84ms

That's a good return, and tells me that I don't have an MTU problem. If I had seen either of two other results

C:\>ping -f -l 1472 209.131.36.158 Pinging 209.131.36.158 with 1472 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 209.131.36.158: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

That's a fragmentation error from a router, or a server, telling me that my MTU is too large, and I set it to not fragment.

C:\>ping -f -l 1472 209.131.36.158 Pinging 209.131.36.158 with 1472 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 209.131.36.158: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

That could be a normal "This server isn't online" message. But since I did my baseline connectivity test (above) I don't think that this is the case. In this case, a router or server is simply dropping my ping request, as above because my MTU is too large, and I set it to not fragment. This is called a "black hole" router or server.

Some servers will respond, and tell you that you have a problem (giving you a fragmentation error); others will ignore you (giving you a black hole error). With a server farm similar to "xxxxxxx.blogspot.com", you could have some of the first type, and others of the second type. The network that you go through, to reach the server(s) in question can vary, by the second. Your symptoms can vary, from day to day, and from second to second.

If I see either a black hole error (router or server simply dropping my ping), or a fragmentation error (router or server telling me that I have a problem), I know that I have to reduce my MTU. I'll start by reducing it by 20.

C:\>ping -f -l 1452 209.131.36.158 Pinging 209.131.36.158 with 1452 bytes of data: Reply from 209.131.36.158: bytes=1452 time=83ms TTL=58 Reply from 209.131.36.158: bytes=1452 time=84ms TTL=57 Reply from 209.131.36.158: bytes=1452 time=87ms TTL=57 Reply from 209.131.36.158: bytes=1452 time=84ms TTL=57 Ping statistics for 209.131.36.158: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 83ms, Maximum = 87ms, Average = 84ms

So 1452 is good, but maybe too small. So now, I'll try making it bigger, in steps of 2.

C:\>ping -f -l 1454 209.131.36.158 Pinging 209.131.36.158 with 1454 bytes of data: Reply from 209.131.36.158: bytes=1454 time=83ms TTL=58 Reply from 209.131.36.158: bytes=1454 time=84ms TTL=57 Reply from 209.131.36.158: bytes=1454 time=87ms TTL=57 Reply from 209.131.36.158: bytes=1454 time=84ms TTL=57 Ping statistics for 209.131.36.158: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 83ms, Maximum = 87ms, Average = 84ms

Again, too small. Keep going up by 2.

... (later)

C:\>ping -f -l 1466 209.131.36.158 Pinging 209.131.36.158 with 1466 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 209.131.36.158: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

OK, 1466 is too large. Back down by 2 to 1464. Add the 28 byte header, giving me an MTU of 1492. This is a common value for the MTU, for many who can't use 1500.

Do you see the technique used? I found the MTU, by bracketing it. I started from a value too large (1472 data bytes), went down by 20 (to 1452, though I might have gone progressively lower) to a value too small, then up by 2 (to 1466) again too large. Then back down to the largest value where no error was seen (1464, in this case), an even number.

There's nothing magical about the sequence "Down by 20, Up by 2". You can use any sequence that pleases you. Try "Down by 60, Up by 20, Down by 2". Or "Down by 80, Up by 8, Down by 2". It's your computer. The point is to find the largest data size that you can successfully ping the target server with, then add the 28 bytes for the header, giving you the maximum MTU that you can use.

Note that I said "maximum MTU". If you find out that "www.yahoo.com" is accessible with an MTU of 1492, but "www.google.com" isn't, you'll have to repeat the process, from the beginning, using "www.google.com" as the target. Always target the problem web site.

Once you know what MTU to use, if your computer is running Windows 2000 or XP, you can set it using the free tool DrTCP, from DSLReports. Download DrTCP, into any convenient folder, and run it from there. You'll be changing the "MaxMTU" or "MTU" value under Adapter Settings. If you have multiple network adapters, be sure to choose the one that provides the Internet service.

Setting The MTU In Windows Vista

Long ago, when I first heard of the dynamic tuning in the Windows Vista TCP/IP stack, I envisioned the manual setting of the static MTU to be a thing of the past. Unfortunately, I was wrong - the MTU is still a fixed setting, in Vista.

The legendary tool, DrTCP, which is used by everybody to change the MTU in Windows 2000 and XP, doesn't work under Windows Vista. Fortunately, Microsoft now allows us to adjust the MTU using the "netsh" command. As other commands in Windows Vista, you run "netsh" using the command window, in Administrative mode.

To see what interfaces you have on your computer, type
netsh interface ipv4 show subinterfaces

To change the MTU, type
netsh interface ipv4 set subinterface "Local Area Connection" mtu=nnnn store=persistent

where
Local Area Connection is the name of the network connection on your computer, from the list obtained above.

nnnn is the desired value for MTU.

Reboot after making the change.

The MTU Setting Problem - Why Is It So Obscure?

The Maximum Transmission Unit, aka MTU, is a setting on your computer, that controls the size of the messages that it passes to other computers. When you surf the Internet, your computer is in communication with hundreds of other computers, each with their own possibility to contribute to packet loss. Packet loss is caused partly because of an optimistic MTU setting on your computer, and partly because of constantly varying paths between the computers, resulting from packet switching.

The symptoms of an MTU problem - packet loss and inability to connect to the server of your choice - are so transient that you may never be aware of the problem, until 3 conditions are met, simultaneously.
Your computer has an optimistic MTU setting.
You attempt to access a server that is reached (even temporarily) through a network that fragments the packets from your computer, partly because of your optimistic MTU setting.
The server in question, or a network between your computer and the server in question, has a problem with fragmented packets.

Because of packet switching, the path between your computer and the server of your interest can change in milliseconds. With each different path comes a greater or lesser chance of conditions 2 or 3 becoming an active issue. If condition 1 is an active issue, andboth conditions 2 and 3 are met, you'll see the symptoms of the MTU problem. If condition 1 is an active issue, and both conditions 2 and 3 are not met, you'll not see symptoms of the problem.

Each different packet from your computer, possibly taking a different route to the server in question, may or may not pass through a network that contributes to the problem, and thus be susceptible to packet loss. If not susceptible, the packet won't be dropped, and the symptom will seem to simply go away.

Any individual server may be more or less susceptible to contributing to conditions 2 and 3.
The server may have an individual problem with fragmented packets.
The server may be connected to a network that has a problem with fragmented packets.
If the server in question has an individual problem with fragmented packets, and you access this server more frequently, you may observe the symptoms more frequently.
If the server in question is simply connected to a network with a problem with fragmented packets, the symptoms may be seen less often.
The likeliness of packet switching causing an alternate path, and bypassing the network in question, will reduce the chances of you seeing the symptoms. This likeliness will vary, depending upon logical and physical distance between the target server, and a network that has a problem with fragmented packets.
If the target server itself has the problem, or is directly connected (and notmulti homed) to the network with the problem, the symptoms will be seen consistently.
A network that is close to the server in question, and having a problem with fragmented packets, will be less likely to consistently cause the symptom.
A network that is not very close to the server in question, and having a problem with fragmented packets, will be still less likely to cause the symptom consistently.

All of the above issues should explain, in part, why the MTU problem is so transient, and so seemingly random. Even with identical computers, with identical configurations, in the same location, individual surfing habits (targeting different servers) may make any single computer more, or less, susceptible to exhibiting the symptom of packet loss caused by an optimistic MTU setting.

Internet Connectivity Problems Caused By The MTU Setting

The messages sent and received between your computer, and the Internet web servers that you're accessing, may go thru dozens of networks. The Internet is, by design, dynamic. The networks that you use, to access any server, may change within seconds.

Any one of those networks might have a restriction on the maximum message (packet) size that it will accept. Each computer has a setting, called the Maximum Transmission Unit (MTU), which controls how large it may make any packet. The larger your packets, the fewer packets required for sending or receiving a web page, but the greater chance any network have a problem with your packet size.

Setting the MTU on your computer can be a double edged sword.

If you make the MTU too large, some networks will split (fragment) your packets. Some servers may have a problem with fragmented packets, causing the dreaded "Server not available..." error, or other symptoms.
If you make the MTU too small, your computer will send and receive small packets. You'll be able to access any server, thru any network, but a web page will require too many packets. The speed that your web pages download will make you think you're not connected at all.

If you have a problem accessing some websites (or running some programs like email or IM), but not others, or if this problem seems to come and go, you may have an MTU setting problem. The best known examples of this problem are those with dial-up or PPPoE sevice, or those using ICS. An MTU issue can affect anybody, though, and different people (computers) will, almost certainly, be affected differently, with different web sites being unreachable at different times.

Here are several articles, of differing technical detail and level, discussing the issue further, and offering ways to diagnose and correct it. Read through each one, until you find one that explains the issue to your liking. This list, like each of the ones that I create, is alphabetised.

Allen Smith: ICS Web-browsing Problem: the Real Solution.
Annoyances: Can't access some websites while using a shared PPPoE connection.
Microsoft: (KB319661): Connectivity Problems on ICS Clients When You Use a PPPoE Connection on a Windows XP ICS Host.
Microsoft: (KB314825): How to Troubleshoot Black Hole Router Issues.
NetHeaven: Sites With Broken / Working Path MTU Discovery
Nitecruzr Dot Net: The MTU Setting Problem - Why Is It So Obscure?

When you get ready to adjust the MTU setting, make it easy on yourself. Download DrTCP, from DSLReports, and use it to make the changes for you. Simply copy the downloaded file into any convenient folder, and run it from there.

You'll be changing the "MaxMTU" or "MTU" value under Adapter Settings. If you have multiple network adapters, be sure to choose the one that provides the Internet service. For instructions about what values to change MTU to, see the articles linked above. Read all 6, and pick the one that you're most comfortable with.

Note: An MTU problem can be confused with, or masked by, a DNS problem, or LSP / Winsock Corruption. If you're here after trying the above procedures, unsuccessfully, consider each of the latter possibilities.