Network Troubleshooting at the Command Line – CompTIA A+ 220-901 – 4.4

Many network issues can be identified and resolved at the command line. In this video, you’ll learn how to use PING, IPCONFIG, IFCONFIG, TRACERT, NETSTAT, NET, NETDOM and NSLOOKUP.

<< Previous: Network Troubleshooting ToolsNext: Troubleshooting Laptops >>


When you’re troubleshooting a network, some of the best tools available are at the command line. So, in this video, I’ll take you through some of the more popular network troubleshooting tools that you can find in almost every operating system.

If you’re wondering if a device is available on the network. Or if it has failed or been turned off, one of the best tools you can use is ping. This is going to test, not only the reachability of that device, but we’ll be able to tell a round trip time in milliseconds between our device and the device we’re pinging. This uses a protocol called Internet Control Message Protocol, or ICMP, to be able to send this ping request and to get a response back from that remote device.

Ping is one of the most common troubleshooting tools. It’s often the first tool you will use to be able to tell if a device might be up or down. This is a utility that’s been around since 1983. And it’s certainly one of the most used network troubleshooting tools available.

I’m going to use a Windows command line to demonstrate ping, but the ping command is available in almost any operating system. The most basic ping command might be to type the word “ping”, and then the IP address, or fully qualified domain name, of the device you would like to communicate with. And you can see that it pings four times, it gets a reply each time, I get a round trip time value. It even tells me that it sent four packets, it received four packets. So it lost none of the packets that was sent between me and the Google DNS server.

When you sit down at a device to begin network troubleshooting, it might be useful to understand the IP configuration settings for the device you’re using. Two commands that can provide you this information is ipconfig if and ifconfig. These are going to provide IP information for your local IP address, your subnet mask, your default gateway, and some additional IP details as well. You would use ipconfig if you’re running in a Windows environment. And if ifconfig is appropriate to run in Mac OS10, or Linux environments.

In Windows, to see this information, we use ipconfig. And it shows me all of the different ethernet adapters, wireless adapters, and other network interfaces that might be used in my operating system. For each one of these, it’s going to provide me with the IP address information. So for my ethernet connection, you can see my DNS information. You can see that my IP address is 10.1.10.25. And the subnet mask is 255.255.255.0. This gives me also the default gateway information of 10.1.10.1.

There’s other information available as well. One good way to see that is to use the same ipconfig command, but use /all at the end. And by adding the /all, we get much more information about the IP address configuration. I’ll go right back to the top where it says ipconfig/all. It tells me the host name of this device, the primary DNS suffix, and other IP details.

And now, look at the difference in information we’ll get for the Ethernet adapter. Not only the DNS suffix, but I also get information about the adapter itself, and the Mac address, along with additional IP information as well. Let’s look at similar information in a Mac OS10 environment. This is similar to the command line, you might have in Linux. And we’ll simply use the ifconfig command.

On my computer, I have many different network interfaces. You can see them listed along the left side. If I scroll back up, we can start to see more details. The primary interface on my computer is the en1 interface. And you can see an IP version 6 address, and an IP version 4 address. 10.1.10.13 is the address on my device. So by using ifconfig and ipconfig, I can learn a lot more about the IP configuration of the device I’m using.

When you’re communicating with devices across the network, it might be a web server on the internet, your traffic has to hop through a number of different routers on the way to that web server, and back again. It’ll be interesting if we could see exactly what path it took between my device and the device on the other side. That might be very helpful if we feel that there may be some type of communications issue between my computer and the computer I’m trying to talk to.

One command they can give you this information is traceroute. This is a command that’s going to be able to show you in Windows with the tracert command. Or in a Linux, a Unix, or Mac OS environment with the command traceroute. The traceroute command relies on the ICMP protocol. This was the same protocol we used with ping, but it’s using a subset of that protocol to be able to determine what the next hop might be.

It uses a functionality called time to live to be able to determine this. Time to live is not referring to seconds, or minutes, or hours. This time to live is referring to the number of hops that it takes to go between point A and point B. When we send a packet across the network, it starts off on our computer with a large time to live value. This time to live value is decreased by 1 every time it passes through a router. If a time to live equals zero, the packet is dropped by that router. And a message is usually sent back to you called an ICMP time to live exceeded message.

In normal communication, this time to live exceeded is bad. It usually means that there’s some type of loop on the network. But for troubleshooting with traceroute, we can use this capability to determine what the next path might be. So we set the time to live to one, we send a message out, and the router that responds back will be the first hop. Then we send out a message with the time to leave equal to 2. And the second router will be the one that reports back with the second hop. This happens over, and over, and over, again until we’ve built an entire map between us and the remote device.

One challenge with this is that not all devices will respond back with ICMP time to live exceeded messages. And some firewalls will automatically filter out any ICMP. So sometimes traceroute is available, sometimes it will not be available. It’s going to depend on how your network configuration is, and what’s between your device and the device you’re trying to perform the traceroute on.

In Windows, we run the traceroute command with tracert. And if I type that in and hit Enter, we’ll simply get an overview of the different options for the traceroute command. And you can change a lot of different parameters for trace route. You can tell it not to resolve addresses, you can specify the maximum number of hops, and other options as well.

In our case, let’s perform a trace route without any of those additional options. I’ll run tracert, and then I’m going to use the IP address of the Google DNS server. When I run this, you’ll find it’s going to perform one hop, and then the second hop, and then the third hop. And you’ll see it build the path between my device and the Google DNS server on the other side.

In my case, it took about a minute to perform this trace route. You can see that each hop along the way is tested three times, and then it gives you either an IP address, or a DNS name for the hop that you found. And, you can see, mine goes through Tallahassee, it goes through Georgia, and then finally finds its way to the Google DNS server.

So I now know that there are 11 hops between my device and the Google DNS server. This would be useful later if there happens to be a problem with the communication. The traceroute may fail somewhere in the middle and I’ll know exactly what the last router was before I was not able to communicate properly to Google’s DNS server.

Another common network troubleshooting utility that you’ll find in many different operating systems is netstat. Netstat stands for network statistics. And although the name is similar across different operating systems, you’ll find that some of the options may be a little bit different depending on what OS you’re using. We’ll run netstat in a Windows environment where we could run a netstat -a to show all of the active connections that are being made into, and out of, our computer.

We have netstat -b that shows this information, and also shows the application that’s being used, because it will show the binary that’s in use. And netstat -n is one we can use to get rid of the names and simply show us IP addresses in the netstat command.

Back on our Windows computer, if we run netstat -a you’ll see a list of all of the IP addresses that are in use. The 0.0.0.0 is our local internal IP address. You can see there are some port numbers that are listening on our computer. And if I scroll back up, you can see that I also have outgoing communication that appears to be going over HTTPS. There’s both TCP and UDP protocols being listed in this amount of communication between my computer and somewhere else out on the network.

Let’s run netstat -b to see the binaries that might be in use. And what I’ll do is go to my browser, I’m going to refresh this page so I know that we’ve got some communication being used by Internet Explorer. And we’ll use the netstat -b command. It’s going to look at the communication that’s going inbound and outbound from my computer. But more importantly, it adds on to these IP addresses the name of the executable. The binary with the -b. You can see, indeed, that iexplore.exe, or Internet Explorer, is listed in communications out to the network.

When we ran netstat -a we were able to see all of the active connections, but you’ll notice there were delays while your system was performing DNS lookups so that it could provide you with the names of these servers, rather than the IP addresses. If you’re not interested in the resolve names, or you’d like to see the IP addresses instead, you can run the same netstat command with the -a, but add a -n onto the end of it. And it will run the same netstat command, but instead of waiting for any type of name resolution, we’re able to instantly see the communication going back and forth and see IP addresses listed instead of those resolve names.

Microsoft uses the NetBIOS protocol inside of TCP/IP to be able to communicate with Windows devices across the network. One way to query these devices is with the command nbtstat, or NetBIOS statistics. This is going to not only show us what’s happening on our local devices, but we can also query devices across the network. To see the names of the local device you might be using, we can use the nbtstat command with a dash lowercase n to list out all of the local names on your computer.

If you happen to have an IP address of a device across the network, you can query that device with nbtstat dash capital A, and the IP address, to find out what the NetBIOS names might be on that remote IP address. If you have the reverse situation, where you have the name of the device and you’d like the IP information, you can use nbtstat dash lowercase a, and the NetBIOS name of that device to find out more details about that machine.

Let’s run an nbtstat on my local device with the -n to see the local names. And we can see that this device is GATEROOM-PC1 and it is in a group called SGC. That’s the name of the domain on this Windows Network. We happen to know some IP addresses that we’d like to query. So let’s perform an nbtstat -A, and we’ll use the IP address of 10.1.10.225. That’s an IP address I happen to know on this network, that happens to be an active directory server. And the name of this device is specifically SGC-AD01. You can see the other services that are running on this device as well.

If we happen to have that name instead of the IP address, we can do the reverse. We’ll run an nbtstat -a and use the name SGC-AD01 and receive exactly the same information as we did before, except this time we didn’t need the IP address to be able to get that information.

One very useful Windows utility is the net command. Net has a number of different sub commands associated with it. You can see all of them listed here. So depending on what your network troubleshooting task is, you may have a net command available to help you determine whether you can connect to one of the remote devices over Windows network.

Here are some of the more common net commands. If you would like to stop one of the Windows services, you can use net stop and then stop the service, such as net stop spooler. To start the service, you’d use the net start command and start that service up again. The net use command is used to map a drive letter to a share that’s on a different device. We can use net use, and I’m going to use h:, and then the server name, and the share name in the Windows standard format.

There’s also a net view command that would help be view network resources to see if there are any shares available on a remote device. I know that I have a print spooler running on this computer, so I’m going to use net stop and then spooler. And that will stop the spooler service. If I’d like to start the spooler service again, I can use net start and spooler, and it will start the net spooler.

You could, of course, use the Windows utility for services to be able to find the spooler service and click in the graphical user interface. As you can see it’s very fast to do this from the command line.

Let’s see if there’s some shares available on a remote server. I’m going to use the net view command and I’m going to use a double backslash, which designates the name of a device. And in this case, it’s the SGC-AD01 server. This will now show me all of the shared resources on that server. There’s a netlogon and a sysvol. These are system server shares. There’s also a users share that I could use.

Let’s now connect to this share of so we can access it. But to do this, we need to assign a drive letter. If we look at the drive letters in use on this computer, I’ll pull up the file manager, and you can see there is an a:, a c:, and a d: available. I can then choose any other letter to be able to use this particular share on the network.

So I’m going to use net use, and I’ll specify m: and then a double backslash SGC-AD01 to specify the server name. And then a single backslash and the name of the share. In this case, I’m going to use the users share name and specify that’s what I would like to use. And now you can see that the command completed successfully. I cannot only access this drive from the command line, I can even go back to my file manager. You can see now the M drive is available. And now I can access all of these folders and files on my local machine, even though all of them are being stored on a remote device.

In many business environments we’re able to centrally manage all of our Windows devices through an Active Directory database. We can, of course, manage this Active Directory database from the graphical commands on our Windows desktop. There’s also a command line function called netdom that allows us to perform some of this functionality from the command line.

This netdom command is built into the Active Directory server. And if you’re running Windows 8 and later, you can install the Remote Server administrator tools to enable this netdom functionality. This allows you to join a computer to the domain, you can remove devices from the domain, you can add a domain account, and many more functions as well.

For example, if you wanted to view information about the domain you’re connected to, you can use netdom, and the query command with a /d:, the name of the domain, and then you could specify workstation, or server, or DC, or OU, or any of these other options as well. On my test domain I’ve added a single workstation that we could query. But, of course, on a normal Active Directory network you might have 10s, or 100s, or even thousands of devices in the database. And this is how you’d be able to view those.

Let’s use netdom and we’ll use the query subcommand. We use a /d: to specify the domain name. And my domain is SGC. And I’m going to use the command workstation to list out all the workstations that are in my database. And you can see there is one, GATEROOM-PC1. And those are the lists of all of the different devices that I could find.

I can use all of those different sub commands for the netdom query. For instance, if I wanted to see the organizational units, I could use OU. And it will spell out the OUs available in the database and what those settings might be.

We rely on the domain name system to be able to convert between names to IP addresses and back again. And if we’re having problems identifying a particular device, or you’d like to know what name might be associated with an IP address, you can use the nslookup command. This will query a DNS server and give you information about the IP address or name that you’re interested in. This is something you’ll find in both Windows, Mac OS, Linux, and other types of operating systems. And it’s very flexible.

We can use this to find an IP address. For instance, nslookup www.professormesser.com will return the IP addresses associated with that particular, fully qualified domain name. If all we have is an IP address, we can still use the same nslookup command. But instead of using the name, we’ll put in the IP address to see what name is associated with that IP address.

Let’s use those same examples to run an nslookup. And I’m going to choose my domain name, professormesser.com. And it’s going to query a server and find that the answer is 104.20.18.63. There’s actually another IP address associated with it, 104.20.19.63. And depending on where you are in the world, I have load balancers everywhere, so that you might get different IP addresses listed. But you’ll know that particular www.professormesser.com is going to be able to resolve to those IP addresses and you’ll be able to communicate directly with my web server.

Let’s now do the reverse and find out the name of a device if we have the IP address. We’ll run nslookup again. And instead of the name, I’m going to simply add 8.8.8.8, which we know to be the Google DNS server. But the specific, fully qualified domain name is google-public-dns-a.google.com. And again, you might get a different name depending on how Google has configured the DNS settings where you happen to be. But you can see how easy this is with nslookup to either resolver the name or the IP address, and know instantly what the configurations are for those different addresses.