Valuable time and resources are often wasted replacing hardware that
actually functions properly. This document helps troubleshoot potential
hardware issues with Cisco 2600 series routers, and can help you identify which
component may be causing a hardware failure, depending on the type of error
that the router is experiencing.

Note: This document does not cover any software-related failures except for
those that are often mistaken as hardware issues.

Whenever you install a new card, module or Cisco IOS® software image,
it is important to verify that the router has enough memory, and that the
hardware and software are compatible with the features you wish to use.

Perform the following recommended steps to check for hardware-software
compatibility and memory requirements:

Tip: If you want to keep the same features as the version that is
currently running on your router, but don't know which feature set you are
using, enter the show version command from your
Cisco device, and paste it in the Output Interpreter Tool. You can use the
Output Interpreter
(registered customers only)
to display
potential issues and fixes. To use the
Output
Interpreter
(registered customers only)
, you must be logged in and have JavaScript enabled.

Tip: If your 2600 doesn't have a connection to the network or does not
have a valid Cisco IOS software image, you may need to use the console port of
the router to perform an
Xmodem
Console Download Procedure Using ROMmon. This procedure does not require
the use of a Trivial File Transfer Protocol (TFTP) server.

Some error messages are informational only, while others indicate
hardware or software failures and require action. The Error Message Decoder
Tool provides an explanation of the message, a recommended action (if needed),
and if available, a link to a document that provides extensive troubleshooting
information about that error message.

show technical-support command output -
The show technical-support command is a compilation
of many different commands including show version,
show running-config, and show
stacks. TAC engineers usually ask for this information to
troubleshoot hardware issues. It is important to collect the show
technical-support information before doing a reload or
power-cycle as these actions can cause all information about the problem to be
lost.

Complete bootup sequence if the router experiences boot errors.

If you have the output of a show command
from your Cisco device (including show
technical-support), you can use the
Output
Interpreter
(registered customers only)
to display potential issues and fixes. To use the
Output
Interpreter
(registered customers only)
, you must be logged in and have JavaScript enabled.

A 2600 Series Router may experience a router hang. A hang is when the
router boots to a certain point and then no longer accepts any commands or
keystrokes. In other words, the console screen hangs after a certain point.
Hangs are not necessarily hardware issues and most of the time, they are a
software issue. If your router is experiencing a router hang, refer to
Troubleshooting
Router Hangs.

When the router reboots, it returns to a normal state. A "normal state"
means that the router is functional, passing traffic, and that you are able to
gain access to the router. To check why the router rebooted, issue the
show version command and look at the output (see
example below):

Router# show version
Router uptime is 20 weeks, 5 days, 33 minutes
System returned to ROM by power-on

When we refer to a "system crash", we mean a situation where the system
has detected an unrecoverable error and has restarted itself. A crash can be
caused by software problems, hardware problems, or both. This section deals
with hardware-caused crashes and crashes that are software-related, but may be
mistaken for hardware problems.

IMPORTANT: If the router is reloaded after the crash
(for example, through a power-cycle or the reload
command), important information about the crash will be lost, so try to collect
show technical-support and show
log output, as well as the crashinfo file (if possible) before
reloading the router!

The system encounters a bus error when the processor tries to access a
memory location that either does not exist (a software error) or does not
respond properly (a hardware problem). A bus error can be identified by looking
at the output of the show version command provided
by the router (if not power-cycled or manually reloaded).

The router may experience a continuous loop that could be due to a
hardware issue. A continuous loop never lets you gain access to the router (for
example, you won't be able to log in to enable mode, and so on), and the router
continues to give scrolling error messages until it is powered off. Below are
examples and troubleshooting steps to determine which piece of hardware is
causing the continuous loop.

**If the router does not experience the continuous loop after following
the troubleshooting steps above, then the problem may have been caused by a
mis-seated network module. It is recommended that you monitor the router for 24
hours to be sure that the router continues to function without experiencing the
issue again.

When booting, a router may detect that a Cisco IOS software image is
corrupt, return the "compressed image checksum is incorrect" message and
attempt to reload, reporting the event as a software-forced crash:

This behavior can then repeat indefinitely, or the router may drop to
the ROM monitor.

This can be caused by a Cisco IOS software image that has actually been
corrupted during transfer to the router, in which case it can be resolved by
loading a new image onto the router. Use
Cisco
Search to find a ROMmon recovery method for your platform.

Cisco processors have timers that guard against certain types of system
hangs. The CPU periodically resets a watchdog timer. The watchdog timer
basically controls the time of each process. If the timer is not reset, a trap
occurs. If a process is longer than it should be, the watchdog timer is used to
escape from this process.

There are two main types of watchdog timeouts. The first type is
usually caused by a software problem and is reported in one or both of these
ways:

The show version command output shows:

"System returned to ROM by bus error at PC 0x602DADE0, address 0x480811"
- or -
"System returned to ROM by error - a Software forced crash, PC 0x60435894"

The console logs show:

%SYS-2-WATCHDOG: Process aborted on watchdog timeout

The second type of watchdog timeout is usually due to a hardware
problem and is reported in one or both of these two ways:

The show version command output shows:

Router uptime is 17 minutes
System returned to ROM by watchdog timer expired
System image file is "flash:c3640-is-mz.122-3.bin"

Capturing information from the console of the router is essential for
troubleshooting a router that does not boot. The console output should be
logged in a file for later analysis or for the Cisco Technical Assistance
Center (TAC) if a TAC case is opened. Compare the following symptoms and
recommended actions to take if you are encountering boot problems:

No LEDs on after powerup

Check whether the power cord is plugged in firmly and the power supply
is good. If that does not resolve the issue, replace the power cord. If the
problem persists, replace the router.

Verify that the baud rate is set to 9600 bps. If that doesn't help,
verify that the equipment used for connecting to the console is operating
properly. You can do this by connecting to a known good router to check your
console equipment. If the equipment is successfully tested, but the problem
remains, replace the router.

These mean that either the Flash is empty or the filesystem is
corrupted.

To resolve this, copy a valid image onto the Flash. While copying, you
will be prompted to erase the old contents of Flash (if any). Then reload the
router. Refer to
ROMmon
Recovery for the Cisco 2600 Series Router for instructions on how to
copy a valid image into Flash.

If installing a new image fails to resolve the problem, you can try
swapping out the memory. If replacing the Flash and DRAM fails to resolve the
problem, there is a chance that the memory slot on the chassis is faulty; you
need to use the
TAC Service Request Tool
(registered customers only)
to create a service request
in order to resolve the hardware issue.

An exception to this is when CRC and frame errors are found on
channelized interfaces; these can also indicate clocking problems. The fault
that is causing the errors can be anywhere between two connected interfaces -
on cables, intermediate devices, or on interfaces themselves. Troubleshooting
techniques differ slightly for different interface types.

For Ethernet interfaces, troubleshooting differs between a shared
environment (devices connected through a hub or with a coaxial cable) and a
switched environment (devices connected to a switch).

In a switched environment, there are only five components that could
cause the error:

cable

local interface (port)

remote interface (port)

speed

duplex mismatch

Consequently, the troubleshooting steps are simple. For example, if a
router is connected to a switch, the troubleshooting steps would be:

Replace the cable.

If this does not solve the problem, try another port on the switch.

If the problem persists, replace the Ethernet interface.

In a shared environment, the source of the problem is a lot harder to
find. Every piece of hardware that makes up the shared segment can be the
cause. All components (cables, connectors, and so on) have to be tested one by
one.

If "ignores" are present on all interfaces, then the router is probably
overloaded with traffic, or doesn't have sufficient free buffers in the pool
that match the maximum transmission unit (MTU) on interfaces. In the latter
case, an increment of the ignored counter is followed by an increment of the no
buffer counter:

The number of preconfigured permanent, free, and maximum allowed
buffers may not be completely compatible for every environment. You can read
more about this and how to avoid it in
Buffer
Tuning.

If "ignores" are only increasing on one interface and are not followed
by an increment of the no buffer counter, and the interface is not heavily
loaded, then this interface could be faulty. In that case, capture the output
of the show tech-support command and contact the
TAC. The load on the interface can be viewed in the output of the
show interfaces command:

Input queue drops are never caused by hardware problems. Output queue
drops may be caused by a hardware problem only if the output queue is
constantly full and no packets are being sent out of the interface. You can
read more about these kinds of drops in
Troubleshooting
Input Queue Drops and Output Queue Drops.

If you have identified a component that needs to be replaced,
contact your Cisco partner or reseller to request a replacement for the
hardware component that is causing the issue. If you have a support contract
directly with Cisco, use the
TAC Service Request Tool
(registered customers only)
to open a TAC Service
Request for a hardware replacement. Make sure you attach the following
information:

Console captures showing the error messages

Console captures showing the troubleshooting steps taken and
the boot sequence during each step

The hardware component that failed and the serial number for
the chassis