This document discusses troubleshooting procedures, symptoms,
show commands, and diagnostics for the Cisco
Catalyst® 5000 family, which features five modular chassis: Catalyst 5000,
5002, 5505, 5509 and 5500 (13-slot chassis). The 2900/2926 series has six
non-modular or fixed-configuration switches: the 2901, 2902, 2926T, 2926F,
2926GS, and 2926GL, which are in the same switch family as the 5000/5500 series
and share the same architecture.

The goal of this document is to help Cisco customers identify and fix
some basic hardware issues or to perform more extensive troubleshooting prior
to contacting the Cisco Technical Assistance Center (TAC). Following an orderly
troubleshooting process by collecting specific diagnostics ensures that
information necessary to resolve the problem is not lost. Refining the scope of
the problem saves the customer valuable time in finding a solution.

Note: If the switch is connected to the network, do not reset or reseat
modules as a first troubleshooting step. In addition to the downtime users
experience, the internal buffer, which logs system messages, is erased and
potentially useful information regarding hardware or software errors is lost.
If the switch is offline, you have more freedom to monitor the LED status, and
then pull cables, reseat modules, or reset the switch as necessary.
Troubleshooting LED status is discussed in more detail later in this
document.

The information in this document is based on Catalyst 5000 series
switches, including Catalyst 2900/2926 series switches.

The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.

Many hardware problems encountered during field installations or during
normal operation could be prevented by a thorough product overview ahead of
time. For those customers not already familiar with general system and power
requirements, redundancy requirements, proper installation procedure, switch
management, and software considerations for these switches, we recommend that
you read the documentation below.

Cisco has a variety of troubleshooting tools and resources to help you
interpret switch output, determine hardware/software compatibility, track bugs,
and search Field Notices. The tools are available to
registered
users only and are mentioned throughout this document.

Software Advisor
(registered customers only)
—Determine which
features are found in a software release and get information about hardware and
software compatibility.

Output Interpreter
(registered customers only)
—Paste in the
output of a command and get the interpretation with relevant errors, warnings,
and status information.

Hardware failures in LANs are characterized by certain symptoms. These
symptoms might be general, such as the inability to make a Telnet connection
between switches, or more specific, such as link flapping or the switch
resetting itself. Each symptom can be traced to one or more causes by using
specific troubleshooting techniques. A systematic approach works best. Define
the specific symptoms, identify all potential problems that could cause the
symptoms, and eliminate each potential problem (from most likely to least
likely) until the symptoms disappear. The flowchart below illustrates the
General Problem-Solving Model.

Gather diagnostic and
show commands from the switch to isolate the scope
of the problem. If physical access to the equipment is possible, locate and
list any modules with red or yellow LEDs, disconnected cables, or loose
connections.

Consider possible problems based on the information you gathered.
Depending on the data, you might be able to eliminate hardware as a problem,
allowing you to focus on software problems. At every opportunity, try to narrow
the number of potential problems so that you can create an efficient plan of
action.

Create and implement an action plan based on the potential problems.
Focus on only one potential problem at a time. If you alter more than one
variable simultaneously, you might solve the problem, but it becomes far more
difficult to identify the specific change that eliminated the symptom. As a
result, what you learn will not help you solve the same problem if it occurs in
the future.

As described in the Problem Solving Model, the first step in resolving
a problem is to identify the symptom. Most problems with LANs fall into the
three general categories listed below, with various symptoms related to each
category.

Note: Some commands presented in this document are "hidden," meaning they
cannot be parsed with a "?" and you cannot press
Tab to complete. When a hidden command is suggested in this
document, simply gather the output and send it to the TAC engineer, if opening
a case. This output may or may not be useful in solving your case. These
commands are undocumented, so the TAC engineer is not required to explain the
output to the customer.

Connectivity problems occur when communication with the Supervisor, a
module, or hosts connected to the module is intermittent or has been lost.
Below are two tables that list common symptoms and commands associated with
connectivity. Click on the symptom for a list of steps and commands to help you
diagnose the problem. Click on the command for a description of the command and
sample output.

The following commands are supported by the Output Interpreter and can
be used to assist in troubleshooting connectivity problems:

show version

show module

show system

show port

show mac

show counters

show cdp neighbors
detail

If you have the output of the supported commands from your Cisco
device, you can use the
Output Interpreter
(registered customers only)
to display
potential issues and fixes. To use this tool, you must be logged in and have
JavaScript enabled.

Step 1—Verify that the link (port) LED status is
green. If it is solid orange, it has been disabled by the software. If it
blinks orange after Supervisor bootup and module initialization, there is a
hardware failure. If there is no link LED, check and swap cables. Verify the
operation of the end device and network interface card (NIC).

Verify that show
module status is "ok" for that module and not "disabled"
or "faulty."

If the status is "disabled," use the set module enable
mod command.

If the status is "faulty," establish a console connection to capture
bootup power-on self test (POST) diagnostics and any system error messages.
Reset the module with the reset
mod command. Determine if the
show test 0
command shows this module passed all of its diagnostic tests on
bootup.

Remove the module and inspect it for bent pins. Reseat the module,
firmly press down the ejector levers, and tighten the captive installation
screws. If the show
module status is still "faulty," try the module in another
slot. Slot 2 accepts line cards or a Supervisor Engine. If necessary, power the
switch off and then on. If the status is still "faulty," the module has
failed.

Note: A status of "connected" does not mean the ports are free of errors.
If there are errors on the ports, proceed to the Seeing Errors on the Ports section of this
document.

Step 4—Verify whether this device is on the
same or a different VLAN. Remember
that this is a Layer 2 device and a router is required to route between
VLANs.

Step 5—If connecting to another switch, what type of
port is being used? If it is a trunk port, what trunk encapsulations does it
support? Is the port capable of EtherChannel? Issue the
show port
capabilities command for a quick look at port
capabilities. For troubleshooting issues with trunking or EtherChannel, refer
to
LAN
Switching Technical Support.

If the end device is a Cisco router or switch, and Cisco Discovery
Protocol is enabled, issue the show cdp
neighbor detail command to identify the device, remote
interface type, and remote IP address.

Step 7—Swap cables. Move the cable to a different
port. Eliminate patch panels. Patch panels are a common source of connectivity
failures, so you should attempt to connect directly to the end device and
verify the operation of the end device.

The following table describes potential port statuses and
troubleshooting tips:

Status

Description and Troubleshooting Tips

connected

The port is operational and connected to the end device. A status
of "connected" does not mean the ports are error-free. If there are errors on
the ports, proceed to the Seeing Errors on the
Ports section of this document.

notconnect

Nothing is connected to the port. Check or swap cables and verify
the operation of the end device.

The show mac
mod/port
command shows the number of unicast, multicast, and broadcast frames
transmitted. Check to see if frames are being received and transmitted.

In-Discard shows frames that did not need to be switched. This is
normal if the port is connected to a hub and two devices are exchanging data.
Lrn-Discards indicates that Content Addressable Memory (CAM) entries are being
discarded. In-Lost/Out-Lost indicates port buffer overflows. For an explanation
of these errors and possible causes, refer to the Explanation of
CatOS Show MAC Counters table in
Troubleshooting
Switch Port and Interface Problems.

The show counters
mod/port
command is useful for troubleshooting "R" line cards. For example, the
following is an excerpt from the show counter output
of a 10/100BaseTX Ethernet line card (part number WS-X5225R):

5 badTxCRC = 0

If badTxCRC is incrementing, the problem
may be bad hardware corrupting packets. Capture the output and open a case with
TAC.

Step 4—Issue the show spantree summary
command for a quick check on how many ports are in each VLAN, whether any ports
on the switch are blocking, and which VLANs they are blocking for. Since
spanning tree loops can cause link flaps or actually bring down a switch or
network—giving the appearance of a hardware failure—this is vital information
to capture whether troubleshooting hardware or software. For troubleshooting
spanning tree issues, refer to
LAN
Switching Technical Support.

Step 1—Make sure you have speed and duplex configured
the same way on both sides of the link. Catalyst 5000 switchports are set to
auto by default. If, for example, both sides of a 100 BaseTX link autonegotiate
correctly, then you see the following result when you issue the
show port
mod/port
command:

Duplex Speed
------- -------
a-full a-100

If you hardcode both sides, you see the following result:

Duplex Speed
------- -------
full 100

Step 2—If there is an autonegotiation problem caused
by a speed/duplex mismatch or NIC incompatibility, errors show up on the ports.
Refer to the following documents for more information:

System, Supervisor, and module problems occur when either system status
(Sys-Status) LEDs indicate a problem, when the Supervisor or modules are not
recognized or show "faulty," or when users are experiencing poor performance.
Below are two tables that list common symptoms associated with system component
problems and the commands used to troubleshoot them. Click on a symptom for a
list of steps to help you diagnose the problem. Click on a command for a
description of the command and sample output.

The following commands are supported by the Output Interpreter and can
be used to assist in troubleshooting system, Supervisor, and module problems:
show version, show
module, and show system.

If you have the output of the supported commands from your Cisco
device, you can use the
Output Interpreter
(registered customers only)
to display
potential issues and fixes. To use this tool, you must be logged in and have
JavaScript enabled.

Capture the output of the show version and
show flash or dir
bootflash: commands, depending on the type of Supervisor you
have. Verify that you have enough DRAM and flash for the image you are trying
to upgrade to, and then perform the copy tftp
procedure.

The most common cause of a Catalyst 5000 Family Supervisor not being
recognized is that it is stuck in boot or ROMmon mode due to a missing or
corrupt image. In these modes, you cannot make a telnet connection to the
Supervisor and must open a console session.

Step 1—If you observe orange or red LEDs on startup,
wait until the system boots up completely before you conclude that there is a
problem. The Sys-Status LED on the Supervisor remains orange until bootup is
complete, and turns green if the bootup is successful.

Next, the Supervisor initializes the switching modules, which operate
differently depending on the module. Some flash on and off; others stay orange
until initialization is complete. At this point, the link (port) LEDs turn off
altogether until a signal is detected.

Fan assembly—The system fan assembly should operate
whenever system power is on. You should be able to hear the fan assembly to
determine if it is operating. The Fan LED on the Supervisor should be green. If
it is not, perform the following steps:

Determine if the fan status is "faulty" using the
show system
command.

Inspect the fan assembly and the power supplies, and verify that
power is being applied to the system.

Supervisor Engine—The Supervisor Engine contains the
system operating software, so check the Supervisor Engine if you have trouble
with the system software. The Sys-Status LED on the Supervisor Engine indicates
whether the Supervisor Engine has passed all diagnostic tests. Open a console
session and check whether or not the Supervisor is in boot or ROMmon mode. If
it is, refer to the Supervisor Is Not Online or Is Stuck
in Boot or ROMmon Mode section for troubleshooting steps.

Issue the show
system command to determine if the Sys-Status is "faulty."
Determine if the show test
0 command shows the Supervisor passed all diagnostic tests
as of the last bootup of the switch. Note any "F" results.

Inspect the fan assembly and power supplies for any
problems.

Open a console session and capture bootup POST diagnostics and
system error messages. Reset the Supervisor. If you have redundant Supervisors,
you can perform a reset x
command, where x is the active Supervisor experiencing
problems. This forces the standby Supervisor to become active. Then look at the
show test 0
command output to see if the Supervisors pass their diagnostic tests on bootup.
If you have only one Supervisor, enter reset and check the
command output of the show test
0 command to see if it passes its diagnostic test on
bootup.

Remove the Supervisor and inspect it for bent pins. Reseat the
Supervisor, firmly press down the ejector levers, and tighten the captive
installation screws. Wait for the Supervisor to initialize. If the
show system
command shows that the Sys-Status is still "faulty," try the Supervisor in
another slot. Only slots 1 and 2 accept Supervisor Engines. If necessary, power
the switch off and then on. If Sys-Status is still "faulty," the Supervisor has
failed.

Switching modules—The LED status on each switching
module indicates whether the switching module has been initialized correctly.
The Supervisor Engine must be operating properly for the switching module to
initialize. If a switching module is improperly installed in the switch, it
does not function.

Capture the output of the show version and
show module
commands. Determine if the software version you are running supports this
module. Consult the
Software Advisor
(registered customers only)
. Determine if the status is "faulty"
for that module. Determine if the show
test 0 command shows this module passed all of its
diagnostic tests as of the last bootup of the switch. Note any "F"
results.

Determine if the status says "disabled," because this indicates the
module was administratively disabled. The status LED is orange in this case.
Issue the set module enable
mod command.

Open a console session and capture bootup POST diagnostics and any
system error messages. Reset the module with the reset
modcommand. Determine if the
show test 0
command shows this module passed all of its diagnostic tests on
bootup.

Remove the module and inspect it for bent pins. Reseat the module,
firmly press down the ejector levers, and tighten the captive installation
screws. If the show
module command shows the status is still "faulty," try the
module in another slot. Slot 2 accepts line cards or a Supervisor Engine. If
necessary, power the switch off and then on. If the status is still "faulty,"
the module has failed.

Step 2—Issue the show version command
to check the software version you are using and the model number of the module
you are having problems with. Determine total DRAM and total flash. Use the
Software Advisor
(registered customers only)
to determine
hardware/software compatibility.

Poor performance is often perceived to be a hardware issue, but that is
usually not the case. When customers describe to the TAC that users on a
particular switch are experiencing slow performance, it often turns out to be
related to connectivity problems, software misconfiguration, or problems
elsewhere on the network.

Step 1—Identify whether performance issues are
occurring for users connected to all switching modules, one module in
particular, or just one or more ports. Capture the output from the
show module and
show test 0
commands. Make sure that the Supervisor and modules have an "ok" status. If
there is a "faulty" status, follow the troubleshooting steps for the Switching
Module under System Component LEDs Are Orange or
Red or Supervisor Is Not Online.

Step 3—Capture the output from the
show config and
show logging buffer
1023 commands. The show config command
shows only the non-default configuration changes. Ideally, every time you make
a change, you have backed up the configuration to use as a comparison. Issue
the show config
command to associate a configuration change with the behavior you are
experiencing.

Step 4—Many performance problems are related to
network traffic conditions. Capture the output of the
show system
command. Additionally, for a Catalyst 5500 with the Supervisor III Engine,
capture the output of the show
traffic command.

The show
system command has a Traffic field which indicates the
current backplane utilization, which is typically less than ten percent. If you
believe you are having performance-related issues on a particular switch, look
at the Peak field (the peak backplane utilization on the switch since it was
last booted) and note the timestamp indicated by Peak-Time. Keep in mind that
spikes in traffic percentage on the backplane could be a spanning tree loop or
broadcast storm. Refer to
Troubleshooting
Spanning-Tree Protocol and Related Design Considerations for more
information.

With a Catalyst 5500/Supervisor III, the Traffic field indicates the
current backplane utilization per bus and is typically less than ten percent.
Look at the Peak field and note the peak backplane utilization per bus since
the switch was last booted. Also note the timestamp indicated by Peak-Time.
Keep in mind that spikes in traffic percentage per bus could be a spanning tree
loop or a broadcast storm. Refer to
Troubleshooting
Spanning-Tree Protocol and Related Design Considerations for further
information.

If the current traffic percentage on a particular bus is greater than
30 percent—which is higher than it should normally be—you can issue the
whichbus
mod/port (hidden)
command to see which slots in the chassis belong to that bus. A module with
users experiencing performance issues could then be moved to a different bus to
see if this resolves the problem.

The tables below list the slot/bus assignments for the Catalyst 5000
Family. If the switch has a single bus, it is represented by the letter A. If
the switch has three buses, they are represented by A, B, and C.

1The Supervisor III Engine
is required to use all three of the 1.2 Gbps buses.

Slot Dependencies

All three 1.2-Gbps input buses in the Catalyst 5505 or Catalyst 5509
extend across all slots. For all of the Catalyst 5500 chassis, all line cards
except the Gigabit Ethernet modules and Supervisor III Engines plug into the
connector on the left-hand side of the chassis. This is the bus shown on the
left for each slot in the Backplane Bus Layout tables above. The Gigabit
Ethernet modules and Supervisor III Engines connect into all three buses
simultaneously. Therefore, on a Catalyst 5500 chassis, it makes sense to put
any Gigabit Ethernet modules into slots 2 to 5, because these slots possess all
three buses.

Catalyst 5500 Specific Dependencies

The last five slots (9 to 13) of a Catalyst 5500 chassis also contain
an ATM bus. Slot 13 is reserved for an ATM Switch Processor (ASP) or a
Multiservice Switch Route Processor (MSRP) of a Catalyst 8510. If you place an
ASP in slot 13, then slots 9 to 12 can hold LightStream 1010 CAMs/PAMs. If you
place an MSRP in slot 13, then slots 9 to 12 can hold Catalyst 8510 cards.

Note: You can still have regular line cards (such as Ethernet cards) in
slots 9 to 12 with an ASP or MSRP installed in slot 13.

Step 5—Capture the output of the
show process cpu
command. This command helps identify a process that may cause high CPU
utilization on the Supervisor.

A common misconception is the meaning of the process Kernel and Idle.
Below is an excerpt from the show
process cpu command.

Kernel and Idle indicates the amount of time the CPU has been idle.
Notice the value in the output is approximately 95 percent, which is a typical
idle time. This is because decisions about packet forwarding on a switch are
handled in the hardware, unlike a router where packet processing decisions are
made in the software.

Some processes, such as SNMP, can excessively poll the management
interface, causing a spike in CPU utilization. A high amount of Topology Change
Notifications (TCNs) can overwhelm the CPU with spanning tree BPDUs. To help
identify which process may be causing the problem, proceed as follows:

Issue the show process
cpu command during a time of normal activity for your
network, and then save the output.

Issue the command again if you experience any performance-related
issues.

Compare the two outputs. Is there a process you can identify that is
unusually high in comparison?

Issue the show process
cpu command multiple times and notice if there is a
significant increase or decrease in CPU utilization or spikes. Does the CPU
utilization remain consistently high?

The answer is most likely not a hardware problem, but a problem
elsewhere.

Step 6—One performance-related issue that results from
misconfiguration occurs when the inband channel, which is used for any control
traffic terminating on the switch (such as ping, Telnet, VTP, STP, or Cisco
Discovery Protocol), is not put in a separate VLAN from user data.

Cisco always recommends that the management or sc0 interface of the
switch be kept in a separate VLAN from user data. Otherwise, any broadcast or
multicast storm can flood the inband channel to the Network Management
Processor (NMP), which needs to be free to handle the protocols just
mentioned.

If you have not been able to track down any reason for performance
issues on the switch by following the steps mentioned previously, capture the
output of the following hidden commands, as well as the other commands in the
preceding steps, and open a case with the TAC.

show biga (Supervisor I and
II)

show inband (Supervisor
III)

show scp
stat

Step 7—Though rare, memory leaks may occasionally
occur, causing what seem to be issues of poor performance and other apparently
performance-related symptoms. If you have not been able to track down any
reason for performance issues on the switch by following the steps mentioned
previously, capture the output of the show mbuf all
command, as well as the other commands in the preceding steps, and open a case
with the TAC.

As mentioned in the Online Troubleshooting
Tools section of this document, Cisco has a suite of online diagnostic
tools to help you determine hardware and software compatibility, interpret
output, and decode errors. One of these tools is the
Error Message Decoder
(registered customers only)
. This tool can be used to
decipher the output of system messages that concern you.

Supervisor crashes occur when the switch has reset, is continually
resetting, or is down completely. Below are two tables that list common
symptoms and commands associated with Supervisor crashes. Click on the symptom
for a list of steps to help you diagnose the problem. Click on a command for a
description of the command and sample output.

The following commands are supported by the Output Interpreter and can
be used to assist in troubleshooting Supervisor crashes: show
version and show system.

If you have the output of the supported commands from your Cisco
device, you can use the
Output Interpreter
(registered customers only)
to display
potential issues and fixes. To use this tool, you must be logged in and have
JavaScript enabled.

The re-boot history indicates only that the switch was reset. It
could have been reset manually by the user or unintentionally by a crash.
However, the most recent manual reset of the switch is recorded further down in
the output.

Last software reset by user: 1/10/2002,21:13:16

Notice that the timestamp of the last manual reset
(1/10/2002,21:13:16) matches the most recent entry in the re-boot
history.

It shows whether there have been any exceptions. Exceptions are CPU
dumps that occur immediately after a crash.

Exceptions: 0

In the case above, there were no exceptions recorded. In the case of
an exception, it would include a timestamp that could be matched with the
re-boot history. It would also include a HEX dump or stack which could be
decoded by a TAC engineer to determine whether this was a software-forced
exception or one caused by hardware. Below is sample output of the
show log command when an exception is
recorded.

It shows other errors that may have caused the Supervisor to reset,
such as a power supply failure or a memory problem with DRAM, flash, or a
failed module.

The show
version command provides software version information to
use for a bug search. If you identify an exception using the show
log command, use the
Bug Toolkit
(registered customers only)
to search for bugs on the Catalyst 5000
and this exception or search on Catalyst 5000 and the software version you are
running. Also, the show
version command gives you a quick snapshot of how long the
switch has been up, as shown below.

Step 2—Try to use the show
commands and troubleshooting procedures in the preceding steps first. If these
steps fail, capture the command output from the show tech-support
command. This command continuously displays output for all of the commands
listed below. The output continues to scroll until complete, but you can end
the display by pressing Ctrl-C.

show version, show
flash, show microcode,
show system, show module,
show port, show mac,
show trunk, show vlan,
show vtp domain, show spantree
active, show spantree summary,
show test, show arp,
show ip route, show cdp neighbor
detail, show netstat stats,
show memory buffers, show out-of-band
stats, show inband stats,
show cam static, show cam count
dynamic, show cam system,
show config, show log,
show process, show process
memory, show process cpu,
ps, ps -c

Often the output from all of these commands is not necessary to resolve
a specific problem, so TAC engineers usually do not ask for it. However, it is
good output to have in case other show commands or
troubleshooting procedures fail to resolve the problem.

Step 3—If all of the previous troubleshooting steps
fail to diagnose the problem, capture the output of the following hidden
commands, as well as the other commands listed in the preceding steps, and open
a case with the TAC.

This command can be especially useful for situations in which customers
with Supervisors I and II are upgrading from 2.x to 3.x versions, where there
was a change in the way flash was formatted. It is also useful for situations
in which Boot ROM upgrades may be required, as is the case when installing a
Supervisor II or III in a Catalyst 5509. Please refer to
Upgrading
the Catalyst 5000 Supervisor II and III Boot ROMs for further
information.

This command displays the contents of the flash file system. Flash file
systems differ among Catalyst Supervisors. Some Supervisors use
show flash to display the contents, while others use
dir bootflash:. When you copy an image to the
Supervisor IIIG, for instance, you issue the
download command and flash is completely erased in
the process of installing the image. With other Supervisors, you can issue the
copy tftp flash command to add one or more
images.

This command displays the non-default system configuration. This is
useful to capture every time you make a configuration change as a way to
possibly associate changes to hardware or software problems. Notice there is a
timestamp for each output. Compare the output to show config
all, which shows the entire system configuration and can be
lengthy.

This command displays the results of diagnostic tests for the
Supervisor and all modules. The show test command
only displays the results of diagnostics on the last bootup of the switch or a
reset of the Supervisor or modules.

If you are running version 5.4.1 or later, check the status of the
diaglevel with the show test diaglevel command. A
status of "complete," which tests the Enhanced Address Recognition Logic (EARL)
cards, port loopback/bundle/inline rewrite, and DRAM/NVRAM/External cache is
recommended. This test takes a minute as compared to 30 seconds for a test
level of "minimal," however it is more thorough. Results are output with a "."
for Pass or "F" for Fail, indicating a hardware failure.

This command displays system information. The status fields relate to
the various LEDs for system components on the Supervisor front panel. One
common customer issue occurs when the System LED shows faulty after a second
power supply is added but not powered up. In this case, PS2-Status and
Sys-Status both say faulty, since the switch senses a power supply is
installed, but not active. Because this could also mean that the second power
supply has actually failed, an on-site inspection is required. Take note of the
uptime (how long the switch has been up and running). This is useful
information to know in the event of a switch crash.

This command displays the day of the week, month, and year, as well as
the time in 24-hour format. This output verifies the operation of the system
clock and serves as a reminder that system log messages carry a timestamp. Make
sure to set the time accurately or sync the switch to Network Time Protocol
(NTP) (refer to
Catalyst
5000 Series Switches—Configuring NTP).

This command displays system messages from the internal buffer. The
show logging buffer command alone gives you only the
last 20 system messages, while adding the 1023 keyword gives you the last 1023
messages. Many of these messages are strictly informational. Others may contain
clues as to the nature of the problem, whether it is a hardware problem, a
switch crash, or a software problem.

This command displays the capabilities of the modules and ports in a
switch. This command is a quick way to display hardware and software features
without having to search the Release Notes for the trunk encapsulation types
supported and the port EtherChannel capabilities.

This command displays the MAC counters and is useful in determining
whether counters are incrementing as expected. This command also shows the
total unicast, multicast, and broadcast frames received on a port. The
In-Lost/Out-Lost counters indicate that port buffers are overflowing. Refer to
Seeing Errors on the Ports for
troubleshooting steps.

Below is an example of the show mac
mod/port command.
Refer to the
Command
Reference for more information on the
show
mac command.

This command displays hardware counters for the port and varies
depending on the type of port. In the WS-X5225R 10/100 card below, look at
counter 5, badTxCRC = 0. If this counter
incremented, it indicates a hardware failure. Refer to
Seeing Errors on the Ports for
troubleshooting steps.

Below is an example of the show counters
mod/port command.
Refer to the
Command
Reference for more information on the
show
counters command and a description of these
counters.

This command displays the error log for the system or a specific
module. If there has been a switch reset or crash, the stack information
necessary to determine the cause of the switch crash is displayed here.

This command continuously displays output for all of the commands
listed below, meaning the output continues to scroll until complete. You can
end the display by pressing Ctrl-C.

show version, show
flash, show microcode,
show system, show module,
show port, show mac,
show trunk, show vlan,
show vtp domain, show spantree
active, show spantree summary,
show test, show arp,
show ip route, show cdp neighbor
detail, show netstat stats,
show memory buffers, show out-of-band
stats, show inband stats,
show cam static, show cam count
dynamic, show cam system,
show config, show log,
show process, show process
memory, show process cpu,
ps, ps -c