Guest

Cisco WAN Switching Modules

Field Notice: *Expired* FN - 11751 - Active or Standby UXMs or UXMEs Reset After Date Change to February 29


Revised July 27, 2007
February 29, 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.



Note: Please also see the March 1 update to this document: Field Notice: March 1 Clarification to Field Notice: Active or Standby UXMs or UXMEs Reset After Date Change to February 29.

Products Affected

IGX-UXM
IGX-UXME  

Problem Description

On February 29, 2000, some UXMs and UXMEs, which are used only on the IGX8400 series of wide area switches, reset. This reset can interrupt user traffic if the UXM is in use. The expected probability of this anomaly occurring is very low and has been observed in a small fraction of the customer base.

Background



This anomaly has been observed when the following conditions are met:

  1. The UXM or UXME has any Model B firmware release.
  2. The node date is February 29.
  3. Certain node events such as trunk alarms or card resets occur.
  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.

Problem Symptoms

UXM cards reset themselves after date goes to February 29. Software errors 121 and 103 (use dspswlog) and missing back cards are symptoms of this anomaly, but not necessarily indicators of this anomaly.

Workaround/Solution



Workaround:

One proactive step may be taken depending on the customer's operational needs. The customer has the option of changing the network time or date such that all nodes in the network are set to a date and time after March 1.

The following steps should be taken only if the symptoms described above occur:

  1. Disable Selftest (cnftstparm).
  2. Set the network date to March 2 or later (cnfdate).
  3. Reset any affected UXMs or UXMEs in the network in order to synchronize the UXM or UXME clock to the network clock (resetcd UXM_slot_number h).
  4. After February 29, set the network date back to the correct date (cnfdate).

Note: Step 3 above may be applied to all UXM or UXME cards to prevent the symptom from occurring.

For networks equipped with Y-redundant UXMs or UXMEs, a graceful workaround may be accomplished by performing the following steps:

  1. Disable Selftest (cnftstparm).
  2. Set the network date to March 2 or later (cnfdate).
  3. Reset all Standby Y-redundant UXMs or UXMEs in the network (resetcd standby_UXM_slot_number h).
  4. Switch the Y-redundancy (resetcd active_uxm_slot_number h).
  5. Reset all UXMs or UXMEs that just transitioned to Standby from step 4.
  6. After February 29, set the network date back to the correct date (cnfdate).

For UXMs or UXMEs in standby, but not part of a Y-redunandant pair, a simple workaround is to down the card before February 29 (dncd UXM_slot_number) until after March 1 and up the UXM or UXME after March 1.

Solution:
The solution will be included in a new firmware release for the UXM and UXME. This firmware is to be released at a later date.  

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