Monday, June 16, 2025

Jumbo Frames are a LAN-side performance feature, while MTU clamping in SD-WAN is a WAN-side compatibility safeguard.

 Jumbo Frames are completely separate from standard MTU and not affected by our standard MTU clamping — unless we explicitly allow and use Jumbo Frames end-to-end. When we clamp standard MTU from 1420 to 1300, we're only affecting regular Ethernet frames (standard traffic).

Jumbo Frames (LAN-side Optimization)

  • Ethernet frames larger than the standard 1500 bytes, typically up to 9000 bytes.
  • Primarily used within high-speed internal networks (e.g., data centers) to reduce CPU overhead and improve throughput.
  • Jumbo frames require explicit support and configuration end-to-end across all network devices — not used over the public internet or SD-WAN circuits by default.
Aspect Standard MTU Jumbo Frames
Typical Size 1500 (often clamped to 1300–1420) 9000 (custom, non-standard)
Used by Most Internet and enterprise traffic Only within high-speed internal LANs / data centers
Needs Clamping? Yes, for tunnels/overheads (e.g., IPsec, GRE, SD-WAN) No (unless you're running Jumbo over the same constrained path, which is rare)
Negotiated? Yes (Path MTU Discovery, MSS) No — must be manually configured and supported end-to-end
TSO / LSO Impact Still applies Jumbo frame simply increases physical wire frame size

Clamping standard MTU does not impact Jumbo Frames, because :

  • Jumbo Frames work only inside a Local Area Network (LAN) or similarly controlled environments like: Data centers, Storage networks (NAS/iSCSI), High-performance computing clusters.
  • Operate in separate L2 environments (e.g., within LAN, not over WAN tunnels)
  • Are already constrained to trusted, known MTU paths.
  • Jumbo Frames are not “clamped” in the same sense, because:
    • They must be explicitly allowed and configured on the interface (NIC, switch, router).
    • They don’t rely on PMTUD — they’re rejected outright if any hop doesn't support them.

Here is 3 technical concepts : 

Concept Scope Purpose
PMTUD (Path MTU Discovery) 🌐 WAN Dynamically discovers smallest MTU along a path to avoid fragmentation
TSO (TCP Segmentation Offload) 🌐 WAN + LAN (mostly host NIC) Offloads TCP segmentation to NIC to boost performance for large buffers
Jumbo Frames 🏢 LAN Increases Ethernet frame size to reduce per-packet overhead in LAN

1. PMTUD (Path MTU Discovery)

This is our current process by default where DF (Don't Fragment) is always set by default , where we can see more than 25000 bytes are send without any fragmentation , even we never see any where with Fragmentation is enabled. As most OS supports the TCP Segmentation Offload (TSO) or Large Segment Offload (LSO).

Client  exchange the MSS during the TCP 3-way handshake. "MSS is advisory, not enforced.  But the sender is not obliged to obey."

The OS kernel or TLS layer may send larger chunks for performance or protocol reasons. The sender relies on PMTUD (with DF set) to discover if large packets are acceptable along the path.  TCP stacks may choose to initially send large segments, assuming large MTUs, unless PMTUD fails.

Path MTU Discovery (PMTUD) is a mechanism that helps a sender find the maximum IP packet size (MTU) that can traverse the network without fragmentation. Each link in a network path can have a different MTU.  PMTUD helps avoid:

  • Sending packets too big, which would get dropped if DF (Don't Fragment) is set
  • The overhead of IP fragmentation, which can hurt performance

How PMTUD Works :

  • Sender sets the DF bit (Don't Fragment) in IP packets.
  • Starts sending large packets (e.g., 1500 bytes).
    • If a router encounters a too-large packet, and can't fragment:
    • It drops the packet.
  • Sends back an ICMP Type 3, Code 4: “Fragmentation Needed but DF Set”.
  • The sender receives this ICMP and reduces packet size accordingly.

2. TCP Segmentation Offload (TSO) 

Technically A TCP segment with a payload size larger than the path MTU, constructed by the OS kernel and offloaded to the network card for segmentation. This is called as TCP Segmentation Offload (TSO)” or “Large Segment Offload (LSO)".

  • TSO is a hardware-level optimization, handled by the NIC, not part of the IP protocol stack.
  • If TSO is enabled on a host's network interface , it is used for all outbound TCP traffic (LAN or WAN).
  • The OS creates a huge TCP segment (e.g., 64KB or more). TSO allows the OS to send large TCP buffers (e.g., 64KB) to NIC, which NIC splits it into MTU-sized packets (e.g., 1500 bytes) for transmission over the network.
  • Instead of the CPU breaking the data into small packets, the NIC takes over the segmentation task, reducing CPU overhead and improving throughput.

Will TSO Still Work After MTU Clamping?

Yes, TSO/LSO will still function as expected, but the size of the individual MTU-sized frames generated by the NIC will be adjusted based on the clamped MTU.  We can safely clamp MTU/MSS at the edge or adjust tunnel overhead without breaking TSO.  Just ensure : Firewalls/routers don’t apply hard limits below our clamped MTU.

TCP Segmentation Offload (TSO) — also known as Large Segment Offload (LSO) — is a network performance optimization technique used in modern operating systems and network interface cards (NICs).

With TSO enabled:

  • The OS creates a large TCP segment (say 64KB).
  • The NIC is responsible for breaking it into packets that match the effective MTU.
  • If you've clamped the MTU to 1290 or 1383 (instead of 1500), the NIC will now segment based on the new lower MTU.
  • This increases the number of packets per large segment but does not break functionality.

📦 Without TSO:

  • OS creates and segments each TCP packet.
  • CPU is involved in calculating checksums, headers, segmentation.
  • More CPU cycles used, especially at high throughput.

📊 Visual Representation:

Layer Without TSO With TSO
OS (Kernel) Segments into 1460-byte TCP segments Sends 64KB chunk to NIC
NIC (Hardware) Just transmits Splits into MTU-sized packets (e.g., 1460B)
Result More CPU work, more interrupts Less CPU work, higher performance

✅ Benefits of TSO:

  • Reduces CPU load for high-volume TCP traffic.
  • Enables higher throughput without additional CPU consumption.
  • Particularly useful for web servers, file transfers, high-performance applications.

 

TermLayerDescription
PMTUDNetworkDiscovers the largest IP packet that can be sent without fragmentation
MSS (TCP)TransportMax TCP payload advertised by each endpoint
MTU (IP)NetworkMax IP packet size supported by each link
TSO/LSONICOffloads large TCP segments to be split at NIC level
Jumbo FramesEthernetFrames > 1500 bytes (e.g., 9000B) — only supported on compatible networks
Jumbo TCP SegmentTCP/OSLarge segments seen in capture due to TSO — not actual on-wire sizes

 

  Impact of Lowered MTU:
  • More packets per TSO segment → slightly higher CPU/network processing overhead.
  • Possible minor reduction in throughput if NIC offloading is limited or CPU is under pressure.
  • But TLS handshake reliability improves significantly, which is more critical in your case.
ParameterBefore Clamping (MTU=1500)After Clamping (e.g., MTU=1290–1383)
TSO Segment Size (e.g., 64KB)64KB64KB
NIC Segments per TSO SegmentFewer (64KB ÷ 1460)More (64KB ÷ 1250 or similar)

🚫 TSO Could Break Only If:

  • TSO/LSO is explicitly disabled at OS or NIC level.
  • The network path drops fragmented packets (rare with TSO since fragmentation doesn’t occur at IP layer).
  • There's a misconfigured firewall/router that drops larger packet bursts or doesn’t respect the new clamped MTU.

 ✅ Recommendation:

You can safely clamp MTU/MSS at the edge or adjust tunnel overhead without breaking TSO. Just ensure:

  • NIC and OS TSO settings remain enabled.
  • Firewalls/routers don’t apply hard limits below your clamped MTU.
  • Your monitoring considers potential rise in packet counts per request (not errors).

 

3. Jumbo Frames

Jumbo Frames are Ethernet frames that exceed the standard Ethernet MTU of 1500 bytes. They are typically configured to carry up to 9000 bytes of payload (sometimes more), allowing more data per packet on high-speed networks. They must be manually enabled and matched end-to-end — and are not suitable for WAN or tunneled traffic.

Common jumbo frame sizes are 9000 bytes, but they can range from 1500 to 9600 bytes depending on the device. 

  • Standard Ethernet MTU: 1500 bytes (payload)
  • Jumbo Frame MTU: Typically 9000 bytes (payload)
  • Jumbo Frame Ethernet Frame Size: ~9018 bytes (includes Ethernet headers and CRC)

🎯 Why Use Jumbo Frames?

  • Lower CPU overhead: Fewer packets for the same amount of data = fewer interrupts and TCP/IP stack processing per byte.
  • Improved throughput: Larger payloads per packet improve the efficiency of high-speed networks (e.g. 10GbE, 40GbE).
  • Better for large transfers: Especially beneficial in storage networks (iSCSI, NFS), data center replication, and video streaming.

  ⚙️ How They Interact with TSO

  • When TSO and Jumbo Frames are both enabled:
  • OS sends a large segment (e.g. 64 KB) to the NIC (via TSO).
  • NIC splits the segment into larger packets due to the higher MTU.

Example :

Setting Packet Size on Wire Packets for 64 KB
MTU 1500 ~1460 bytes (TCP payload) ~44 packets
MTU 9000 (Jumbo) ~8960 bytes (TCP payload) ~8 packets

So with Jumbo Frames:

  • Fewer segments need to be generated.
  • Less per-packet overhead.
  • Faster total data transfer with less CPU load.

 When to Use Jumbo Frames

In controlled environments like data centers, HPC clusters, and backend storage networks . When all devices between sender and receiver are:

  • In the same broadcast domain or VLAN
  • Configured with matching Jumbo MTU (e.g., 9000)

🔬 When Not to Use Jumbo Frames

  • Not all network devices support it:
    • Switches, routers, firewalls, VPN appliances, etc. must all support and be configured for the same jumbo MTU.
  • Path MTU Discovery (PMTUD) can fail if ICMP is blocked:
    • Leading to black holes or silent packet drops if an intermediate hop can't handle jumbo frames.
  • Debugging becomes harder if partial support exists along the path.
  • Increased latency per packet in some workloads (e.g., small request/response).
  • Over the Internet , Over VPNs / SD-WAN / IPsec / GRE tunnels
  • Where intermediate devices may silently drop large frames
  • On consumer-grade or mixed-vendor networks

How MTU Works in Jumbo Frames

  • Sender checks MTU: If sender NIC is configured for Jumbo MTU (e.g., 9000), and the application generates large enough data, the OS/driver builds Jumbo Frames.
  • No fragmentation needed — if the entire path (Layer 2 switches, NICs) supports the larger MTU.

📊 Jumbo Frames and TSO

Feature Effect
Jumbo Frame Increases wire MTU (e.g. 9000), fewer packets needed
TSO Sends large 64KB+ buffers to NIC; NIC segments
Jumbo + TSO NIC splits large TSO buffers into large MTU-sized packets (e.g. 9000 bytes)
Combined Result Lower CPU use, fewer packets, better throughput

🛠️ Steps to Identify Jumbo Frames in Wireshark

✅ 1. Look at "Frame" and "Ethernet II" Lengths

Each captured packet will show you:

  • Frame Length on the Wire (includes L2 headers)
  • Payload length (Ethernet MTU)

  • Standard Ethernet Frame: ~1514 bytes (MTU 1500 + Ethernet header 14)
  • Jumbo Frame: >1518 bytes (e.g., 9014 for MTU 9000)

2. Filter for large frames

Use the Wireshark display filter, To see only Jumbo Frames.:

frame.len > 1514