When working with iSCSI storage configurations (like Dell MD3000i) in virtualized environments, jumbo frames (MTU > 1500) can significantly improve throughput. However, misconfigured network equipment between endpoints often silently drops oversized packets without proper fragmentation.

For Linux-based systems (including Ubuntu VMs), these commands provide MTU verification:

# Basic ping test with DF (Don't Fragment) flag
ping -M do -s 8972 -c 4 storage_target_ip

# Alternative using tracepath for path discovery
tracepath -n -l 9000 storage_target_ip

On ESXi hosts, use:

# ESXCLI ping with custom packet size
esxcli network diag ping -H storage_target_ip -s 9000 -d

• Successful response: Packets up to 9000 bytes return successfully (jumbo frames working)
• "Frag needed" error: Intermediate device requires fragmentation (MTU mismatch)
• Timeout: Silent packet drop (common with misconfigured switches)

For comprehensive testing, use this bash script to test incremental packet sizes:

#!/bin/bash
TARGET="storage_target_ip"
BASE_MTU=1500
JUMBO_MTU=9000

for size in {$BASE_MTU..$JUMBO_MTU..100}; do
  if ping -M do -s $((size-28)) -c 1 $TARGET &>/dev/null; then
    echo "Success at $size bytes"
  else
    echo "Failed at $size bytes - MTU likely restricted"
    break
  fi
done

When ICMP is blocked, consider TCP-based testing:

# Using nmap for TCP MTU discovery
nmap --mtu-version 1 --send-eth -T4 -F storage_target_ip

# Packet capture verification
sudo tcpdump -i eth0 -s 0 -w jumbo_test.pcap 'ip[6:2] & 0x3fff != 0'

If switch verification isn't possible, direct-connect tests between ESXi and MD3000i can isolate the issue:

1. Configure temporary IPs on dedicated interfaces
2. Disable all firewalls between endpoints
3. Run MTU tests without intermediate devices

When dealing with iSCSI storage (like Dell MD3000i) on VMware ESXi hosts, jumbo frame misconfiguration is a common performance killer. Here's how to validate end-to-end jumbo frame support when you don't have switch access privileges.

The most reliable method uses ping with DF (Don't Fragment) flag and varying packet sizes:

# Linux/Ubuntu VM:
ping -M do -s 8972 -c 4 target_ip

# Windows (PowerShell):
Test-NetConnection -ComputerName target_ip -TcpPort 3260 -InformationLevel Detailed

For VMware environments, check these key points:

# Check vSwitch MTU setting:
esxcli network vswitch standard list

# Verify VMkernel adapter MTU:
esxcli network ip interface list

# Test from ESXi host:
vmkping ++netstack=vmk -d -s 8972 target_ip

Here's what a successful jumbo frame test looks like:

$ ping -M do -s 8972 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 8972(9000) bytes of data.
8980 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.402 ms

And a failed test indicating MTU issues:

$ ping -M do -s 8972 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 8972(9000) bytes of data.
ping: local error: Message too long, mtu=1500

For more detailed analysis:

# traceroute with MTU discovery:
traceroute --mtu target_ip

# Advanced packet analysis:
sudo tcpdump -i vmnic0 -s 1518 -vvv "icmp or tcp port 3260"

Remember that iSCSI requires:

• Consistent MTU across all devices (initiator, switch, target)
• Proper TCP window scaling configuration
• Verified end-to-end path MTU (including any VLANs)