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