All of the detailed troubleshooting tools are at the command line. In this video, you’ll learn about ping, traceroute, nslookup, dig, tcpdump, netstat, and more.
One of the most common utilities you’ll use at the command line is the ping command. The ping command tells you if a device on the network is reachable. And if it’s not reachable, it will give you information that might help you understand why that device is not reachable.
This uses the ICMP protocol. This is the Internet Control Message Protocol to be able to query that device and get a response from that device. This will be one of the first things you do when you’re troubleshooting a device. You would like to know if the device is on the network and if it’s responding to these pings, so your first question will probably be, can you ping that host?
Here at the command line of my Mac, we will run the ping command, but it works exactly the same whether you’re in macOS, Linux or Windows. We will use the ping command and we’ll specify a host name. In this case, I will specify 1.1.1.1, which is a DNS at Cloudflare. And then, we’ll run the ping command.
If everything works properly, we’ll get a response like this where the ping is working exactly the way you would expect. We are sending 64 bytes and we are receiving 64 bytes back from that 1.1.1.1. You will see sequence numbers for the ICMP protocol, a time to live, and then you have the round trip time.
If you ever run into a situation where you are not able to ping that device, you will see messages saying that it has timed out and you are no longer able to access that particular device. If the network then is restored, you will start pinging that device again and you’ll be back to seeing the response times for all of those individual pings.
In Linux and macOS and in Windows, if you set this to continuously ping, you can use the Control C command and it will stop the pain and provide you with a series of statistics about this particular ping session.
A utility that you might find yourself using almost as much as the ping command is the traceroute command. This, as the name implies, will trace a route and tell you what routers are between your device and the device that is the destination. It will map the entire path between you and that secondary device. In Linux and macOS, you would run the full trace route name as the command.
In Windows, it’s an abbreviation of that command, and it’s called tracert. This also uses ICMP, but it uses a different aspect of ICMP than what we were using for the ping command. In this particular case, it’s using the ICMP time to live exceeded error message. This is a message sent back to the originating station saying that it was not able to complete this because the time to live has exceeded.
And of course, in IP, time to live is referring to the number of hops or the number of routers that were going through, not the number of seconds or the number of minutes. Traceroute modifies the TTL and starts performing this test over the network. So it might start with a total of one to give you information about the first router. Then it will change the TTL to two so that you can get information about the second router and so on.
One of the challenges with ICMP is that many firewalls and other devices will disable or filter ICMP messages. So although our time to live may have been exceeded, there’s no ICMP message that’s being sent back because it’s being filtered by another device. In your traceroute output, you’ll know when the icmp is being filtered because you’ll see an asterisk instead of traceroute statistics.
Depending on the operating system you’re using, traceroute might work a little bit differently. For example, in Windows, the ICMP echo requests are used to send information and we’re expecting to receive ICMP time exceeded messages. There will also be an ICMP echo reply that is finally received once we make it to the destination device. As we mentioned earlier, ICMP is often filtered, so you may find that, sometimes, the information you’re looking for does not make it back to your console.
Other operating systems or different versions of traceroute might allow you to change what type of payload is being sent out. So if you’re running Linux or macOS, you might have some options available at the command line to customize your traceroute messages.
We’re going to run a trace route. But before we do that, I want to show you what’s happening behind the scenes when we run that trace route command. In this particular example, we’re going to run a trace route from Sam’s machine all the way through these multiple routers all the way to Jack’s workstation. And we’re going to run this by using the trace route command.
And when we run this, the very first message sent from Sam’s computer has a traceroute set to TTL of one. That means the time to live is one. That means when this first frame reaches the very first router, that router will decrease the TTL by one. So that means the TTL will turn into zero, meaning our time to live has been exceeded.
A message will then be sent back to Sam’s computer saying, the TTL was exceeded and here’s the IP address that reported that the TTL was exceeded. In this particular case, that was the 10.10.10.1 router, and it says that we were able to reach that router in two milliseconds.
Next, Sam will send a trace route to Jack’s machine, but the TTL will be set to two. That means the packet will first get to router one, that router will decrease the TTL by one, and it will send that down to the next router that will also decrease the TTL to one. And in this particular case, we’ve now exceeded the TTL and that message will go back to Sam’s workstation and it will be noted in the output of the trace route command.
This process continues and the trace route command now changes the TTL to three. That means it will go through the first router, be decreased to two. It will get to the second router, the TTL will be decreased to one. It will make it to the next hop along the way, the TTL will be moved to zero, TTL will be exceeded, and a message will be sent back to Sam’s workstation and that information will also be added to the traceroute output.
The TTL will now be set to four. The same process will occur where it will decrease the TTL through each router that it goes through until, now, it finally reaches the destination workstation where Jack’s workstation will decrease the TTL by one and send back a TTL exceeded message all the way to Sam’s workstation and that information is added to the traceroute results.
Here are the results of a traceroute that I ran. Let’s go through each line so you can see exactly what we’re looking at in the output. I ran a trace route to 8.8.8.8, which is a Google DNS server IP address. It started with the first hop. You can see the number one next to the first hop is 10.1.10.1 and it has three values next to it. By default, traceroute runs each test three times and it gives you the three response times for each one of those tests.
The next hop is hop number two. It is 96.120.58.137. You can see response times for those. We have a hop three, a hop four, a hop five all the way through to hop number 10, which is finally made its way to 8.8.8.8 and, of course, you can see the response time measurements for that device.
This displays every router that we had to hop through to get between our device down to the DNS Google server. This information can be very important, especially if later on you run into a problem communicating to that server. If you then ran a second trace route, you could compare your first trace route with the second to see where you might be missing a route or which router may be stopping this route from continuing.
When you’re troubleshooting problems on the network, you often need to perform a name resolution between an IP address and a fully qualified domain name. That is, of course, something done behind the scenes when you’re using a browser or referencing a fully qualified domain name. But you might want to query the DNS server yourself to see what type of results you would get. There are two useful and very similar commands that you could use to perform this query.
One of them is nslookup and the other one is dig. This will allow you to make queries to a DNS server and receive a response to any of those queries. You can look at canonical names, IP addresses, cache timers, text records, and anything else that might be inside of that DNS server.
Nslookup is included with Windows, Linux, and macOS and it allows you to perform this query to a DNS server. This utility is deprecated, which means the goal is not to use this particular utility in the future. Instead, we should be using the dig command.
Dig is a utility that is also included with Linux and macOS. And there are some versions of dig that you can download and use in a Windows environment. There’s an older version of the bind package that comes with an executable for dig. This is available from isc.org, although newer versions of the bind utility no longer include this executable in the package.
Let’s run an nslookup and we’ll use this command to look up www.professormesser.com. We can see that we get a response back from our DNS server, in this case, our DNS server is 1.1.1.1. And we can see that there are three answers that we received from that DNS server. One was that www.professormesser.com can be found at 104.22.73.108. We can find it at 104.22.72.108 and 172.67.41.114.
You would think there would be one single IP address for that server, but we have redundancy built into these servers so that if this first IP address is not available, there are other IP addresses you can use to access the web server. Let’s run the same query with the dig command, and again, we’ll choose www.professormesser.com.
On this output, it shows us that we are performing a query and we can see that for this question about www.professormesser.com we’re looking for the internet address, or the A record, associated with that name. And again, we get three responses. They are 172.67.41.114. That matches what we got earlier. We have 104.22.73.108. Again, we have a match. And we have 104.22.72.108.
So the information that we’re querying with both of these utilities is the same, it’s just that the format that’s provided in the output is slightly different. If you’re trying to query a DNS server or you’d like to look at the configuration of a DNS server, you can find that you can access those records using either the nslookup utility or dig.
In earlier videos, we talked about the idea of capturing packets on the network in order to view the information that’s being sent and to troubleshoot network issues. One of the ways you could do that is by using a third party utility, such as Wireshark, but many operating systems include this capability as part of the OS itself.
A utility that allows you to capture these packets is the TCP dump utility. This allows you to capture packets right from the command line and either view them on the screen or save them into a file. Tcpdump is usually included with Linux and macOS and you can install utilities in Windows that would give you a similar functionality. A good example of one is the Win Dump Utility. You can either capture every packet traversing the network or you can apply filters and view that information on your screen at real time.
Sometimes, there is a lot of information that appears on the screen, however, and you may choose to put this information into a file that you can then download and load into Wireshark. Tcpdump saves these files into a standard format known as the pcap, or packet capture format, and that is a format that can be easily read by Wireshark and many other third party utilities.
When you start looking at this information, it can be almost overwhelming to see hundreds or even thousands of packets all listed out on the screen. So it may take some time to understand how to parse this data and how to read it properly. But once you spend the time learning about these packet captures, you can gather a lot of information about the way the network and applications are running in your environment.
Here’s a view of a pcap session from a Linux command line. Each one of these lines is a separate packet on the network. There’s a mix here of IPV6 packets and IPV4 packets. You can see a number of these lines are communicating with the Jabber client, so it may be an instant messaging application. You can also see DNS information where someone is performing a DNS query to the Google DNS server.
Another useful utility is the netstat utility. Netstat is network statistics, and it allows us to see who we’re communicating with over the network and who might be communicating with us. Netstat-a will show you all active connections that are coming to your machine and the ones that you are making to a separate device. Netstat-b is used in Windows to show you the Windows executable that is being used to make that network connection. And then, netstat-n show you the same information, but it will only show you IP addresses. It will not resolve any names from a DNS server.
I’m in Windows, so let’s run the netstat command. Here we go. And we can see an output that shows us the protocol that’s in use, the local IP address, and on my computer, the local IP address is 10.1.1.102. This also includes the TCP port number associated with this session. And you can see all of the IP addresses that I’m communicating to in each one of these lines.
Some of these are established states, some of them are closing out, and some are waiting. We might want to see what executables are being used for all of these. So we can use the netstat command with the -b associated with it, and you can see the output is slightly different. You can see some of these are being used by servicehost.exe. Some of them are the Microsoft Edge webview2.exe. We have the HxOutlook.exe, and there’s even an Apple mobile device service.exe.
Let’s start up a application such as Google Chrome. We’ll have this start up on our screen and let’s run the netstat-dash command again and you’ll start to see more information will appear. In fact, here is the chrome.exe showing us exactly what IP addresses we’re communicating to and we can see the status of every single one of those sessions.
When you first sit down at a computer to start troubleshooting, one of the things that might be useful to know is the local IP address configuration of that device. And depending on the operating system you’re using, there might be a different command that you might want to use. For example, if we wanted to ping our local gateway, it would be useful to know what the IP address of our local gateway happened to be.
If you’re in a Windows environment, you would use the ipconfig command. If you’re in Linux or macOS, you can use ifconfig. And a newer version of that command is the IP address command– two words– and shows you similar information about your IP address.
So I’ve now sat down at a Windows computer and I’d like to know more information about the IP address configuration. The command we will use is ipconfig. This will show me IPV6 information. I also have IPV4 addresses, a subnet mask, and a default gateway. And now, I can perform my troubleshooting based on these IP values.
But we might want more details about how this system has been configured. So we will use ipconfig/all to get more information. You can see it starts with the name of the device, how the node type is configured. This is a Windows option. And then, we do have information about the Mac address, the adapter card that’s in use, IP address information, even the DHCP details associated with this config along with the DNS servers that have been configured for this system.
In macOS or Linux, you can run the ifconfig command and I can specify an adapter name, in this case, en0 is my ethernet adapter. This provides information showing the Mac address, IPV6 address, the IPV4 address, on this device, it’s 10.1.10.249, and other details about the configuration of this specific ethernet adapter.
Knowing the IP address of a device is useful. But sometimes, it’s also useful to know the Mac address of a device. This can be especially useful if you’re trying to look up this device in the Mac address table of a switch. One way to view this information is contained within your local ARP table. This is the Address Resolution Protocol cache, and it’s one that is kept on every local machine.
To view this, we would use the arp-a command. This will list out the IP address and the Mac address associated with those IP addresses on your local subnet. This command works in Linux, macOS, and Windows so you can try it on your own system. I’m going to perform an ARP-a and we can see the IP addresses and Mac addresses that have been resolved previously and are stored in my ARP cache.
There are some IP addresses on my network that are not in the cache. That’s because I’ve not communicated to those devices lately. So let’s communicate to one of those devices. I’m going to communicate to 10.1.10.234. You’ll notice that is not in my ARP cache currently. So we’ll simply ping 10.1.10.234 and we get a response back from that device. I’m going to finish that ping. And then, let’s perform the ARP-a again.
You’ll notice that 10.1.10.234 is now in the ARP cache and I can see the Mac address associated with that specific IP because it has now been stored locally in my ARP cache.