Routing Troubleshooting Tools 0:00-0:13

In this lesson we're going to look at several utilities you can use on Cisco routers to
troubleshoot connectivity and the overallrouting process on an IP network.

Ping 0:14-0:58
The first utility we're going to look at is the good old ping command. If you've been
working with networking for very long, you're probably very familiar with ping. Just
as you can use pingon a workstation, you can also use ping from a Cisco router. The
ping command basically tests connectivity between network hosts. It does this by
sending small requests to the target system asking, basically, "Hey, are you
there? Are you available?"If true, the target system responds back to the sender
affirmatively. However, if the target host does not respond, then you know
there's something wrong somewhere. Perhaps the target host is powered
off. Maybe a network cable's unplugged.Maybe a network card is bad or we've got a
broken cable somewhere.

Ping Uses ICMP Echo Requests 0:59-1:40

In order to do this, ping uses the Internet Control Message Protocol, or simply
ICMP, to send requests. When the ping command is run on the sending host--for
example, let's saywe're sending a ping from 10.0.0.1 to 10.0.0.5 this direction--the
router 10.0.0.1 will send an ICMP echo request addressed to the target system, in
this case, 10.0.0.5. If the target system receives that ICMP echo request, it should
respond back with an ICMP echo response addressed to the source system where
ping was run.

Denial of Service Attacks 1:41-2:10

Before we go any further, however, be aware that, because of the prevalence of
Denial of Service attacks (DOS attacks), many firewalls, both network and host-
based, are configured bydefault to drop all ICMP packets. If this is the case, the
target host won't respond, and so you may assume that it's down orthat a
communication problem exists somewhere in the network. In reality, it could just
be that the target host is ignoring your ICMP echo request packets.

Round Trip Time (RTT) 2:11-2:56

When the ICMP echo response packets over here arrive at the sending system, the
ping utility can then analyze those packets and determine the time that elapsed
from the original transmission of the ICMP echo request packets to the receptionof
the ICMP echo response packets. This provides us with theRound Trip Time
(RTT). The round trip time provides a lot of information. If the round trip time is only
a few milliseconds, you know you've got a great connection between the sending
and target host. If the round trip time is really, really long, then you know that
that packet had to traverse a very long distance, crossing, probably, many
routers in order to get to the target system.

ICMP Echo Responses 2:57-3:57

In addition, ping can identify any of the ICMP echo requests thatwere sent to which
it did not receive an ICMP echo response.Believe it or not, this is fairly
common. You might send three or four ICMP echo requests and only get one
or two ICMP echo responses back. That means that we've got a problem
somewhere in the network, perhaps latency. Maybe it's just taking too long. Maybe
it could be that we have congestion, and packets were dropped somewhere along
the way. Perhaps we have a faulty network board in the target host and it only
accepted one of the ICMP echo requests that were sent to it.

Essentially, using ping, you can establish that a basic level ofconnectivity exists
between the two hosts and get some idea as to the quality of that connection. Not a
lot of detail, but at least some that will give you an indication as to how your overall
network is functioning. If the communications are successful,then you can rule out
a lot of possible problems between these two hosts.

Ping by Hostname and IP Address 3:58-4:47

Before proceeding, I do want to point out that you can ping byhostname as well as
by IP address. In order to ping by hostname you do have to have a valid DNS
server configured for your router. It's got to know where to send name resolution
requests. Here's a key troubleshooting trick. If you are able to ping, say, this
host right here, 10.0.0.5, by its IP address, butwhen you try to ping it by its
hostname and you can't, then you know that the basic network connectivity
between the two hosts does exist, but your DNS name resolution system isn't
working right. Perhaps you have the wrong address configured. Maybe the DNS
server's down. Something is causing your hostnames to not be resolved to IP
addresses.

Extended Ping 4:48-5:32

Be aware that when working with Cisco devices you can also use extended
ping. Extended ping is really useful because it allows you to test IP routing
more extensively, more thoroughly, than using standard ping can. In the network
we're working with here, we've got a PC over on the side with this IP address. We
have a switch. We have two routers: Router1, Router2. We have another switch,
and we have another host over here with this IP address. As far as IP networking
is concerned, we've got the 10subnet over here on this side, we've got the 192.168
subnet here in the middle between the routers, and we have the 172.17
subnet over here on the right.

Example of No Default Gateway 5:33-6:33

One of the scenarios in which extended ping can be really useful is one where
there's no default gateway set on a particular network host, such as this PC system
over here. Let's suppose that this host does not have its default gateway
parameters set.If we were to just use standard ping from 10.0.0.5 to test
communications, we would be able to ping this interface right here on the default
gateway. Because it's on the same networksegment, it doesn't have to go through
the default gateway itself. If we were to try to ping this interface over here, it would
fail because the host down here would have no idea where the192.168.1 network
segment is. Because it doesn't have a defaultgateway, it has no place to send it,
so the ping request would not be successful.

At that point you know that something's wrong. You can't ping the other side of
the router, but you really don't have a lot of clues as to why this is the case. This is
where using extendedping can come in really handy.

Test the Reverse Route 6:34-9:39

For example, in this scenario we could use extended ping to test the reverse route
from this router interface right here back to 10.0.0.5. This is possible because
extended ping does one thing differently than standard ping does. Using standard
ping, you send your ICMP echo request packets out of the exit interface. If we ran
ping 10.0.0.5 from this router, those packets would exitout of 10.0.0.1, and they
would make it to 10.0.0.5 without any problem. We can't specify where
those packets are going to originate from.

This is not the case with extended ping. Using extended ping, we can specify which
interface we want to send the ping requests from. To test reverse routing, what we
can do is use extended ping to send those packets from this interface over
here. Those ICMP echo request packets are going to originate from this IPaddress
right here, 192.168.1.1. When we do this, those ping requests are going to go
through the router and are going to come down to 10.0.0.5. This is called
testing the reverse route.

If we do this and we get a reply back from 10.0.0.5 onto this interface right here,
192.168.1.1, we know several things. First of all, we know that the target host is up
and running because it's responding to our ping request. We know also that the
default gateway on this target host right here is working properly because it was
able to send those ICMP echo response packets back through the router to
the interface on a different network.We also know that the router itself, right here,
is functioningproperly, at least for these two interfaces, this one and this
one.Because we're able to send data through the router to 10.0.0.5 and able to
receive data back from that network segment through the router to the 192.168.1.1
interface.

Let's suppose that we do not get a reply--we use extended ping to send an ICMP
echo request packet from 192.168.1.1 down here to 10.0.0.5. We don't get a
response. At this point, we know that we need to do some serious
troubleshooting. It could be something simple. It could simply be that, as we
talked about, this host right here does not have the default gateway set.Therefore,
when it gets those ICMP echo request packets, it can't send back ICMP echo
response packets because it doesn't know where they go. They're on a
completely different network segment, and it doesn't have a default gateway, and
so it can't send them. It could also be that there's a problem with the router itself. It
could be that the router is not routing data between these interfaces properly. As
you can see, extended ping provides us with a lot more information than just using
standard ping.

Traceroute 9:40-10:52
The next utility we need to look at is the traceroute command.Traceroute is
extremely useful. Traceroute is designed to verifythat a remote host is
reachable through an internetwork of routers. Remember that, if you try to
send information to an IP host that doesn't reside on your local network segments,
the packets have to go to the default gateway router first, and this router will then
use its routing table to figure out how to get those packets to the destination
system. In this process, the packets will have to be transferred from router to
router to router to get there.

You can use traceroute to trace the route a packet has to traverse through these
various routers to arrive at its destination. As you can see here, if I wanted to send
data from 10.0.0.5 to 172.17.1.11, those packets would have to go through two
different routers to arrive at its destination. You can use this traceroute utility to
make sure that packets actually can do that.If you're dealing with Cisco routers or
the Windows workstations, the traceroute utility uses the same ICMP echo requests
and ICMP echo response packets that are used by ping.

Time to Live (TTL) 10:53-12:49

It uses those in a different way than ping, however. What it does is manipulate the
time to live (TTL) parameter of the ICMP echopackets sent to the target
system. Before we go any farther, I doneed to point out that if you are using
traceroute on a Linux orUnix system, it does not use ICMP. Instead, it uses TCP
packets.But the way that it uses the TCP packets is identical to the way that the
standard traceroute uses ICMP packets.

What it does is manipulate this time to live parameter on thepackets that are sent
from the source system to the target system. What you need to understand is
that every time one of these packets crosses a router like this, the time to live
value on these packets is decremented by one. This is done by design. If you think
about it, if we had a packet that we sent out on an internetwork such as this, or
even a bigger internetwork like the internet, and we had a bad address or we had
some type ofrouting loop going on, it is theoretically possible for that packetto sit
there in the ether, so to speak, going back and forth and back and forth and back
and forth literally forever because, if it's undeliverable, it will just keep going around
in a loop from router to router to router.

We don't want that. When a packet has traversed a certain number of routers,
we want to say, "You know what? This packet is not going anywhere. Drop it." That's
done using the TTL. As I said, every time a packet crosses a router, the TTL value is
decremented by one. If the TTL reaches a value of zero, an ICMP error message--
this is the third type of ICMP message--is sentback to the source address of that
packet, and then the packet is dropped. This can be a very useful thing.

Works by Sending Sequential ICMP Packets 12:50-16:44

Traceroute works by sending sequential ICMP packets to the target system. In this
scenario, we're going to send ICMP echo request packets from 10.0.0.5 over to
172.17.1.11. But we're not going to send just one; we're going to send a whole
series of them. This is the key to how traceroute works. The TTL of the first packet
that is being sent from 10.0.0.5 to 172.17.1.11 is set to a value of one. As you can
see, it's an almost dead packet already. It can only cross one router, because,
remember, when the TTL goes to zero, it's going to get dropped. This packet is sent
from 10.0.0.5. It hits the first router. What happens when ithits the first router? The
TTL decrements down to zero. At this point, that router over here says, "Oh, it's got
a TTL of zero. This is an old packet. Drop it and let's send an ICMP error message
back to the source host." That ICMP error message comes back.

The source address on that ICMP error message is the source address of the
router. Guess what we just found out? We found out the IP address of the first
router in the path between the sender and the receiver. The TTL of the second
packet is not set to one, but instead, this time, it will be set to a value of
two.Because it's set to two, it will actually make it past this first router. When it
does, though, remember, it's going to be decremented to one. That way, when it
hits this second router, it's going to say, "Uh oh, we got a bad packet. We've got to
decrement this to zero. It's a bad packet. Let's go ahead and drop it and let's send
our error message again back to the host that originally sent the ICMP echo request
packet. That's 10.0.0.5."

Once again, the source address of that error packet is the IP address of the router
that basically killed the packet, 192.168.1.2. Do you see what's happening? We're
slowly building a list of routers between 10.0.0.5 and 172.17.1.1. The first packet
identified this host. The second packet identified the second router. The next
packet has its TTL set to three. The fourth packet has its TTL set to four, and so
on. By doing this, we expose every router between the sender and the target
systems. This is really useful, because if there's a problem somewhere--say this
router right here is malfunctioning--we would be seeing our traffic only making it
that far. The router over here is dead, so traffic isn't getting past it. That's good
information when you're troubleshooting communications onthe internetwork.

Using this information, you could--if you had the ability to do so--access the last
router in the output of the traceroute command.This is the last one to send a
proper response. You could view its routing table to identify any routing issues it
may have.Basically, you're trying to see--is the problem right here? Does it have a
problem with the routing protocol configuration? Is there something missing from
the routing table? Is the routing table malformed and trying to send packets the
wrong direction? If everything checks out, then you could go and access the
interface of this router and see if it's got a problem, take a look at its routing table,
and see if it's got the necessary routes to deliver the packet. Maybe there's a
problem with the reverse route going back this direction. Maybe it's going this way.
As with ping, you can use traceroute with IP addresses or hostnames. Again, using
hostnames could be useful if you're trying to also isolate name resolution issues.

Extended Traceroute 16:45-17:17

Also be aware that on Cisco devices we also have extended traceroute. Just like with
extended ping, the extended traceroute command allows you to change the source
IP address when you run it on a Cisco router, and thereby test reverse routes. Just
as with ping, be aware that many firewalls do not allow ICMP traffic through. Thus
they may block the ICMP echo requests that are sent by traceroute, as well as the
ICMP error messages that are sent back by the remote routers in the path.

Summary 17:18-17:31
That's it for this lesson. In this lesson we introduced you toseveral troubleshooting
utilities you can use on Cisco routers to test connectivity and routing. We first
looked at ping. We then looked at extended ping. We then looked at traceroute,
andthen we looked at extended traceroute.