Modern switches are usually part of a large, possibly integrated network topology. As such, two different management techniques need to be established. First, administrators need to be able to view the complete network, taking a holistic approach to managing the environment. The second technique relates to managing individual switches.
For the first problem, Cisco designed the Cisco Cluster Management Suite, and all modern switches are enabled with the correct processes to support this centralized management. For the second problem, we have the regular range of show commands, supplemented by a process called debugging. Read on, MacDuff.
The Cisco Cluster Management Suite represents the smallest of the management options supplied by Cisco. Larger offerings fall into the CiscoWorks range of SNMP-based management programs.
CMS supports the management of up to 16 distributed switches. Access is via a standard browser interface, providing a web-based interface for managing the IOS commands on a Cisco switch. CMS is used as an alternative to connecting to the console or establishing a Telnet session to a switch and using the standard command-line interface (CLI).
The use of a standard browser plus the enhancements made possible by customization of the interface mean that this is a simple-to-use application. CMS provides a topology map to enable you to identify the switch that you wish to configure simply by looking at the diagram. Built- in applets include report creation and alarm monitoring. CMS supports all of the advanced features found on the CLI, including MLS forwarding options and QoS for voice and video.
Debugging may be new to you. It is available only on IOS-based switches, and there is no comparable feature in CatOS. Of course, debugging has been inside routers since time began, so those of you familiar with router IOS already know something about it. For those wanting to learn the complete story of debugging, I refer you to CCNP: Cisco Internetwork Troubleshooting Study Guide, 3rd ed., by Arthur Pfund and Todd Lammle (Sybex, 2004).
Debugging is the process whereby you can gather information about specific activities going on in the switch as they happen. Bearing in mind that debugging commands often have several extensions allowing greater granularity of capture, you must remember that the context-sensitive help provides the best guide to what debugging commands you can use.
Debugging is not free. Debugging takes place in the router processor at the heart of the switch, and uses system buffers to store debugging information. If you try to debug too much all at once, then you run the genuine risk of preventing the switch from functioning due to an overworked processor and overloaded memory. Debugging should therefore be used like a surgeon's scalpel, cutting finely into what you need to see. Don't use debugging like a club!
It is easy to forget precisely which debugging command you have entered, and therefore commands exist to disable all debugging activity. There are two choices; no debug all and undebug all work equally well.
Terry_2950#no debug all All possible debugging has been turned off Terry_2950#undebug all All possible debugging has been turned off Terry_2950#
Not too long ago, I was consulting for a large ISP, and we were working as a team making lots of changes to customer networks in the wee small hours of the morning. At one stage, one of the guys needed to debug some activity on the customer router, and he was a little worried about the effect. Because we had no time to run tests on the debug, I suggested that he set a reload timer on the router in question so that it would reboot in five minutes if everything went wrong. Well, things started off fine, but when he typed the undebug all command, he got a little confused and typed debug all instead.
The target router lasted about 30 seconds before it terminated his Telnet session and overloaded the memory and processor. Fortunately, it reloaded about two minutes later, and all was well. He bought the beers. The moral of this story is don't ever use the debug all command outside the lab or classroom!
In addition to the sophisticated debugging option, a huge variety of show commands are available to allow you to take snapshot views of everything from the configuration to information about the frame flow on an interface. In the absence of a photographic memory, the context- sensitive help is the first step in determining which command you need. This can best be demonstrated by using the show help command below.
Terry_3550#show ? access-expression List access expression access-lists List access lists accounting Accounting data for active sessions adjacency Adjacent nodes aliases Display alias commands arp ARP table auto Show Automation Template boot show boot attributes
One command you may wish to familiarize yourself with is the show processes command. In addition to providing an (almost indecipherable) list of the processes running, it provides a very valuable snapshot of the processor overhead. (The underlines are mine.)
Terry_3550#show processes ? cpu Show CPU use per process memory Show memory use per process | Output modifiers <cr> Terry_3550#show processes cpu CPU utilization for five seconds: 20%/20%; one minute: 16%; five minutes: 10% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 1 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 105887 0 0.00% 0.00% 0.00% 0 Load Meter 3 0 72 0 0.00% 0.00% 0.00% 0 SpanTree Helper 4 0 2 0 0.00% 0.00% 0.00% 0 IpSecMibTopN 5 106752 53797 1984 0.00% 0.01% 0.00% 0 Check heaps 6 4 477 8 0.00% 0.00% [output cut]
One additional module that can be implemented with the 6500 series switches is the Network Analysis Module (NAM), which constitutes an integrated traffic monitoring solution, enabling network managers to gain 'application-level visibility' into network traffic. The NAM supplies an embedded, web-based traffic analyzer, providing remote monitoring and troubleshooting through a browser. Main features include
Real-time and historical data gathering
QoS and VoIP monitoring