The command line can provide a wealth of troubleshooting information. In this video, you’ll learn about ping, ipconfig, nslookup, traceroute, and many other command line tools.
One of the most common command line tools you will use is the ping command. Ping is used to test reachability. It will tell you if another device on the network is responding to your queries. It will also show you the round-trip time to send information to that device and get a response back. This uses a protocol called ICMP, or the Internet Control Message Protocol. This is probably going to be one of your primary troubleshooting tools, and one of the first things you run whenever you sit down at a new device.
Let’s say you’re on a local subnet, and you’d like to see if you can communicate to the internet. There are a number of IP addresses on the internet you could use, but I like to use quad 9, which is a DNS provider that’s located at IP address 9.9.9.9. An easy ping would be to ping that device with ping command to 9.9.9.9. In Windows, we’re going to get four pings that go back and forth. And you can see I get a reply each time from that device. It shows me that I am pinging 9.9.9.9 with 32 bytes of data. I get a reply all four times. Each of those replies is 32 bytes, because that’s what I’m sending to that device. It takes 27 milliseconds for a round trip that I send to that device until I get a response back. I have some larger round-trip times also in this list. And it also shows a time to live, or TTL. This is referring to the number of hops between my device and this IP address.
When the ping is finished, it gives you a summary of the results. It sent four pings. It received four back, which means it lost zero frames. We know that the round-trip time minimum was 27 milliseconds. The maximum was 77 milliseconds. And the average of all four was around 60 milliseconds. Now that we’ve pinged this device and received a response, we know that we can at least communicate to other devices that might be on the internet.
When doing this troubleshooting, you might want to ping your local IP address, or the IP address of the router that’s on your network. So it will be useful to know what those IP addresses might be, which isn’t always something obvious when you’re sitting down to a new workstation. So it might be useful to know the local IP and network adapter information for the device that you’re using. This is something that can be found in Windows by using the ipconfig command. In Linux, it’s ifconfig. And if you’re using a relatively new version of Linux, you might also use the ip address command.
In Windows, we can use the ipconfig command to view the IP configuration of our local device. You can see that its DNS name, its IP address, subnet mask, and default gateway are used by default. If you like to get more information, you can use the IP command /all to show more details about the IP configuration and more details about the ethernet adapter itself. In this example, you can see that my IP address is 10.1.10.46. My default gateway is 10.1.10.1. And if I’d like to see if I can communicate to that gateway, we can use the ping command to ping 10.1.10.1. And I am getting a response from that gateway.
Sometimes when performing our troubleshooting tasks, we may need to gather information from a DNS server. We can use the nslookup or the dig command to get information about canonical names, IP addresses, cache timers, and anything else that might be configured in that DNS server. nslookup is a utility you may find available on Windows, Linux, and other devices as well. It will look up names and IP addresses. And you’ll find that many devices are moving from using nslookup to using the dig command. The command provides similar information to nslookup, although the user interface on dig tends to be more straightforward. And although dig is not included with Windows, you can install it separately, from this link, into your Windows configuration.
Let’s do a quick nslookup lookup for a fully qualified domain name. We’ll perform an nslookup, and we’ll perform that lookup to www.professormesser.com. This command will go to the default DNS server that I’ve configured in my system, which in this case is at quad 9, which is 9.9.9.9. And I get a response from that DNS server that shows me three separate IP addresses for that single web server. That’s because I have multiple IP addresses and locations you can visit to gain access to my web server.
You can also use the dig command. Let’s do this from MacOS, where I will dig www.professormesser.com. And you can see I get a similar response with different IP addresses, but you’ll notice that the format for dig is very different than nslookup. This can provide you with a lot of information, and can help you understand what information may be gathered from the DNS server that is being used by the local workstation.
Another common utility to use when troubleshooting is traceroute. traceroute will create a route that a packet takes through all of the routers between point A and point B. In Windows, this is the tracert command. And in Linux or MacOS, you’ll use traceroute. traceroute uses a function within ICMP called the Time to Live Exceeded message. Time to live is not referring to the number of seconds or minutes. It’s referring to the number of hops that a packet takes through a router. traceroute usually works to most devices, but you may find certain hops where the router will not reply with an ICMP time exceeded message. These are usually firewalled out or prevented from being sent back, so you’ll see that an asterisk is used to designate one of these hops where you don’t receive a response.
As you move between different operating systems, you’ll notice that traceroute works a little bit differently with different protocols in each of those operating systems. For example, Windows commonly sends an ICMP echo request to begin the traceroute, and it receives back the ICMP time exceeded message. One of the problems with this is that the ICMP echo requests are commonly filtered on the internet, so you may find that this particular traceroute is not as reliable as others. Other operating systems may allow you to determine what protocol is being used. You can do this in Linux, Unix, MacOS, and other similar operating systems.
It’s interesting to see how traceroute builds the route between one device and another. Let’s take a traceroute that will perform between Sam’s workstation, which hops through one, two, three routers before it is able to talk to Jack’s workstation. We’ll perform that traceroute to 10.10.30.10– that’s Jack’s workstation– and that traceroute will occur over a maximum of 30 hops. The first thing that Sam’s workstation does is set a traceroute with the time to live equal to 1. That means as this packet goes out to the first router, that router decreases the time to live by 1, therefore exceeding the time to live. When time to live hits 0, it sends back a message saying the TTL has been exceeded. Sam makes a note that it has received a TTL exceeded from this router, and puts a note that 2 milliseconds of response time, it received the first route of 10.10.10.1, which is the IP address of this Router1.
Now, Sam sends the same traceroute to the destination of 10.10.30.10, but he changes the TTL to be 2. When this packet hits the first router, TTL is decreased by 1, which means it’s TTL 1, and sent on its way. When it reaches the next router, it is decreased by 1 again. TTL goes to 0, and a TTL exceeded message is sent back to Sam’s workstation. Sam’s workstation calculates this took 1 millisecond of round-trip time, and it received that TTL from 172.16.1.2, which is the IP address of Router3.
The same process is performed again, except this time, TTL is equal to 3. It gets to the first router, where it’s decreased by 1. Gets through Router3, where it’s decreased by 1 again. Gets to Router4, where TTL is finally 0, and the TTL exceeded is sent back to Sam’s workstation, and the IP address of Router4 is added to the list.
Not unexpectedly, the process occurs again with TTL equal to 4, where it passes through Router1, Router3, and Router4, and finally makes its way to Jack’s workstation. Jack will reply to that traceroute with the TTL exceeded, because it did finally get to the last device. And that IP address is added to the list, making the final hop in this traceroute, and now Sam knows exactly what routers are used to get between Sam’s workstation and Jack’s workstation.
Now we know there is a lot going on when we perform a traceroute. Let’s do one in Windows– so we use the tracert command– and we’ll do a traceroute to quad 9. During each hop of the traceroute, it performs three separate checks, and then it provides the IP address or the fully qualified domain name of the router that it’s finding. You can see to quad 9 that we had eight different hops, and you can see that with each one of these hops, you have an IP address associated with the router at that hop.
If you suddenly lose connectivity to quad 9– you try to ping it and it’s not responding– you can perform this traceroute again. You’ll get another list, but if you’re not able to communicate to quad 9, what you’ll find is the last router that you’re able to communicate with, and then suddenly you’re not able to communicate any further. This would at least tell you how far you’re able to communicate before you run into an issue, which might help you determine where you can start troubleshooting.
Sometimes it’s useful to know if your local device has been able to communicate with other devices on your local subnet. One way you can determine that is by using the Address Resolution Protocol, or ARP. ARP is used to determine what the MAC address of a remote device might be when all you know is the IP address. You can use the arp -a command to view the ARP cache that’s on your local machine and see if it has been able to determine the MAC address of that remote device.
Let’s look at the ARP cache on my local Windows machine. We’ll perform an arp -a, and I can see there are three IP addresses and three MAC addresses in my ARP cache. I can create a new entry in my ARP cache by simply communicating to another device on my local network. So let’s ping 10.1.10.222, and you can see the ping is operating, so that device must be on my network. And if I perform an arp -a, you can see that 10.1.10.222 has been added to my ARP cache, and you can see the MAC address of that device. This could be useful if you’re trying to troubleshoot why a device may not be responding to the ping command. It could be that device has a local firewall running, and never responds to any ping requests. But if you look at your local ARP cache, you can at least see if that device is responding to an ARP request.
The netstat command stands for network statistics, and its a utility that can provide you with a wealth of information about the network. And it works on many different operating systems. netstat -a will show you all of the connections that are being made between your machine and a local device. If you’d like to see the executable that’s being used to create that network traffic, in Windows, you can use the netstat -b command. And if you’d like to see the netstat output without all of the fully qualified domain names, and you just want to see IP addresses, you can use the netstat -n command.
Let’s run a netstat on my local Windows machine to see what connections may be in use. I’ll run the netstat, and we’ll use netstat with the -n to just view IP addresses. You can see my local machine, which is 10.1.10.46, is talking to a number of different devices, most of them over port 443. Let’s see what would happen if we connected to another device. I’m going to perform a refresh to this device, which is 10.1.10.222, over port 5000. It’s going to refresh this screen. And then as we go back to netstat– I’ll perform exactly the same netstat– you can see there are new connections to 10.1.10.222 over port 5000. You can see that these connections originated from my device, which is 10.1.10.46, using port numbers 63715, 63716, and so on.
With this netstat information we can not only see where we may be communicating to on the network. We can also correlate that back to packet captures or other information where we can see the IP address and the port number.
The hostname utility is a great utility to use, especially when you have a lot of windows up on your screen and you’re moving back and forth between many different systems. When you’re ready to perform a critical command that could disrupt or change the configuration of a device, it’s always good to know that you’re making that change on the correct host. This is a command available on many different operating systems. So whether you’re using Windows, Linux, MacOS, or almost anything else, you can always use the hostname command.
The hostname command is relatively straightforward. It is designed to give you one piece of information, and that’s the name of the host you’re currently connected to. If we use the hostname command on my Windows machine, it simply replies back “Daedalus,” which is the hostname for this particular system.
When you’re troubleshooting where traffic may be going on the network, it’s useful to know what the local routing table might be for a device. If you’re in Windows, you can use the route print command to be able to view this routing table. And if you’re in Linux, MacOS, and also in Windows, you can use the netstat command with the -r function.
Let’s look at the routing tables that are on my Windows device. We’ll use the route print command, and you can see that it prints out an IPv4 routing table. And here are all of the routing details for my local computer. If you’re on a different computer, you’ll be able to see the destination, netmask, gateway, interface, and metrics associated with that network communication.
Another utility that may have more functionality than you may have realized is the telnet command. Telnet stands for telecommunication network, and it commonly communicates over the network using TCP port 23. telnet is a command that provides you with terminal access, or command-line access, to a remote device. But as we’ve always said, this is an insecure communication. Everything is sent back and forth in the clear over the network, including your username and password. Obviously, you would not want to use this on a production network for production reasons. You would almost always use SSH if your intention was to get a console screen. However, telnet can be very useful for determining if a particular port might be open and if it’s responding to application queries. For example, you can use telnet to a particular IP address and port number to see if it will respond to any type of user input.
Let’s try a telnet command to my local NAS, which is on 10.1.10.222. And that device is communicating on port 5000. When I hit Enter, I get a dark screen. But if I type get space /, get a response back from that device in HTML that’s simply being shown to my screen in plaintext. This is obviously being set across the network in the clear, but it is showing me that this particular application is responding to input on that IP address with that port number.
If you’ve ever worked with Wireshark, then the value of capturing packets and being able to view them in a protocol analyzer. You can also capture packets from the command line with the utility tcpdump. This is available in most versions of Unix and Linux and MacOS, although there are some options available for Windows, such as WinDump. This allows you to apply filters to view information going back and forth in real time, and it can give you some basic troubleshooting of packet information at the command line. There’s also an option to save this information into a standard pcap format, which is able to be read in many different utilities, including Wireshark.
As with most things associated with protocol analysis and viewing packets, there is a little bit of a learning curve involved. But once you become accustomed to performing a tcpdump, this can be a valuable troubleshooting tool at the command line.
Here’s an example of an output from a tcpdump. Most of this is IPv6 traffic. There’s some IPv4 traffic in here as well. It looks like much of this is a Jabber client that’s going from one device to another. And each line of this is a separate packet that’s being sent across the network. I can see timestamps, the protocol that’s being sent. I can see the source device and the destination device. You can also add different options to the command that would show you more verbose output, and be able to view the data that’s being sent over the network.
If you’re trying to perform any type of scan to the network for IP addresses, port numbers, and applications, the utility that does the best job of this is Nmap. Nmap stands for network mapper, and I think most people think of in map as a simple port scanner where it can identify open ports that might be on another device. But it can also identify what operating system might be on that other device, even though it’s not authenticating or providing any user credentials to that remote machine. It can also perform service scans. So once it’s found an open port, it can tell you exactly what service is running on that open port, even without logging into the device. Nmap is also very extensible. It includes an Nmap Scripting Engine, or NSE, where you can extend the capabilities of the utility.
Let’s run an Nmap scan to my NAS machine. I’m going to run nmap with the option of -f, which is a fast scan. Instead of going through every possible port number, it only goes through the most popular ones. And then I’ll specify the IP address of this device and have Nmap begin the scan. Here are the results from the Nmap scan. It found port 22 TCP is open– which is commonly the SSH service– port 80, port 111, port 139, port 443, 445, 548, 2049, and 5000. I will say there are a number of reports that I found on this scan that I did not expect to see, so I might go back to my NAS and disable a number of features, which would minimize the open ports on that device.
As we’ve gone through this video, you may have seen there are certain utilities that are exactly the same on Windows, MacOS, and Linux. You might see similarities also between commands that might run across switches, routers, firewalls, and other infrastructure devices. Once you know the commands on one device, you can usually find similar commands that might be on another device. For example a command such as show interface is very common across many different devices. For example, a Cisco switch is show interfaces status to show details about an interface, or show interfaces to get a lot more detail. This also applies to other switches and router manufacturers’ devices as well.
show config is another example of a common command you would find on a device. You can go to the command prompt of many firewalls, type in show config, and see the configuration of that firewall. If you’re on a different manufacturer’s device, like a Cisco switch or Cisco router, you would find there are similar commands to show config such as show run. And if you want to see the routing table across many manufacturers’ routers, you can use the show route command. On a Cisco device, it’s the show ip route command. But you can see that’s very similar to show route. Once you know what you’re looking for and you know the basic platform command, you can usually find the proper derivative in the device that you happen to be using.