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.