Field Notice: burnfwrev Command on Y-Redundant BXMs Can Cause Node Aborts

April 21, 1998

---

Products Affected

• Y-redundant BXM-622 trunk cards at firmware (FW) revision M.B.V or earlier

• Y-redundant BXM-155 trunk cards at FW revision M.B.V or earlier

• Y-redundant BXM-T3/E3 trunk cards at FW revision M.B.V or earlier

Problem Description

• Use of the command burnfwrev to burn multiple cards configured as Y-redundant can cause excessive control traffic to be generated, which can lead to multiple node aborts.

• Use of the commands dncd, failcd and resetcd in a specific sequence to a Y-redundant pair can cause excessive control traffic to be generated, which can lead to multiple node aborts.

Background

These two cases show conditions that must be present for this problem to occur:

Case 1

1. Two BXM trunk cards must be configured as Y-cable (hot standby) redundant.

2. The standby BXM trunk card must run FW revision M.B.V or earlier, and one of these command sequences must be issued:

• burnfwrev active_slot standby_slot

• burnfwrev active_slot , followed within 30 seconds by burnfwrev standby_slot

Case 2

1. Two BXM trunk cards must be configured as Y-cable (hot standby) redundant.

2. The active BXM trunk card must run FW revision M.B.V or earlier, and these command sequences must be issued:

• resetcd standby_slot ¹, followed within 30 seconds by:

• dncd active_slot ²

  ¹ Or anything that causes the standby card to reset (for example, hardware failure or setnovram).

  ² Or anything that causes the active card to go down (for example, hardware failure or failcd).

In these circumstances, control cells can accumulate in a loop internal to the switch. Each time a control cell circulates in the loop, a copy is sent onto the trunk. The control cells are effectively transmitted on the trunk at line rate and can cause other nodes in the network to abort.

Solutions

Immediate Solution #1

For in-service Y-redundant BXM cards, use this procedure to upgrade to FW revision M.B.W:

1. delyred

2. Upgrade FW on standby (the first card).

3. addyred

4. Wait for standby to be completely updated (approximately 5 minutes.)

5. Reset the active card to force a switch (resetcd n h, where n is the card to reset).

6. Upgrade FW on standby (the second card).

Immediate Solution #2

Where it is operationally feasible, a simpler approach is to take the BXM cards out of service and upgrade them to FW revision M.B.W.

Long-Term Solution

Switch software is in the process of enhancement to prevent this type of occurrence from causing node aborts. The versions of switch software for enhancement are given in this table:

8.4.X	8.5.X	9.1.X
8.4.21 or later	8.5.07 or later	9.1.00 or later

Once the cards are at M.B.W, or greater, or the node runs the enhanced software (above), there is no vulnerability and no further requirement to follow the special procedures detailed in the section Immediate Solution #1.

The normal upgrade procedure for a noncontrol card is documented in the document Upgrading Firmware for Non-Control Cards.

If you are a registered user, you can log in to the Cisco corporate FTP site and obtain the software images. Direct your browser to (with the 8.4.21 image as an example):

ftp://username@ftp.cisco.com/cisco/wan/system/8421/...

Replace username with your Cisco.com login.

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:

• Open a service request on Cisco.com
• By email
• By telephone

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.

---