Jumbo Frames

Jumbo frames increase the amount of data carried in each Ethernet frame beyond the conventional 1,500-byte IP maximum transmission unit, or MTU. Approximately 9,000 bytes is common, but there is no single universal jumbo-frame size. An interface MTU normally describes the maximum IP packet size, including IP headers, rather than the complete Ethernet frame. Switch specifications may instead describe the full frame size, so account for Ethernet headers, VLAN tags, and frame check sequences when comparing equipment limits.

The principal benefit is fewer packets for the same amount of application data. For bulk replication, backups, and distributed storage traffic, this can reduce per-packet processing and improve efficiency. Jumbo frames do not increase physical link speed, guarantee higher application throughput, or eliminate bandwidth and latency constraints. Benefits may be smaller when network interface offloads already reduce host processing costs. Larger frames also take longer to serialize, which can matter when latency-sensitive traffic shares a constrained link.

Successful deployment requires a compatible path, not merely a larger MTU on the source interface. Check the source and destination operating systems, virtual interfaces, physical switch ports, VLAN trunks, routed interfaces, cloud gateways, and any intermediate appliances. Ethernet switches generally discard frames exceeding their supported size rather than fragmenting them. Optical transceivers establish physical connectivity, while link aggregation groups combine links; neither feature automatically enables jumbo frames. Configure compatible MTUs across aggregate members and the logical interfaces carrying the traffic.

Cloud paths frequently have different limits. Supported Amazon EC2 instance types can use a 9,001-byte MTU, but that does not mean every destination reachable from the instance supports it. AWS Direct Connect private virtual interfaces support MTUs of 1,500 or 9,001 bytes, while transit virtual interfaces support 1,500 or 8,500 bytes. Public virtual interfaces support 1,500 bytes. Confirm jumbo-frame capability on the underlying connection or link aggregation group and configure the virtual interface explicitly; do not assume a working BGP session proves that large data packets can pass.

AWS Transit Gateway supports an 8,500-byte MTU for supported attachment paths, so a route crossing it cannot carry a 9,001-byte IP packet unchanged. Internet-bound paths should use a 1,500-byte MTU, while VPN encapsulation reduces the usable inner-packet size further. A design using Direct Connect as its primary path and an IPsec VPN as backup must account for this difference. Otherwise, small health checks can succeed after failover while large application transfers stall.

Path MTU Discovery helps endpoints adapt to smaller routed links. For IPv4, packets with the Don't Fragment flag require suitable ICMP feedback when they exceed a link MTU; IPv6 routers do not fragment forwarded packets and use ICMPv6 Packet Too Big messages. Filtering these messages can create an MTU black hole. TCP maximum segment size clamping can help TCP traffic fit a smaller path, but it does not solve oversized UDP packets or replace correct MTU configuration.

Validate each intended route with controlled packet-size tests and application transfers, including backup paths and both traffic directions. On Linux, an IPv4 command such as ping -M do -s 8472 destination tests an 8,500-byte IP packet when standard 20-byte IPv4 and 8-byte ICMP headers apply. Increase test sizes gradually and inspect interface discard counters, retransmissions, and packet captures. Oversized packets visible in host captures may reflect segmentation offload rather than actual frames transmitted on the wire.