Why should you never exceed an MTU of 1500 bytes everywhere?
Understand MTU, Jumbo Frames, fragmentation and silent packet loss before switching a NAS or local network from an MTU of 1500 to 9000 bytes.
One idea often comes up in network discussions: increasing the MTU from 1500 to 9000 bytes would automatically increase the speed of a NAS. Jumbo Frames can indeed reduce the number of packets to process. But in a heterogeneous home or professional network, an isolated change often produces the opposite effect: unstable throughput, frozen sessions, video buffering, or lost packets without a clear message.
The right question is therefore not "what is the largest MTU?", but "what maximum size is accepted end-to-end on the path actually used?".
What is the MTU?
MTU stands for Maximum Transmission Unit. It designates the largest unit of data that an interface can transmit without having to fragment or reject it. On classic Ethernet, the IP MTU is generally 1500 bytes.
This value does not represent the total size of the Ethernet signal on the cable. An IPv4 packet carrying TCP contains, in the simplest case:
- 20 bytes of IPv4 header;
- 20 bytes of TCP header;
- up to 1460 bytes of TCP data, i.e., an MSS of 1460;
- Ethernet headers and controls added around the packet.
A VLAN tag adds another 4 bytes to the Ethernet frame. PPPoE often reduces the usable IP MTU to 1492 bytes. A VPN adds its own headers and can impose an even lower value. This is why a correct size on the local network is not necessarily correct after passing through a tunnel or over the Internet.
Why 9000 bytes can seem faster
With an MTU close to 9000, each frame carries more useful data. To send the same file, machines produce fewer packets, fewer interrupts, and fewer processing operations. This gain can be interesting on a heavily loaded fast link, for example between servers, iSCSI storage, a virtualization cluster, or two NAS dedicated to backups.
But Jumbo Frames does not automatically mean more throughput. On a 1 Gbit/s link that is already saturated, modern network offload mechanisms often make it possible to reach the practical limit with an MTU of 1500. Increasing the MTU can mainly reduce CPU load or the number of packets per second. The result depends on the hardware, drivers, protocol, and type of load.
The problem of a network with multiple MTUs
On the same Ethernet segment, a switch does not split a frame that is too large for the next port. If a NAS sends a Jumbo frame to a device or port limited to 1500, the frame may simply be dropped. The behavior then seems random because small exchanges still pass while large transfers fail.
It is not necessary for every connected device in the entire building to use the same MTU. However, every element of the path taken by the Jumbo Frames must accept the chosen size: interfaces at both ends, switch ports, aggregated links, VLANs, bridges, virtual interfaces, and any routers.
Televisions, smartphones, Wi-Fi access points, and connected devices generally remain around 1500 bytes. TCP can adapt the size of its segments, but it does not repair a path whose MTU discovery is broken. SMB, NFS, HTTP, Plex, Jellyfin, or Syncthing may seem to work, then slow down or freeze when a larger packet meets the wrong interface.
When a 9000 MTU is justified
Jumbo Frames become coherent in a closed and documented segment:
- direct link between two servers or two NAS;
- separate storage network for iSCSI or NFS;
- internal network of a cluster or virtualization platform;
- 10, 25, 40, or 100 Gbit/s infrastructure where all ports have been validated;
- massive backup traffic never leaving the dedicated VLAN.
On a Synology cluster, for example, ports reserved for internal traffic can be configured with an MTU 9000 while interfaces intended for users remain at 1500. The separation is safer than enabling it globally on the main network.
When should you keep 1500?
- Internet access: the path crosses networks you do not control.
- VPN: WireGuard, IPsec, or OpenVPN add headers and reduce the available MTU.
- PPPoE: the common value is often 1492, unless specific support for a higher MTU.
- Wi-Fi and connected devices: the fleet is heterogeneous and rarely configurable end-to-end.
- VoIP, video conferencing, and gaming: stability, latency, and jitter matter more than a small reduction in the number of packets.
- Undocumented network: if you do not know every device traversed, 1500 remains the interoperable setting.
Fragmentation, PMTUD, and network "black holes"
In IPv4, a router can fragment a packet that is too large if the Don't Fragment flag is not set. Each fragment must then be processed separately, and the loss of a single fragment compromises the entire packet. In practice, modern systems rather try to avoid fragmentation.
In IPv6, intermediate routers do not fragment packets: only the source machine can do so. The router returns information indicating that the packet is too large, so that the sender reduces its size.
Path MTU Discovery, or Path MTU Discovery, relies on these ICMP messages. If a firewall blocks them, the sender continues to send packets that are too large without understanding why they disappear. Small requests work, but a page, an SMB transfer, or a VPN session remains stuck: this is the classic PMTU black hole.
For TCP through a tunnel, MSS clamping can advertise a suitable segment size and prevent traffic from exceeding the actual MTU. This setting does not, however, replace a consistent path configuration.
Practical test between two NAS with iperf3
The original test directly connects two Synology NAS on a 1 Gbit/s interface. One NAS runs the iperf3 server, the other launches a client with five streams for sixty seconds:
iperf3 -c 192.168.69.10 -t 60 -i 5 -P 5-cindicates the iperf3 server address;-t 60sets a duration of 60 seconds;-i 5displays a summary every 5 seconds;-P 5opens five parallel streams.
With an MTU of 1500 at both ends, the aggregate throughput reaches approximately 941 Mbit/s, practically the useful limit of a Gigabit link.
With an MTU of 9000 correctly configured on both interfaces, the result also remains close to 941 Mbit/s. On this 1 Gbit/s link and for this test, Jumbo Frames therefore bring no measurable throughput gain.
The third test uses 9000 on the sender and 1500 on the receiver. The measured throughput drops to approximately 562 Mbit/s, with one stream at zero and a heavy distribution among the others. This figure describes this specific setup, not a universal rule, but it well illustrates the cost of an inconsistent path.
During another run, the five streams temporarily remain at zero. The capture alone does not prove the exact cause of a link drop, but it shows the symptom the user perceives: traffic stops while the interfaces still appear configured.
How to validate the path before enabling Jumbo Frames
- Note all interfaces and ports actually traversed.
- Check the documentation for the maximum size accepted by each device.
- Configure both ends and intermediate ports, never just a single machine.
- Test first for the absence of fragmentation, then for throughput and stability.
- Keep a management interface at MTU 1500 to be able to roll back.
Under Linux, an IPv4 test with the flag preventing fragmentation can be performed like this for a 1500 MTU path:
ping -M do -s 1472 192.168.69.10The 1472 bytes of ICMP data, added to the 28 bytes of IPv4 and ICMP headers, give 1500. For a 9000 Jumbo path, use 8972. Options vary depending on the operating system; always check the local syntax.
Conclusion
A larger MTU is not a free speedup. It becomes useful in a fast, closed, homogeneous, and measured segment. On a network mixing Wi-Fi, Internet, VPN, televisions, connected devices, and equipment of different generations, 1500 bytes remains the most predictable choice.
If you must enable 9000, isolate the affected traffic, validate every link, and measure the result with iperf3. If you cannot precisely describe the end-to-end path, do not change the MTU.
Technical references
Read next
About the author
Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.