9 Tips to diagnose remote GNU/Linux server network connectivity issues

by on February 20, 2007 · 13 comments· LAST UPDATED February 22, 2007

in , ,

Many new admin or Linux users get frustrated when their remote Linux box is not accessible dues to network connectivity.

In this article I will try to provide tools and information about how to diagnose network configurations. You can try these tips/tools to diagnose an issue of Linux network connectivity to remote or local servers.

Steps to diagnose the problem:

#1: Use ping command

Always ping the IP address of server and then try hostname. For example:
$ ping 75.126.43.232
$ ping cyberciti.biz

If you can ping by IP address but not by hostname, then make sure you have correct DNS name servers setup in /etc/resolv.conf file.
$ less /etc/resolv.conf
Output:

nameserver 192.168.1.10
nameserver 208.67.222.222
nameserver 208.67.220.220

Make sure your own DNS server running.

#2: Use traceroute command

If you cannot ping your server at all, use traceroute to trace network problem. traceroute provides the detailed information about path to a network server. You can always find out if server is down from your own workstation or gateway router.
$ traceroute cyberciti.biz

#3: Look for default route / gateway IP

If traceroute point out that you cannot reach to your own gateway, then check routing setting on your own workstation. Add default route.
# route
# route add default gw 192.168.1.254 eth0

#4: Look for IP address

Make sure you have correct IP address assigned by DHCP server. Some time network admin make changes to DHCP server or changes IP routing or other stuff. It is a good idea to restart network interface:
# /etc/init.d/network restart
# tail -f /var/log/message
# ifconfig -a
# route

#5: Check for network cables and power supply

Make sure the network cable is plugged into interface as well as into network switch/hub. It is possible that someone may have pulled out network cable from switch/workstation.

#6: Check firewall log

Make sure your own firewall is not blocking access to remote server. Just try to stop your firewall.
# iptables -L -n
# tail -f /var/log/messages
# /etc/init.d/iptables stop

If you are using Cisco PIX or dedicated Linux / OpenBSD box as firewall, check logs for more information.

#7: Connect to correct ports

Most service connects to default port such as
HTTP - port 80
Proxy - port 3128
SSH - port 22
FTP - port 21

Sometime you change default ports to increase security, so make sure you are connecting to correct remote port.

#8 Network analysis

Besides above tools you must use network analysis tools such as Wireshark aka Ethereal sniffer, netwatch, tcpdump and others. These tools are commonly known as a network protocol analyzer. They can watch routing, client and server communication, packets and much more.

Install Wireshark.
# apt-get install wireshark
$ sudo wireshark &

wireshark  network analysis tools
(click to enlarge)

For detailed usage please refer to official documentation

tcpdump

tcpdump is one my favorite tool. For example to print all packets arriving at router, use:
# tcpdump host router

Read man page of tcpdump for more examples and usage. I recommend you to read tcpdump recipes for more information.

If all of the above test fails contact remote IDC staff. Remote server may be down due any one of the following causes:

  • Remote network/gateway down (traceroute will tell this)
  • Your server is down (cable is not plugged or power is down or hardware failure etc)
  • Your server is under heavy load (Slashdotted or dugg to death)
  • Your server is under attack ( DoS/DDoS )
  • Your server is rooted (read as cracked or hacked)
  • Misconfiguration (server software - firewall, apache, mysql config issues)

#9: Some common question (FAQ)

I can ping a server by its ip address, but I can not "ping" it by name
Setup correct nameserver

I can connect to a Web or FTP server directly, but if I “ping” the server it always returns “Request Timed Out”
Many net/server admins block ICMP ping request as a security measure. So it is not possible to use ping or traceroute command. However you can try out tcptraceroute to bypass the firewall filters policy to run traceroute.

Can I use GUI tools?
You can use cheops - a network monitor tools for same purpose. It’s a combination of a variety of network tools to provide system administrators and users with a simple interface to managing and accessing their networks. Install cheops with apt-get command:
# apt-get install cheops
$ sudo cheops &

7 Tips to diagnosing remote GNU/Linux server network connectivity issues
Now just add your domains and hosts. You can select any of your host by right clicking and run ping, traceroute, DNS lookup etc.

You can also use mtr for finding out a bad or simply overloaded network link with Linux/UNIX oses.

Please note that you can use these tools to diagnose any operating system such as Sun Solaris or Microsoft Window server :)

That's all my brain can remember. Feel free to share any other tips in the comments.

Updated for accuracy.

TwitterFacebookGoogle+PDF versionFound an error/typo on this page? Help us!

{ 13 comments… read them below or add one }

1 Sean February 20, 2007 at 1:42 pm

Also check the arp table… Good for finding out if the problem is fw related, layer2, or layer 3.

Sean

Reply

2 gregf February 20, 2007 at 3:13 pm

Great article. Sure this will help a bunch of people. Keep up the great work on the site. Have it in liferea.

Reply

3 mangoo February 21, 2007 at 11:00 pm

“arping” command is sometimes useful, too (mainly for local problems).

Reply

4 Joe February 22, 2007 at 10:18 am
5 Sven Hoexter February 22, 2007 at 3:36 pm

When you’re at #5 you might have a serial console to access (ok that’s lokal network debugging then) the system and ask mii-tool for informations. Sometimes that’s a fast option to check if someone pluged off the network cable or the port on the patch panel is dead etc. pp.

Reply

6 Chris Dos February 27, 2007 at 12:12 am

Don’t forget that tcptraceroute can also help diagnose if there is a transparent proxy between your and your server. mii-tool doesn’t work with all network cards, ethtool seems to work with everything at this point.

Reply

7 raj February 27, 2007 at 6:03 am

99% time the cause of network connection problems are environmental and IDC staff, stemming from someone inadvertantly pulling out a network cable.

Reply

8 Tim Archer April 10, 2007 at 12:11 am

In case you want some details on how to change the default port for SSH on your server, making it a little more secure, check out the writeup at:
http://timarcher.com/?q=node/46

Reply

9 vikram September 3, 2007 at 11:13 am

please send me linux networking command

Reply

10 Vince September 12, 2007 at 5:39 pm

Great article. Can you suggest any other resources? I have a server I’ve setup with Fedora7 and it keeps going offline seemingly randomly. None of the items you mentioned appear to be the issue.

Here are suspicious logs, but I’m not sure what this means:
Sep 12 08:26:40 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Sep 12 08:26:40 localhost kernel: sky2 eth0: tx timeout
Sep 12 08:26:40 localhost kernel: sky2 eth0: disabling interface
Sep 12 08:26:40 localhost kernel: sky2 eth0: enabling interface
Sep 12 08:26:40 localhost kernel: sky2 eth0: ram buffer 0K
Sep 12 08:26:43 localhost kernel: sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both

Reply

11 Andy January 16, 2008 at 3:55 am

Yeah, this was a nice article to refer to.

Reply

12 arti ajans April 4, 2008 at 7:23 pm

thanks you much.

Reply

13 Server Support June 18, 2009 at 4:01 am

I am agree with Chris Dos that Don’t forget that tcptraceroute can also help diagnose if there is a transparent proxy between your and your server.

Ya it helps to diagnose your server error. MTR also play a important role in finding network..

Thanks for such a nice stuff.

Reply

Leave a Comment

Previous post:

Next post: