Cisco CCNA / CCNP Certification: Deciphering Ping Results
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!
