Debugs, Conditional Debugs, Ping and Traceroute

What it is

Ping, traceroute and debug are the basic tools for finding out why traffic fails.

Ping tests whether a destination answers. Traceroute shows the path and where it stops. Debug shows what a device is doing inside, one event at a time.

How it works

Start with simple tools, and use debug only when you need detail.

Ping

Ping sends ICMP echo requests and waits for replies. The router prints one character for each attempt.

R1# ping 10.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

By default the router uses the address of the outgoing interface as the source. The reply must return to that address, so a ping can fail because the far end has no route back.

Extended ping

Typing ping with no address starts an extended ping that asks for options. You can also give options on one line.

R1# ping 10.2.2.2 source Loopback0 repeat 100 size 1500 df-bit

Using a loopback as the source tests whether the far side has a route to that network.

Traceroute

Traceroute sends packets with an increasing time to live (TTL). Each router that lowers the TTL to zero returns an ICMP time exceeded message, which reveals its address. On IOS the probes are UDP packets sent to a high port, and the last hop answers with a port unreachable message.

R1# traceroute 10.2.2.2
  1 10.1.1.2 4 msec 4 msec 4 msec
  2 10.1.2.2 8 msec 8 msec 8 msec
  3 10.2.2.2 12 msec 12 msec 12 msec

A line with asterisks means a probe timed out. The last answering hop is the place to investigate, since the next router may be down, may have no route or may be filtering the reply.

Debug

The debug commands print events as they happen. They help with protocol problems, such as OSPF neighbours that will not form.

R1# debug ip ospf adj
R1# show debugging
R1# undebug all

show debugging lists the debugs that are active. undebug all turns every one off. Output goes to the console by default, so on a remote session you must also enter terminal monitor to see it.

Debug is dangerous on a busy device. A command such as debug ip packet prints a line for every packet and can overload the CPU and lock out the console. The safe habits are to limit the scope and to turn debug off as soon as you have what you need.

Conditional debugs

A conditional debug limits the output to chosen traffic, such as one interface.

R1# debug condition interface GigabitEthernet0/1
R1# show debug condition
R1# no debug condition all

Set the condition first, then enable the debug you need. A debug that supports conditions then prints only events for the matching interface, and support varies by feature and platform.

Other conditions exist, for example on an IP address or a user name. The command no debug condition all removes the conditions.

You can also use an access list to restrict debug ip packet:

R1(config)# access-list 100 permit icmp host 10.1.1.10 host 10.2.2.2
R1# debug ip packet 100

Use debug ip packet detail 100 for more fields. Remember that only the packets that the router process switches are shown, and on some platforms hardware forwarded traffic does not appear.

A simple method

1. Ping the next hop, then the destination, to find where it first fails.
2. Use traceroute to see the last responding hop.
3. Check the routing table and interfaces on that device.
4. Use debug with a condition only if the cause is still unclear.
5. Turn off debug and note what you found.

Logging debug output

Debug messages are sent to the logging system. You can send them to a buffer so that they do not flood the console.

R1(config)# logging buffered 64000 debugging
R1(config)# no logging console
R1# show logging