Debugging

Almost every aspect of the router's configuration can have debugging enabled. For example, we could say:

 debug chat

With debugging on, any chat script activity is logged to the router's console (or to the syslog server, if configured). To disable logging, use the undebug command:

 undebug chat

If you forget what debugging you turned on, use the undebug all command to turn all debugging off:

 undebug all

There is a debug all command, butunless you have major problemsthere is rarely a good need for it. When it is executed, all debug information possible is flooded to your screen. You'll be overwhelmed with data, even if logging is enabled. The best practice is to activate debugging only for the items in which you're interested.

16.3.1. Using Debugging in Practice

The debug command is an extremely powerful troubleshooting tool. Assume that you have a serial interface on a router named Baltimore. At the other end of this interface is a router named New-York with an IP address of 10.1.2.55. You are having trouble communicating with the New-York router. One strategy for analyzing the problem is to enable IP packet debugging on the Baltimore router to see if packets from New-York are arriving. To do so, use the command debug ip packet:

 baltimore#debug ip packet
 IP packet debugging is on
 baltimore#
 IP: s=10.1.2.55 (Serial0), d=255.255.255.255, len 72, rcvd 2
 IP: s=10.1.2.29 (Serial1), d=255.255.255.255, len 72, rcvd 2
 IP: s=10.1.2.97 (local), d=255.255.255.255 (Ethernet0), len 72, sending
 broad/multicast
 IP: s=10.1.2.66 (local), d=255.255.255.255 (Serial0), len 72, sending
 broad/multicast
 IP: s=10.1.2.93 (local), d=255.255.255.255 (Serial1), len 72, sending
 broad/multicast
 IP: s=10.1.2.55 (Serial0), d=255.255.255.255, len 72, rcvd 2
 IP: s=10.1.2.29 (Serial1), d=255.255.255.255, len 72, rcvd 2
 baltimore#undebug ip packet

This command is very dangerous: it produces a great deal of output and could render a busy router useless. The problem arises because logging debug messages takes priority in IOS. To get around this problem, we could use an access list to limit which packets are displayed. We will cover that trick in a moment.

The s field in the output indicates the source of the packets. This short transcript shows that we've received packets from a number of hosts, including two packets from the New-York router's IP address. Therefore, we are capable of receiving from the other end. Now that we have confirmed that we have communication between the two sites, we can troubleshoot other items, such as our routing configuration.

A safer way to use this commandone that doesn't risk overwhelming the router with its logging dutiesis to combine the debug command with an access list that limits which packets get displayed. In the following example, we set up an access list that controls which packets are logged:

 baltimore(config)#access-list 1 permit 10.1.2.0 0.0.0.255
 baltimore(config)#end
 baltimore#debug ip packet 1
 IP packet debugging is on for access list 1

This command is still somewhat dangerous because you still don't know how much traffic will make it through the access list. But it's significantly less likely to cause problems than enabling packet debugging without some form of access control. Other debug commands aren't as dangerous; we can enable them with some level of confidence that the router won't be overworked. For example, let's debug RIP packets:

 baltimore#debug ip rip
 RIP protocol debugging is on
 1d07h: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (10.1.2.97)
 1d07h: subnet 10.1.2.192, metric 1
 1d07h: subnet 10.1.2.64, metric 1
 1d07h: RIP: sending v1 update to 255.255.255.255 via Serial0 (10.1.2.66)
 1d07h: subnet 10.1.2.192, metric 1
 1d07h: subnet 10.1.2.96, metric 1
 1d07h: RIP: sending v1 update to 255.255.255.255 via Serial1 (10.1.2.93)
 1d07h: subnet 10.1.2.96, metric 1
 1d07h: subnet 10.1.2.64, metric 1
 baltimore#undebug ip rip
 RIP protocol debugging is off

This output shows that we are sending RIP updates from each of our active interfaces. The next step is to see whether the end routers are receiving the updates. To check, you can turn on debugging on the remote routers, continuing until you have discovered the problem.

There are debug commands for just about everything within the router. When you need help, use the debug ? command to get you started. If you forget what you enabled, always remember that undebug all disables all debug output.

16.3.1.1. The debug list command

The debug list command allows us to apply an access list or interface to a specific debug command. It's an effective way to control the load debugging places on your router and to limit the amount of debugging output you have to look through. This command takes an access list number or an interface name as an argument; it applies to the next debug statement. For example, assume that we're using EIGRP for routing and we're having problems communicating with the router at 10.1.1.1. We could use the command debug ip eigrp, but that would bombard us with output for all the EIGRP routers. Instead, we first create an access list that permits traffic from 10.1.1.1. We then use the debug list command to apply the access list to the following debug statement. Finally, we can give the command debug ip eigrp:

 router1#undebug all
 router1#config terminal
 router1(config)#access-list 10 permit host 10.1.1.1
 router1(config)#exit
 router1#debug list 10
 router1#debug ip eigrp
 IP-EIGRP Route Events debugging is on
 for access list: 10

The router responds by saying that EIGRP route event debugging is enabled for access list 10.

The debug list command can also apply to specific interfaces. In the next example, we limit the output from the debug ip eigrp command to EIGRP traffic through ethernet0:

 router1#undebug all
 router1#debug list ethernet0
 router1#debug ip packet
 IP-EIGRP Route Events debugging is on
 for interface: ethernet0

You can apply a debug list to just about any debugging command.