Network Troubleshooting at the Command Line – CompTIA A+ 220-802: 4.5

A large portion of network troubleshooting can be done at the command line. In this video, you’ll learn how to use the ping, ipconfig, tracert, netstat, nbtstat, and net commands.

<< Previous Video: Network Troubleshooting ToolsNext: Troubleshooting Operating Systems >>


If you’re doing some troubleshooting to your network, there are a number of utilities you can use at the command line that will help you solve these network problems. One utility used by every network administrator is called Ping. The ping command is able to check the reachability from your machine to another machine on the network. It’s also able to give you information about round-trip time. And it’s using a protocol called the Internet Control Message Protocol or ICMP to make this happen.

You’ll find that the ping command is one of the first things that you’ll do when you start troubleshooting a network. It’s common to hear someone say, can you ping that host, are you able to reach that host by using the ping command? And you’ll start pinging around the network to see just what you can communicate with.

This is a utility that was written in 1983 by Mike Muuss. And he named it based on the way that sonar is used on submarines. Some people will say that this stands for Packet INternet Groper. It’s kind of a backronym, where somebody created an acronym based on this command. But Mike says in his article that you can read at this URL, that he really designed it based on the sounds that are heard when a submarine is trying to locate other devices in the water.

Let’s try pinging around my network to see what devices might be available. I’m in Windows 7. So I’m going to hit the Start and bring up CMD to launch a command prompt. And let’s type in ping. And I’m going to ping my local gateway, which is 10.1.10.1.

When I do that, it’s going to send out four ICMP requests to that device. And if that device is configured to listen to those requests and send responses back, then I’ll get messages like I see here that showed that I received four replies.

They were 32 bytes in length. It was a less than a millisecond to access that device. That makes sense. It’s here on my local network. And the time-to-live is 64. The time-to-live is a value that decrements by 1 every time you go through a router.

So you’re able to get an idea of just how many routers you’ve hopped through because your time-to-live will go down by 1 every single time. And when time-to-live gets to 0, the device that sees that time-to-live of 0 throws the packet away. That we were preventing any loops from occurring on the network.

You can see we sent four packets. We received four. We lost zero. And you can see the round-trip times were very, very small.

Let’s try another device. Let’s do the one out to Google. So we’ll ping 8.8.8.8. One thing you’ll notice is that we’re sending the same number of bytes. But notice the times are little bit longer. I have to now go across the internet to wherever these Google servers might be.

And the time-to-live is also different. Notice the time-to-live changes as it passes through as well. Especially on a larger sites, you could have situations where you might have one way or another to get to that same location for redundancies purposes.

And you can see the minimum was 17 milliseconds. The maximum was 35 milliseconds. The average was 25.

If I start running into performance problems, I might want to run this ping again to 8.8.8.8 and see if those times change at all. Maybe I start seeing much larger times or maybe the times are very different than what I would commonly see to that location. This ping is very simple to run. And you can see it gives you a lot of information about availability and response time.

If you’re sitting down at a device to perform some network troubleshooting, then you might want to determine how the IP address configuration is for this particular machine. So you can pop out to the command prompt in Windows and run the ipconfig command to see exactly the way the IP configuration is on this Windows desktop. A lot of your troubleshooting starts right here. Before you even ping a local IP address and a local gateway, you need to know the local IP address and the local gateway’s IP address.

So to do that, you would run the ipconfig command and see what the response might be. This is going to give you information about IP, but it’s also going to give you information about other components of the network adapters, like the MAC addresses and how they might be configured. And of course, you might have multiple adapters inside of a computer. You might have a wireless adapter. You might have a wired connection. And you can see all of that information here in the ipconfig command.

At the command prompt, we would simply type ipconfig. And if you’d like a lot more detail, you can use the ipconfig/all all command.

We’re back to my command prompt. So let’s run the ipconfig command on my desktop. And you can see that I have an ethernet adapter called Local Area Connection. It has an IPv6 address and an IPv4 address.

My IPv4 address 10.1.10.67. My subnet mask is 255.255.255.0 and my default gateway 10.1.10.1. I also have a tunnel adapter and another tunnel adapter on this device that are currently not in use.

Now, if you want to see a lot more about that local connection we can use that same ipconfig command /all. And you’ll see if I scroll up just a little bit, there’s a lot more information here about this particular connection. It is indeed my local connection. There’s my ipconfig/all. You can see information about this IP device.

And you can see everything about the adapter, the name of the adapter, the MAC address. You can see if DHCP was enabled or not. Was autoconfiguration enabled? IPv6 and IPv4 information, it even shows you DHCP server information and DNS server information. So there’s a lot more information you can see what the /all command that you were not able to see what the simple ipconfig command.

It’s nice to be able to see our local addresses and run a ping to see if a device is available on the network. But sometimes it’s useful to know the exact path that a packet takes when it’s going between point A and point B. To be able to see that we can use the trace route command. This will tell us exactly the path that it takes to go all the way there and back again.

In Windows, the command is trace route tracert. This takes advantage of a function within ICMP called time-to-live exceeded. Every time we go through a router, time-to-live exceeded is decremented by 1. This takes advantage of a capability within the ICMP protocol called time-to-live exceeded.

And although the name says time, we’re not really talking about minutes or seconds. The number of times we go through a router is really what this is talking about. Every time we go through a router, the time-to-live drops by 1.

So the way the trace route command works is it sends information out onto the network, with the time to live set to 1. And when it’s the first router, time-to-live goes to 0. And the router responds back with a message to you saying the time-to-live was exceeded. I’m sorry. I had to drop this packet.

So now we have a message back to know exactly where the first router was. Now, let’s set the time-to-live to 2 and send it through. So it makes it through the first router. It gets to the second router, which then sends you back a message saying, sorry, I had to drop this particular packet. And by doing this one at a time, we can start to build out a map of exactly the path that that takes.

One of your challenges with this is that not all routers are going to send you back these ICMP time exceeded messages. Some of the routers will filter ICMP completely. You can’t even send this information back and forth. And sometimes ICMP is a lower priority. If a router is very busy, it’s not going to bother sending you back a message. It’s just going to drop the information and you’ll never know it happened.

Let’s do our own trace route, tracert in Windows. And I’m going to trace route that 8.8.8.8, that Google DNS server. And when I hit Enter, we’ll begin that process of sending out those packets and getting information from that device.

There are three different packets that are sent out, one after the other, that give you information about response times as it’s going out these IP addresses. And each time it does that, it tries to come up with a DNS name for that IP address so that you can perhaps recognize where it happens to be. So there may be a bit of a delay as it’s trying to do that DNS resolution. That’s a capability you could turn off when you’re running the trace route, if you’d like it to go a little bit faster.

Well between me and Google, it’s going to try a maximum of 30 hops. And you can see, based on some of these names, that’s it’s hopping through different routers that are located in different places around Florida. It looks like it went up to Georgia. It finally got to a router that wasn’t participating. That wasn’t sending back this ICMP information. And then finally it got to the Google device.

So there are at least 11 hops between my device and the Google DNS server. And you can see exactly the IP address that was used every time it went through one of these connections. Now, if you know exactly what the path should be to that device and suddenly you’re losing connectivity, you could run a trace route to see just how far am I getting and that might give you an idea of where the problems might be occurring somewhere between those two locations.

If you’re interested in seeing all of the network communication that’s going in and out of your computer, you might want to look at the netstat command. That stands for network statistics. And it can give you a lot of information about exactly what your device is communicating with.

If you use the netstat -a command, you’ll be able to see all of the active connections that are on your computer. You can use netstat -b to see all of the binaries that are associated with those connections. And netstat -n will not resolve names. And if you’re trying to speed up the netstat process, that can really help you avoid those DNS lookups and the delays that occur while it’s trying to figure out all of those names.

Let’s see what’s connecting on our computer. I’ll run a netstat -a command. And you can see there is a number of different connections that are being used. A lot of these are being done on our local device.

There are some devices out over the network that are listening. Some are waiting for us to connect to them. And then there’s some local addresses that are being used for other things on this machine.

Now, if we were going to for instance start up a browser session on one screen and we’ll run that netstat -a again, you’ll notice you’ll get some other things hopping up. As it’s going out to different IP addresses and communicating to that web server, you’ll see all of those different connections in place.

Maybe I’d like to also see exactly what binaries are in use. I can do a netstat -b. But notice that it tells us that this requires elevation. You can’t do this with a normal user account.

So let’s start up the command again. But I’m going to right mouse click on CMD and run that as an administrator. And it’s going to confirm that I am indeed a human being that really does want to run this as an administrator. And we’re going to run the netstat -b command.

And it’s going to give us information about exactly the executable that’s being used to establish these connections. You can see iexplore.exe, which is pointing back to this browser screen. Notice there’s a bit of a delay as it’s going through and trying to get those names assigned here. And that’s why we have that netstat -n.

That went very quickly. We’re not doing all of that DNS look up. And now you can see we can gather just the raw details about exactly what IP address we’re communicating with.

Microsoft Windows has its own way of communicating on the network and it uses a number of different protocols. One primary protocol is NetBIOS over TCP/IP. This is the Windows networking functions that use TCP/IP to get the traffic from one side to the other.

To be able to perform some queries using this protocol, you use a command called nbtstat. This allows us to use these Microsoft commands to be able to see what’s on our network and to query both local and remote devices.

There’s a few useful commands that can really help when you’re troubleshooting. One is an nbtstat -n, so you can see your local NetBIOS names that are running on this machine.

You can do an nbtstat – capital A and IP address to learn more about a remote device on the network. And you can also get nbtstat – lowercase a and the name of that device, which is the same thing, but in reverse now, to get information about that, knowing just it’s NetBIOS name.

Let’s use the nbtstat command to look at things that might be running on our network. Let’s first see what our particular machine is configured as. So I’m going to use the nbtstat -n. And that tells us that 10.1.10.67, our local machine, is called AUXCONTROL CTR. This is the auxiliary control center computer. And it’s in the workgroup called WORKGROUP. Not very creative, but that is how this particular machine is configured.

Let’s say that we’d like to know more about a device that’s across the network, but all we have is its IP address. So we can perform an nbtstat – capital A. And I’m going to use my 10.1.10.222, which somebody said I have a device out there on that IP address. But what is that device? And you will query that device across the network and tell me that the name of that device is called DISKSTATION. And it is in also so that same workgroup that is named WORKGROUP.

If you know the name of the device, you can use the nbtstat and a lowercase a. And I can use the name of a machine like TRICASTER and find out more about that device, which is named TRICASTER. And you can see the workgroups that are assigned to that device as well.

It’s very easy to find this information if you know what you’re looking for and you know those command line prompts for nbtstat.

We’re so used to using the Windows graphical frontend to be able to see what different devices may be on the network or to map a drive to a different device. But you can also do all of this at the command line. And Windows gives us the net command to be able to see what devices are on the network, map these drives, see what devices and workgroups are available, and much, much more.

If you’d like to get an idea of what options might be available, you can use the net command with a /? And see all of the options available. If you wanted to know more about an individual option, we can do something like net view /? and it tells us everything we need to know about the net view command. Maybe I just would like to use net view and see what all of the devices might be all my local network. And then I can decide whether I would like to map a drive to that device or be able to perform any one of these functions right here at the command line.