As you study for your CCNA and CCNP exams, particularly
if you're getting hands-on practice in your home lab or rack rental service,
you're going to be sending a lot of pings. As a CCNA or CCNP candidate, you
know that five exclamation points (!!!!!) as a ping return indicates that you
have IP connectivity to the remote destination. Five periods (.....) indicates
that you do not have that connectivity.
It's not enough to know that you don't have IP connectivity to the
remote device, you've got to know why. Ping is a great first step to network
troubleshooting, but the results are quite limited. As a CCNA and CCNP, you've
got to know how to diagnose the problem and resolve it. Just looking at the
routing table is not enough - a high-powered Cisco debug, debug ip packet, can
often show you exactly where the problem is.
WARNING: debug ip packet should not be run on any production router
without understanding the effect of this command on your router. This command
results in a lot of output and can actually lock up a router.
In this case,
we'll run the command on a home lab router that cannot ping 22.2.2.2. The debug
will be turned on and another ping sent.
R1#debug ip packet IP packet
debugging is on R1#ping 22.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 22.2.2.2, timeout
is 2 seconds: 3d23h: IP: s=1.1.1.1
(local), d=22.2.2.2, len 100, unroutable.
R1#undebug all All possible
debugging has been turned off I've
edited this output for clarity; the important word is "unroutable".
This indicates that the packet is not leaving the router because there is no
match in the routing table for this destination. We'll configure a static
default route and send the ping again.
R1#ping 22.2.2.2 Type escape
sequence to abort. Sending 5, 100-byte
ICMP Echos to 22.2.2.2, timeout is 2 seconds:
U.U.U Success rate is 0 percent
(0/5) That output may surprise those of
you who are used to getting five of the same symbol back whenever you send a
ping. We got three "U"s back along with two periods. We'll now run
debug ip packet and send the ping again.
R1#debug ip
packet IP packet debugging is on R1#ping 22.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 22.2.2.2,
timeout is 2 seconds: 3d23h: IP:
s=172.12.123.1 (local), d=22.2.2.2 (Serial0), len 100, sending R1#traceroute 22.2.2.2 Type escape sequence to abort. Tracing the route to 22.2.2.2 1 172.12.123.2 36 msec 36 msec 36 msec 2 172.12.123.2 !H * !H R1#undebug all All possible debugging has been turned off Again, I've edited this output. The key word
in this output is "sending", meaning that the packets are leaving the
router. The ping return of "U.U.U" is a general indication that the
packets are indeed being transmitted, but that a downstream router is having a
problem routing the packets. Running traceroute reveals some more interesting
return characters! In this case, the downstream router did not have a match for
the destination in its routing table.
It's easy to concentrate on the local router when you're not getting
positive ping returns. When troubleshooting this kind of issue, keep in mind
the problem could be on an intermediate router and not on the local router. Use
debug ip packet to make sure the packets are leaving the local router, and
traceroute to determine what downstream router may have the problem. And get
used to the fact that pings and traceroutes can give you some unusual-looking
returns!
