There are many built-in utilities that can help with troubleshooting network issues. In this video, you’ll learn about ping, traceroute, nslookup, netstat, and many others.
<< Previous Video: Microsoft Command Line Tools Next: Windows Administrative Tools >>
There are a number of network troubleshooting utilities that are built into Windows. And in this video, we’ll look at some of these network command line tools.
When you sit down at a computer to troubleshoot any type of network connection, the first information that you’ll need will probably be network address configurations. The IP config utility is the perfect choice to use to gather information about how this local computer happens to be configured on the network. It can tell you the IP address, the subnet mask, the default gateway, along with other information such as DNS server information, DHCP server information, and much more.
Here’s our local Windows 10 computer. I’ve clicked on the search bar, typed and CMD, and hit Enter to get this command line screen. From here, we can type IP config, and that will show us that this is an ethernet adapter. Here’s the connection-specific DNS suffix, which is the fully qualified domain name of this device. The IP address of this particular device, which is 10.1.10.36. We have a subnet mask of 255.255.255.0, and we have a default gateway of 10.1.10.1.
This is a good start for gathering network information about this computer, but we can get more details if we type ipconfig /all. This will show us everything we just saw, along with other details, such as the DNS servers that are configured for this device, the DHCP server that assigned the IP address to this computer, and other information about the network configuration as well.
You’ll often be tasked with determining if a device that’s somewhere else on the network is up and working. And one way that you could tell if a device might be responding to you is by sending it a ping. This is the ping command, and it’s designed to determine if a device is indeed operating on the other side of the network and is able to send you a response. It can also give you information about round trip time and other details as well. The ping command relies on a protocol called ICMP. This stands for Internet Control Message Protocol, and you’ll find ICMP is a protocol used often for performing some of these network administration and network troubleshooting functions.
This will be, probably, one of the primary tools you use because it’s so easy to send that ping across the network, get a response back, and see if that device is indeed operating properly. The ping utility was written by Mike Muuss in 1983, and he named it ping so that would be similar to the sound of sonar when it finds another device. Sometimes you’ll see the term pinging described as an acronym of Packet INternet Grouper. This is, in fact, someone who created an acronym after the ping utility was created.
The ping command is an easy utility to use. Back at our command prompt, I’ll run the IP config command and we’ll determine what our default gateway is. And our default gateway on this subnet is 10.1.10.1. So if I perform a ping command to 10.1.10.1, I’ll immediately see replies coming back from that device saying that it is on the network and replying back with information.
Let’s look at these ping results. You can see there were four replies that came back. And in Windows, when you perform a ping, it performs four pings before it stops. You can specify the number of pings that you would like to send, or you can tell Windows to keep pinging until you hit the Control C option. This gave us four replies from 10.1.10.1. The amount of data in that reply was 32 bytes. It took one milliseconds to get that reply back from 10.1.10.1, and the time to live is 64. We’ll talk about time to live in the moment as it’s associated with trace route. But time to live is a marking that shows us how many routers are on the network between one point and another.
The breakdown of these four ping replies shows that there were four packets sent, four packets received, which means we had a 0% loss of ping information on this network. The approximate round time in milliseconds on my local network here is a very boring one millisecond as a minimum, one millisecond as a maximum, which means our average was one millisecond.
Let’s try to take these values and add some additional distance between our devices. Let’s ping a device that is on the internet that has to go through a number of hops. So let’s try the ping command again, and I will ping Quad 9, which is a DNS provider that has a DNS server at 9.9.9.9, and I’ll hit Enter. And you can see now we’re getting different numbers back. Our round trip times are larger because we are going out over the internet. The time to live is different because the time to live value is determined by the station that’s on the other end, and it has a different operating system and uses a different set of time to live values.
We can suspect that it started at 64, which means there were a number of different hops, about eight different hops, between our station and that 9.9.9.9 device. We sent four packets. We received four packets. We didn’t lose any packets along the way. The minimum round time was 27 milliseconds, the maximum was 29, and the average was about 27 milliseconds to send that traffic across the network.
Now let’s see what happens if we try to ping a device that is not on the network. We’ll use the same ping command, and we’ll go to Quad 9, except we’ll ping 9.9.9.8, and we’ll hit Enter. And you’ll see there is delays while we’re waiting for the response to come back. The first response says the request timed out. We’ll get a second response that says the request timed out. And we’ll ultimately get all four of these attempts timed out, and we’ll get information that shows us that we sent four packets to that device, we received zero, and therefore there is a 100% loss. We can assume that 9.9.9.8 is an IP address that is not available on that network.
Our ping command showed us that there are devices available out on the network. We’re not exactly sure of the route that it takes to get to that device and back, but we know there were a number of hops to be able to reach 9.9.9.9 and send the information back to us. If we wanted to get a breakdown of every step along the way and understand every router that that packet goes through to reach that remote device, we can run the command trace route. This will map the entire path between our workstation and the device we specify on the other side.
Just as we saw with ping, trace route also uses the ICMP protocol, specifically an error message associated with ICMP called time to live exceeded. This time to live, again, is based on the number of hops through routers as it’s going through the network. It’s not based on the time of day or a number of seconds.
For a trace route to work properly, we have to be able to receive these ICMP time to live exceeded error messages back on our local computer. But occasionally you’ll find that there are firewalls or other filters between you and that other device that may filter out ICMP. And in those particular cases, you may find that there are certain hops or certain information that is simply unavailable because you won’t be able to receive those ICMP messages. You’ll find that firewalls very commonly filter ICMP, and other devices have ICMP as a lower priority. So if that device is very busy, it may drop ICMP to make sure all of the other traffic is able to pass through that device.
When you use trace route in Windows, you’re sending an ICMP message outbound, very similar to sending a ping, and you’re expecting to see the ICMP time to live exceeded messages in return. Once your packet finally makes it to the destination device, that device will send back an ICMP echo reply, which is the same reply you receive when you send a ping. ICMP, as we mentioned, is commonly filtered, so there could be situations where using tracer route in Windows may not be the best tool to use.
In other operating systems, you may be able to change this outbound protocol that’s used. For example, in Linux or Unix or Mac OS, you can change it to be different protocols such as UDP or TCP protocols. For example, iOS devices send the outbound message through UDP over port 33434, and many programs allow you to change those port numbers as well.
Let’s step through the process of how trace route is really operating on the network. There’s a lot of detail here, so let’s focus only on the broad view. For instance, we have Sam that will be sending a trace route to Jack. Sam is connected to a local switch. That switch is connected to a router. And there are multiple routers in between Sam and Jack. Once this finally hits Jack’s network, there is a local switch there as well that Jack is connected to. We’ll perform a trace route on Sam’s machine. And we’ll trace route to 10.10.30.10, which happens to be Jack’s IP address on the other side of the network.
When you start trace route, it will give you a message that says it’s tracing a route to that IP address over a maximum of 30 hops. The first packet that is sent from Sam’s computer will have a destination IP of Jack’s computer. But it will have the time to live set to one. This means that as this packet goes out over the network and hits the first router, the first router decreases that number by one. Every router along the way decreases that time to live by one.
Since our time to live is already one, once the time to live is set to zero, the router knows that it can’t send that message any farther down the path and has to send a time to live exceeded message back to Sam. At this point, Sam has received that message from that router, knows what the IP address is of that router, and specifies that it took two milliseconds to get to 10.10.10.1, which is the IP address of router one.
Sam then sends another packet, but this time changes the time to live to two, which means it’s going to make it through router one, the time to live will be decreased by one, and then it finally gets to router three. Again, the time to live will be decreased by router three, and of course will be exceeded since time to live is now zero. That message is sent back to Sam, and Sam will document what router sent the time to live exceeded, and that was 172.16.1.2, which is the IP address of router three.
The process continues again, except this time Sam sets the time to live to three, which means it will make it through router one. It’ll make it through router three, and it finally gets to router four. When time to live is set to zero, that message is sent all the way back to Sam, and Sam documents that the time to live exceeded came from 172.16.3.1, which is the IP address of router four.
Sam sends the same packet again, but changes the time to live to four, which means it’s going to make it through router one, it’ll make it through router three. And you can see the time to live is decreasing each time. It passes through router four, and since time to live is one, it finally makes it all the way to Jack’s computer. Since this is an ICMP request that is sent in Windows, Jack sends back an ICMP reply, which is going to follow the path back to Sam’s machine. Sam documents that she received the ICMP reply from 10.10.30.10. And now you’ve built out the entire path between Sam’s computer and Jack’s computer with every router along the way.
If you recall earlier, we performed a ping to Quad 9, where we typed in ping 9.9.9.9. Now let’s perform a trace route. In Windows, it’s Trace RT. In other operating systems, it may be the entire word trace route. But it will also trace route to the IP address of 9.9.9.9. And we press Enter, and we’ll begin the process of sending this information through the network, changing the time to live every time, receiving that information back, and building a list of all of the routes between our device and the device at 9.9.9.9.
The trace route command will perform three separate tests using the same time to live value. So you can see there are three separate columns here that specify the round trip time it received for each one of those tests at a particular TTL. You can also see that the name of the device is listed if there is a name in DNS. And the more important number for us, as we’re troubleshooting the network, is probably going to be the IP address associated with this. So we can see that the first router that we hit is the local router on my network, which is 10.1.10.1.
The second router we hit is 96.120.158.137, and so on. And if we look at the names of these devices as we’re going through the network, we can see that it goes through the Tallahassee network. It goes to Dallas, to Houston, to Marietta, Georgia. It goes to an IP address at 50.248.117.86, and then finally makes it to Quad 9 at 9.9.9.9.
Now that we know the path that this packet takes to get between our computer and that remote device, we can now use that information to determine when there might be a problem. If suddenly we’re not able to ping Quad 9, we may want to try running a trace route and see exactly where along the way we stop receiving responses from a particular router. That might give us an idea that there could be a break in the network between Dallas and Houston, or between Houston and Marietta. It would depend on what the results of the trace route happen to be.
It obviously helps if you have very good documentation of your network. If you’re pinging a remote device, and suddenly you need to perform a trace route, it’s helpful if you understand what the route should be so that you can interpret what the results will be from that trace route.
Netstat is a utility that’s short for Network Statistics, and it’s a utility that you’ll find on many different operating systems including Windows, Linux, and Mac OS. You would use netstat to determine what type of network connections are occurring inbound or outbound from my local computer. The netstat command is very powerful and has many different capabilities, so we’ll focus on some of the more popular functions in this video.
For instance, netstat-a will show you all of the connections that are inbound and outbound from your local computer. You can also use netstat-b to show which binaries in Windows maybe sending or receiving information. It’s important that you run your command line in administrator mode or elevated mode to be able to use the netstat-b option.
And one thing you’ll notice when using netstat is a lot of this information is presented with its DNS name. If you want to see IP address information instead, then you want to include -n at the command line to not resolve any of those DNS names.
Let’s try running through some of these netstat options. I’ve opened up a command line window, and I’ve chosen to run this as an administrator. You can see at the top it does show administrator and command prompt. On the other part of the screen, I have a browser window open up to professormesser.com. If we perform a netstat-a, we’ll see a lot of information go by.
This first column tells us the protocol, such as TCP or UDP. It tells us the local IP address that’s being used, the foreign address or the address of the remote device, and then the state, whether it’s listening in for information or whether it’s a closed session. You can see a lot of these IP addresses are going to HTTPS IP addresses, which are probably associated with the connections on the Professor Messer website.
If we scroll down a bit, we can even see that a lot of the source IP addresses are our local computer, which is 10.1.10.36. But you can see there are a number of IP addresses that are not listed with simply port numbers, and they’re listed as listening. These are services that are running on our local computer. And if you’re concerned about security, you may want to go through all of these different port numbers to determine what services are running on this computer that is opening up those particular port numbers and having them listen in for anyone to connect from the outside.
Let’s perform the same netstat command, but let’s choose the -b, which will show similar information, such as the IP address of the source and the destination. But we can also see the executable that is used, the binary that is used to create this particular session. And you can see a lot of these are associated with the Microsoft Edge cp.exe, which is the browser that is up in the other part of the screen.
Let’s refresh some of these sessions, and we’ll see more information appear in the netstat command. We’ll run again a netstat -a. And you’ll see a number of IP addresses come through. Some of these IP addresses have been resolved to DNS names. For example, Instagram is one of those links from my website. So what we’ll perform is the same netstat command with the -a. But we’ll also include the -n to not resolve those IP addresses. And now we can see the exact IP address that’s being communicated to instead of that DNS name.
We’ve become very accustomed to connecting to devices in our browser by using the fully qualified domain name. So to get to my website, you would type in www.professormesser.com. But behind the scenes, of course, there’s an IP address that you’re connecting to. That IP address resolution is made by your domain name service’s servers. These DNS servers contain information about the names, the IP addresses, caching information, and other details specific to DNS.
This means you can query a DNS server to determine the IP address of a fully qualified domain name, or you could also query that DNS server with an IP address and have that server tell you the fully qualified domain name of that IP. To be able to perform these queries, we would use the ns lookup command. To be able to see the IP address associated with a fully qualified domain name, we’ll use the ns lookup command, and we’ll put in the name of a website, for example, www.professormesser.com.
This will then query my local DNS server, which in my case is local to me at 10.1.10.1. And we get an answer back that is www.professormesser.com can be connected at two different IP addresses, 104.20.215.41, or 104.20.214.41.
The answer that we received here is a non-authoritative answer, which means this DNS server of 10.1.10.1 has this information locally cached in that server, and this is not the DNS server that normally provides DNS information for professormesser.com. Instead, my DNS server had to ask the authoritative DNS server what that information is, and ultimately that’s what was provided to me.
We can also perform an NS lookup in the other direction. So if we perform NS lookup and type in an IP address such as 9.9.9.9, a DNS query will take place. It’s obviously the same DNS server we had before. And you can see that a fully qualified domain name was found for that IP address of DNS.qua9.net. This is useful when you’re troubleshooting and someone has only given you the name of the device and not the IP address. To be able to determine what that IP address happens to be, we can perform this DNS lookup. And now we’ll be able to perform our pings and our trace routes to the IP address associated with that server.
So far, we’ve looked at a number of network troubleshooting commands that are very specific to IP, and many of these work across many different operating systems. But there is a utility that you can use to gather information specifically from Windows devices. This is the net command, and this command is very specific to the Windows operating system.
For example, we can use the Net View command to view resources on a remote device. The syntax for that would be netview, two backslashes, and the name of the server. If this is on a workgroup, you can specify the workgroup name as well. You can also map a drive to one of those resources by using the net use command, specifying a drive letter such as h colon or any other drive letter that’s available on your computer, and then specify two backslashes, the name of the server, a backslash, and the name of the share on that remote server.
And the net user command is used to view user account information and to perform administrative functions such as resetting passwords. The syntax for that command would be net user, and then the user name that you would like to view.
Let’s use some of these net commands. I’m on a Windows 7 machine on my network, and I would like to connect to a share that’s located on the Windows 10 machine that is on this network. To be able to view the available shares on that computer, I would use the Net View command and I would specify the name of that Windows 10 device, which is gate-room.
And if I do that, it will show me that there are shares available. There are three shares, one called Mission Reports, Ship Diagnostics, and Users. I would like to share that Mission Reports, and I would like to make it drive H on my computer. Right now there is not a drive H on this particular Windows 7 system.
So to be able to map that drive, I’ll use the Net Use command. I’ll specify that I would like it to be on that drive H, and then I’ll specify gate room, and I’ll include the Mission Reports share. And when I hit Enter, it will tell me that the command has completed successfully. And now if I move to drive H, I can see that all of the files I need to access are located now under this remote share that happens to exist on that remote Windows 10 device.