Microsoft Windows provides a number of networking features, and many of those capabilities can be viewed and configured at the command line. In this video, you’ll learn how to manage your Windows network settings, modify network configurations, and troubleshoot network connections from the command line.
<< Previous Video: Installing Windows 7Next: Operating System Command Line Tools >>
All of our devices are connected to networks these days. So if you’re going to be troubleshooting a workstation, you need to understand all of the different network troubleshooting commands at the command line. Let’s run through all of these commands and give you an idea of how you might use these in the real world.
If you’ve just sat down at a computer to trouble shoot, one of the first things you’ll need to know if you’re doing any type of network troubleshooting is IP address information for that device. You need to know the IP address, maybe your default gateway, and some other variables as well. The best way to get that information is with the IP config command. This will tell you everything you need to know about every network adapter that happens to be on that particular computer. And there are some very specific commands for IP config you should be aware of. IP config by itself will give you an overview of IP address information.
But if you use IP config/all, you can see everything there is to know about IP addresses, DNS configurations, and much more on that particular computer. There’s two DHCP related IP config commands you should know. One is IP config release. That will release the IP address that has been gathered automatically from a DHCP server. And to get a DHCP address, you would use IP config/renew.
Whenever you do any type of DNS query across the network, it caches a local version of that query on your computer into a local DNS cache. If any of those IP addresses change in the meantime, you may not be able to receive those updates because you’ve already got that information cached. So one very useful command to completely clear out your DNS cache is the IP config/flushDNS.
Let’s run through some practical IP config options. I’m in my Windows 7 desktop, so let’s click our Start menu at the bottom. I’m simply going to type CMD, and that will bring up the Command Interpreter. And that will work the same way if you are in Windows XP. You would go to Start, Run, CMD. And we’ll hit Enter.
And then we get the Command prompt. At this point, we can use the IP Config command to determine how our machine is configured. This is the basic Windows IP configuration for this device. The first thing you’ll notice, especially on Windows 7, is there’s more than just a single network adapter. I have an Ethernet adapter called Local Area Connection. There’s a Tunnel adapter called IsaTap, and there’s a tunnel adapter called Local Area Connection 9.
The adapter are at the top is the adapter to the physical interface that I’m plugged into on my local network. These other two adapters in Windows 7 are used to facilitate IPv6 communication and to allow tunnel communication using other protocols. If I want to see more about these adapters, I can use the ipconfig again, but use /all at the end, and a lot of information goes by. I’m going to scroll back up, so we can see all of the things that happened when we typed in that ipconfig command. As you can see, a lot of things went by.
First, it gives you an overview of this Windows IP configuration. We can see the host name is Aus-Control. We have a primary DNS suffix that is not configured. This is a hybrid node type. The IP routing is not enabled. The WIN Proxy is not enabled. So already, we’re seeing a lot more detail, probably than we even cared to know about this configuration at this particular time. But you can see the /all command gives you everything, gives you all of the configurations.
The /all is really good, if I look at my Ethernet Local Area Connection, at providing me a lot more detail about how this is configured. So not only do I see information about physical addresses and the type of adapter this is, but I can see details about my IPv4 address. I can see my subnet mask, identify my default gateway through this configuration. There is a lot of detail in here that I can gather that will help me later on when I need to perform troubleshooting.
So if you’re trying to determine, can I even access my local gateway? It’s good to know the IP address of your local gateway. And the ipconfig/all slash all command tells you exactly what that IP address happens to be. Let’s try releasing our DHCP lease and see what we get. I’ll use the ipconfig/release. And you can see it gives us an update of our local area connections that says, you’re now completely blank.
There’s no IP addresses at all associated with your Ethernet Adapter Local Area Connection as there was before. So I’ll use my ipconfig/renew to have my computer go back out to the DHCP server and receive an IP address again. And when it does, you can see that it fills in the details of the IP address for this device. If you’re trying to figure out where those local devices, are what your local IP configuration might happen to be, or you’re trying to troubleshoot DHCP, these are the ipconfig commands that you need to use.
Now that we understand how our local device is configured, it would be nice to know if we were able to communicate out on the network to other devices. You would commonly use a command called ping to determine if another device happens to be accessible on the network because it can then repeat back to us, or echo back to us, a reply to a message. This will tell us not only if a device is available, but it will also give us an idea of round trip time to be able to communicate to that device. This is something you will use all the time. This is an extremely common troubleshooting tool, especially when you’re first configuring a device, or you’re trying to determine if there’s a problem with this device being able to communicate to other devices on the network.
The ping command was written by Mike Muuss in 1983. This has been around for a long time, and he called it ping because it describes that sound that sonar makes when it’s talking to another device. You send one ping out to the device and see if you get that sonar reflection from that device.
Sometimes you’ll see ping referred to as the Packet INternet Groper, which is not exactly what Mike had in mind. From this link, if you were to follow that, Mike describes how that name came about for the word ping, and it’s not an acronym for anything. That idea of taking this word and turning it into an acronym sometimes is called a backronym.
But in this particular case, ping is referring to sonar. And that’s a good way to think about it. You’re trying to determine what devices might be alive out there on the network. And you’re hoping to get a reflection back from those devices telling you that they are up and running.
Let’s say that we have sat down at this computer for the very first time. We’d like to gather information about the IP addresses on this device so that we can then start pinging the other things that might be out on the network. Let’s first do an ipconfig/all. We just learned that, so we know we can gather IP address information from that. And we can see our Ethernet Adapter Local Area Connection IP address is 10.1.10.72. We also know that our default gateway is 10.1.10.1. And our DNS servers are listed down here as well.
We have all this information that we can now use to start determining if we can communicate to these devices across the network. So I know that 10.1.10.1 is my default gateway. That would be a great device to try to communicate– that would tell us that we can at least talk on our local subnet and that we don’t have a problem, maybe, communicating to our local switch.
I’ll type ping 10.1.10.1. And if we get a response back, then we’ll know that that gateway is there, and we’re able to communicate with it properly. And you can see that we have a reply from that device. It took 16 milliseconds for one of those pings, 38 milliseconds for another, less than one millisecond for the others. And you can see the time to live there is 64 hops. That means we didn’t even have to go anywhere. We didn’t have to pass through a router. We sent this communication, and, in this particular configuration of Windows, it will decrement from 64 every time it goes through a router.
Look at the summary we have for the ping packets. We sent four packets, and we received four packets, which means we had 0% loss in this ping configuration. The round trip times are listed here. Our minimum was 0. Our maximum was 38 milliseconds. So for those four attempts that we made to that device, the average amount of response time there, the round trip time, was 13 milliseconds.
Now let’s try to communicate to a device that’s farther away. Let’s talk to, maybe, Google’s DNS server. It’s an easy one to use for pinging devices on the internet because it is so easy to remember. We would use the same ping command. And that device is 8.8.8.8. So let’s use that.
Now we’re communicating all the way out to the Google DNS server, and it’s responding to our pings. Notice that our statistics are a little bit different with this configuration. We did receive four replies. Notice the time on the round trips is a little bit longer than talking locally on our network. And notice the time to live changed. It was 64, but, notice, we went through a number of routers to get there and on the way back. So the time to live went down to 46.
And you can see the round trip times are calculated below. 36 milliseconds was the minimum. 48 milliseconds was the maximum. And the average was 39 milliseconds.
You’ll notice that we set the ping, and we received four responses back from that. We’re only doing four attempts at a time whenever we’re trying to ping a device. There is an option to the ping command that tells the ping command to continue sending pains every second until you tell it to stop. Maybe you’re rebooting a device across the network, and you’d like to see when that device became active again on the network. Maybe you’re changing out cables on your local workstation, and you want to have some feedback on the screen that tells you if you’re now able to communicate back out to the internet again.
It’s a very simple command to put onto your ping. We’ll use ping-T. You put a hyphen and a T and then continue with the IP address. It will do 8.8.8.8. And when we do that, the ping command continues to run. Notice that we’re doing a lot more than four settings here. And we can start to watch things like, if we’re getting a response back, what the difference in the response times, the round trip times, might be. And we can simply have this configuration continue to run as long as we’d like.
If we wanted to stop the configuration, we hold down the Control key and we press C. And it will stop the configuration and give us a summary of everything that happened during that last session. There were 24 packets sent, 24 received. We did not lose any of those packets. And here’s our round trip times– 35 milliseconds, a maximum of 88 with an average of 39 milliseconds.
You’ll notice when we did that ping command that our time to lives were very different when we were pinging a local device versus a device that’s out on the internet somewhere. That’s because we have to go through a number of routers to get there and a number of routers to get back. And every time we pass a router, that time to live is decreased by 1.
If you wanted to see the actual path that the packet takes as it goes out to that device and back again, you can use a command called trace route. This will trace out for you on the screen the exact path all the way to that remote device and back again. Behind the scenes, the trace route program is taking advantage of a capability in the ICMP protocol called the Time to Live Exceeded Error Message. Whenever you’re sending traffic across the network, and it’s decreasing that time to live, every time it goes through a router, once you finally get down to zero, the router drops the packet. And it sends a message back to you that says, I’m sorry I wasn’t able to deliver this because it went through too many routers.
This is ideally a way to prevent any type of looping on the network. But you can also use it with utilities like trace route to help understand the different routes along the way. As long as a router is configured to send these messages back to you, you’ll be able to get an idea of just how many hops you’re passing through. It sets the time to live to 1, and tries to send a message out to that device. As soon as the time to live is expired, it went through the very first router, you get an error message back. And now we know what the first router was. Then we set the time to live to two, and we get through the first router. We get to the second router, and it realizes the time to live is expired. It sends a message back, and now we know where the second router is, and so on, and so on.
Not all devices are going to be able to participate in this trace route because they may be configured not to tell you that the time to live has been expired. Sometimes people consider that a security problem, or they aren’t interested in having their device participate in these trace routes. So they disable that function within their router or within their firewall.
ICMP is generally a low priority for these devices. So you’ll notice sometimes wide swings in the amount of response times, or round trip times, that you’re getting. You can generally take an average and at least understand. But if you notice that the times are going very high and very low, just keep in mind it may be that those particular devices are busy doing other things at the time. ICMP, trace route, the ping commands that we use are not necessarily a perfect representation of round trip time. But they should give you a pretty good idea of how long it’s taking to get a packet out to a device and back to you again.
Let’s run a trace route in Windows. The command is tracert. And I’m going to use the IP address of our Google name server, 8.8.8.8. And I’m going to hit Enter. You’ll notice that it tells us that we’re tracing a route to, here’s our name resolution, Google-public-DNS-a.google.com. So a reverse DNS took place that took the IP address of 8.8.8.8 and determined that here is the name of this device as it’s configured in the DNS servers.
It’s going to try at least 30 hops to get there. And you can see that there are three columns that it puts up for each one of these hops. It performs three of these ICMP checks against these devices and gives you round trip time for each one of those. It then provide you with the IP address each hop along the way. And it performs a name resolution at each hop to help determine if there might be a name associated with that IP address.
It’s really a reverse DNS resolution that occurs. And as we step through these you’ll notice there will be certain instances where the device, the router, will not participate. It will not send us those error messages back. And we’ll have stars instead of using that IP address. And once it gets past that point it continues on its way and finally gets to the end.
So you’ll see here, we were able to trace 14 of these hops between point A and point B. We know we lost at least one or more right there at hop 13. You’ll also, because you’re looking at the names of these devices, get an idea where these devices might be. I’m located in Tallahassee. I’m on Comcast. So you’ll start to see Tallahassee Comcast .net routers. You can see it goes through mobile Alabama out to Dallas, Texas. Look at all the information we can start to gather about all of these.
And one of the nice parts about this is, we now understand the entire path between our device and the Google name server. If we suddenly are not able to communicate to the Google name server anymore, we perform a ping 8.8.8.8. It’s not able to respond. We might want to run another trace route and compare it to this one.
And we may find that somewhere in between we have a router problem. It’s not a problem with Google. Google may still be up and running. Their name server may be working properly. But the problem may be somewhere in between point A and point B.
You’ll notice when we ran that trace route command that we started to see names pop up that were associated with IP addresses. And that certainly helped us a bit because we understand where in the world our packet was going. It went to Alabama. It went to Texas. And we knew that because this name resolution took place that the trace route program did for us. It used a capability of communicating out to our DNS server to perform that reverse DNS look up.
And you can also do the same thing for yourself manually by using the nslookup. Command this will talk out to your default DNS server, and you can perform DNS queries yourself. You can find out IP addresses of devices. You can find out what name has been configured in a remote DNS server for that device, like we were seeing with those routers. And you can find out a lot of other DNS-specific information by using the nslookup command.
This ns look up command is especially useful for troubleshooting these types of DNS problems. If you go to a browser, and you type www.google.com, the first thing that has to happen is, this computer needs to understand the IP address of google.com. Behind the scenes, your computer is performing this look up to determine what the IP address might be. And by using the nslookup command, you can perform the same process to help understand where the problems might be in resolving that information.
You may hear some people say that they prefer using DIG over nslookup to perform these types of name resolution tests. DIG is certainly a more advanced program that allows you to do a lot more than nslookup does. And you can always go out to the internet and look for a version of DIG that would work inside of Windows. But DIG is not included with the Windows operating system, and nslookup is. So we’ll focus our efforts on using the tools that are available on a local Windows machine. But if you start getting into doing a lot more with name resolution, you might also want to consider downloading DIG and trying that as well.
The nslookup up program is relatively straightforward. We type in nslookup, and we type in the name of a device that we would like to resolve. Let’s try Google. www.google.com, and we hit Enter. What it tells us is two different things.
First, it tells us that we are using a server called resolver1.opendns.com, which is located at 208.67.222.222, to provide this information. This is almost always the DNS server that’s configured on this local machine. So the place that it knows to go to get all of this resolution is its DNS server configuration. So the first thing it tells you is that we’re using this open DNS server to find this information.
Now let’s look at the response that we’re getting from this open DNS server. And we see that it provides us with a non authoritative answer. That means that this information was actually gathered from a query that was performed earlier to the DNS server. And this information is cached locally on the open DNS DNS server. Because earlier somebody went out and performed a look up to www.google.com. And we got two types of addresses. Here’s the IPv6 address for google.com. And then you’ll notice a number of other IP version 4 addresses as well.
Google’s not unusual. When you have one of these large internet service providers that it has a lot of different servers, you make it more than one IP address that would be associated with google.com. Primarily this is done for redundancy. If there’s any problem with the first one, we’ll use the second one. And it is up to the application and the operating system to determine what IP address that it’s going to use to communicate out to that device.
Now let’s reverse this process. We’ll perform an nslookup. And we’ll perform this to 8.8.8.8. Instead of having a name that we need an IP address from, we’re performing what, effectively, is a reverse DNS look up. Again, we’re going to the same open DNS server. And in this case, the address 8.8.8.8 resolves to a name called Google-dash-public-dns-a.google.com.
You can also start nslookup in a command mode. Let’s clear the screen with CLS. And I’m going to just simply type nslookup. When I do that, I get a simple prompt, a greater than sign on my screen. And from here, I can start giving nslookup certain commands. For instance, I can perform www.google.com. And then notice it doesn’t take us back out to a command prompt. We simply have another nslookup prompt. So maybe I want to choose another IP address. And you can do one after the other, after the other. And when you’re finished doing that, you can simply type the quit command, and you go back to the main command prompt of Windows.
When you’re at the command line, you can gather a lot of details about the network communication that’s occurring. And in almost every operating system, there’s a command called netstat that gives you a huge amount of details about not only outgoing communication but also incoming communication to your device. Let’s run through some different netstat commands. Let’s use the netstat-a that shows all of the active connections, both incoming and outgoing, on our computer.
We’ll also perform a netstat-b, which correlates back the binaries, the actual programs that are using to provide this communication. And we’ll also look at netstat-in, that shows us all of that information without having to perform DNS queries every time we run the command.
Let’s perform some netstat that commands, and run some programs, and see what the differences might be on this local machine when we start using netstat. If we’d like to see what’s happening on our local user session, we can simply type netstat. And there’s not going to be a lot happening on this user session. We really have a local address on TCP 127.0.0.1. That’s our that’s our local loop back address. That’s communicating out to other devices on the same computer because this computer name is actually Aux-Control as well.
If I was, for instance, to start a browser session and then flip back to this netstat command, notice that we have some additional information. We have this local address, 10.1.10.72, and a port number. That’s communicating out via HTTP to another device out there on the internet, yh-in-f106. Well, looking at the names might not help us very much in that case. So let’s perform a netstat-in. And that’s going to remove the name resolution of those. And you can see that that yn-in-f106, which is probably that Google page that came up, is communicating, really, to 74.125.137.106. So if you’re trying to troubleshoot, perform some pings, try some trace routes, it’s really helpful to know what the IP addresses of this device happens to be, so the netstat-in will remove those names and give you the raw IP’s, so that you can then perform that extra troubleshooting.
If we wanted to see a lot more running on this computer, we have the Windows operating system– there are services that are running. And we’d like to see all of the possible connections that might be incoming or outgoing– we can use netstat-a. And you’ll get quite a bit of information that goes by. I’m going to scroll back up, so we can see the very beginning of this is really looking at the 0.0.0.0 addresses. Those may be internal services that are running. And all the port numbers that are open via TCP. And they’re just listening for somebody else to communicate inbound to this device. We recognize a number of those port numbers as being used by Windows. So if somebody wanted to connect to my machine to share files, it would use those port numbers.
Let’s try turning on some services and see what we get. I’ve loaded on this particular computer this Filezilla server. This server interface enables an FTP server running on my local machine that other people could use to communicate. So I’m going to double click on Filezilla, and I’m going to start it up with this lightning bolt. And it even tells you that it’s creating a listen socket on port 21.
Now last time we did this netstat-a, there was no port 21 enabled anywhere in this list. But if I simply press the up arrow key to perform the same command again and press Enter, and if we scroll back up, we’ll see that now there are some port 21’s that are enabled on this device because we’ve created another server that’s now a listening for somebody else to communicate in to this machine.
Now of course, we may not know what executables are on this machine, and what might be running. And I told you there is a netstat command with the -b that will show you binaries. But look at what happens when you try to run this from a normal command prompt. You’ll see that this requested operation requires elevation. You can’t just run this is a normal user. You have to run this as an administrator. And if you look at the top, we’re simply running this cmd.exe as the current logged in user.
In order to run the netstat-b, we would need to open up a new version of the command prompt. We’ll type CMD. But instead of just pressing Enter, I’m going to right mouse click. This is one way to do it. Right mouse click, and run as administrator. And Windows will give you the normal user account control prompt that says, is this OK? Are you trying to do this? Yes, I’m myself typing that in. I would like to run as administrator. Yes I would.
We get the same view that comes up. There’s actually two windows now that are here. And the same command line looks a little bit different, though, it says Administrator and then the command.exe. So we can see very clearly on that title bar that we are indeed running as Administrator. So now, if I do a netstat-b, I’m going to see different information.
And you can see, for instance, those port number 777 are associated with the Filezilla Server.exe. If I run the netstat-b and a, I’ll get that same all command along with the binary view. And if we go all the way back to the top, I told you that that port 21 that was running we thought was the FTP server, well, with the -b we can really see that is Filezilla Server.exe. So if you’re on someone’s machine, and you’re seeing they’re communicating out to the internet, you’re noticing that there are some odd communication maybe inbound to your computer, this is a great way not only to see what is happening inbound and outbound but really lock it down and identify exactly what executable might be using this.
A lot of the commands that we’ve used so far are very specific to IPv4 capabilities. But of course, we’re running the Windows operating system. So there are a lot of Windows-specific networking features that we need to be able to access. And one of the commands that allows us to troubleshoot those Windows networking features is NBTStat. That stands for Net BIOS Over TCP/IP Statistics.
We can use in NBTStat to query devices using that Windows NetBIOS language to determine how it might be configured to do Windows networking. We can not only look at our local device, but we can query other devices that might be located across the network. Let’s look at a few of these commands. We’ll perform an NBTStat-n that will list out all of the local names that we have on our computer.
We’ll perform an NBTStat-A with an IP address that goes across the network to see if we can understand what names might be associated with that remote device. And then we can effectively do the reverse of that, where we know the name of the local device, and we’d like to know more information about that based on its NetBIOS name.
Let’s look at our local device first. We’ll perform an NBTStat-n. And this tells us that the device that we’re using to query this is 10.1.10.72. That’s our local device. And we see that we have a number of NetBIOS names associated with this. And we have some different numbers associated with those NetBIOS names. The exact representation of the numbers is not important for the A+ exam, but you should understand that different machines have different NetBIOS names that are registering different pieces. For instance, this Aux-Control is the name of our local machine. But we also have a workgroup associated with this that we left the default of work group. And you can see the group that’s associated with that piece.
Let’s see what this might be if we happen to have a device on the other side of the network. Maybe we saw there was inbound communication to our device using the netstat command. And we’d like to know the name of that device because now we know the IP address. So we’re going to perform NBTStat. And I’m going to use the uppercase A. And in this case, I’m going to go across the network to a device that we saw communicating via 10.1.10.74.
NBTStat will now do a query to that device across the network and determine, oh, that’s the hologram room device. And you can see it’s also in a work group called workgroup. And we’ve now got exact information on what that device is. It’s a Windows device. It’s configured to communicate to me. And I can see exactly the name that’s configured on that machine. If we had the reverse, if we have the name of that device, we could perform an NBTStat and do a lowercase a instead of an upper case A and use hologram-room, the name of the device itself, and it would effectively go out to that device, gather that information, and pull it back. So whether you’ve got the IP address or the name, you can still query that device using the NBTStat command.
We’re so used to using the Windows graphical front end to move around. We can start services. We can close services out. We can connect to a file share that’s across the network. We can do a lot of this with a mouse.
But what if you only have a command line access to a machine. We still need a way to perform the same functions, even though we don’t have a mouse and a graphical display available. To be able to perform these functions, we have a command called net. This net command provides us with these Windows commands within a command prompt view. So we can connect to a share. We can view all the connections that might be inbound to our device. We can start and stop services and much more using this net command. If you’re trying to determine what your options might be, you can always use the /? to get an idea of what the options are for all of the net commands, or for an individual net command itself.
Let’s use the net command to stop or start a service that might be running on our Windows desktop. First, we need to understand what services might be here. And I told you earlier we have this Filezilla server. And if you remember, we clicked on that icon. I went into the graphical user interface, and I enabled and disable the service from that interface. But again, we want to do all of this from the command line.
So first, let’s understand what the name of that service might be. To look at our services, I’m going to first use a graphical display. You’ll learn in another video how you can look at your services using another command line prompt. But I’m going to go to my Control panel, under Administrative tools, and look right at services to be able to get this information. And if I click the standard tab, I’ll be able to fit more information on the screen.
And if I scroll down just a bit, you’ll see that the Filezilla FTP server is listed right in this view. And it’s called Filezilla server FTP server, and you can see that it is indeed started. So we would like to stop that from our command line. And you can see I’ve already got this configured as an administrator because you need those types of credentials to be able to start and stop services.
So if I use the Net command, and I simply do a /?, you’ll see all of the options that are available. And we can even extend this. If I’d like to use net stop/?, it will tell us more about the syntax of this command. And the net stop command is pretty simple. You simply use net stop, and you put in the name of the service.
So let’s do exactly that. I’ll perform a net stop. And because this particular service has spaces in it, I’ll use the quotations to call this Filezilla server FTP server because that’s the one that has the name associated with it that’s currently started. And if I hit Enter, you’ll see that the Filezilla Server FTP server service is stopping. And it was stopped successfully.
So was it really? A good way to determine this is to refresh the page. And you can see that that service has now been stopped. And of course, we can reverse the process by using the net start command and use the same service name, server, FTP server, and we hit Enter. And it says the server service is starting. And if we refresh again, we can see that, indeed, it has now started again. Very simple to be able to go up to that command prompt. And you can automate this process and perform other administrative features by going right to the command prompt instead of using some of those graphical utilities on the Windows desktop.