Troubleshooting the network is often managed from the Windows command line. In this video, you’ll learn about ipconfig, ping, netstat, nslookup, net view, net use, net user, tracert, and path ping.
You will do quite a bit of network troubleshooting when you’re trying to determine why the network is slow, why someone’s not able to start a particular application, or why their network connection simply isn’t working as you would expect. Whenever you sit down at someone’s computer, there may be a very different network configuration than someone else’s computer. So it’s useful to run a utility to see how this particular system is set up. The command you want to use in Windows is ipconfig.
This will tell you information about IP addressing, subnet masks, gateways, and other information that’s important when troubleshooting the network. The ipconfig command can also tell you information about the network adapter you’re using. So whether you’re on a wired ethernet connection or a wireless link, you can get more information about your network interface card using ipconfig.
And of course, you may want to know what DNS servers are configured on this device. Did this device receive a DHCP address and from what DHCP server, and other important network details? ipconfig can give you this information and a lot more.
Let’s say Rodney has asked us to stop by his computer and perform some diagnostics. Before we start making any changes, let’s see how this particular system is configured. We will run simply the ipconfig command. This tells us that we are on an ethernet network. It gives us IPv6 address information, IPv4 information, subnet masks, and default gateway details. But if we’d like more information, we can run the same ipconfig command with the /all option.
And this provides us with a great deal of additional information such as the hostname, DNS suffix information, the type of IP routing configurations are on this system. We have information here about DNS servers that are configured. And we can see here that DHCP is enabled and that we have not configured an IP address using DHCP on the system. This gives us a great deal of information about how this system has been configured and what those individual settings might be.
When you’re troubleshooting network connectivity issues, one of the first things you’d like to know is if the machine you’re trying to connect to is really connected to the network. One of the ways you can do that is by using the ping command. The ping command tests reachability by sending a special packet to a device and getting a response back from that device. It uses a protocol known as the Internet Control Message Protocol, or ICMP.
Let’s say in this case, we’d like to know if Rodney’s machine is really able to communicate to his primary DNS server. If we look at the results of our ipconfig command, we can see that the primary DNS server is 192.168.1.155. So we will use the ping command and we’ll specify 192.168.1.155. And we can see that we have connectivity to that device.
We ping that device with 32 bytes of data and it got four separate replies back from that device. This also tells us response time information for receiving that response from that particular IP address, and it provides time to live information as well. We’ll talk more about time to live in just a moment.
Now we’ve got a summary of all of the pings that we ran. By default, we sent four pings. We received four back, which means there was 0% loss. And we can see the approximate round trip times minimum are 5 milliseconds, maximum is 322 milliseconds, which means the average is 143 milliseconds. Based on this information, we can determine if we really are able to reach that particular device, and we can get information about how well and how quickly we’re able to send and receive information to that server.
Our local computers are constantly communicating across the network to other servers, and there may be times that other devices are communicating to your device to gather information as well. One way that you can see these connections is by using the netstat command. netstat stands for network statistics, and it’s a command that’s used in Windows, Linux, macOS, and other operating systems.
The default netstat command can tell you a lot of information about the communication occurring across the network, but there are some options you might want to try to give you some additional details. For example, netstat -a will show you all active connections on a Windows machine. If you’re interested in knowing exactly which Windows binary was used to be able to send or receive this network communication, you can use netstat -b. If you are going to use that command, you will need to run in an elevated mode or run as an administrator at the command prompt.
By default, netstat will try to perform DNS resolution so you can see the fully qualified domain name instead of IP addresses. But if you’d rather see the IP address, you can use the -n option to only show IP the netstat output.
Let’s run the netstat command on Rodney’s machine. We’ll run netstat without any other options and just see what we get. You can see there’s a column for protocol. In this case, it would be TCP or UDP. There are local addresses and port numbers that are mentioned. There are also foreign addresses. This is the other device that we are communicating with that is different than the local address. And then there is a state for that communication.
Sometimes we are established. Others might say CLOSE-WAIT. There may be other statistics that you’d see, depending on the status of that network connection. To get an idea of how things might change with network communication, let’s start up a browser communication using Chrome. It loaded up the Google Home page and now let’s run that netstat command again. You can see there are a number of new entries in this netstat table because we initiated additional network connections to these servers located at Google.
It’s difficult to tell from this view exactly what applications are associated with these different connections. So let’s close out that window and open a new command prompt. But in this case, we’re going to run it as administrator. Windows now asks for administrator access so that it can launch that command prompt with elevated access we will use administrator, and I will use the password for the administrator account on this domain. And now we have a command prompt that is running as administrator.
Now let’s do the same netstat command, and you can see there are a number of different connections that are going back and forth. Now let’s open up our Chrome browser again and have it launch that Google screen. And in this case, let’s run a netstat -b. You’ll notice the same connections are shown, but for every connection you can see the executable that’s used for that connection. For example, we have a number of different connections down here that are connecting over HTTPS. And you can see that chrome.exe is the application that caused that network communication to occur.
We rely on our domain name servers to be able to convert from a fully qualified domain name back to an IP address, and we can also perform an IP address to fully qualified domain name conversion. We also can gather a lot more details from DNS servers, and we can use the utility nslookup to be able to perform those queries. There are extensive options available in the nslookup application, although most of the time, we’re simply performing a lookup of an IP address, or a name. There are many different options within nslookup, and I highly encourage you to look at some of the other capabilities. You might end up using those to troubleshoot a number of network issues.
Let’s perform a simple nslookup from this machine. Let’s see if we’re able to get the IP address of www.professormesser.com. So I’ll run nslookup and then I’ll specify www.professormesser.com. This will go out to our default DNS server, which is 192.168.1.155. And this tells us there are three IP addresses that are associated with this fully qualified domain name. There’s 104.22.72.108, 104.22.73.108 and 172.67.41.114.
Normally, we would see a one-to-one relationship between the fully qualified domain name and the IP address, but I’ve built in additional redundancy into my network configuration, so this is not an unusual response when you’re querying this particular fully qualified domain name.
Many of the commands that we’ve done so far are very specific to TCP/IP. But there are some commands we can run that gives us information about the Windows operating system and how it connects to other devices. The command that we would commonly use for this is the NET command or N-E-T.
There are a few NET commands you should be aware of. One is the net view command that shows us what shares might be available on a particular device. There’s the net use command that allows you to connect to those available shares. And then there’s the net user command that can be used to view information about an account and change passwords associated with that account.
Back on Rodney’s machine, we know that there is a server called cheyenne1 and there are shares on that server, but we don’t remember what those shares are. So we’re going to use the net view command with the name of that server. And we’ll use two backslashes to designate that this is a server name. C-H-E-Y-E-N-N-E-1 is the name of that server. And you can see that there are a number of shares available.
There’s the NETLOGON share and the SYSVOL share. These are common shares that are built into the Windows system. But there’s also the Missions share and the Schematics share. Let’s say that we’d like to connect to the Schematics share. If we were to look at our system, I’ll bring up the File Explorer. We can see that currently we have a local drive. That’s our C: drive. We also have an X drive, a Y drive, and a Z drive on this system.
So let’s now connect to the Schematics share by using the net use command For net use, we need to specify the drive letter that will be associated with this share. Let’s say that we’re going to use H: in this example. And then we’ll specify the server name and the name of the share.
The server name has two backslashes and C-H-E-Y-E-N-N-E1, and then another backslash and the name of the share, in this case Schematics. And if we hit Enter it says that the command completed successfully. If we now go back to our File Explorer, we can see that a new drive share has appeared on cheyenne for H: and it is our Schematics share.
If we’re troubleshooting Rodney’s computer, we may want to get more details about their user account information, so we can run the net user command to provide those details. Let’s specify that this is rmckay. That’s the username for this user. And let’s also specify that this is going to be for a domain. If we hit Enter, we can get more details on this username. We can see the full name for this person, information about country codes.
Is the account active? In this case Yes it is. When was the password last set? When does it expire? You got information about login scripts and login directories, and information about any groups this user may be a part of. So if you’re troubleshooting this particular user and you want to know information about what groups they belong to or how their account is currently configured, simply use the net user command.
When we’re communicating to another device on the network, that other device might be on our local subnet, it might be in our building, it might be in a different city or a different country. One way that you could see all of the different connections between you and that other device is by using the traceroute command, and in Windows this is abbreviated tracert. traceroute uses ICMP, which is the same protocol we use for ping, to be able to determine where all of the different routers might be between our device and another IP address.
It uses a feature of ICMP called Time to Live Exceeded, and it uses that in conjunction with a time-to-live setting. In the world of IP version 4, time to live is not referring to seconds or minutes or a time of day. It’s referring to a number of hops. A hop is referred to as a single connection passing through a router. So a time to live of 1 would be your connection to the first router. Time to live of 2 would be able to give you the information to connect to the second router, and so on.
Time to live relies on ICMP and the ability to send these ICMP messages across the network. Some firewalls will filter out this ICMP information, which means you may have limited visibility when trying to determine where a particular router might be. We’re going to run a time to live on Rodney’s computer. But before we do that, let’s see what’s happening behind the scenes.
This is a setup that has a couple of computers on our local network and a device that’s on the remote network. In this scenario, we’re going to run a traceroute from Sam’s laptop to Jack’s computer, and it’s going to pass through a few switches. You can see those switches are the square boxes. And then it’s also going to pass through a number of routers. The routers are the round icons that you see on the screen. Each time we hit a router, that’s a hop. And it’s going to specify what the IP address is of that hop on the local machine.
So for instance, let’s run a traceroute to 10.10.30.10. Obviously 10.10.30.10 is Jack’s machine here on the remote network. The first step is Sam will set up a traceroute, and it will set a time to live of 1. And that will be sent to the first router that is closest to Sam. That first router sees the time to live is equal to 1, and one of the responsibilities of every router is to decrease time to live by 1 each time a packet goes through. So time to live is going to be changed to 0, which means the time to live is exceeded.
Every time you hit TTL equals 0, a message is sent back to the originating station saying, sorry, we weren’t able to complete this because time to live got all the way down to 0. Your time to live has been exceeded. When traceroute receives that TTL exceeded message, it puts a message up on the screen that says, our first router is 10.10.10.1 because that’s the device that’s sent back that Time to Live Exceeded message.
Now the process repeats, but instead of sending it out as is a time to live equal to 1, the time to live will be equal to 2. When it hits the first router, the time to live will be decreased by 1, so time to live is now 1. Then it goes to the next router and time to live is decreased one more time down to 0. Time to live has been exceeded and that message is sent back to Sam’s workstation and the results are put on the screen.
The process happens again where time to live is now set to 3. This goes to the first router where time to live will go from 3 to 2. Goes to the second router where time to live goes from 2 to 1, and then goes to the third router where time to live hits 0. Time to live is exceeded. That message is sent back to Sam’s workstation and the results of that are put on the screen.
This process will continue until we finally make it to that end device of 10.10.30.10. So now time to live is incremented up to 4. That means it goes to the first router and decreases to 3. It goes to the second router, goes down to 2. Goes to the third router, TTL goes down to 1. And then finally makes it to Jack’s workstation, and Jack now is able to send back a reply to that message, saying that it made it all the way through from Sam’s machine to Jack’s machine. The results of that are also put on the screen, and we now have our traceroute showing all four hops between Sam’s machine and Jack’s machine.
Here’s an example of a traceroute. This traceroute is to 9.9.9.9. It takes a few seconds for traceroute to run. This is the result of a traceroute that I did to 9.9.9.9. It says that it’s doing this to dns9.quad9.net which is the DNS name associated with 9.9.9.9. And you can see there are eight different hops that occurred to get from my machine, which is 10.1.10.1 all the way down to 9.9.9.9.
And you can see with each one of these there are three different attempts that were made. And in each attempt, we’re able to receive information about response time for each one of these hops. We also have IP addresses and names associated with each router along the way. So we know that 10.1.10.1 communicates to 96.12.158.37. The next router in these hops is 96.110.208.117, and so on. We can track every hop along the way to determine exactly what routers are involved with this communication.
If we run into problems on the network, we can run this traceroute again and compare the results we got originally with the new set of results. For example, if a router in the middle of the conversation was to fail, even though that router is in a different city or a different state, we still know what IP address was supposed to be there, and we can show that this is the normal route versus the route that we’re seeing now.
These ping functions and traceroute root utilities are incredibly useful when you’re troubleshooting the network. But what if you could combine the features of ping and traceroute into a single utility? That utility is pathping, and this is a utility commonly found on most versions of Windows. pathping has two different phases that it goes through. The first phase is that it runs a traceroute to build out a map of the connection between your device and the destination IP address.
On the second phase, it then runs a round-trip test to each of those hops. So now we’re able to get a better understanding of the performance from our device to each router on every hop, from our device to another. Here’s an example where I ran a path ping to 8.8.8.8. And you can see the first thing that it does is run a traceroute. This is a very similar view to what we saw when running an independent tracert utility command.
This is one that shows us all of the different hops. And you can see there are 13 hops to reach 8.8.8.8. This is the output from the first phase of the pathping command. Once it understands what all of these different hops are, it will then start computing statistics for each one of those routers along the way. And you can see here that pathping says it’s going to calculate statistics for 325 seconds. Once those 325 seconds have elapsed, pathping then presents you with information about every hop, the amount of round-trip time between each one of those. We can see how many packets have been sent and how many were lost along the way, and we can see information about the addresses at each one of these hops.
Most of these work flawlessly, but you can see there must be a firewall at hop 12 or some type of filter, because we weren’t able to get response time statistics from that particular IP address.