// Guide · Networking & infrastructure

MTU Path Calculator

NSX overlay traffic is encapsulated in GENEVE — adding overhead at every layer. If your physical MTU isn't at least 1600 (1700 recommended), you get silent fragmentation and packet drops that are notoriously hard to debug. This tool walks through the math and flags mismatches.

GENEVE / VXLANNSX OverlayFrame AnalysisEncapsulation Overhead

Open the tool Jump to walkthrough

Quick start

Enter your physical link MTU — usually 9000 (jumbo) or 1500 (default).
Set the encapsulation type — GENEVE for NSX-T/NSX, VXLAN for legacy NSX-V.
Enter your VM MTU — typically 1500 unless guests use jumbo internally.
Read the validation result — green for compatible, red for mismatch with the exact byte deficit shown.

On this page

When to use this tool
How it works
Step-by-step walkthrough
Examples
Common mistakes
Related tools
FAQ

When to use this tool

Use this tool when:

Designing a new VCF/NSX deployment — confirm the physical network is sized for overlay overhead before ordering switches.
Debugging mysterious packet loss — particularly TCP sessions that work fine for small packets but stall on large transfers.
Auditing an existing environment — verify your switches actually carry jumbo frames end-to-end (not just on a few interfaces).
Mixing legacy and modern overlay — GENEVE adds different overhead than VXLAN; switching between them needs MTU re-validation.

How it works

Every layer of network encapsulation adds bytes. From the inside out for an overlay packet:

VM payload — typically 1500 for the inner Ethernet frame
+ Inner Ethernet header — 14 bytes
+ Outer IP/UDP headers — 28 bytes
+ GENEVE header — variable, typically 16-40 bytes (8 base + options)
+ Outer Ethernet header — 14 bytes (or 18 with VLAN tag)

Total overhead for GENEVE is typically 54-78 bytes. To carry a 1500-byte VM frame, the physical MTU must be at least 1554 bytes. NSX recommends 1600 minimum, 1700 preferred, 9000 (jumbo) ideal.

ℹ

Why jumbo frames win With MTU 9000, you have 7,400+ bytes of headroom over the worst-case overhead — fragmentation is impossible. With MTU 1500, you have negative headroom and overlay traffic gets silently dropped or fragmented, killing performance.

Step-by-step walkthrough

1. Set the physical underlay MTU

This is the MTU configured on your ToR switches and ESXi physical NICs. Typical values:

1500 — default Ethernet (NEVER use this for NSX overlay)
9000 — jumbo frames (recommended for VCF)
1600 or 1700 — minimum acceptable for NSX overlay

2. Pick encapsulation type

GENEVE for NSX (modern, default) or VXLAN for legacy NSX-V. The headers differ slightly in size (GENEVE has variable-length options).

3. Set VM MTU

The MTU configured inside guest VMs. Almost always 1500. Some workloads (storage, HPC) use jumbo internally — set 9000 in those cases.

4. Read the result

The tool shows a layered breakdown:

Per-layer MTU vs. overhead
Required minimum physical MTU
Pass/fail verdict
Specific byte deficit if your config is too small

Examples

Example · Standard VCF deployment with jumbo

Physical: 9000, Encap: GENEVE, VM: 1500

Result: ✓ Compatible. Headroom: 7,422 bytes. No fragmentation possible.

Example · Bad config — default MTU on overlay

Physical: 1500, Encap: GENEVE, VM: 1500

Result: ✗ Insufficient. Need 1554 bytes minimum. Frames silently drop or fragment.

Common mistakes

⚠

"Jumbo on switches" doesn't mean "jumbo end-to-end" Jumbo MTU must be configured on every device in the path: ToR ports, uplinks to spine, spine ports, and the ESXi vmnic. One device at 1500 bottlenecks the whole path. Test with vmkping -d -s 8972 -I vmkN target.

⚠

TEP MTU and physical MTU are not the same field In NSX, the TEP MTU configured on the host transport profile must be ≤ the physical MTU. If physical is 9000, set TEP MTU to 8800-9000. Going over physical = silent drops.

⚠

Don't set VM MTU to match physical Setting a VM's MTU to 9000 only helps if the VM's peers also use 9000 AND the entire path supports it. For internet-bound traffic, 1500 is correct. Inappropriate jumbo at the VM layer causes more breakage than it solves.

Tools that pair well with MTU Path Calculator:

FAQ

What MTU should I configure for NSX TEP?

Standard guidance: TEP MTU = physical MTU minus 100 bytes for safety. So with physical 9000, set TEP MTU to 8900. With physical 1700, set TEP to 1600.

Why does NSX recommend 1700 specifically?

NSX 4+ GENEVE with all options enabled can use up to 76 bytes of overhead. 1700 covers 1500 + worst-case GENEVE + Ethernet header + safety margin. 1600 is the absolute minimum for basic GENEVE.

Does this matter if I'm only using VLAN-backed segments (no overlay)?

No overlay = no encapsulation = no extra overhead. VLAN segments use the physical MTU directly. But most VCF deployments use overlay for at least workload networks.

How do I test MTU end-to-end?

Use vmkping -d -s <size> -I vmkN <target>. The -d flag sets don't-fragment so the test fails (rather than fragmenting) if MTU is too small. Try size 8972 (9000 minus 28 IP/ICMP overhead).