• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

no ping reply from vmkernel ports?

Thuleman

Supreme [H]ardness
Joined
Apr 13, 2004
Messages
5,833
Two physical NICs in access mode, each physical NIC shows good info via CDP, links are fine, both physical NICs are connected to physical switch ports which are in the same vlan.

Standard virtual switch. Two vmkernel ports, each vmkernel port has been assigned an IP address. No special setting on the vmkernel ports as they are for iSCSI traffic. Let's assume that the IP addresses are 172.25.10.10 and 172.25.10.11 for host1, for host2 they are 172.25.10.20 and 172.25.10.21, etc.

Software iSCSI adapter, iSCSI port binding has been configured. When looking at the iSCSI software adapter properties, Network Configuration tab, VMkernel Port Bindings, it shows both vmkernel ports, both have green icons, one reads Active whereas the other reads Last Active.

If I do a 'vmkping 172.25.10.20' (pinging host2) from host1, that works fine. If I do a 'vmkping 172.25.10.21' from host1 I get 100% packet loss. The same is true when pinging host1 from host2. It's also true when pinging from the "second" vmkernel port like so 'vmkping -I vmk2 172.25.10.20'. So the ping works if it comes from the first vmkernel port/nic but it doesn't when it either comes or goes to the "second" port/nic.

Not sure what to make of this. Suggestions?

I should add that the network folks say that they are not getting any MAC addresses from the switch port that the second pNic and vmk is connected to.
 
If you remove the iscsi port binding what happens?
Its been a while since I dealt with standard switches and iscsi. I don't think they handle traffic any differently. Just curious even with a flat network why not subnet off your iacsi traffic?
 
So you have two vmkernel ports on the same virtual switch.

Does the MTU of the virtual switch match that of the vmkernel ports? There is a setting for the vmkernel port and one for the vswitch.

If used for iSCSI you should go into each vmkernel port and set the alternate nic to unused in the failover order of the nic teaming tab, checking the box to override virtual switch setttings.

vSwitch 1 MTU 9000
iSCSI-1 MTU 9000, Active vmnic0, Unused vmnic1
iSCSI-2 MTU 9000, Active vmnic1, Unused vmnic0

try using the esxcli network diag ping commend, this chooses the source vmkernel port and the host address you are pinging, try pinging both ports from both ports to see which works and doesnt.

esxcli network diag ping -I vmk0 -H 172.25.10.11

Additionally if you have to switches and these cables go one to each switch then ensure the switches can talk to eachother on this vlan, IP the vlan and make sure the switch can ping the other switch.
 
If you remove the iscsi port binding what happens?
[...] Just curious even with a flat network why not subnet off your iacsi traffic?

Good idea on the port binding troubleshooting but that didn't affect the ping reply

The iSCSI traffic is subnetted, the 172.25.10.0/24 is all iSCSI only.

Additionally if you have to switches and these cables go one to each switch then ensure the switches can talk to eachother on this vlan, IP the vlan and make sure the switch can ping the other switch.

This appears to be the problem, after fiddling with this more systematically I was able to determine that you were right on. The interfaces on one switch can talk to interfaces on the same switch, but switches cannot talk to each other even though they ought to. Not sure how I missed that the first time around, thanks!
 
This appears to be the problem, after fiddling with this more systematically I was able to determine that you were right on. The interfaces on one switch can talk to interfaces on the same switch, but switches cannot talk to each other even though they ought to. Not sure how I missed that the first time around, thanks!

Ah, seen this quite a few times, i got a bag of guesses to pull from on these issues. haha
 
Back
Top