ESXi vmkping Commands: Test VMkernel Connectivity, MTU, and Jumbo Frames

vmkping tests network connectivity from an ESXi VMkernel interface rather than from a guest operating system. Use it to verify management, vMotion, vSAN, NFS, iSCSI, replication, and other VMkernel paths; force the correct source interface or TCP/IP stack; and prove whether an end-to-end path carries the configured MTU.

The most useful pattern is:

vmkping -I vmk<N> -d -s <payload-bytes> -c 3 <remote-destination-IP>

For IPv4, use a payload of 1472 to validate an MTU of 1500 or 8972 to validate an MTU of 9000. If the VMkernel adapter uses a dedicated stack such as the vMotion TCP/IP stack, add -S vmotion. Always test a remote peer in both directions; pinging the source host’s own address does not validate the network path.

What vmkping actually tests

A normal ping launched from another machine proves that an IP address can answer ICMP. It does not prove that ESXi used the VMkernel adapter, VLAN, route, uplink, or TCP/IP stack that carries the workload you are troubleshooting.

vmkping originates ICMP traffic inside the ESXi VMkernel. The -I option selects a source VMkernel interface such as vmk1. The -S option selects a TCP/IP stack when the adapter is not on the default stack. Those controls make the command useful for isolating failures that affect one service path while management traffic still works.

Quick vmkping command reference

Goal	Command
Basic reachability from a VMkernel adapter	vmkping -I vmk1 -c 3 10.10.10.11
Use the dedicated vMotion stack	vmkping -I vmk1 -S vmotion -c 3 10.10.10.11
Validate IPv4 MTU 1500	vmkping -I vmk1 -d -s 1472 -c 3 10.10.10.11
Validate IPv4 MTU 9000	vmkping -I vmk1 -d -s 8972 -c 3 10.10.10.11
Validate MTU 9000 on the vMotion stack	vmkping -I vmk1 -S vmotion -d -s 8972 -c 3 10.10.10.11

Replace vmk1 and 10.10.10.11 with the actual source VMkernel interface and the remote VMkernel or storage endpoint. Do not assume the same VMkernel number is used on every host.

Before you run vmkping

Connect to the ESXi Shell or an approved SSH session. The commands in this guide inspect configuration and send test traffic; they do not change MTU, routing, switch, or VMkernel settings. Record the source host, destination, service, expected VLAN, expected MTU, and maintenance or incident context before you begin.

1. Inventory the VMkernel interfaces

esxcli network ip interface list
esxcli network ip interface ipv4 get

Confirm the interface name, IP address, port group or distributed-port connection, MTU, and TCP/IP stack. If you are troubleshooting vMotion, check which adapter carries that service tag:

esxcli network ip interface tag get -i vmk1

The older esxcfg-vmknic -l overview remains useful on many hosts, but the esxcli output makes the interface and addressing checks explicit.

2. Choose a real remote destination

• For vMotion or vSAN, use the corresponding VMkernel IP on another ESXi host.
• For iSCSI or NFS, use the target interface on the storage system.
• For replication, use the remote endpoint assigned to that replication path.
• Use an IP address during path testing so DNS does not send the test to a management address or hide a name-resolution problem.

Test basic VMkernel connectivity

Start with a small, ordinary ping before testing jumbo frames. From host 01, where vmk1 is 10.10.10.10, test the remote VMkernel address on host 02:

vmkping -I vmk1 -c 3 10.10.10.11

Then reverse the test from host 02:

vmkping -I vmk1 -c 3 10.10.10.10

A reply in both directions confirms basic IP reachability over the selected VMkernel path. It does not yet prove that the path supports the intended MTU or that an application port is open.

Use the correct TCP/IP stack

If the adapter is attached to the dedicated vMotion stack, test that stack explicitly:

vmkping -I vmk1 -S vmotion -c 3 10.10.10.11

Without the right stack, ESXi may use the default route or return sendto() failed (Network is unreachable) even when the intended service path is configured correctly. Broadcom documents -S stack selection for IPv4; validate IPv6 testing separately when IPv6 is in scope.

Test MTU 1500 and jumbo frames

For an IPv4 path, subtract the 20-byte IP header and 8-byte ICMP header from the configured MTU. That produces the payload sizes used in the standard tests:

Configured MTU	vmkping payload	Purpose
1500	1472	Validate a standard Ethernet MTU
9000	8972	Validate a jumbo-frame path

Test the standard path first:

vmkping -I vmk1 -d -s 1472 -c 3 10.10.10.11

Then test an MTU of 9000:

vmkping -I vmk1 -d -s 8972 -c 3 10.10.10.11

The -d option sets “do not fragment,” making a successful reply evidence that the complete path carried the requested packet size. If the service uses the vMotion stack, add -S vmotion to both tests.

Repeat from the destination host back to the source. Asymmetric VLAN, routing, gateway, firewall, or uplink behavior can allow one direction and break the other.

How to interpret vmkping results

Result	What it indicates	Next check
Replies with 0% loss	The selected source path reached the destination at the tested size.	Reverse the direction and, if relevant, test the application port.
Small ping succeeds; 1472 or 8972 with -d fails	A device on the path may not support the intended MTU.	Compare the VMkernel, virtual switch, uplink, physical switch, inter-switch link, router, firewall, and destination MTUs.
sendto() failed (Message too long)	The packet exceeds a local interface or virtual-switch limit before it leaves the host.	Verify the source VMkernel and virtual-switch MTU.
Network is unreachable	The selected TCP/IP stack lacks a usable route or gateway to the destination.	Verify the stack, subnet, route, and gateway; do not assume the default stack.
100% packet loss at every size	This is broader than a jumbo-frame-only failure.	Check the destination IP, service interface, VLAN, link state, route, firewall, and physical path.
Intermittent loss	A teaming, uplink, switchport, congestion, duplicate-IP, or physical-layer issue may be present.	Test repeatedly, correlate by uplink and switchport, and review counters and logs.

A safe vmkping troubleshooting sequence

1. Define the service path. Identify the exact source host, source VMkernel, destination interface, TCP/IP stack, VLAN, and expected MTU.
2. Verify local configuration. Confirm that the VMkernel interface is enabled, has the expected IP address and MTU, and is attached to the intended port group or distributed port.
3. Run a basic explicit-interface test. Use -I with a remote IP and three packets.
4. Select the service stack when required. Add -S vmotion or the applicable configured stack instead of relying on the default route.
5. Validate MTU in stages. Test normal reachability, then 1472 bytes with -d, then 8972 bytes only when MTU 9000 is expected.
6. Reverse the test. Repeat from the remote host or peer to reveal asymmetric behavior.
7. Trace the path outward. Map the VMkernel to its port group, virtual switch, active vmnic, physical switchport, VLAN trunk, inter-switch links, routed hops, and destination.
8. Change configuration only after the failing boundary is known. Coordinate MTU, VLAN, route, gateway, and switch changes with the platform and network owners.

If the problem involves an NSX overlay, pair these tests with the NSX-T overlay networking and MTU troubleshooting guide. A VMkernel ping can validate underlay reachability and packet size, but it does not by itself validate GENEVE state, transport-node configuration, or distributed routing.

Common vmkping mistakes

• Pinging the local VMkernel IP. That proves the local stack can answer itself, not that the network path works.
• Using a hostname. DNS may resolve to the management interface rather than the service interface you meant to test.
• Omitting -I. ESXi can select a different source interface than expected.
• Omitting -S for a dedicated stack. The default stack may not contain the required route.
• Using -s 9000 for MTU 9000. The payload excludes the IPv4 and ICMP headers, so the standard ESXi test uses 8972.
• Testing only one direction. Return-path failures and asymmetric routing can remain hidden.
• Changing MTU before proving the boundary. A mismatch can exist at the VMkernel adapter, virtual switch, uplink, switchport, inter-switch link, router, firewall, or destination.

vmkping options cheat sheet

Option	Use
-4	Use IPv4; this is the default.
-6	Use IPv6.
-c <count>	Set the number of requests.
-d	Set “do not fragment” for IPv4 or disable fragmentation for IPv6.
-i <seconds>	Set the interval between requests.
-I <vmk>	Select the outgoing VMkernel interface.
-N <next-hop>	Specify a next hop and bypass the normal route lookup; IPv4 also requires -I.
-s <bytes>	Set the ICMP data payload size, excluding headers.
-S <stack>	Select a TCP/IP stack for IPv4, such as vmotion.
-t <ttl>	Set IPv4 TTL or IPv6 hop limit.
-v	Show verbose output.
-W <seconds>	Set the reply timeout.

When vmkping is not enough

A successful vmkping proves ICMP reachability at the tested size. It does not prove that a required TCP or UDP port is open, that packet loss is absent under load, or that NSX, storage, replication, or vMotion control-plane state is healthy. Continue with service-specific port checks, virtual and physical interface counters, logs, and packet capture only when the symptom requires them.

For repeatable evidence, record the command, source host and VMkernel, selected stack, destination IP, expected MTU, direction, timestamp, packet loss, and round-trip values. That turns “ping works” into evidence the platform and network teams can use together.

Official references

• Broadcom: Testing VMkernel network connectivity with the vmkping command
• Broadcom: Testing jumbo frame pings from ESXi over the network
• Broadcom: Risks and potential impacts of changing MTU

Continue reading

VM Network Troubleshooting from Guest OS to Uplink: A Layer by Layer VMware Runbook

Explore another guide in this topic and build on what you have just read. Read the article →

Stay informed

Make your next architecture decision with confidence.

Get Paul Bryant's practical guides to enterprise AI, hybrid platforms, and day-2 operations by email. New articles as they publish. Unsubscribe anytime.

Email Address

Get new articles