no network access after booting

Latest response

Good day all
I have a very strange problem" I have three virtual host running redhat 5.11 on VMware EXSI 6.0
The first two network work just fine and the third one have no network connection after booting.
I used a windows system with a continues ping to the server.
"request from 172.17.0.33 Destination host unreachable" This is when the system is OFF
When the system is booting and load the network card i get a five pings then go offline and get the error Request timed out. From my knowledge REQUEST TIMED OUT is that no Echo Reply messages were received within the default time.
Please note it can ping it self but cant ping no other system on the network.

Please see attach screen shot.
Am not sure if the problem is related to firewall or network card

Responses

Hello,

as the network interfaces are virtual, supplied by the virtualization software or hypervisor, it seems that they cannot be faulty, only incorrectly selected or configured. I wonder could someone else have made any changes to the hypervisor settings? Checking in the VMware settings for any differences would be a place to start.

On the virtual machines themselves, you could check the addresses are in the expected network and check the firewall.

~]# ip address
~]# service iptables status

rhel 5 did not have an vmxnet3 driver included - check you have the vmware tools installed or the nic is set to something other than vmxnet3.

I think RHEL 5 has/used to have an issue where the network stopped working when you were starting up VMware tools for the first time (i.e. when the virtual network interfaces get switched from whatever emulated hardware to the vmxnet3 driver). I think "service network restart" used to fix it without rebooting.

Your "five successful pings and then timeouts" behavior suggests to me the server might be first loading a different network driver, then unloading it and replacing it with vmxnet3 when the VMware Tools starts up.

If that is your issue, then after VMware Tools is installed, make sure your VM is now fully configured to use the vmxnet3 driver from the moment it boots up, i.e.: - make sure any "alias ethN" lines in /etc/modprobe.conf are using the vmxnet3, instead of whatever driver was there previously - if your VMware ESXi environment is a cluster, you might need to remove the HWADDR= lines from /etc/sysconfig/network-scripts/ifcfg-* files, as I think the MAC address of the network interfaces might change if the VM someday is booted up on a different VMware cluster node. This might cause the ethN names to be allocated differently from what you expect. - after you've done this, rebuild your initrd, in case the configuration for the old NIC driver module is still in effect within the initrd file.

Bottom line: you don't want the system to start the network using a different network driver and then unload it & replace it with vmxnet3 when the VMware Tools starts up; you'll want it to use vmxnet3 from the very beginning.

But if that is not the problem, have you checked network connectivity in any way other than pinging?

Run "cat /proc/sys/net/ipv4/icmp_echo_ignore_all": if it returns a value of 1, the system has been configured to not answer to pings at all, probably with a "net.ipv4.icmp_echo_ignore_all = 1" setting in the /etc/sysctl.conf file. The same effect can also be caused by iptables rules that block ICMP traffic.

When you get the "Destination host unreachable" message, it means that either the pinging host (if the destination host is in the same network segment as the pinging host) or the gateway nearest the destination host (if pinging from a different network segment) is making an ARP request for the target host but not getting an answer, so it's generating the "host unreachable" error.

But when your ping requests are timing out, that's obviously not happening: the target host might be answering to the ARP requests, so it might not actually be completely deaf. Or you might be having an IP address conflict and a network router that is configured to protect against IP hijacking. If the pinging host is on the same network segment as the target VM, use the "arp" command on the pinging host to see if it has successfully discovered the correct MAC address for the VM or not.

On the VM, you can likewise try and ping the default gateway (which may or may not answer to pings anyway) and immediately after the ping attempt, use the "arp -n" command to see if whether it got the MAC address of the gateway or not.

Bottom line: answering to pings is not mandatory, and some security hardening instructions will suggest disabling the ping response completely, so it is not a fully reliable diagnostic any more. However, ARP responses cannot be disabled if you want the network to function normally, and they will also provide much the same information on basic connectivity.