Network troubleshooting is a large and complex topic. How you approach a situation will largely depend on the circumstances and environment in which you are doing the network troubleshooting. However, in this lesson, you will learn some of the most common tools you can use to perform network diagnostics. First, you'll learn about the ping command and how to test network connectivity with it. Next to learn how to examine network routes using the traceroute and tracepath commands. You'll also learn how to display various network statistics with the netstat command. We'll cover how to analyze raw network traffic using, tcpdump. Finally, you'll learn how to test if a port is actually opened, by connecting to it with the telnet command.

If you're having trouble connecting to a host over a network, one of the first things you can do is to ping the host. The ping command sends one or more ICMP packets to a host that you specify and waits for a reply. To use the ping command, simply run ping and provide a host name or an IP address. By default, ping will keep sending packets until you stop the program with Control + C. If you want to specify the number of packets to send, use the -c option. For example, to send three packets to google.com, run, ping -c 3 google.com.

Here is the output of a ping command. You should notice that the host name was translated into an IP address. In this case, google.com resolved to 216.58.2.7. If the name doesn't resolve, you'll get an unknown host error. In that case, you should use the IP address of the system you're trying to connect to. Also, if you can ping by IP address but not by name, there's a problem with a resolution of the DNS name. This ping command sent three packets. The statistics section reported that three replies were received and thus no packet loss was encountered. This means that we have network connectivity to google.com. You'll also notice that each packet has a time associated with it.

In this example, the first reply was received in 20 milliseconds as was the second packet. The third reply took 23.9 milliseconds. You'll see a summary of this activity on the last line in the output, rtt stands for round trip time. Here's an example where no reply we're received. You'll see that 100% packet loss is reported. This means that there is no connectivity between this host and google.com. At this point, the only thing we really know is that we can't ping google.com. It doesn't necessarily mean that Google is down.

At this point, I would try to ping something on my local network. If I can not ping anything on my local network, then I have a problem with my host. Maybe my network cable accidentally got disconnected or maybe I performed an upgrade on my server and the network drivers didn't update properly. Maybe I forgot to start the networking services on my server after I perform some maintenance. The point is that I at least know where to start looking. If I could successfully ping another host on my local network, then the problem lies outside of my system.

Maybe the router on the edge of my company's network is down and I cannot reach any hosts on the public Internet. We could test that scenario by pinging other hosts like facebook.com or youtube.com. If we can ping Facebook and YouTube, then it's a problem specifically getting to Google. Perhaps Google installed a firewall that simply discards ICNP packets and thus pings will never work. If that turns out to be the case, then we'll need to use other tools to test network connectivity, which we'll be covering soon.

This example demonstrates pinging an IP address. This IP address is on the same local network as the host I'm running the command from and the response times are very fast. They're less than one millisecond in fact. Ping tests an end point, but it doesn't tell you anything about the path or route the network packets take. To examine the route, use the traceroute command.

Note that the traceroute command requires root privileges to function properly. By default traceroute will attempt to translate IP addresses into DNS names. If you want to skip that step and just work with IP addresses, use the -n option. This will speed things up a bit and can be helpful if you are experiencing DNS issues. The output is easier to read than DNS names in my opinion. The traceroute command sends three packets to each hop along the way. You can see the response times for each hop along the route.

The first hop it was very quick, while the last hop is slower. This is expected behavior. However, if one of the hops along the path takes a very long time to respond, then that's an indication of where an issue may exist. Maybe there's network congestion on that particular router for example. If you see an asterisk where you would normally see time, that means a reply wasn't received. Some routers are actually configured to block traceroute data. In these cases that traceroute command may be of little use to you. If network connectivity is otherwise working and you see asterisks in traceroute output, that probably means a router is blocking traceroute data and not that there's an actual problem.

Network troubleshooting consists of looking at the same situation from multiple angles, using multiple tools and drawing conclusions from the overall picture. It also helps to know how your particular network is configured. Situational awareness is key to network troubleshooting. You cannot simply rely on one tool, like ping or traceroute and be guaranteed you know exactly what is happening on a network.

An alternative to traceroute is tracepath. The tracepath command does not require root privileges. You can use the -n option to use IP addresses instead of DNS names, just like you did with traceroute. Tracepath will produce one line of output for each response it receives, unlike traceroute which produces one line of output per hop. In this particular example, you'll see that two responses were received from 10.0.2.2. For simple checks, tracepath can do the trick. For advanced options, you'll probably end up using traceroute.