VMware Communities
rsalter123
Contributor
Contributor

Dropping packets when pinging host (RedHat 7.2) from guest (RedHat 6.2 or Windows 10 VM)

Dropping packets when pinging host (RedHat 7.2) from guest (RedHat 6.2 or Windows 10 VM)

Using VMware Workstation Pro 12.5.7

I've tried two different configurations and receive the same results:

1) Host OS: Red Hat 7.2, Guest OS: Red Hat 6.2

2) Host OS: Red Hat 7.2, Guest OS: Windows 10

In both cases when I ping the Host from the Guest I'm losing an average of 26% of the pings as "Request Timed Out"

In both cases the Guest can ping other machines with no loss and pings *from* the Host to the Guest have no loss.

There are multiple Ethernet adapters on the Host machine each on different subnets (2.2.2.x, 131.1.1.x, etc) and the Guest needs to use 2 in one configuration and 3 different subnets in the other one.

I've set up a custom Bridged vmnets for each network adapter on the host, linking each one to a specific Ethernet adapter.

For instance, if the Host's eth0 is 2.2.2.2 and the Guest is configured as 2.2.2.4 then I created vmnet0 and bridged it to eth0.

When pinging 2.2.2.2 (Host adapter) from with the Guest OS I'm getting the packet losses.

Any thoughts?

Message was edited by: Robert Salter Clarification: Changed RHEL to RedHat.

4 Replies
cyberpaul
Enthusiast
Enthusiast

Hi, what about firewall on the host? More often that not, there is a limit on icmp echo packets to prevent ping storms.

0 Kudos
rsalter123
Contributor
Contributor

@cyberpaul  Thank you for the suggestion.  The firewall is off in the host and each VM and the problem remains.

0 Kudos
cyberpaul
Enthusiast
Enthusiast

OK, in that case please run tcpdump on the host to see if echo requests are coming in and replies going out.

If there are missing replies, that would suggest problem on the host. In that case, please check /var/log/messages for any related info, especially "non-zero address" errors etc.

Let me know the result 🙂

0 Kudos
rsalter123
Contributor
Contributor

It turned out when we turned off the firewall on the host machine the time to live was set to something very small, under a second apparently.

Turning the firewall back on, on the host machine, fixed the problem.