In this video, we're going to cover the ping
and traceroute command line tools,
and how to use them in maintaining
and troubleshooting our networks.
First, we have Ping.
Ping is used in checking the connectivity
between two devices, and we often use this
in network troubleshooting.
There are a couple different ways to use Ping,
but the most common way is to just type in "Ping,"
and the domain name you want to test.
For example, if you're on a Windows machine,
you can enter ping www.jasondion.com and hit enter,
and this is going to send out four pings and get four replies,
and it tells you the site is either up or down.
This is the default one that you're going to use.
Now, if I wanted to get 10 or 20
or 30 pings, I can do that by doing ping -n
and then the number, so ping -n 10,
jasondion.com will ping jasondion.com 10 times,
and then it will stop.
Now, you can also do this where it'll just keep pinging over
and over and over again forever.
To do this, you're going to use ping -t, and the domain name,
so in this example, I would do ping -t jasondion.com,
and it would go forever and ever,
keep pinging that site.
Now, why would I want to do that?
Well, it might be useful
to see if your WAN link is up all the time.
In some places I've worked,
we've had a ping constantly running on a distant end
and we leave it up on a big screen monitor.
Then we could just look up
and we could see if that connection is working or not,
or if it's having any issues.
Now, in the examples I just gave you,
I was working on a Windows client,
but Ping does work a little differently
if you're using Linux, Unix or OSX.
One of the key differences is that on a Windows machine,
it only sends four pings by default and then it stops.
If we wanted it to run forever,
we would use the "-t" option like I said.
Now in Linux, Unix and OSX clients,
ping is going to run continuously by default,
just like that -t and Windows did.
Now, if you only want to send four pings
like we did in Windows, we would have to do that
by doing the -c command, which stands for "count,"
so I would say -c 4 after my ping command.
So I would do ping -c 4 jasondion.com,
or if I wanted to do 10,
I could do ping -c 10 jasondion.com and then stop.
Really, you can use any number of pings you want
with the -c option,
and it works like the -n option you had in Windows.
If you're running ping continuously on any operating system
and you want to stop it at any time,
you can issue the brake command.
To do this, you simply press the control key and see,
and this will end up breaking
or stopping that continuously running ping.
The last option we need to cover is the -6 option.
If you enter ping -6 and the domain name,
this is going to force the ping
to go over IPv6 instead of IPV4.
This -6 option is going to work the same
regardless of the operating system you're using.
So what does all this look like in the real world?
Well, here you can see I did a ping of jasondion.com
from my Windows machine,
and it sent out four pings and received four replies.
Here you can see the time it took 74 milliseconds,
74 milliseconds, 156 milliseconds, and 71 milliseconds.
This gave me an average of 93 milliseconds
across all four pings, and all pings were sent
and all four packets were received back.
This indicates that my web server is up
and accepting traffic at this time.
Now, next we have Traceroute,
and this can be written as either Traceroute,
all written out, or Tracert
if you're on a Windows system.
If you're on a Unix, Linux or OSX system,
you're going to enter that command as Traceroute.
Now, either way, we pronounce it the same way,
we call it Traceroute.
Now, traceroute is going to be used to display the path
between your device and its destination,
showing the source and destination IP address
along every single hop as you go.
Now, a hop is simply any router or firewall
that's there as part of the layer three path
in that transmission going from the client
to the destination.
To perform a traceroute, simply enter the traceroute
and the IP address or domain name
of the destination you want to reach from your client.
Now, in response, you're going to get a list of all the routers
between you and the computer you're trying to get to.
If you want to do this using IPv6 instead of IPv4,
you can add the -6 option to your traceroute command.
Now, let's look at a quick example here
by doing a traceroute to www.diontraining.com,
from my workstation.
Notice it's going to go out
and resolve the IP address for us automatically.
Then it starts tracing out the route from my computer
with a source IP of 10.0.2.2 out to the destination IP
of 54.221.229.100.
Now, how does Traceroute work?
Well, it's going to use the time to live field
in the IP packet header.
Normally, the TTL or Time to Live,
is going to be used to prevent packets from being forwarded
around the internet indefinitely by routers.
This would create a routing loop, right?
So we don't want that to happen.
Instead, each time a packet is forwarded by a router,
it takes one off of that time to live.
So if the time to live reaches zero,
that packet is dropped and discarded
and response gets sent back with an error message.
So Traceroute actually uses this to its advantage
and it sends out a series of packets to the destination.
The first packet is going to be sent out
with a time to live of one.
It's going to hit that first router,
and then that's going to decrease its time to live to zero,
because it hit zero, it's going to now drop the packet
and send back an ICMP message that says,
"time exceeded for that packet back to the source IP,"
and informs it that that packet didn't make it
to the final destination and it was dropped.
Then Traceroute sends out another packet.
This time it has a time to live of two.
Again, it goes through the first router
and it hits the second router.
At that point, it's hit zero again,
and so it's going to go back to the original sender.
This continues over and over again
until Traceroute finally gets
to the final destination successfully,
but the entire time, it keeps increment that time
to live one every time it sends out a new packet.
This way, it can identify each and every router
or hop along the source to destination.
Now, sometimes you're going to come across something
that looks a bit strange in your trace routes output.
For example, notice here around line 15,
I have a bunch of timeout requests,
even though my server is up and running.
What does this mean?
Well, this means you're seeing a firewall in our path
or some other kind of device that's not responding
to ICMP or Ping traffic.
This is a security feature of a lot of firewalls,
so my Traceroute command simply reports back
that the response that it received
or in this case didn't receive from that device at that hop.
Now, this still tells me there's some kind of device there,
but I know it's filtering that traffic,
and so I'm now being able to fingerprint your network
and figure out where your firewalls are.
In this case, my service provider for diontraining.com
does not respond to those types of requests,
therefore, I can only trace the path as far out
as the outermost layer of their network.
Once I get to the outermost layer of their network,
their border gateway, it's going to stop responding
to my request and I'm going to receive timeout messages,
but I won't be able to see all the information
about the routers and firewalls there
except to know there is something there,
and I can see that by those stars that are existing.
Now, when it comes to troubleshooting your network,
you can use ping to determine
if you have a network connection from your source
to your destination without any issues.
If someone's complaining that their network connection
isn't working, I usually follow a simple four step process
to determine where that issue is occurring.
First, I'm going to try to ping google.com
or some other really big website
that's always up and available.
If this works, I know my network connection is good,
and the internet connection is good,
and in this case, it would be a user issue
that's specific to a website they're trying to access.
If I can't ping google.com successfully,
I'm going to switch to pinging an IP address,
something like 8.8.8.8,
and I'll see if that works.
Now, 8.8.8.8 is a great IP address to use
for a couple of reasons.
First, it's really easy to remember it's just four eights.
Second, it's the DNS server for Google,
so it has an extremely high rate of availability
and reliability, so it's almost always up,
and it makes a great IP to use for your troubleshooting.
Now, if you can ping 8.8.8.8 successfully,
this indicates your inner connection is working,
but I'm probably having DNS issues
because I couldn't resolve google.com
to its proper IP address and ping it.
At this point, we would shift our troubleshooting efforts
towards the DNS issue, either with our local DNS cache
or our DNS server.
Now, if you can't ping 8.8.8.8,
this means you can't reach the internet successfully.
So we need to go back and refocus our efforts
by moving inwards by one step.
Now, I'm going to ping my default gateway,
my router or my modem.
This way I can see what the internal IP address is
of that border gateway or router, and see if I can reach it.
For example, in my home office,
we're using a private IP range
of 192.168.1.0/24.
So my default gateway is 192.168.1.1.
If I can ping that IP address
and it goes successfully,
this means I have a good connection from my client
all the way through my switches and routers
up to that border gateway router.
So now I can know the issues
between my border gateway router and the 8.8.8.8 server,
because something is wrong with our internet connection,
maybe our modems offline or something like that,
so we'll troubleshoot in that half of the network.
Now, if I can't ping the default gateway,
that means there's an issue between my client
and my border gateway.
This can be anything, it could be cabling or switches,
or anything else in between those two devices,
including my local workstation itself.
So the next thing I want to ping
is my local client's IP address.
For example, if your IP address is 192.168.123,
and your default gateway was 192.168.1.1,
you are going to ping the local IP address
of 192.168.1.23, and you'll see if that works.
If pinging, that does work,
this means that you have an issue
between your network card and the default gateway,
so you need to check your cabling and your switches,
and all the things outside of your device.
Now, if you can't ping your local IP address,
that means you now need to ping your local host
of 127.0.0.1.
If you can, that means your network card
and its drivers are properly installed.
If you can't, that means you need to reinstall
your network card drivers because there is most likely
something being corrupted in there.
As you can see, by just using my pin command,
I can quickly identify where the issue is.
Is it on the internet side?
Is it a problem with my modem or my router,
or is it a cabling or switch issue?
Or maybe it's a client or driver issue.
By doing these four steps, you can figure it out.
Now, if the issue is between the router
and the destination, this is where traceroute
is going to become really helpful for you
because I can identify all the routers are being used
between my client and the destination,
and then I can see where the data stops flowing.
Then if I own that device, like an internal router
or firewall, I can check its configuration
and work to restore those services.