As you study for your CCNA and CCNP exams, especially if you’re getting practice in your home lab or rack rental service, you’ll be sending out a lot of pings. As a CCNA or CCNP candidate, you know that five exclamation points (!!!!!) as a ping return indicate that you have IP connectivity to the remote destination. Five (…..) dots indicate 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 need to know why. Ping is a great first step in troubleshooting network problems, but the results are pretty limited. As a CCNA and CCNP, you must know how to diagnose the problem and resolve it. Just looking at the routing table is not enough: a high powered Cisco debugger, debugging 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 returns a lot of output and can actually crash a router.
In this case, we will run the command on a home lab router that cannot ping 22.2.2.2. Debugging will kick in and another ping will be sent.
R1#debug IP packet
IP packet sniffing is enabled
R1#ping 22.2.2.2
Type escape sequence to abort.
When sending 5 ICMP echoes of 100 bytes to 22.2.2.2, the timeout is 2 seconds:
3d23h: IP: s=1.1.1.1 (local), d=22.2.2.2, len 100, not routable.
R1#undebug all
All possible debugging has been disabled
I’ve edited this output for clarity; the important word is “irrutable”. This indicates that the packet is not leaving the router because there is no match in the routing table for this destination. We will configure a static default route and send the ping again.
R1#ping 22.2.2.2
Type escape sequence to abort.
When sending 5 ICMP echoes of 100 bytes to 22.2.2.2, the timeout is 2 seconds:
UUU
Success rate is 0 percent (0/5)
That output may surprise those of you who are used to getting five of the same symbol every time you ping. We have three “U’s” back along with two dots. We will now run the debug IP packet and send the ping again.
R1#debug IP packet
IP packet sniffing is enabled
R1#ping 22.2.2.2
Type escape sequence to abort.
When sending 5 ICMP echoes of 100 bytes to 22.2.2.2, the timeout is 2 seconds:
3d23h: IP: s=172.12.123.1 (local), d=22.2.2.2 (Serial0), len 100, sending
R1#trace route 22.2.2.2
Type escape sequence to abort.
Trace the route to 22.2.2.2
1 172.12.123.2 36ms 36ms 36ms
2 172.12.123.2 !H * !H
R1#undebug all
All possible debugging has been disabled
Again, I have edited this output. The keyword in this output is “sending”, which means that the packets leave the router. The ping return of “UUU” is a general indication that packets are getting through, but a downstream router is having trouble 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 focus on the local router when you’re not getting positive ping returns. When troubleshooting this type of problem, keep in mind that the problem might be with an intermediate router and not the local router. Use IP packet debugging to ensure packets are leaving the local router and traceroute to determine which downstream router may have the problem. And get used to the fact that pings and trace routes can give you some unusual looking returns!