- "Do I Know This Already?" Quiz
- Foundation Topics: System Impact of Cisco Troubleshooting Tools
- Cisco Routers' Routing Processes and Switching Processes
- Switching in 7000, 7500, 4000, 3000, and 2500 Series Routers
- Handling the Cisco IOS Debug Troubleshooting Tool
- Error Message Logging and Limiting the Display of Error Messages
- Reachability and Step-by-Step Path Tests
- Information Needed by Technical Support
- show version Command
- Buffers and Queues
- show memory Command
- show processes Command
- show controllers cxbus Command
- show stacks Command
- Core Dumps
- Foundation Summary
- Q&A
This chapter is from the book
This chapter is from the book
This chapter is from the book
Handling the Cisco IOS Debug Troubleshooting Tool
Debug is a troubleshooting command that is available from the privileged exec mode (of Cisco IOS). This command can be used to display information about various router operations and the related traffic generated or received by the router, as well as any error messages. This tool is very useful and informative, but you must be aware of the following facts regarding its use: Debug is treated as a very high priority task. It can consume a significant amount of resources, and the router is forced to process-switch the packets being debugged. Debug must not be used as a monitoring tool—it is meant to be used for a short period of time and as a troubleshooting tool. By using it you discover significant facts about the working and faulty software and/or hardware components. The following is a list of recommendations on proper usage of the debug command:
If you are interested to see a timestamp with each line of the debug output, you must load the timestamp service using this command:
router(config)#service timestamps debug [datetime | uptime]
If you plan to see the debug output from within a Telnet session, you need to enter the terminal monitor command.
Usually, the debug command is used to diagnose a specific facility, task, or protocol. Sometimes a protocol suite has a specific member (e.g., TCP from among the TCP/IP protocol suite members) that you may want to focus on. When you choose the protocol you want to debug, then you usually have a choice to use the events option or the packets option of the debug command for that specific protocol. Event debugging is less resource intensive than packet debugging, but packet debugging produces more information.
Turning debugging on for everything (using the debug all command) is seriously discouraged in production networks. You get a tremendous amount of information, very fast, but it can severely diminish the router's performance or even render it unusable. The debug all command is also quite useless since it presents overlapping information that is difficult if not impossible to interpret.
Before using the debug command, see the CPU utilization of your router (using the show processes cpu command). If your router's CPU utilization is consistently at 50% or more, you are advised to debug events instead of packets.
If possible, use the debug command during periods when network traffic is not at its peak and fewer critical business applications are active. Cisco routers give the debug command higher priority (with respect to CPU cycles) than network traffic.
Always remember to undo debug as soon as possible. You can use the no debug {argument} to turn off a specific debugging type. The no debug all or undebug all commands can be used to turn off all types of debugging that may be on.
For troubleshooting, also consider using protocol analyzers to capture and display network traffic. These have little or no impact on your network performance, yet they provide valuable information. I also recommend capturing debug info to a file for offline perusal and training.
Using an access list with your debug command helps you focus the debug output on the task you are troubleshooting. See the next section for more information on this technique.
Using an Access List with Debug
With the debug ip packet detail command, you have the option to enter the name or number of an access list. Doing that causes the debug command to get focused only on those packets satisfying (permitted by) the access list's statements. Here is an example. Imagine that host A has trouble making a Telnet connection to host B, and you decide to use debug on the router connecting the segments where hosts A and B reside (see Figure 4-4).
){kind=link}
Considering the addressing scheme used in Figure 4-4, the access list 100 permits TCP traffic from host A (10.1.1.1) to host B (172.16.2.2) with the Telnet port (23) as the destination. Access list 100 also permits established TCP traffic from host B to host A. Using access list 100 with the debug ip packet detail command (as shown in the figure) allows you to see only debug packets that satisfy the access list. This is an effective troubleshooting technique that requires less overhead on your router, while allowing all information on the subject you are troubleshooting to be displayed by the debug facility.
Figure 4-4 Using Access Lists with the debug Command