Deals! 🛒
Generally, you don’t need to worry about MTU and Jumbo Frame. In a network, these are taking place behind the scenes.
However, as more and more get Gigabit-class or even faster broadband, understanding these two will help specific situations. I’ve seen many instances where minor changes in these values help improve the network connection significantly.
This post will give you a basic understanding of these two settings and an easy way to determine the optimal MTU value of a remote party, allowing you to set yours appropriately — if need be.
So what is MTU exactly?
MTU stands for maximum transmission unit. Data is sent via packets (or frames) in networking, and MTU is the largest packet size.
How large?
- The standard MTU is 1500 bytes.
- When you go Jumbo Frame, the MTU is now 9,000 bytes or even more.
To put things in perspective:
Generally, a byte represents a character (a letter or the space between a word) in a document. That said, technically, the text on this webpage, which consists of some 10k letters, arrived on your screen via about seven packets.
In reality, for this page to materialize, a lot more packets were involved. That’s because colors, images, videos, font sizes, formatting, and other behind-the-scenes elements are also information originally stored remotely somewhere.
Jumbo or not, MTU is relatively small — in a connection, devices send and receive lots of them. And since this is the maximum, chances are the actual packets are even smaller. By default, the router or devices determine this.
Before we go any further, let’s understand the significance of MTU. It’s not as simple as larger is better, far from it.
Understanding MTU: Larger is not neccesarily better
Sending data over a network is similar to trucking standard packages from one place to another in the real world. The larger the boxes, the faster you can load and unload the truck. So larger sizes can mean better efficiency — faster speed, that is.
The issue is at the receiving end. If the packages are too large, they might not fit through the door of the warehouse. In this case, they need to be broken apart (fragmented) to go through or get denied (dropped). So larger can also mean incompatibility, which kills the efficiency.
To be safe, you can always use the smallest package size, but that’d make loading and unloading the truck much more time-consuming. In networking, small packet sizes and fragmenting packets mean the equipment needs to do more processing than necessary.
So, the idea of MTU is this: You want to use the largest possible size that all parties involved can handle. The packages have to fit through the smallest door but no smaller than that. I’d call this the optimal MTU value, and it’s not a one-size-fits-all number.
Why Jumbo Frame?
For years, the standard MTU (1500 bytes) has been working fine, and it’s working well now, too. That’s because, in most cases, we deal with sub-Gigabit connections.
However, when you have a 1Gbps or faster network, using Jumbo Frame can dramatically improve the speed, again, as long as all parties involved support it.
Jumbo Frame is sometimes required to deliver the top performance. For example, a 10Gbps switch might need to use Jumbo frames to provide 10000Mbps. If you use the standard MTU, chances are it’ll cap at just half of that.
Most modern devices can handle Jumbo frames and switch between Jumbo and standard automatically, by default. This switching also requires processing power, so it’s not a good idea to enable “Jumbo Frame” when there’s no benefit in doing so.
But for the most part, it’s harmless to enable this on your device.
When it’s safe to use a fixed MTU value
No matter if you use standard or Jumbo Frame, it’s always the MTU number that matters.
In other words, just turning the support for “Jumbo Frame” on or off, the equipment will take care of the actual MTU value, and in most cases, it will favor compatibility.
However, if you have a network you know for sure can handle a certain MTU number, it’s better to set the MTU the optimal value. This method applies when you have a local network of all modern devices or segment the network via virtual LAN and then manually set the MTU on each.
The point is the use of fixed MTU is specific and only applies to particular cases. And when applicable, it will greatly improve the speed, but it can also hinder the performance when not. It’s a double-edged sword.
MTU and WAN (Internet) speed
Generally, you don’t need to do anything about MTU in your WAN (broadband) connection. That’s the case for all sub-Gigabit connections, of which the MTU value is likely 1500.
However, if you have Gigabit or faster Internet, the support for Jumbo frames in either the WAN or LAN side of the network likely helps. Likely because, again, this depends on specific situations. Also, a particular ISP requires a particular MTU value to work well.
And no, you do not necessarily need Jumbo Frame to support Gig+ and faster WAN speeds. Modern equipment can take care of this on its own.
A particular example where MTU likely plays a big role:
You have an ultra-high-speed WAN connection and get the expected speed when a single device connects directly to the terminal device — such as a modem or a Fiber ONT.
However, the same device (as the only connected one) gets significantly slower speed (either upload or download) when you put a router in between. In this case, the discrepancy likely has something to do with the router’s default MTU setting.
Unfortunately, what MTU value to use depends on the situation. Many times, enabling the router’s support for “Jumbo Frame” on the LAN side will do it. Other times you need to disable it. And for the rest, you have to change the WAN MTU value manually. There are just too many variables.
Another thing to note is there’s no universal way to adjust MTU in home routers — the methods vary among networking vendors, and some don’t even allow for changing this value at all.
On top of that, determining the optimal MTU value itself can be tricky.
How to determine the best MTU value
Generally, which MTU value is the best depends on the remote party — the one we typically have no control over. You want to make sure the packet size is the best for the receiver.
The good news is while there’s no way to ask a party for its best MTU value, you can figure it out fairly quickly via the ping command.
You can run this command in both the Command Prompt (Windows) and Terminal (Mac).
To use Command Prompt, search for it in Windows’ Start Menu. Use Spotlight for Terminal on a Mac.
Here’s the syntax (command line) in Windows:
ping -f -l [packet size] [remote party]
There are a few components in this command:
- -f : This switch is to turn on the “Don’t Fragment” flag. It prevents the packet from being fragmented to get through. Instead, it’ll show that fragmentation is required, meaning the packet size is too big, and drop the packet.
- –l : This switch allows for entering the packet size manually.
- [packet size]: The packet size in bytes that you want to send, such as 1500.
- [remote party]: This is the party of which the optimal MTU you want to figure out. It can be a computer name, an IP address, or a domain name.
The command means: Send that remote device a packet of this size and see how it replies. And via the way it responds, we can determine the best packet size (MTU value).
So, for example, if I want to find the best MTU value for this particular, I’d start with this command using the 1500 MTU value (you can try it yourself):
ping -f -l 1500 dongknows.com
The command returned, “Packet needs to be fragmented, but DF set,” meaning the MTU number is too high. We need to lower it, so I tried again with1400:
ping -f -l 1400 dongknows.com
The command returned “0% loss”, meaning the MTU size is accepted, but it might still be below the optimal. I increased it to 1470 with this command:
ping -f -l 1470 dongknows.com
Still, no data loss — the optimal is now either 1470 or 1500. Let’s tread more lightly this time by adding just 3 bytes to the packet size:
ping -f -l 1473 dongknows.com
This time, once again, I got the “Packet needs to be fragmented, but DF set.” By now, it’s clear that the optimal value must be between 1470 and 1472. I tried:
ping -f -l 1472 dongknows.com
0% data loss returned! Voila! 1472 is the optimal MTU value for dongknows.com
By the way, this is the optimal MTU value for most websites. The example above only shows you how to use the ping command to determine this value.
To figure out the best MTU value for any remote party, replace dongnows.com with that party’s IP address or name (if it’s in your local network.)
For example, if you want to know the best MTU for your Internet (WAN) connection, use the broadband’s default gateway IP. (Not to be confused with the default gateway address of your router, which is for the LAN side.)
However, it’s not easy to find what the WAN Default Gateway IP address is — unless you have a static IP, in which case this address is provided — but it’s generally within the range of your WAN IP.
Note that even when you know your WAN’s Default Gateway IP, some ISPs block WAN pings as a security measure. So, maybe you’re better off giving them a call and asking for the best MTU value.
The idea is this: Handling MTU values can be a bit of work, and it requires at least a basic understanding of MTU itself, which you now have. In many cases, it’s a matter of trial and error. But the result can be gratifying when appicable.
The takeaway
Most of the time, you don’t need to worry about MTU or Jumbo Frame, but this can be the last puzzle piece that gets you the top connection speed in certain situations.
In any case, if you want to mess with these, keep in mind that networking is a field of constant flux and fluctuations. It’s tough to determine the optimal.
So before you proceed, make sure you back up your router. Afterward, tread lightly by applying a small change at a time. This area is where the best can indeed be the enemy of the good.
I always thought MTU was self negotiating, until today. I put a cable modem in bridge and started getting errors. By default some routers and OS set MTU to 1500. I reset the cablemodem to NAT, and noticed that the ISP has hardcoded the MTU to 1490. Problem solved.
PPoE, ATM? some layers are still used to encapsulate the data, and MTU can be shortened.
It’s generally negotiating until one party sets the number manually. But it’s always how the firmware of a device is designed to handle it.
Might want to warn folks that versions of ping -f -l 1500 url_to_ping.com will -f FLOOD the ip with -l 1500 packets instantly. Hoping my ISP forgives me for that stunt. Thanks.
I think part of this is incorrect. The ping command sends a 28 byte header along with the packet size, so when you type ping -l 1472, it includes 28 more bytes, for your 1500 MTU. If you change your MTU setting to 1472, and try pinging again with -f -l 1472, I think you will get ““Packet needs to be fragmented, but DF set.” until you change it to -f -l 1444 or less.
Hi Dong
In an Asus Mesh set-up, do I need to enable JF in satellites as well as the router or router only ??
Great article, just upgraded my ISP to 1G so very much on point.
Only on the router, you can’t manage that on the satellites anyway, Mario.
I’m not sure that’s true. I have a GT-AX11000 as my main router and four ZenWifi XT8s as nodes. I can enable jumbo frames on the AX11000 through the switch control tab. But under each node, there’s also a switch control link that takes me to a separate GUI login at the node’s IP address, and there’s a toggle there to allow jumbo frames too. Wouldn’t it make sense that I’d need to enable it for all five components of my mesh for it to work, especially on the Backhaul?
It makes sense, Alan. Previously, that option on the satellite wasn’t avaible as it’s still not available to some currently.
Thanks, I admit that am using an RMerlin firmware build on all of these devices, and have not been able to verify whether the jumbo frame toggle on the nodes is available on the stock firmware. But my suspicion is that it likely is, as there’s no mention of this attribute in any of RMerlin or GNUton’s release notes.
Since this toggle has its own entry under the “Management” section for each node in the AX11000’s GUI, I’m guessing that the principle of allowing you to activate jumbo frames on some nodes and not others is to employ the feature only on nodes that have attached NAS hardware.
What I am not clear on is how enabling JF on the AX11000 affects transmission protocols on nodes that have it disabled. When JF is enabled on the main router, would it impact speeds and performance for non-mass storage devices?
It’s always case by case, but I’d say it’d not adversely affect the speed. Since you don’t dictate the actual MTU value, enabling JF would only improve or make no difference.
If I enable jumbo frames running MoCa with 2.5 gbe ports in several different rooms but only have 2 devices (NAS and laptop) that are jumbo frame capable (that i know of) as individual clients on my network would it be more beneficial to leave JF disabled? All switches are 2.5 gbe JF compatible. ISP subscription is 1200 mbps down and 40 up.
Enabling/disabling JF is safe, T, it’s different from setting a specific MTU value, which you need to do with care.
Note that the command is different in each platform, e.g. on macOS:
`ping -D -s 1400 dongknows.com`
Thanks for the tip, Dror. 🙂