Jumbo frames

Sending fewer, larger packets sounds like pure upside. It is, as long as every single device on the path agrees on what "larger" means.

The short answer

A jumbo frame is an Ethernet frame whose payload is larger than the standard 1500 bytes. The size of that payload is called the MTU (maximum transmission unit). No industry standard defines the size of a jumbo frame [1]. Intel says jumbo frames can lower CPU load and improve wire efficiency when large packets make up most of the traffic [3]. Our assessment: they can help a storage network between a NAS and one or two servers, and they are not worth it on a mixed home network where one forgotten device breaks the path.

How it works

1. The standard frame. The original IEEE 802.3 specification defines frames from 64 to 1518 bytes. After 18 bytes of overhead (a 14-byte header and a 4-byte CRC trailer), the payload ranges from 46 to 1500 bytes [1]. A VLAN tag (IEEE 802.1Q) adds 4 bytes and raises the maximum frame to 1522 bytes, but the MTU stays 1500 [1][2].
2. No standard for "jumbo". The Ethernet Alliance defines jumbo frames as all frames with an MTU above 1500 bytes. It writes that no industry standard defines their size, and that the IEEE decided not to define them because of interoperability concerns [1]. In practice many vendors default to an MTU of 9000, for example in VMware guidance [4][5].
3. Why it can help. Larger frames mean fewer packets for the same data, so less per-packet work for CPU and network card [3]. This matters for bulk transfers such as backups and storage traffic, not for small request and response messages.
4. Why it breaks. Every device in the path needs the same MTU: network cards, every switch port and the NAS. A device that receives a frame bigger than its MTU may fragment or drop it [4]. Different devices also count the size differently. Some include header bytes and some do not, and Intel advises setting a switch's frame size 4 bytes higher for the CRC, plus 4 more if VLAN tagging is used [3]. Intel also warns that jumbo frames at 10 or 100 Mbit/s can cause poor performance or loss of link [3].
5. Path MTU discovery. Normally, hosts find the largest packet a path can carry through ICMP error messages from routers [6]. Our assessment: a Layer 2 switch is not a router, so an MTU mismatch inside one switched network often shows up as connections that start and then stall. Test with large packets before you trust the setup.
6. Testing. Send a ping that must not be fragmented. On Linux, -M do forbids fragmentation, and -s sets the data size [7]. The size is the MTU minus 28 bytes for the IP and ICMP headers [4][7]: 8972 for an MTU of 9000, 1472 for 1500 [5].

A homelab example

We have not recorded jumbo frames at Bytearium (inventory as of 14 to 16 Oct 2026), so this is a generic test between two Linux machines. Set the MTU on a spare interface and prove the path before you move real traffic:

sudo ip link set dev eth1 mtu 9000
ping -M do -s 8972 -c 4 192.0.2.20

The ip link form is documented in ip-link(8) [8]. If the ping fails while -s 1472 works, something on the path still has an MTU of 1500 [5]. The address is a placeholder.

Checklist

• Ask whether the workload moves large blocks, such as a NAS backup or storage link; if not, leave the MTU at 1500.
• List every device on the path: network cards, switches, NAS, hypervisor, VLAN interfaces.
• Set the same MTU on all of them, and mind how each device counts header bytes [3].
• Test with ping -M do -s 8972 before you move real data [5][7].
• Keep an MTU of 1500 on the network that reaches the internet.
• Do not enable jumbo frames at 10 or 100 Mbit/s [3].
• Write the MTU into your network notes next to the VLAN ID.