Verifying the networking within a Linux based guest operating system
Article ID: 324946
Updated On:
Products
VMware
VMware Cloud Director
VMware Desktop Hypervisor
VMware vCenter Server
VMware vSphere ESXi
Issue/Introduction
This article provides steps to verify the network connectivity within a Linux based guest operating system.
Symptoms:
Symptoms:
- Virtual machine does not have network connectivity
- Virtual machine cannot connect to the network
Resolution
If you are having network connectivity issues, verify that the guest operating system is configured properly.
To verify that the guest operating system is configured properly on a Linux virtual machine:
- Verify that VMware Tools has been loaded on the guest operating system. In a Linux virtual machine, boot the guest operating system, open a command prompt or run start X and launch your graphical environment. You can then launch the VMware Tools background application using this command:
vmware-toolbox &
If the command does not run, VMware Tools has not been installed. It is necessary to have VMware Tools loaded for your NIC to function. For more information, see Installing VMware Tools in a Linux virtual machine using a Compiler (1018414).
- Verify that the virtual network adapter is present and enabled by using ifconfig. If nothing appears, this can indicate that the NIC is shut down or not present.
Note: Network interfaces appear if they are activated, but do not have a link. Proceed to Step 3 if they appear available.
# ifconfig
You see an output similar to:
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.48.128 Bcast:192.168.48.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2080 (2.0 KiB) TX bytes:7037 (6.8 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1453 errors:0 dropped:0 overruns:0 frame:0
TX packets:1453 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2294308 (2.1 MiB) TX bytes:2294308 (2.1 MiB)
- Verify the link status by using ethtool. If this fails, it indicates an issue with a physical link or improper duplex setting.
# ethtool eth#
Where # is the network adapter number as shown in ifconfig.
For example:
# ethtool eth0
You see an output similar to:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: p
Current message level: 0x00000007 (7)
Link detected: yes
- If a link is detected, ping an outside source to see if you get a response. If this fails, this can indicate a routing issue, or possible DNS problem if a hostname is used. Ping an IP address and hostname to verify both.
# ping ip address/hostname
Where ip address/hostname is a known outside IP address or a valid resolvable hostname known to work on other virtual machines or workstations.
For example:
# ping 192.168.1.10
PING 192.168.1.111 (192.168.1.111) from 192.168.1.100 : 56(84) bytes of data.
From 192.168.1.111 icmp_seq=1 Destination Host Unreachable
From 192.168.1.111 icmp_seq=2 Destination Host Unreachable
From 192.168.1.111 icmp_seq=3 Destination Host Unreachable
From 192.168.1.111 icmp_seq=4 Destination Host Unreachable
From 192.168.1.111 icmp_seq=5 Destination Host Unreachable
From 192.168.1.111 icmp_seq=6 Destination Host Unreachable
--- 192.168.1.111 ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% loss, time 7021ms, pipe 3
- If you can ping by IP but not by hostname, then check that the DNS name server entires in /etc/resolv.conf file are correct by executing:
less /etc/resolv.conf
- If there are no ping replies, then ping the gateway and check network settings by executing:
ping <gateway ip>
less /etc/sysconfig/network
- If you can ping by IP but not by hostname, then check that the DNS name server entires in /etc/resolv.conf file are correct by executing:
- If the ping fails, verify further using the telnet command to test network connectivity:
# telnet <ip address> <port>
For example:
# telnet 192.168.111 22
Trying 192.168.1.111
telnet: connect to address 192.168.1.111: Connection refused
- If a ping is successful, and you are unable to connect to a specific port, it indicates a blocked port or an active firewall somewhere in your environment. Use the netstat command to verify ports on the source system:
# netstat -a
You see an output similar to:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:30037 *:* LISTEN
udp 0 0 *:bootpc *:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 6135 /tmp/.X11-unix/X0unix 2 [ ACC ] STREAM LISTENING 5140 /var/run/acpid.socket
- If everything appears to be listening and opened, you can use the traceroute command to see where the connection is failing. Generally it is a good idea to use the command to trace your path back to a known good connection in your environment, such as a your vCenter Server, if available.
# traceroute ip address
For example:
# traceroute 192.168.1.29
Tracing route to VCENTERSRV [192.168.1.29]
over a maximum of 30 hops:
1 101 ms 100 ms 116 ms example.yourdomain.com [192.168.1.254]
2 138 ms 152 ms 115 ms core.yourdomain.com [192.169.1.2]
3 124 ms 134 ms 138 ms VCENTERSRV [192.168.1.29]
Trace complete.
If, at anytime, you receive the error message Destination host unreachable, it indicates there is a firewall or device preventing you from establishing a network connection. Note where the failure occurs and troubleshoot from there.
Additional Information
Feedback
Yes
No
Powered by
