Guest

Cisco WAN Switching Modules

Field Notice: *Expired* FN - 11791 - March 1 Clarification to Field Notice: Active or Standby UXMs or UXMEs Reset After Date Change to February 29


Revised July 27, 2007

March 1, 2000

NOTICE:

THIS FIELD NOTICE HAS BEEN ARCHIVED AND IS NO LONGER MAINTAINED OR UPDATED BY CISCO.

THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE, WARRANTY OR SUPPORT. USE OF THE INFORMATION ON THIS FIELD NOTICE OR MATERIALS LINKED FROM THIS FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.


Products Affected

IGX-UXM IGX-UXME

Problem Description

This field notice is a clarification and update of Field Notice: Active or Standby UXMs or UXMEs Reset After Date Change to February 29 and does not represent a new anomaly. This anomaly can occur only on Feb 29; therefore, there are no customers now at risk of experiencing this issue, including those customers who may have experienced this anomaly on February 29.

On February 29, some UXMs and UXMEs, which are used only on the IGX8400 series of wide area switches, reset. The reset affected customer traffic in some networks. This issue was present only at a small fraction of the installed customer base.

For customers who did experience the issue, please refer to the Workaround/Solution section below for clarification on appropriate next steps.

Note: The Field Notice: Active or Standby UXMs or UXMEs Reset After Date Change to February 29 sent on February 29 provided options for customer action intended to be taken on February 29. Now that February 29 has passed, there is no risk that the customer will experience incidences of this bug.

Background

The following is a description of the configuration which was at risk on February 29. Note that the configuration below is not at risk now due to the fact that February 29 has now passed in all theaters.

This anomaly was observed when the following conditions were met on February 29:

  1. The UXM or UXME has any Model B firmware release.

  2. The node date is February 29. This problem will not occur on any other date.

  3. An internal UXM asynchronous logging event occurs.

  4. Node is operating with switch software 9.1 or 9.2.

This issue is not specific to any hardware revision of the UXM or UXME. Model A firmware does not exhibit this anomaly.

The problem was triggered by an asynchronous internal logging event when the card date was February 29. If no asynchronous event occurred, then no problem was seen. Therefore, not all UXM cards were affected.

The following section explains why the resetting of affected UXMs after changing the network clock (as recommended in Field Notice: Active or Standby UXMs or UXMEs Reset After Date Change to February 29) was required on February 29, but is no longer needed:

The date is recorded on the card as well as the node. The card date is not updated immediately when an operator change is made to the network system clock. If the system clock was changed on February 29, there was still a potential for this problem to occur until the card date was updated. One method of forcing an update is a card reset.

For networks with system clocks that were changed on February 29, the system clock can now be updated to the correct local date and time, without the need to reset cards.

The following is a clarification of why disabling self-test as referred to in Field Notice: Active or Standby UXMs or UXMEs Reset After Date Change to February 29 is not detrimental to Y-redundancy:

As self-test completes on UXM cards in standby mode, an event may be logged which could trigger the anomaly (but only on February 29). Therefore, we recommend turing self-test off. Note that UXMs in Y-redundant standby are hot standby and do not run self-test. Turning off self-test does not disable the Y-redundant standby cards.

Problem Symptoms

The observable symptoms may include:

  • UXM cards reset themselves on February 29.

  • Software errors 121 and 103 (use the dspswlog command) and missing back cards are symptoms of this anomaly, but not necessarily indicators of this anomaly.

Workaround/Solution

If the customer did not experience this issue on February 29, then no immediate action is required. A firmware upgrade is recommended before February 29, 2004. The firmware upgrade will be available in the next release.

If the customer did experience this issue and changed the system dates, then the appropriate next step is to update the system date to the correct current date. Now that February 29 has passed, it is no longer necessary to reset cards after setting the correct date as specified in Field Notice: Active or Standby UXMs or UXMEs Reset After Date Change to February 29. A firmware upgrade is recommended before February 29, 2004. The firmware upgrade (same as above) will be available in the next release.

DDTS

This defect has Cisco bug ID CSCdp97100. If you are a registered CCO user and you have logged in, you can view the bug details.

DDTS

Description

CSCdp97100

UXM Cards failing and resetting themselves.

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.