Guest

Cisco WAN Switching Modules

Field Notice: Firmware Caveat Results in Resets of UXMs, UXMEs and URMs


Revised February 13, 2002

February 1, 2002


Products Affected

Product

Comments

IGX-UXM

Loaded with Model A, Model B and Model C Firmware

IGX-UXME

Model B and Model C Firmware.

IGX-URM

Loaded with Model A Firmware

Problem Description

Due to an anomaly in Universal Switching Module (UXM) and Universal Switching Module-Enhanced (UXME) firmware, UXMs and UXMEs will reset and recover. The nature of the anomaly is that, if left undisturbed, the UXM or UXME will reset autonomously every 320 days. Each time the UXM or UXME resets, the timer will be restarted, and the next reset is not expected to occur for another 319 days.

The expected outage time will be 200 seconds where traffic through the UXM or UXME stops in addition to the reset period. The 200-second outage will occur regardless of redundancy. The reset period will vary as to whether or not redundancy is applied.

In rare instances, new activities involving the addition or deletion of connections do not execute correctly.

This anomally also applies to the IGX Universal Router Module (URM) since the URM shares the part of UXM/UXME firmware that causes this outage.

Background

A timer register variable is periodically incremented in the UXM, UXME, and URM. Every 320 days, this register overflows and causes an exception that blocks traffic, including switch software commands.

This problem is caused by firmware, not hardware or software. All currently released versions of UXM, UXME, and URM firmware share this anomaly. In all observed instances of this fault, the UXM, UXME or URM will recover automatically without user intervention.

Problem Symptoms

The symptoms of this anomaly include the following:

  • UXM, UXME or URM halts traffic for 200 seconds and then resets.

  • Depending on whether all the trunks in an IGX are on a single UXM or UXME, the IGX may become unreachable.

  • Network users may lose connectivity to remote applications and resources.

  • Voice connections may be interrupted or terminated.

  • A card error containing the string 0B 29 00 A9 01 0D 17 may be logged against the reset UXM, UXME or URM. Use the dspcderrs slot# command to observe this.

  • A software error 103 is logged in the software log. Use the dspswlog to observe this. In software releases prior to 9.1.24 only one 103 error will be logged per event. In 9.1.24 and later software, all 9.2 and all 9.3 software, ten 103 errors are logged per event.

It should be noted that during the 200-second outage, there is no alarm or trap that alerts users to a problem. The card reset produces the expected alarms and traps.

Workaround/Solution

Workaround

Network engineers are advised to reset each UXM, UXME, and URM in the network during a pre-scheduled maintenance window. This ensures that the UXM, UXME, or URM resets will restart the timers.

Until the firmware that resolves this anomaly is available, network engineers should reset each UXM, UXME, and URM in the network before the 320-day limit is reached again. Failure to follow this recommendation will result in indeterminate reset times which may have greater negative impact on the network than scheduled resets. In addition, proactively resetting the cards will avoid the 200-second outage.

Follow these procedures to reset the UXM, UXME, and URM. At the designated maintenance time, log in as SuperUser, Service or Cisco user.

  • For non-redundant UXMs or UXMEs, issue the resetcd UXM/UXME_slot_number h command.

  • For redundant UXMs or UXMEs, reset the standby UXM or UXME first and wait for it to return to standby mode, then reset the active UXM or UXME. As with non-redundant UXM/UXMEs, the command is resetcd UXM/UXME_slot_number h.

Note the time and date of each UXM or UXME reset and schedule the next reset prior to the expiration of the 320-day timer. This procedure should be followed until the firmware containing the resolution to this bug is available.

In order to facilitate the scheduling of the reset cards and to reduce off-hour staffing, the resetcd command may be run in a job. Refer to the appropriate switch software release Command Reference Manual for information on using the addjob command.

Some cards may not experience this problem, especially those cards that have been in a standby state for an extended period of time. It is still recommended that all potentially affected cards be reset on a regular basis until the solution below can be implemented.

Solution

UXM/UXME or URM firmware releases for both Model B and Model C with the fix for this bug will be released to Cisco.com. Monitor bug number CSCdw15969 for resolution.

Firmware Model

Revision to Fix this Issue

UXM/UXME firmware Model B

Revision A.B.R

UXM/UXME firmware Model C

Revision A.C.H

URM firmware

Revision X.B.C

IGX8400 Firmware and IGX8400 Firmware Release Notes may be downloaded from the Cisco Connection Online Software Center (registered customers only) .

DDTS

To follow the Cisco bug ID links and see detailed bug information, you must be a registered user and you must be logged in.

DDTS

Description

CSCdw15969

UXME CARD RESET CD ERRORS ONLY

CSCdt14885

uxm card resets, we see swerr 103 and or cderrs 0B 29 00 A9 01 0D 17

CSCdt12989

UXM Trunk failure

CSCdv83962

Swerr 103 occurred on UXM trunk card 320 days after reset

CSCdw16658

UXME card reset and leaves no card or swlog messages.

CSCdw16695

UXM-E card reset leaving only swlog messages.

For More Information

If you require further assistance, or if you have any further questions regarding this field notice, please contact the Cisco Systems Technical Assistance Center (TAC) by one of the following methods:

Receive Email Notification For New Field Notices

Product Alert Tool - Set up a profile to receive email updates about reliability, safety, network security, and end-of-sale issues for the Cisco products you specify.