ESXi 5 vmkping from specific interface

[4nd7]

Hello everyone,

Is there a possibility in ESXi 5 to send pings from a specific vmk interface? The option seemed to have been removed from vmkping.

Thank you!

[Virtualinfra]

vmkping is still available.

#vmkping <target ip>

refer the below kb

http://kb.vmware.com/kb/1003728

[4nd7]

vmkping is still avaiable, I know. I was asking if there is still a way to specify the originating vmk interface.

[KamilAzmer]

The vmkping is not able to set the specific interface but the way vmkping is work based on the routing that you have

If you want the IP source/destination is been tested via the interface then you need to add the route via esxcfg-route command.

Hope it able helps you to use vmkping with route.

[4nd7]

I've tried to modify the route that is added by default. It doesn't seem to work, or I'm doing something wrong:

~ # esxcfg-route -a 192.168.126.0 255.255.255.0 192.168.126.183
Adding static route 192.168.126.0 to VMkernel
Error: Duplicate route to network 192.168.126.0/24 found.  Please delete the old route first.

~ # esxcfg-route -d 192.168.126.0 255.255.255.0 192.168.126.180
Deleting static route 192.168.126.0 from VMkernel
Error: Unable to delete route to 192.168.126.0/24 this route is automatically created based on the  IP address and netmask of one of the VMkernel TCP/IP  interfaces

[KamilAzmer]

Firstly, what is your objective for another vmk interface that you had,

If you are trying to test on it, make sure that you are not using the same ip address that your management used, if the purposed of trying to do vmkping via specific interface is for vmotion, the best to given you vmotion is different ip, because of one ip network only applicable for one routing table.

I suggest that you put in the different IP/s subnet to test on it.

[4nd7]

Hello,

I've moved the vMotion traffic to another subnet 192.168.128.0/24. This is how the routing table looks like now:

~ # esxcfg-route -l
VMkernel Routes:
Network             Netmask          Gateway          Interface
192.168.126.0    255.255.255.0    Local Subnet     vmk0
192.168.128.0    255.255.255.0    Local Subnet     vmk4
default               0.0.0.0               192.168.126.2    vmk0

All the traffic intended to the 192.168.128.0 flows through vmk4. How can I specify a different vmkernel inteface?

If I add a static route like: esxcfg-route -a 192.168.128.7/32 192.168.128.3 the ping stops working and the routing table looks like below. As you can see, vmk4 is still the interface through which traffic would flow:

~ # esxcfg-route -l
VMkernel Routes:
Network             Netmask             Gateway          Interface
192.168.128.7    255.255.255.255  192.168.128.3    vmk4
192.168.126.0    255.255.255.0      Local Subnet     vmk0
192.168.128.0    255.255.255.0      Local Subnet     vmk4
default               0.0.0.0               192.168.126.2     vmk0

This is how the vSwitch looks like:

Thank you

[KamilAzmer]

You must enable/tick vmotion traffic is used for the vmkernel and secondly you need set your management traffic for the vmk only.

You doesn't required to specific any route, because if you perform vmkping is automated used the range of subnet before talk to gateway.

If you want to verify the traffic use esxtop.

Sent by Maxis from my BlackBerry® smartphone

[4nd7]

Kamil,

Let's assume that I don't want to use that vmk for vMotion, I just want to test sending traffic from specific vmk. Do you know how this can be done? Have you done it before?

[KamilAzmer]

Erm..

May I know what the reason you want to use vmkping? Can you elaborate the info, if you want to tested your nic connection, you doesn't required to use vmkping method to perform on that.

Sent by Maxis from my BlackBerry® smartphone

[4nd7]

I want to test the nic connectivity. I can figure out how to do it, but it was simpler with vmkping, when the command had the option to specify a IPv4 interface.

The solution with esxcfg-route was never tried by you as it shows.

[KamilAzmer]

This is my suggestion to you, if you are trying to test the nic which is will be used for vm traffic after this, it was better that you create the new port group and assigned to the vmnic, and using the vm testing to perform it.

The vmkping is not used for testing any of nic connectivity, because it cannot be specific any of vmnic to be used.

It was useless if you trying used route for the same of range subnet and can be difficult you to test on it.

So, I suggest that you test using virtual machine network, don't test directly to your esxi.

Sent by Maxis from my BlackBerry® smartphone

[4nd7]

Using a vm connected to a portgroup was exactly the same idea that I had in mind.

I was trying with a new route at your suggestion, remember?

[KamilAzmer]

Yes, i know that was my suggest before to used the route, but basically to use the route is for the non used subnet range then you may test on it. (without required the gateway).

The better way to test the network is using port group. cause u able to defined directly to the network adapter, what is your purpose to test of network? for you iSCSI ? if iSCSI you need to know the iSCSI network is need to do a binding and only one vmnic for one vmk. If not your iSCSI network still using your management network.

Let make it clear,

1. What your purposed of the test?

2. what is your network adapter (vmnic) need to be tested)

3. what traffic that you wanted to use going thru

4. what is your ip range required to test

[chriswahl]

The method you describe here won't work. The vmkernel is not the gateway for the traffic (as shown in your example esxcfg-route -a 192.168.128.7/32 192.168.128.3). This would just loop.

The traffic will flow based on the routing table, and the specific vmkernel used can be identified in the neighbors table. (esxcfg-route -n).

Based on your screenshot I'm guessing you're looking to make sure the iSCSI vmkernel ports don't carry other stuff? If so, I'd suggest putting iSCSI on a unique subnet and using iSCSI binding.

[4nd7]

Hello Chris,

I just wanted to test vmnic connectivity first and after that configure certain services (vMotion, iSCSI).

Thank you!

[rickardnobel]

4nd7 wrote:

I've moved the vMotion traffic to another subnet 192.168.128.0/24. This is how the routing table looks like now:

...

This is how the vSwitch looks like:

It does look like vMotion is sharing the same IP subnet as iSCSI? (192.168.128.0/24?)

Like has been suggested earlier, you can not really specify how the vmkernel traffic is leaving the host other then the internal IP routing table - which itself comes from how you have defined your IP networks.

This means, if you have clear and separate subnets for Management, vMotion and iSCSI (and no special /32 adds to the routing table, just ordinary /24 networks for each function) there should never be an issue which interface(s) the traffic will go.

[4nd7]

Hello Rickard,

I've started this thread to find out a way to test connectivity using a specific vmk at source and destination. It appears that it went in all kind of directions :smileyhappy:

Thank you all for your thoughts!

[rickardnobel]

4nd7 wrote:

I've started this thread to find out a way to test connectivity using a specific vmk at source and destination.

The point might be that if you have different IP subnets for the different functions (and only Management needs gateway) then you should not need to actually define this specific vmk, it should already be obvious.

[GalNeb]

Unfortunately there is no way to do it with IP4.  There is a way using the -I argument with IP6, but it only works with IP6.  There is an obvious need for it.  And with all due respect for some of those answering here, the route table is of no help when both interfaces are on the same network.  The most common example of this is Sofware Based iSCSI where multiple vmk's are all on the same network for multipathing.  We need the ability to test each interface for connectivity and know which interface is being tested.

So if anyone from VMware is listening, consider this a request.

[rickardnobel]

That is true, it should be of great value to be able to do that on multi-path iSCSI. In other cases it should be "solved" by the routing table and be of less importance, but with iSCSI it should be good to be able to confirm both interfaces.

One work-around, however not very elegant, is to disconnect one iSCSI cable at the time... :smileyhappy:

[GalNeb]

Kind of hard to do that when you are 1500 miles away from the datacenter like I am.  :-)

[rickardnobel]

GalNeb wrote:

Kind of hard to do that when you are 1500 miles away from the datacenter like I am.  :-)

Telnet to the physical switch and do a "interface gi0/x shutdown". :smileyhappy: Ugly, but should work.

But, of course, such option should be included into vmkping, that would be great.

[chadleyhamil]

vmkping [args] [host]

   args:

      -4               use IPv4 (default)

      -6               use IPv6 - ICMPv6 Echo request

      -c <count>       set packet count

      -d               set DF bit on IPv4 packets

      -D               vmkernel TCP stack debug mode

      -i <interval>    set interval (secs)

     -I <interface>   outgoing interface - for IPv6 scope or IPv4

                       (IPv4 advanced option; bypasses routing lookup)

      -N <next_hop>    set IP_NEXTHOP - requires -I option

                       (IPv4 advanced option; bypasses routing lookup)

      -s <size>        set send size

      -t <ttl>         set IPv4 Time To Live or IPv6 Hop Limit

      -v               verbose

      -W <timeout>     set timeout to wait if no responses are

                       received (secs)

      -X               XML output format for esxcli framework.

   NOTE: In vmkernel TCP debug mode, vmkping traverses

         VSI and pings various configured addresses.

Run vmkping -I vmk0 ipaddress it will ping out a certain interface.

[FabSanSF]

the best way i found to validate interfaces are to down the nics to test each interface

vswitch0

vmnic0

vmnic1

vmnic2

esxcli network nic down -n vmnic0

esxcli network nic down -n vmnic1 (if applicable)

vmkping -I vmk0 x.x.x.x (gateway) <- this will force pings to vmnic2

it if works, UP the vmnics and repeat the process for the remaining vmnics