You can submit several pings during your CCNA and CCNP examinations, particularly if you have practical experience in your home lab or in the rack rental service. As a CCNA candidate, you know, in the form of a ping return, that you have IP connectivity to the remote destination at five exclamation points (!!!!!). Five intervals (…..) mean that this connectivity is not in place.

You don’t know anything about the IP-connectivity you do not have to know why on the remote computer. Ping is an excellent first attempt to resolve network problems, but there are only few outcomes. You must be able to detect and fix this issue as a CCNA and CCNP. It is not sufficient to look at the routing table – a high power Cisco debug, debug ip packet, will also show you precisely where the problem lies.

ATTENTION: debugs should be executed on no production router until the impact of this order on your router is understood. This command leads to a lot of production and can lock a router.

Here we’re going to execute the order on a home laboratory router that can no longer ping 22.2.2. The debug is enabled and a ping is received.

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

This performance has been edited by myself; “unroutable” is an essential term. This shows that the packet does not leave the router, so the routing table for that destination is not matched. The normal static path will be setup and the ping will again be dispatched.

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)

The result could surprise those of you who are familiar with five of the same symbol when sending a ping back. Along with two times we got three “U”s back. Now we are going to run debug ip and give the ping back.

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

Any debugging available has been disabled

This performance has been edited again. In this output the key word is “send,” indicating the packets leave the router. The “U.U.U” ping return is a general indicator that packets are already sent but the packet routing is problematic for a downstream router. Traceroute running shows even more fascinating characters! In this case, in its routing table, the downstream router did not fit the destination.

If you don’t get a positive ping response, it’s safe to focus on the nearby router. Beware that the problem could be on an intermediate router and not on the local router until this kind of problem is solved. Use debug ip to make sure that the packets leave the local router to traceroute the downstream router. And get used to the fact that tracerouts and pings will give you unusual benefits!

Leave a Comment