Today I had a network issue in my lab, I still don’t have a clue what the issue was but I did discover something useful. I had 3 different VMkernel’s setup and I wanted to make sure each of the three had network connection to a specific destination address. After going through the esxcli command I bumped in to the following command which I found very helpful:
esxcli network diag ping -I vmk0 -H 10.27.51.132
In this case I use VMkernel Interface “vmk0” to ping to the address “10.27.51.132”. If I want to use a different VMkernel Interface I just specify it, so swap “vmk0” with “vmk1” for instance. Useful right?!
Doesn’t the vmkping -I command do the same thing?
Yes it does, but I would expect that esxcli is preferred from now on as most non-esxcli tools will be deprecated at some point
The nice thing about this command is that it’s specific for a VMkernel port. Typical example would be if you have multiple VMkernel ports configured for iSCSI. If one of them acts strange (paths down), you can easily check which one is causing trouble. As far as I know this esxcli option has only been introduced in version 5.1. There’s a number of other additional options (MAC Address table) which is useful as well.
Thanks. Was wondering how this could be achieved.
Yes; very useful.
I also had a very strange network issue come up. It impacted me immediately after last week’s upgrade from ESXi5.0 (Build 914586) to ESXi5.1 Update 1 (Build 1065491).
I have an intentional overlapping subnet design; where there is one primary path VMKernel interface on each ESXi host assigned IP addresses in a /20; each VMKernel with the /20 netmask.
Then there is a second VMkernel on a different port group on the same subnet, assigned IP addresses in the last /24 of that /20, with a longer netmask, a /24.
In order to select the _other_ VMkernel port in the host routing table for outgoing traffic to certain IPs (such as that of secondary NFS and iSCSI target points).
I have this design, because in the migration from ESX 4 to ESXi 5; the feature of VMware that previously allowed setting of static routes is no longer present (There is no way to set static routes in ESXi; like there used to be in ESX); the desired design can no longer be achieved.
Unfortunately, after the upgrade from ESXi5.0 to 5.1; the overlapping subnet design stopped working, and needed further adjustments that bring the outcome even farther away from the desired design of the NFS and management networking for the environment.
The -I option of vmkping is very useful in proving the issue, that IPv4 pings sourced from the VMKernel port with an overlapping subnet no longer works, but IPv6 traffic does function as expected.
Thanks for the fyi as I have always used vnkping i did even realise you could do it from esxcli.
I sure hope they’re not deprecating the non-esxcli ping tool any time soon. I happened to also find vmkping useful for troubleshooting in other cases; where in fact ESXCLI itself would not work; due to some error about unable to connect to localhost…
The root cause being; that one of the older iSCSI arrays which was no longer in production had been turned off; and that somehow caused hosts to never boot to a point where the ‘esxcli’ command would even work.
This should be a reminder that: troubleshooting tools should be as simple to use and have as few dependencies as possible! Some options should be provided to troubleshoot and adjust the config of things, even when complex system daemons such as iSCSI or WS-Man daemons cannot work properly.
That’s also where I have some complaint about the distributed Vswitch implementation… if vCenter is down; they have failed to provide a robust CLI tool to quickly block/unblock a port, or make other emergency temporary changes to get things back running, in the event that access to vCenter virtual machine is inoperative.
Compare to ESX 4 or ESX3.5 where there was a robust command line tool for about any configuration change you could imagine needing. Whereas lately; there seems to be a trend to move things to be dependant on more and more complicated tools using APIs such as “esxcli” that are dependant on more daemons and therefore more fragile… 🙁
I know this article is a little old, but I was hoping I could post a question to it.
It sounds like esxcli network diag ping works the same as vmkping. Since all my hosts are still on 5.0, I only have access to vmkping. My question though come on the side of how vmkping/esxcli network diag ping actually verifies connectivity.
Here is some info about my question:
Host1’s vmk01 – 10.10.0.5
Host 1’s vmk02 – 192.168.10.20
Host2’s vmk01 -10.10.0.10
Host2’s vmk02 – 192.168.10.22
If I ran a vmkping -I vmk01 10.10.0.10 on host 1. The round trip is successful. This makes sense to me, but what doesn’t make sense is when I do: vmkping -I vmk01 192.168.10.22 on host 1. The round trip is still successful. How is it getting from 10.10.0.5 to 192.168.10.22? Maybe I’m misunderstanding this command. Any explanation would be greatly appreciated.