Changes to ICMP Ping response in 5.1

In ESXi 5.1, the default behavior of ping has changed from previous releases.  According to KB 2042189 " ICMP Echo replies are now only sent back out the same interface that the Echo Request was received on"  What exactly does that mean, and why does it matter?

Lets say we have three interfaces:
mgmt   vmk0  10.10.20.12
iSCSI1 vmk1  10.10.30.12
iSCSI2 vmk2  10.10.30.13

The iSCSI array is at 10.10.30.50, and both vmk's are bound to the iSCSI intiator.  Since pings are not iSCSI traffic they are not handled by the initiator, instead they are handled by vmkernel routing.  In previous versions, this would mean all ping replies went out vmk1, since it was the first interface in the routing table.  Even if you ping vmk2, the reply will go out of vmk1.  This isn't usually a problem, but what happens if the vmnic that vmk1 is bound to goes down?  vmk2 is still up, but cannot reply to pings.  It isn't very often that this will cause an issue, but there are times when it does.

This change might also cause problems if you have your routing tables set up in such a way that the packets don't follow the same route in both directions.  For instance:

  
In previous versions of ESXi, the response would have used the routing table (green) even though this was not the same path that the packet was transmitted on.  With 5.1 (red), the reply has to go out vmk1, and because there is no way for it to reach the source address from there, the ping will fail.  Generally you won't see this type of configuration, and you really shouldn't be testing interfaces other than management from outside of it's subnet, but it does happen sometimes.

This is a relatively minor change, but it could cause some unexpected results, so it is important to be aware of.

See also Changes to ping command in ESXi 5.1.