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.
Term | Layer | Description |
---|---|---|
PMTUD | Network | Discovers the largest IP packet that can be sent without fragmentation |
MSS (TCP) | Transport | Max TCP payload advertised by each endpoint |
MTU (IP) | Network | Max IP packet size supported by each link |
TSO/LSO | NIC | Offloads large TCP segments to be split at NIC level |
Jumbo Frames | Ethernet | Frames > 1500 bytes (e.g., 9000B) — only supported on compatible networks |
Jumbo TCP Segment | TCP/OS | Large segments seen in capture due to TSO — not actual on-wire sizes |
- 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.
Parameter | Before Clamping (MTU=1500) | After Clamping (e.g., MTU=1290–1383) |
---|---|---|
TSO Segment Size (e.g., 64KB) | 64KB | 64KB |
NIC Segments per TSO Segment | Fewer (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
No comments:
Post a Comment