You can gather many details about network performance from the command line, but only if you know the right commands. In this video, you’ll learn about netstat, ping, traceroute, nslookup, and much more.
<< Previous: Network Troubleshooting MethodologyNext: Physical Testing Tools >>
If you’re monitoring or troubleshooting your network, you’re going to need to use some tools at the command line. And in this video, we’ll look at a number of tools that are available in your operating system to help solve problems on your network. A good starting point when you begin your troubleshooting process is understanding the IP address you’re using on your workstation. It’s good to know the IP address, the subnet mask, your default gateway, and other details they can help you during troubleshooting.
One of the things that ipconfig and ifconfig can do is provide you that information. Ipconfig is commonly used in Windows and ifconfig is commonly used in Linux and Unix type environments. You can gather a lot of details from these utilities. Sometimes it’s almost overwhelming the amount of information that’s in the configuration details of your network adapters, but depending on the troubleshooting you’re doing, you may find this information is extremely valuable.
Let’s step through ipconfig in Windows and ifconfig in Linux. I’ll use OS X on my workstation to give you a feel for what you would see in both of those environments. Here’s my Windows desktop. I’m going to run ipconfig and it’s going to give me a breakdown of all of my different adapters. I’ve got an ethernet adapter, a tunnel adapter, and another tunnel adapter for my IPv6 Toredo.
This is the primary IP configuration on my ethernet adapter Local Area Connection 2. And you can see my IPv6 addresses here, my IPv4 address, my subnet mask, and my default gateway for both IPv4 and IPv4. But of course there’s other information that I might want to gather from my local interface, and I can get more detail by using ipconfig/all.
And by running that, you can see I got some additional details. We’ll look all the way up at the top where I ran the IP config/all. It tells me my host name, the node type, IP routing enabled– no–, WINS proxy enabled– no–, the DNS suffix search list, and then look at all of the now different details I can get for my ethernet adapter Local Area Connection to.
And you can see there’s a lot more information here. There’s Mac address details, I’ve got DHCP server information, DNS information is detailed here. And very often by running the ipconfig/all, I can get the information that I need to start troubleshooting things like DHCP or DNS configuration settings.
Now let’s run ifconfig. I’m going to run this on OS X. You could also run it in Linux or Unix terminal screen. I’ll simply type ifconfig and hit Enter, and it lists out all of the interface configuration details on my machine.
I have a lot of different interfaces. You can see them listed on the left side of the screen. And if I scroll all the way back to the top, you can see the first thing listed is the loopback address, and it shows me details. There’s the 127.0.0.1 loopback.
Here is the primary ethernet adapter I use on this device, E-N-0. I can see the hardware information and how this is configured. Here is the ethernet Mac address on this particular device, IPv6 information, and here’s my IPv4 address on this particular machine. This is running 1,000 base T at gig connection, a full duplex, and the status of this interface right now is active. So you can see a similar type of IP configuration details. Little bit of a difference between Windows and Linux, but if you’re trying to find the IP address that’s running on your machine, either ifconfig or ipconfig will be exactly what you want to use.
Another useful utility is netstat. Netstat stands for Network statistics, and you can find netstat on almost any operating system, although the flags and the settings at the command line might be a little bit different when you move from operating system to operating system. Netstat dash A is used to show all active connections to and from your particular computer.
If you’d like to see what binaries are in use, and what connections they’re making, you can run a netstat dash B. A netstat dash N might speed up this process by showing you only IP address information and not going through a domain name resolution for every single IP address in the listing. Let’s start a simple netstat query with a netstat dash A.
And you’ll see that we’ll get a list of all of the different IP addresses to and from this device. This machine is not doing a lot of communication right now. So most of this are port numbers that are in a listening state and a lot of local connections, and some connections that are going out to the rest of the network.
If we wanted to know more about the executables in use, we could do a netstat dash B. And if there were any connections right now, we would see that. Let’s start one up. I’m going to launch a browser connection. It’s going to make the connection out to my main screen.
And let’s go back and run that netstat dash B again and see what active connections we might have, and what executables are associated with that. And you can see in this case, there is a connection out to a separate IP address, and it is Internet Explorer that is performing that particular connection. Here’s a list out all the different connections that were made from our browser, and you can see they where all made using iexplore.exe.
So if you’re wondering what is supporting an inbound connection, or what is making an outbound connection, the netstat dash B can give you a lot more details of exactly which executable’s in use. Let’s look at our netstat dash A again. I’m going to run that same netstat query that we originally did. Notice there’s a bit of a delay, as it does its name resolution process, and tries to find names for each of the IP addresses that are listed in the table.
Let’s take some time as it’s going out and trying to find these names if the name’s not there, or try again. And you can see that it slows down the process of running the netstat. If we perform the same netstat now with a dash N, it’s now going to run through much faster configuration. And you can combine this netstat dash A, N, and it will perform that same dash A function, but notice that it runs right through the listing without doing any type of name resolution.
PING is a utility that can help you determine if a device is reachable across the network. It uses ICMP to accomplish this. That’s the Internet Control Message Protocol. This is probably the first thing you’ll do when you’re trying to troubleshoot connectivity. You should try to PING the device that’s on the other end.
This was a utility that was written by Mike Muuss in 1983, and he named it because a PING is the sound that sonar makes when it’s trying to determine if something might be out there across the water. Sometimes you’ll see this as a acronym for Packet INternet Groper. That’s not actually the case. And you can find out about the history of PING by looking at Mike’s website at this URL.
To run a PING, we use the PING command, and then we need either the name or the IP address of a device. In this case, I’m going to PING the Google DNS server at 8.8.8 because it’s so easy to remember, and it sends out messages to that device, and that device responds back to those messages.
Here are the responses I received from the Google DNS server. I got four replies. You can see the amount of data in each one of those replies. The round trip time it took to receive a message back from that device and the Time to Live settings in the IPv4 part of the packet to tell me just how many times it had to go through a router to get to that particular location.
The final set of statistics is at the bottom. We sent four packets, we received four packets, which meant there were 0% loss. And we can see round trip times are listed here, as well.
Sometimes you want to run a PING, but you want the PING to always constantly run. You want it to never stop, until you hit Control C. To perform that function, we can run the same PING command again, but we’ll use a dash T, and then put in the IP address or the name of the device that we would like to PING.
And in this case, it will perform a constant PING. You might want to have this constant PING going to see if any of these drop off at any point. If you’re making a change on your side you may want to see what the connectivity is to that site. But it gives you a way to get constant updates and refreshes on the screen every second of how your connectivity is to that remote device.
To stop this, we use the Control key and hit C. And it stops the PING and gives us the summary that’s similar to the summary we saw before. In this case, we sent 24 packets, received all 24. And here’s the minimum, maximum, and average response times during that entire PING session.
Traceroute another useful utility. It will show you the exact route that a packet takes between point A and point B. In Windows, we run trace route by running tracert at the command line. In other operating systems, you type out the entire command traceroute.
Traceroute is able to provide this entire path by manipulating the Time to Live values inside of the IP packet. It sets a Time to Live to one and when that packet gets to the next router, that router decreases it by one, and then it’s zero. So the router sends a message back saying the Time to Live hit zero, I’m, sorry I can’t continue with this communication.
Traceroute then sets the Time to Live to two and sends another request out. That goes to the first router, which decreases by one, makes it to the second router, it’s now Time to Live equal to zero, and it sends a message back. And each time we’re getting that message back, we’re identifying what the next router down the line happens to be.
Not all devices on this path however are going to send you and ICMP Time Exceeded message when the Time to Live equals zero. Some firewalls will filter out any ICMP messages, and it is a low priority for many devices. They are designed to route or switch, and they’re going to perform that function first, and then they’ll send you ICMP information.
Let’s run a traceroute. I’m going to run a tracert since I’m in Windows, and we’ll do a traceroute again to the Google DNS server. You could also try this on your machine to see what you’re able to get between your device and the Google DNS server. Your route is going to be very different than the route that my packets take.
As this is going through and showing you all of the different routers, it’s also doing name resolutions where it can, and I can see some of these routers are in Florida. It looks like I’ve gone up to Georgia. And it continues through, providing me with updates of every router between my device and the Google DNS server.
Here’s the final result. You can see there are 11 different hops between me and that final google-public-dns-a.google.com So I have to go through all 11 of those routers and back again just to perform a DNS query. What you are able to find, of course, is the exact route we’re taking. And if we are not able to access that particular server, we can run this trace route again and see how any of this information may have changed or at what point were no longer able to go any further. And that might give us a little bit of troubleshooting information to know where this particular conversation is breaking down, and we can start calling around or trying to determine why that particular router is no longer responding to us.
In Windows, we often use NetBIOS to communicate. This NetBIOS is often included inside of an IP packet. So we are running the nbtstat command to perform Windows type networking functions running this NetBIOS over TCP/IP. Nbtstat can provide a lot of different functions for this NetBIOS, since there are so many things you can do on a Windows Network.
Nbtstat dash N will list out the NetBIOS names that it knows about on your local device. If you’re trying to query a remote machine, you can run nbtstat dash A and the IP address to perhaps tell you what the name of that device happens to be and what services are running on that machine. And if you know the name of the device and you don’t know the IP address, you can run an nbtstat dash lowercase A and the name of the device to get more information about what’s running on that machine.
Let’s get local details about my device. I’m going to run an nbtstat dash N and you can see that is a Local Area Connection too. My IP address is 10.1.10.22. And here are the names of my devices. And you can even see the work group that I’ve configured on the stock Windows 7 configuration.
I also have devices that are out of my network that I’d like to learn about so we could run in nbtstat. I’m going to use a capital A. And then the IP address of a device, such as to 10.1.10.222. This is a device called RACKSTATION2. This is one of my network attached storage devices. And you can see the work group that is also a member of. If I didn’t know the IP address of that device, I could run an nbtstat dash lowercase A and use the name RACKSTATION2, and it will in this case pull up exactly the same information, except in this case I was able to reference that device using its name, rather than an IP address.
If you’re troubleshooting a DNS problem, you’re going to want to run some sample queries. And there are a couple of utilities that can help you do this. You’ll want to become familiar with nslookup and dig. These utilities are designed to query DNS servers and provide you with information like canonical names, IP addresses, cached timers, and so much more.
Nslookup is a utility that runs in Windows and Linux and OS X and Unix based systems, and they can look up names an IP address for you. But it has limited functionality, and we generally consider this to be a deprecated utility. Instead, the better utility, and certainly a much more flexible utility, is dig. That stands for Domain Information Grouper. It provides you with a lot more detail and a lot more flexibility on how you perform these queries to the DNS server. You can also find a Windows version of this at the URL at isc.org that you see here because the dig command is not one that is automatically installed inside of the Windows operating system.
Let’s write an nslookup. And let’s look up the IP addresses for my websites. So I’ll run an nslookup. And I’ll do that to www.professormesser.com. And it goes out to my DNS server that I’ve configured on this device. It gives me the answer, which is a non-authoritative answer, which means that it has this information cached. This is not the primary DNS server for my particular website. And it tells me that this is 162.25.246.164.
I actually have two IP addresses querying back, because I built in redundancy to the connectivity to my website. So you can see the second IP addresses here. And there’s an alias for professormesser.com called www.professormesser.com That way you can type in either one of those, and you’ll go to the IP address associated with my web server.
Let’s see what this looks like if I run dig. I went out to the isc.org website and installed dig on my computer. So we’ll run a dig to www.professormesser.com And the information is similar, but you can see there is a lot of differences in how it is displayed. It shows me first the queries that I made. It did receive an answer. And you can see that it breaks down the professormesser.com and shows me the break down of the DNS record itself.
For instance, you will see the answer section in here of www.professormesser.com and I’m getting information such as the number of seconds that this information is cached. And you can see the exact information in the DNS records, such as the canonical name, or the address record in the DNS server.
When you’re troubleshooting connectivity to a device that’s local to your subnet, you may want to use the ARP command to try to determine if you are able to find the Mac address of the device by giving it the IP address. There is a local table of your ARP cache but you can see by running ARP dash A, and that will tell you if you were able to make that resolution, and then communicate to that device.
Let’s say on my device I wanted to see if I’d communicated to a 10.1.10.16. So I’m going to run a ARP dash A to show me all of the different IP addresses and Mac addresses in my ARP cache. And you can see I have a number of addresses and Mac addresses here.
I can see that I have not listed the 10.1.10.16. I did not see it in my list, so I obviously don’t have the Mac address of that device. So let’s perform a PING. We’ll PING 10.1.10.16, and we’ll see if that device is there, are indeed it is.
And we’ll run that same ARP dash A command now, and you can see that 10.1.10.16 does exist in my ARP cache. And you can see the Mac address associated with that local device.
Looking at the Mac addresses on our local device is important, but if we’re trying to troubleshoot a problem with the switch, we may want to see if that Mac address is appearing in the switch’s Mac address table, as well. Every switch is going to have a list of these addresses because it needs to know where to forward traffic that it’s receiving from other devices.
And of course, there are a number of third party utilities that can also automate this go out to all of your switches, pull back all of the Mac addresses so that you could start to see what switches are aware of what Mac addresses in my environment. In our case, we’re going to simply connect to the console of a switch and look at all of the Mac addresses that this switch happens to know about.
Here I’ve connected to a local switch that’s on my network. Different manufacturers will have different commands to display the Mac address table inside the switch. On my switch, it’s a show command, Mac, and address dash table. And when I hit Enter, you can see all of VLANs, the Mac addresses, the port that that Mac address was identified on, and whether that Mac address was dynamic, or whether it was one that was built in to this device.
Pathping is an interesting Windows utility that combines the functionality of PING with the statistics and details of a trace route. There are two phases to a pathping. The first phase is going to be the map creation, where it determines what the path is between point A and point B. And once it knows that tracerouted path, it then begins measuring round trip time over an extended period. And ultimately will show you details over a long period of how much traffic was able to traverse that network, and what type of response times we saw during that communication.
Let’s try a pathping out to the Google DNS server. I’ll simply run pathping and 8.8.8.8. And the first step is going to be a traceroute. Although it’s not going to show us exactly the same information that a normal traceroute would, you can see it’s going through exactly the same process and finding out what the route is. In this case, google-public-dns-a.google.com, which is our 8.8.8.8 address.
Once it finishes determining what the number of hops is and the path of this takes, it now begins calculating statistics for traffic going over that route. And you can see here, it’s going to go for 275 seconds. So it will sit here at this prompt. It doesn’t look like it’s doing anything, but it is sending information, gathering information about response times during every single part of these paths along the way.
Here’s the results of a pathping .8.8.8.8 that I ran earlier. You can see the hop numbers, the round trip times from the source to this particular IP address– which is my device to this IP address–, the amount lost versus sent packets, and then interestingly, this node, how much we are losing between different locations as well. So you can see just how much you’re able to get through the network. And you can see the exact point between these different hops where mini problems may be occurring. And In this case, you can see a number of ICMPs were dropped right here at this particular node.