- [Instructor] One of the most basic
troubleshooting commands for every network
is the ping command.
This allows us to check for basic connectivity
and reachability over the network.
If I'm troubleshooting a network,
this is quite frequently the first place I'll start.
This is going to tell me
if I'm dealing with a physical layer issue,
something maybe like a broken or unplugged cable,
or if there's a more advanced issue,
something like access control lists,
or routing protocol problems and so on.
Here I have a very simple topology,
I only have two routers,
and those are connected to one another.
If I want to check for basic layer two connectivity
between those routers, I can use the command ping
followed by the IP address that I'm trying to reach.
In my case, that's 10.1.1.2,
that's the IP address for router two.
If I hit enter, you can see that the results
of that ping command are successful.
I'm told that the success rate is 100%,
five out of five messages were sent and responded to.
You can also see, as stated, that this uses ICMP,
the Internet Control Message Protocol.
This is a layer three protocol that sends out an ICMP echo.
By default here, we see that those are 100 bytes each,
so again, 100 byte echo requests is being sent out,
and there were five of those sent to
the 10.1.1.2 IP address.
If this had been a failure,
we would know that something was wrong,
most likely at a lower level.
Common issues would be cabling issues of course,
but it might also be the port interface being shut down
on our router or on the remote router.
But in this case, we don't have any problems indicated.
We can see five exclamation points in the results,
so that indicates
that all five of those pings were successful.
Now, you'll also want to note that often
when you ping a host for the very first time,
it's not uncommon to see that very first attempt fail.
So instead of five exclamations,
you might see a decimal, followed by four exclamations,
and then you would get an 80% success rate
the very first time you try to ping an IP address.
And that's because the remote router
has to put the ping request on hold,
and it will just send out an R broadcast,
so that the Mac address of the device
that you're pinging from, can be learned.
So in our case, router one would send out an ICMP echo,
router two would respond to that with an R broadcast
in order to learn the Mac address of this device,
and then it would be able to respond to subsequent pings.
And that often takes more than
the allotted two second timeout.
We see listed here that the default setting
is timeout of two seconds.
So after two seconds,
an ICMP echo is regarded as being timed out or failed.
And that's why you'll often see
that very first attempt failed.
If you follow that up with another ping immediately,
you should see a 100% success rate, as we see here.
Other things that we can glean from this information
is the round trip time taken for those ping messages.
You can see those stats listed here in milliseconds.
We have the minimum, the average and the maximum,
as six, eight, and 15 milliseconds.
If there was an ICMP failure, as we've already mentioned,
those are indicated in iOS with decimals, or with dots.
So let me ping a nonexistent IP address on my network.
I'll say 10.1.1.10, that doesn't exist here,
so I'm definitely going to get a failure.
And you'll be able to see that
the output is going to show five decimals.
Each one of those five attempts is met with a failure,
and we'll be told at the end,
there we see it, that our success rate is 0%,
zero out of five messages.
So, this would indicate some sort of lower level issue.
If we say ping 10.1.1.2, and look at our contextual help,
you can see all of our other options available to us
with the ping command.
Another very common way that I'll use this
is with the keyword repeat,
followed by a really large number.
And that's going to give me a continuous ping.
If I hit enter,
you'll see that just going to continue to reach out
to that remote device.
And you can break out of that command
with the Control + Shift + 6 key combination
if you need to do that.
I'll often use this if I need to reboot a remote device.
I like to do that in order to see
when the device comes back up.
If I send a continuous ping,
let's say to router two in this case,
and then I rebooted router two,
instead of this series of all successes that we see listed
with exclamation points,
in the middle of that,
you would see some decimals in the output,
indicating failures while the device
was in the rebooting process.
And then when it came back online,
and the interface was available again,
it would move back to showing
the exclamation points for successes.
So, that's just a common way that I like to do that
if I'm rebooting a remote device,
just to keep an eye on things.
Now we can also set the size of the ICMP packet manually
by saying ping 10.1.1.2, followed by the size keyword.
And you can see with our help command,
we're shown a range that were able to set that datagram,
and those are in bytes.
So commonly, we might say something like 1,500 here.
Let's say we're testing out
some sort of quality of service policy that we have in place
on router two that might be limiting certain packet sizes.
Or let's say we're testing out the MTU size
of the remote interface.
If router two's interface had an MTU size set to,
let's say 1,400, then these pings would fail,
and we would know that there was some sort of MTU mismatch.
Another option is to use the source keyword.
Now by default, when we're pinging,
whichever outbound interface that I'm using
to send the ping out of, will be the source address.
In my case, that traffic is going out of gig 0/1.
Let's say I have another subnet on my router,
connected to gig 0/2.
I can force the router to use a source address
using this command from the subnet on my gig 0/2 interface.
And, if I hit enter, we will see that fail.
And the failure here let's me know
that somewhere in the path,
there's a device that doesn't know how to get back
to the subnet on my gig 0/2 interface.
Now, in my case, I don't have any routing protocols set up
between those subnets, so that's definitely the issue.
But, if we were on a normal network,
and we knew we could ping router two
from our local router here,
but our subnet on gig O/2 could not ping that
using that source command,
then we know we have to address the connectivity issue
in that way.
We can use all of these commands together as well,
you can use any combination of those.
So, if we say ping 10.1.1.2 source gig 0/2,
we can append that size command on there again.
Again, this will fail because I'm using a source
that it doesn't know about.
We can also say, we can add repeat on there,
we can add 20, repeat 20 times.
We can use all of those command options together.
I'm going to break out of that command
because I don't actually want it to repeat 20 times.
I know they're all going to fail.
Another option is to simply go under exec mode,
as we are here, and enter the ping command by itself.
If we hit enter, that's going to bring us to a ping wizard,
and you're going to be prompted for certain information.
First, we're prompted for the protocol that we want to use.
By default, that's going to be the IP protocol,
but we could say IP version six or MPLS, for example.
I'll just hit enter and accept the default.
Now it asks us for the target IP address.
I'll say 10.1.1.2.
Next is the repeat count.
We see that default value of five, I'll leave that in place.
We see our datagram size, 100 bytes,
remember we looked at that in the output.
100 bytes is the default size for those ICMP messages.
Next is the timeout.
Again, we see that default value of two seconds.
If we want to increase that, we can certainly do so here.
And then we're prompted with whether or not
we want to use a series of additional commands.
The default is no.
I'm going to yes here just so you can see a list of those.
You can see that we can choose to use the ingress interface
from the remote router, as the responding interface
if we want to.
We can set a specific source address or interface
for the ICMP echo on our side, we looked at that.
We can set a DSCP value, a type of service value.
So if we want to mimic voice over IP traffic, for example,
we could tag that with a particular type of service bit.
We could set the DF bit, the don't fragment bit.
This is the bit within the IP header
that determines if a route is allowed
to fragment the packet.
You could define different data patterns
to test for specific faults, such as circuit clocking.
And then finally, we have the options to choose loose,
strict, record, timestamp or verbose.
Loose specifies the hops that the ping should traverse,
while strict will limit those to specified hops.
Record will display the IP addresses of the first nine hops
that the packet traverses.
The timestamp's going to display the roundtrip time
to the destination for each ping.
And the verbose option is automatically selected
with any of these options, so I'll just hit enter.
And just escape out of that.
And really, because I chose no on most of those options,
it's a simple ping as we would do with the normal command
followed by an IP address.
So lots and lots of options that's going to let you do
a lot of things with a simple command.
You can see our results from hitting enter,
and we have lots of insight into our connection here.
So that's a look at how we can use
the basic and extended options
found within the ping command.