“In physical networking, a 1500-byte packet passes cleanly. In overlay networking, Geneve encapsulation adds 50 bytes of header overhead, silently dropping packets unless MTU 9000 Jumbo Frames are configured end-to-end.”

While architecting multi-tenant IBM Cloud SDDC topologies at IBM, we encountered a maddening intermittent issue: BGP TCP control packets established successfully, but large BGP update messages silently timed out and dropped neighbor adjacencies.

The Overlay Encapsulation Overhead

When NSX-T or NSX-V encapsulates a standard 1500-byte IP frame into a Geneve or VXLAN tunnel, it adds an outer IP header, UDP header (port 4789/6081), and VNI header totaling 50 bytes.

If the underlying physical vDS switch or physical L3 switch is left at default MTU 1500, the encapsulated 1550-byte packet requires IP fragmentation. Because Geneve traffic sets the DF (Don’t Fragment) bit, the physical switch silently drops the packet.

[!WARNING] Standard ICMP ping tests with 64-byte payloads will mask MTU issues. Always test MTU with unfragmented large payloads (ping -s 8972 -D).

# # Diagnosing MTU Blackholing from ESXi CLI
esxcli network diag ping -H 192.168.200.1 -s 8972 -d
# Output: Packet size 8972 bytes exceeds MTU 1500 on vswitch0 (DF bit set). Packet dropped.

# # Solution: Configure MTU 9000 across ESXi vDS and Physical Switch
esxcli network vswitch standard set -m 9000 -v vSwitch0
esxcli network vswitch dvs vmware set -m 9000 -v SDDCLab_vDS

The Verdict

Key Takeaway

Configure MTU 9000 (Jumbo Frames) End-to-End Before Provisioning Overlay Networks.

Never launch an NSX overlay or SDDC lab without verifying MTU 9000 on physical ToR switches, ESXi vDS portgroups, and VM kernel interfaces.