Foundation Summary
The Foundation Summary is a collection of quick reference information that provides a convenient review of many key concepts in this chapter. For those of you who already feel comfortable with the topics in this chapter, this summary helps you recall a few details. For those of you who just read this chapter, this review should help solidify some key facts. For any of you doing your final prep before the exam, these tables and figures are a convenient way to review the day before the exam.
Handling Cisco IOS Troubleshooting Tools
These tools and commands provide a wealth of information that can be very useful for troubleshooting purposes, but due to their impact on router and network performance they need to be handled and used properly. These powerful tools use up a router's CPU cycles and memory, may be given higher priority than network traffic, and may disable some features such as fast switching.
Routing and Switching Tasks and Route Caching
Routing and switching are two of the important tasks that routers perform. Routing is basically the process of selecting one or more output interfaces for a packet (if possible), whereas switching is basically the process of moving the packet within the anatomy of the router from one location or component of the router to another. Switching is simpler than routing. Routing requires the main processor's attention (it interrupts the main processor) and takes CPU cycles and therefore it is responsible for most of the delay (latency) introduced by a router.
Route caching is a technique that reduces this latency and frees up the main processor from having to handle too many interrupts. Once a packet is processed by the routing process, and an output interface is selected based on the packet's destination (layer 3) address, this address/output-interface pair can be saved in a cache and be used for quick processing of the subsequent packets with the same destination network address. Because both routing and switching tasks were performed on the first packet, it is considered to have been process-switched. The subsequent packets (with the same destination network address) need not be process-switched. Since the routing information built from the processing of the first packet is available in the routing cache, the subsequent packets are fast switched. The place where the route caching information is held varies from router to router, and it also depends on the option enabled.
Route Caching Methods and Commands
Route caching methods available in different Cisco router series and the commands to enable them are displayed in Table 4-10 (to disable any of these switching modes, use the no form of the command):
Table 4-10 Route Caching Methods and Commands
|
Interface Configuration Command (IP is shown as the protocol example) |
Route Caching (Switching) Method Enabled |
Cisco Router Series Support |
|
ip route-cache |
Fast switching |
All |
|
ip route-cache cbus |
Fast switching and autonomous switching |
7000 series with SP |
|
ip route-cache sse |
Silicon switching |
7000 series with SSP |
|
ip route-cache optimum |
Optimum switching |
7x00 series with RSP |
|
ip route-cache distributed |
Distributed |
7x00 series with VIP |
|
ip route-cache flow |
Netflow |
7x00 series with RSP |
|
ip route-cache flow ip route-cache distributed |
Distributed Netflow |
7x00 series with RSP and VIP |
Debug Notes
debug is a troubleshooting command 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 lets you discover significant facts about the working and faulty software and/or hardware components.
debug is available from the privileged exec mode (of Cisco IOS).
debug is treated as a very high priority task.
debug can consume a significant amount of resources.
The router is forced to process-switch the packets being debugged.
debug must not be used as a monitoring tool.
Use it for a short period of time and as a troubleshooting tool.
If you want 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 the protocol has a specific member that you may want to focus on. Once you decide what 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 will get a tremendous amount of information, very fast, but it can severely diminish the router's performance or even render it unusable.
Before starting to use 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.
Using an access list with your debug command helps you focus the debug output on the task you are troubleshooting. The syntax for using an access list with the debug command is:
Router# debug ip packet detail access-list-number
Logging Options
Table 4-11 shows logging options and their corresponding commands.
Table 4-11 Logging Options and Their Corresponding Commands
|
Command |
Usage Explanation |
|
logging console [level] |
This command turns console logging on and specifies the level of logging to be directed to the console. (The default setting is Enabled.) The no logging console command disables console logging. |
|
logging buffered [level] |
Use this command to enable sending logging messages to the internal buffer (use no logging buffered to disable it) and specify the level of logging desired to be buffered. This feature is enabled by default. |
|
logging monitor [level] |
Use this command to enable sending logging messages to the virtual terminal sessions (use no logging monitor to disable it) and specify the level of logging desired to be directed to the virtual terminal lines. From within a virtual terminal session, typing the command terminal monitor enables displaying of logging messages. The command terminal no monitor turns this feature off. |
|
logging trap [level] |
This command allows you to enable sending logging messages to syslog servers and specify the level of the these messages. The no logging trap command disables this feature. The default level is Informational. (See also the explanation for the logging [ip-address] command below) |
|
logging [ip-address] |
This command identifies the IP address of the syslog server so that the router can direct its logging messages to this address. If you have a list of syslog servers to which you want to send the logging messages, you may enter this command one time with each server's appropriate address. Use the no form of this command to take a server off the list. |
The following is a comparison of the overhead of different logging methods:
Buffered logging < Syslog < Virtual terminal < Console logging
Information Needed by Technical Support
General Information
Your company's name and service arrangement number
A statement of the problem
A brief history of the problem
A list of reported symptoms, how often the symptoms are observed, and the actions taken so far
Network diagram(s)
A list of protocols in use and policies in place
Outputs of the show version and show running-config commands
Crash Situations
show stacks
Core dump
Performance Degradation Situations
show interfaces
show buffers
show memory
show processes [cpu]
Loss of Functionality Situations
show protocol
show [protocol] route
show [protocol] traffic
show [protocol] interfaces
show [protocol] access-lists
Output of the show tech-support Command
show version
show running-config (in privileged exec mode)
show controllers
show stack
show interfaces
show processes mem
show processes cpu
show buffers
Terms and Concepts Related to Buffer and Queues
Buffer Sizes:
Small buffers: 104 Bytes
Middle buffers: 600 Bytes
Big buffers: 1524 Bytes
Very big buffers: 4520 Bytes
Large buffers: 5024 Bytes
Huge buffers: 18024 Bytes
Configuration Parameters:
Permanent—The minimum number of buffers allocated. Buffers are de-allocated (trimmed) at times, but the number of allocated buffers will not go below this.
Max-Free—When the number of buffers that are allocated but not used (free) reaches this value, a trim (de-allocation) is triggered. The memory is returned to the shared pool and can be used for other purposes.
Min-Free—As the allocated (free) buffers are used up, the number of free buffers is reduced. When the number of free buffers reduces to be equal to the Min-Free parameter, buffer allocation (create) is triggered. This attempts to always have a minimum number of allocated and unused buffers available for each packet size.
Initial—This parameter indicates how many buffers should be allocated (for a particular packet size) at the router initialization time. This value is usually larger than Permanent.
Reported Conditions
Ignored—The number of packets ignored is shown in the output of the show interfaces command. If a buffer (on the interface hardware) gets full, an ignore is registered. In other words, every time an interface cannot accept a frame due to the input buffer being full, the ignore counter is incremented by one.
Dropped—The number of dropped packets is shown in the output of the show interfaces command. If the input or output queue of an interface reaches its maximum size, the queue cannot grow larger and will start dropping the subsequent packets.
Misses—The number of misses is shown in the output of the show buffers command. The number of misses is incremented for each occurrence of a buffer not being allocated and free at the time a packet arrives.
Failures (no memory)—The number of failures is shown in the output of the show buffers command, and it indicates how many times the allocation of more buffers has been unsuccessful.