Bugs Fixed in MFD
Bugs Fixed in MFC
Bugs Fixed in MFB
Bugs Fixed in MFA
Bugs Fixed in MEC
Logic to calculate actual cell transmission rate in a BXM card is as follows (CSCdm94372):
Bugs Fixed in MEB
Bugs Fixed in release MEA
Bugs Fixed in release MDA
Firmware Filenames and Sizes
Appendix B UXM ABL Firmware Release Notes

New Features
Obsolete Features
Compatibility
Bugs Fixed in this Release
Upgrade Instructions
Notes and Cautions
Boot Code Requirements

Obtaining Service and Support
Cisco Connection Online

9.2.41 Version Software Release Notes Cisco WAN Switching System Software

---

About These Release Notes

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

About the 9.2 Release

The 9.2 software release supports the Cisco WAN switching products, BPX 8600 series, and IGX 8400 series. This release does not support the IPX switch.

Phased Release Strategy

The MSSBU rollout plans for the 9.2 release is based upon a series of incremental feature releases. This phased feature release strategy is designed to allow the earliest customer availability of key new features, consistent with maintaining high product quality. For the latest status of each 9.2 feature, please see below.

The minimum release version noted in the table below represents the minimum switch software version required for each feature. As usual, it is recommended that customers use the most current maintenance releases.

Definitions

Generally Available (GA)—Feature is ready for wide deployment with no restrictions. Customers deploying GA features are supported by the Technical Assistance Center (TAC).

First Customer Ship (FCS)—Feature is available for controlled introduction by selected customers. To trial use an FCS feature, please contact your account representative.

Customers selected for controlled introduction will receive assistance with test plan review and special support from the New Product Team (NPT) in addition to the normal Technical Assistance Center (TAC) support.

Pre-First Customer Ship (Pre-FCS)—Feature is not yet available in the Switch Software baseline.

Target Date—This is the date for feature delivery that is supported by current Engineering and Marketing plans. This date is subject to change.

Software Release 9.2.41

This is a maintenance release including all features supported up to Release 9.2.30. The following files will be extracted from a TAR file upon upgrading to Software Release 9.2.41.

Software Release 9.2.31, 9.2.32, 9.2.33, 9.2.34, 9.2.35, 9.2.36, 9.2.37, 9.2.38, 9.2.40

This is a maintenance release including all features supported up to Release 9.2.30.

Software Release 9.2.30

Includes all features supported up to Release 9.2.20 and introduces the following additional features:

Software Release 9.2.23, 9.2.22, and 9.2.21

Includes all features supported up to Release 9.2.20.

Software Release 9.2.20

Includes all features supported up to Release 9.2.10 and introduces the following additional features:

Software Release 9.2.10

Includes all features supported up to Release 9.2.01 and introduces the following additional features:

Software Release 9.2.01

Includes all features supported in Release 9.2.00 and introducing the following additional features:

Software Release 9.2.00

Introduces the following features:

Clarifications

1. The fix for CSCdu50924 has changed the behavior of SWSW with respect to CM parameters 9 (Reroute Timer) and 10 (Reset Timer on Line Fail). Derouted connections will now be eligible for routing immediately, irrespective of the values of CM parameters 9 and 10 and the time of the last reroute. This also means that CM parameter 10 is effectively obsolete.

Previously, if CM parameter 9 was set to a value greater than 0 and CM parameter 10 was set to No, a connection would not be eligible for routing until the time specified by CM parameter 10 had passed since its last reroute. This was true even if the connection was derouted and a route was available. Therefore, the goal of the fix to CSCdu50924 is to get derouted connections routed as soon as possible.

2. Release 9.2.31 introduced a new command—cnffdrlmiparms—which makes the feeder LMI timers and counters configurable. This command is currently supported on BPX only and cannot be added in the Job mode.

Usage: cnffdrlmiparms slot.port T393 T394 T396 N394 N395

where slot.port specifies the feeder trunk to configure. The details of the other parameters are as follows:

3. In Release 9.2.31 the system parameter 2 (cnfsysparm 2) is changed from "Fail Connections On Communication Break" to "Allow CPU Starvation of Fail Handler."

The old parameter has been removed as it violated the principle of the separating control and data plane. The new parameter allows a new feature to be turned off, which gives CPU to the Fail Handler at the expense of the Transaction Handler in case the Fail Handler does not get scheduled for a long time.

4. Do not mix MEE and MEF (or higher) in Y-red pairs for BXM 2-port group enhanced cards (OC-3 or OC-12 port). addyred will fail if both are in standby mode, or the primary card has been activated with MEF (or higher) and the secondary card has MEE.

5. For the BXM 2-port group, enhanced cards activated with MEF or higher, downrev to MEE will bring the cards into MISMATCH mode. This applies to both single cards and Y-red pairs.

6. Release 9.2.30 introduced four new commands in BPX:

7. There are changes in the following commands starting from Release 9.2.30:

8. The multiple partitions introduce two VSI partitions on trunk and port interfaces on the BXM card. One partition can be used for MPLS, and one can be used for PNNI. Virtual Trunk can have only one VSI partition or can be used for AutoRoute, but cannot be used for both VSI and AutoRoute simultaneously. This project introduces six service class templates in addition to the three existing templates.

Even though tag ABR is supported in Service Class Template (SCT), neither the MPLS controller nor the BXM firmware currently support this.

The configurable VPI/VCI introduces 2 new parameters in addctrlr and addshelf commands, through which the user can specify the VPI and VCI of the master-slave control channels.

9. There is a change in reporting of port group numbers in Release 9.2.32. Previous image (MEC) of BXM used to report a 1-port group for the 2-port group cards at the channel statistics level 2 and 3. This made the port belonging to second port group unusable.

For enhanced BXM cards, upgrade to 9.2.30 software first and then burn the BXM card with the MEE or higher firmware, BXM will report 2-port groups for 2-port cards all the time. The smooth transition between the earlier 1-port group and the newly reported 2-port groups also displays the message in dspcd "Inconsistency with logical PG #" (port group number). All earlier software will "mismatch" the card.

If the BXM card is programmed with MEC or earlier firmware revision, the channel statistics for level 2 or 3 will report 1-port group for enhanced BXM cards. Burning an MEE or higher image will result in 2-port groups, but for backwards compatibility the software will not do the recomputation of LCNs based on the new port groups. In its logical database, this will not impact the AutoRoute connections.

For VSI controllers the reported value will be higher than the actual available LCNs. That means a VSI controller may not be able to add connection even though the available connections are non-zero. If the user wishes to remove the above discrepancy, the card must be brought to the standby mode.

Note that the newly configured card or the card in standby mode programmed with MEE or higher image brought to the active state will not have above discrepancy.

10. In BPX nodes that use processor cards with 32 MB of RAM, it is possible to run out of memory in the Hitless Region. This can happen if the node is too heavily configured with cards and connections. The recommendation below should prevent memory aborts.

In nodes that have processor cards with 64 MB of RAM, there should be no Hitless Region memory problem. This is because 64 MB processors contain a second Hitless Region, which is larger than the first.

The following calculation will help prevent memory aborts on BPX processors with 32 MB. For simplicity, the numbers are approximate. It is necessary to add up the number of cards in the node, as well as the number of connections, and make sure that the total does not exceed the recommendation.

During system initialization, roughly 17,100 blocks of the available 40,000 are used for the card database.

In addition, assume that 1500 blocks will be needed for each BXM card that can support 16K connections, which is the more common configuration. Some BXM cards can support 32K connections, and these will need 3000 blocks of the Hitless Region. This chunk of memory is allocated at the insertion of the BXM card and will not be released until a card of different type is inserted.

Also, 300 blocks will be needed for each 1000 via connections on the node. This can be viewed with the user command dspload.

11. The minimum software required to run MPLS are:

The BPX with an external 7x00 label switch controller (router) with Switch Software Release 9.2.10 and IOS Release 12.0(5)T can function as an ATM-LSR. The enhancements to dynamic label switching that was supported in Release 9.1 include support for MPLS Class of Service. The BPX as an ATM-LSR supports the "Multi-Label VC" model to support MPLS Class of Service. Five Qbins (Qbin 10-14) are reserved for MPLS Class of Service. Class-based WFQ is supported on these IP queues.

The BPX can also function as a "P" ATM-LSR in the MPLS-VPN architecture.

Hot redundancy of MPLS connections on the BPX is supported by BXM hot card redundancy. Continuous message forwarding, and keep-alive between the BXM redundant pair ensures the connection continuity on BXM switchover. On failure of a BXM card, the standby card becomes active with the label VCs. Resynchronization between the MPLS label switch controller and the BPX ensures that their databases are in sync.

12. The 16K connections feature increases the number of connections terminating on the BPX switch to 16,000. The count includes connections terminating on BXM or ASI endpoints on cards within the node as well as connections terminating on service modules in the feeder shelves connected to the BPX switch. For example, a Frame Relay connection that originates on an FRSM in an MGX 8220 connected to a BPX counts as one of the 16,000 terminated connections on that BPX.

This feature requires a BCC-3-64 or BCC-4 controller in the BPX as well as Switch Software 9.2.10 or higher.

13. Version 2.2 of the Virtual Switch Interface (VSI) provides the BPX switch with the ability to support multiple network protocols and multiple controllers per switch (for example, MPLS, PNNI, and so on). Switch resources can be dedicated to a specific controller or shared by multiple controllers.

This feature is supported on BXM ports, trunks, and virtual trunks and requires a BCC-3-64 or BCC-4 controller in the BPX as well as Switch Software 9.2.10 or higher and firmware MEA or higher.

Following are the VSI features:

14. The combinations of system limits such as the number of trunks, lines, ports, and connections as well as enabled TFTP interval statistics should be provisioned so that the node has at least 50 percent idle time usage. Use the command dspprfhist to verify.

15. When cost-based routing is used, increasing the cost of a trunk will result in deleting the preferred path on connections in the database if the sum of the preferred path cost exceeds the connection of configured cost. The connections will remain routed on its current path.

16. On the BXM and UXM, for the OC-3 MultiMode Fiber back cards, Y-Redundancy/hot standby is not supported due to hardware restrictions.

17. The trunk reconfiguration feature does not support IMA trunks.

18. An LCN Resynchronization feature was developed to maintain consistency between NPM and UXM connection databases when a switchcc occurs. IGX Software release 9.2.37 or later and UXM firmware Release ABK or later are required to implement this feature.

Special Installation/Upgrade Requirements

General/Upgrade Procedure

Please consult your Support Representative before performing any software upgrade.

1. The earliest release supported for graceful upgrade is 9.1.03.

2. The 9.2 switch software requires a minimum of MED firmware for BXM Model E non-enhanced cards; MEE is the minimum required firmware for enhanced BXM cards.

3. Before upgrading to this release when UXM cards are to be used, certain legacy card firmware must be upgraded. See the compatibility matrix for cards affected and the exact versions to be used.

---

Note   Standards-compliant IMA is not compatible with the proprietary IMA protocol used in revision A firmware. Both ends of an IMA trunk must have the same protocol.

---

---

Caution   Failure to follow this procedure may result in the card not operating. The card should be returned to Cisco if this occurs:

---

---

Step 1   Verify current boot code version

In order to run Model B firmware on UXM, the card needs to be running boot code revision 6 or greater. To determine the boot code running on the card, issue the following command from CLI (user must be logged in as Service level or greater to use this command):

Step 2   Upgrade UXM's boot code if necessary

The process for loading boot code is identical to the process you would use to load firmware. The only part that changes is the name of the file.

---

Note   Burning the boot code will cause the card to reset.

---

Step 3   Upgrade UXM's firmware

Step 4   When Y-redundant trunks are used, the red alarm in/out values must be configured to 1.25/1.5 seconds or greater, or else INVMUX failures will occur and trunk failures will be observed during a Y-redundancy switchover. Use the following command:

This is due to the IMA protocol and may cause reroute of connections.

Step 5   Upgrade NPM software to 9.2

---

4. Procedure for upgrading UXM-to-IMATM trunks from proprietary IMA protocol to ATM forum-compliant IMA protocol.

---

Step 1   Download and burn UXM bootcode version 6 or later to all UXMs in the network. This will cause the card to reset and reroute traffic to other trunks.

Step 2   On IGX, to have firmware upgrade, issue command cnffunc 15 d to disable the UXM from resetting automatically after the firmware is burned in.

Step 3   On each MGX 8220 equipped with IMATM-B, upgrade the ASC to 5.0.10.

Step 4   Download the Forum Compliant Firmware Version IMATM5.0.10.fw but do NOT reset the IMATM-B card.

Step 5   On each IGX-UXM with IMA to be upgraded, burn firmware ABE or later to each UXM with IMA trunks.

Step 6   Simultaneously reset the card at each end of each IMA trunk to minimize trunk outage.

Step 7   Upgrade 9.1 nodes to 9.2 via loadrev and runrev.

Step 8   Issue the command cnffunc 15 e after each IGX is upgraded to 9.2.20 or later.

---

---

Note   The above procedure also applies to the UXME.

---

5. Procedure for upgrading UXM-to-UXM trunks from proprietary IMA protocol to ATM forum-compliant IMA protocol.

---

Note   For Y-redundant UXMs, issue the command cnftrkparm 18 100000 100000 prior to this procedure and return to default values after this procedure.

---

---

Step 1   Download and burn UXM bootcode version 6 or later to all UXMs in the network. This will cause the card to reset and reroute traffic to other trunks.

Step 2   On IGX to have firmware upgraded, issue command cnffunc 15 d to disable the UXM from resetting automatically after the firmware is burned in.

Step 3   On each IGX-UXM with IMA to be upgraded, burn firmware ABE or later to each UXM with IMA trunks.

Step 4   Simultaneously reset the card at each end of each IMA trunk to minimize trunk outage.

Step 5   Upgrade 9.1 nodes to 9.2 via loadrev and runrev.

Step 6   Issue the command cnffunc 15 e after each IGX is upgraded to 9.2.20 or later.

---

---

Note   The above procedure also applies to the UXME.

---

6. Procedure for upgrading BXM cards to the 9.2 firmware release.

To enable BXM cards to utilize 9.2 features, all BXM cards must be upgraded to the 9.2 firmware release. The following steps should be taken to avoid card mismatch:

For the switch running

Perform the following steps to avoid card mismatch for all BXM enhanced cards:

---

Step 1   Upgrade BXM firmware to MEC.

Step 2   Upgrade BCC software to 9.2.30 or higher.

Step 3   Upgrade BXM firmware to MEE or higher.

---

For all other cases, do the following steps:

---

Step 1   Upgrade BXM firmware to MED or higher.

Step 2   Upgrade BCC software to 9.2.30 or higher.

---

---

Note    See the Compatibility Matrix for the exact versions to be used.

---

7. Procedure for adding new BCC cards as a part of upgrading to the 9.2 release.

8. Upgrading VSI 1.1 in Release 9.1 to VSI 2.2 in Release 9.2.

---

Step 1   Upgrade the Tag Switch Controller (TSC)

The TSC is upgraded to the CoS VSI Version Capable Release (IOS 12.XX). This image is VSI bilingual, meaning it understands both VSI Version 1 and Version 2.

Step 2   Upgrade the BXMs

Upgrade all the BXM cards in the node to Model E, which is VSI Version 2 and CoS capable. After each BXM card is downloaded with the Model E image, it temporarily experiences VSI outage until the BCC software is upgraded. The VSI outage during the upgrade is caused by the Model E firmware not being backward compatible with VSI Version 1 features.

Note that from the TSC perspective, after a BXM is upgraded to the Model E image, the interfaces that used to be on the card will "disappear." The TDP sessions that were on the interfaces will be lost. When all the BXMs are upgraded to the Model E while still running Release 9.1 software on the BCC, the node will experience a complete outage of MPLS traffic. AutoRoute will have a hitless upgrade.

Step 3   Upgrade the BCC.

As the BCC is upgraded from software Release 9.1 to the desired 9.2.3x release. The BCC recognizes the Model E BXMs and downloads the VSI partition configuration. This causes the BXMs to issue ifc cfg traps to the TSC, allowing the TSC to rediscover all the MPLS interfaces on the BPX. The TDP sessions are reestablished and MPLS traffic starts flowing again through the BPX.

---

---

Note   The VSI 1.1 and VSI 2.2 are not interoperable.

---

Adding NTM Trunk Limitation

An NTM trunk cannot be added between a Release 9.1 node and a 9.2 node.

If an IGX node is upgraded from Release 9.1.x to Release 9.2.23 and above, adding trunk fails because of an incompatibility with the traffic parameters between the two releases. Executing the addtrk command results in one of the following error messages: Abandoned due to trunk parameters conflict or Abandoned because traffic classes conflict.

In an IGX node running Release 9.1 the bits for VBR-rt and VBR-nrt classes are 0 and are not used to verify traffic parameters. In Release 9.2 these bits are set and are checked to verify traffic parameters.

To workaround this limitation, down the trunk and up the trunk again in Release 9.2 so that the bit is set. Then add the two NTM trunks since both nodes are 9.2.

Revision Interoperability Supported

Revision interoperating upgrades are supported, from the 9.1 to 9.2 releases of Switch software, with secondary revision incorporation for network lowest revision. This will lessen the risk of new features being enabled in a mixed network after the downgrade.

A "Secondary Revision" field in the node is used for the determination of the network lowest revision. Previous to this change, software used only the nodes primary revision.

---

Note   Due to interoperability, the lowest revision running on the node has to be Release 9.2 in order for the VBR-rt and VBR-nrt bits to be set. Check that the lowest revision is 9.2.23 by issuing the dsprevs command.

---

The interoperability functionality uses network lowest revision for:

Version Compatibility Notes

For a complete list of firmware revisions supported, see the Compatibility Matrix document, which is included in this release package.

Control Card Requirements

All processor cards must be configured with a minimum of 32MB of RAM. This includes BCCs and NPMs. NPMs require at least 1MB of BRAM. To verify the BRAM size on IGX 8400 nodes, use the dspcd command.

---

Note   If any control cards contain less than 32MB of DRAM (these would be NPMs) then they must be replaced with cards containing at least 32MB of DRAM prior to upgrading to Release 9.2. The physical upgrade of the nodes with these control cards must be done according to the upgrade procedure defined as follows.

---

Control Card Boot Firmware Requirements

As specified next, the correct version of control card (CC) boot firmware must be installed on the cards prior to a software upgrade to Release 9.2.

With the new version of NPM boot code (RXS), the boot code upgrading does not require physical card resetting with the following steps:

---

Step 1   Burn the boot code on the active NPM (1).

Step 2   Execute the switchcc command and wait until the NPM(1) becomes standby. NPM(2) is now active.

Step 3   Execute the resetcd command to reset the standby (resetcd 1 h). Wait until the reset card NPM(1) becomes standby.

Step 4   Burn the boot code on the active NPM(2).

Step 5   Execute the switchcc command and wait until the NPM(2) becomes standby. NPM(1) is now active.

Step 6   Execute the resetcd command to reset the standby (resetcd 2 h). Wait until the reset card NPM(2) become standby.

---

Control Card Compatibility Requirements

Each redundant pair of BCC cards in a given BPX 8600 node must be of the identical type and memory configuration. That is, for example, if the active card is a BCC-3-32, then so must be the standby. BCC-3 cards with 32MB of RAM cannot be mixed with BCC-3 cards with 64MB of RAM.

Each redundant pair of NPM cards in a given IGX 8400 node must be of the identical type and memory configuration. That is, for example, if the active card is an NPM-32, then so must be the standby. NPM cards with 32MB of RAM cannot be mixed with NPM cards with 64MB of RAM. Also, NPM-64 cards cannot be mixed with NPM-64B cards.

This is a requirement for all software upgrade and downgrade procedures. It does not apply to the physical card upgrade procedure, described in the following section.

Control Card Physical Card Upgrade Procedure

When performing a control card (CC) upgrade, the following procedure must be used. This applies to all processors: BCCs, and/or NPMs.

---

Step 1   Remove the current standby CC front and back card. (Remove back card only applies to BCC.)

Step 2   Replace with new CC front and back cards. (Replace back card only apply to BCC.)

Step 3   Wait for the standby updates on the newly installed standby CC to complete.

Step 4   Issue a switchcc command to utilize the newly installed CC.

Step 5   Verify that the network is stable.

Step 6   Remove the current standby CC front and back card. (Remove back card only applies to BCC.)

Step 7   Replace with new CC front and back cards that are identical to the current active CC. (Replace back card only apply to BCC)

Step 8   Wait for the standby updates on the newly installed standby CC to complete.

Step 9   The CC physical upgrade is now complete.

Step 10   With the secondary card in the standby state, cause a switchover using the switchcc command. This will test that the hardware is working correctly.

---

---

Note   After Step 2, the node will contain a mix of an old type CCs and the new type CCs. This condition is permitted only while the standby updates to the new CC are in progress, which will take less than one hour. The time during which this mixture of CC types exists must be kept to a minimum by immediately replacing the second old type CC with the matching one of the new type.

---

Obsoleted

Notes and Cautions

Additional Notes for Release 9.2.41

None.

Additional Notes for Release 9.2

1. Switch Software Release 9.2 is not compatible with UXM firmware Model A.

2. If attempting to burn UXM firmware Model B into UXM firmware Model A with 9.2 software, the firmware Model B will not be burned into the UXM card due to the incompatibility of software 9.2 and UXM firmware Model A. The UXM has to be returned to Cisco for service.

3. If using MEC or earlier BXM firmware and upgrading to MEE or later, the version of switch software has to be upgraded first so that the enhanced BXM cards will report 2-port groups for 2-port cards all the time. The smooth transition between the earlier 1 port group and the newly reported 2-port groups also displays message in dspcd "Inconsistency with logical PG #" (port group number). All earlier software will mismatch the card. This applies to BXM-OC3 or BXM-OC12 and configured to channel statistic level 2 or higher.

4. Firmware MED and earlier supports APS Redundancy on Legacy BXM only.

5. Because of hardware limitations, BXM hardware is not able to recognize all user-programmed cell transmission rates. Rather only discrete transmission rates can be used instead.

The equation below shows what the BXM hardware actually transmits given a user configured cell rate. The transmitted cell rate is always less than or equal to the configured cell rate. To prevent any cell loss, the transmitted cell rate must be equal to the configured rate. To do so, a cell rate must be chosen from the table below.

The rate table below lists the highest 200 cell rates supported be BXM such that if used, will result in no cell loss (given cell traffic is less than configured cell rate). Additional rates can be calculated using 1470588/[n + (1/256)], where n is an integer.

The logic to calculate the actual cell transmission rate in a BXM card is as follows:

Example:

If a trunk is configured at 100,000 cells per second (cps), the actual transmitted cell rate is then 98,013 cps, any traffic sent over 98,013 cps would be discarded.

If a trunk is configured at 98,013 cps, then the actual transmitted cell rate is 98,013 cps with no cell loss.

Therefore, only rates in the table should be used. Otherwise, cell loss may be experienced. The table will not be exhausted at the end but still go on with the computing from the above equation.

6. On the BPX with MGX 8220 feeder(s), regardless of the setting of the Node Parameter "42 Enable Feeder Alert," a feeder alert message will be sent to all MGX 8220 feeders immediately before a hitless rebuild takes place. The feeder alert message will temporarily disable the LMI polling from the MGX 8220 feeders. The MGX 8220 polling will resume as soon as the BPX is ready to exchange LMI messages.

7. The amount of traffic allowed on a VP tunneling connection is two-thirds bandwidth of that connection. The minimum bandwidth must be 100 cells per second. For example, a CBR connection with a peak cell rate 1500 cps then can pass traffic up to 1000 cps.

Limitations

1. BME firmware MKA and MKB is not compatible with BPX Switch Software Release 9.2x and later.

2. For Switch Software 9.2, MPLS and PNNI controllers cannot coexist.

3. In Release 9.2.30 and later, nodes might declare a communication break when using the BXM virtual trunking feature. The problem has been observed under the following conditions:

The simplest example follows below:

node_A ------ vtrk ----- node_B -----vtrk -----node_C

On the above diagram, node_B is a virtual trunk share a common port

With this topology, "node_A" sees "node_C" as unreachable and vice-versa; however, "node_A" communicates to "node_B," and "node_B" communicates to "node_C."

Workarounds:

4. When the cnfrsrc command is used to delete VSI partitions on an interface, software does not check if any Soft Permanent Virtual Circuit (SPVC) connections exists on that partition. Even if there are SPVC connections on a partition, the partition can be deleted using the cnfrsrc command. The only protection is that users are provided with a warning when they try to delete the partition.

If there are SPVC connections on a partition and if the partition is deleted, the SPVC connections will be left in a undefined and unrecoverable state. Hence, before deleting a VSI partition, ensure that all the SPVC connections are deleted on that partition.

5. For UVM cards, there will be no new revisions of Model A firmware. When attempting to download Model A firmware to a UVM, software will give the user an error message indicating that the firmware does not match the card type. Note that there is no problem with continuing to use existing UVM cards running the old firmware(CSCdp08741).

6. There is a new traffic class added in Release 9.2.20 that causes a trunk parameter conflict with pre-9.2.20 node. The conflict fails adding trunk between 9.2.20 BTM/ATM and pre- 9.2.20 BTM/ATM.

All ATM traffic classes are set for BTM/ALM trunks and is hidden to the user. The introduction of rt-VBR traffic class in 9.2.20 makes it different from pre-9.2.20 BTM/ALM trunk traffic class. The user can not change the ATM traffic class for BTM/ALM trunk.

This problem exists with a new BTM/ALM trunk on an upgraded 9.2.20 node but does not exist with an upgraded BTM/ALM trunk since the rt-VBR traffic class is not set while upgrading (CSCdm64345).

7. The cloud port to which a virtual trunk is connected should have ILMI polling disabled. Otherwise, it could lead to a virtual trunk being clear on one end and declaring Virtual Trunk Path Failure at the other end (CSCdm52909).

8. In a BPX that contains BCC cards with 64MB, there is no limitation. All 12 available slots can contain BXM or Enhanced-BXM cards.

In a BPX that contains BCC cards with 32MB, a maximum of 10 legacy BXM cards are allowed. If some Enhanced-BXM cards are used in place of BXM, then each Enhanced-BXM will count as two BXM cards.

9. For performance reasons, AIS status of connections is not sent to the standby BCC. After switchcc, it may take a few minutes to update the AIS status of connections. If dspcon does not show the proper status of AIS or the dspalms screen shows an incorrect number of AIS, (after switchcc) wait for few minutes so that the status gets updated. (The dspalms and dspcon commands show the status of AIS.)

10. Hitless rebuild has similar limitations to that of a switchcc and full rebuild:

Some will be re-enabled automatically. These include:

All other statistics have to be re-enabled for collection after a hitless rebuild takes place. These mainly include the user statistics.

11. UVM cards in Y-redundancy will mismatch if one is burned with Idle Code Suppression Firmware and the other is not.

When installing/burning Idle Code Suppression Firmware on UVM pairs, the Y-redundancy must be removed, firmware in both UVM cards burned, and then the Y-redundancy can be restored.

12. Mismatch is reported when replacing a BXM card with another BXM card that has a different port group, even though both BXM cards have the identical channel number.

13. When upgrading from Release 9.1 to 9.2, the 9.1 statistics on BXM/UXM cards are supported to maintain compatibility. However, once a user configures a statistics level in 9.2, the statistics cannot be configured back to 9.1 statistics.

There is no 9.1 statistics support for BXM/UXM cards that were shipped with 9.2 firmware since the BXM/UXM card has the default level 1 statistics.

Therefore, when using a UXM with 9.2, a user must either:

OR

14. The BXM and UXM channel statistics level feature gives these cards the capability of collecting more than four statistics per connection. However, it is the controller card's limitations, available memory, and performance, that indicates how many statistics can actually be collected from the cards and then reported to the Cisco Wan Manager (CWM).

The BCC-3-64 can collect at most three interval statistics per connection when there are 16,000 AutoRoute (AR) connections configured on the node. (Interval statistics are those statistics that are reported to the CWM. They are often referred to as TFTP statistics.)

You can collect approximately 48,000 statistics (3 x 16,000) on the BCC-3-64. This is approximate because there are many variables that will affect this value, such as are peaks enabled, how many buckets are collected, are all connection of the same type, are trunk, line or port statistics enabled, and so on.

With this approximation of 48,000 statistics on the BCC-3-64, this then means that as a rough estimate you could enable 32 statistics on 1,500 connections, 48 statistics on 1,000 connections or nine statistics on 5,000 connections, and so on. The approximation formula being:

max_stats_per_connection = 48,000/number_of_connections

15. In Release 9.1, the UXM card ran a proprietary IMA communication protocol. This protocol matched that used on the MGX 8220 4 IMATM-B cards and hence could be connected together to form a trunk. In Release 9.2, standards-compliant IMA are supported on the UXM card and standards-compliant IMATM-B on MGX 8220 5.0.x must be used to form a trunk. There should be no effect on UXM-IMA trunks connected to other UXM-IMA trunks in 9.1 to 9.2 interoperability mode.

16. The transmit rate on an IGX IMA trunk can be altered at the local node with any trunk outage. It is possible that the transmit rates are different at the two ends of an IMA trunk. After this trunk is deleted, it cannot be added back unless the transmit rates are the same.

17. When doing a grouped upgrade from Release 9.1 to 9.2, the software error 1427 may be logged on the BPX/IGX node during a non-graceful upgrade. This error can be ignored since it is harmless to the network (CSCdm14613).

18. Reconfiguring trunk parameters might cause connections to be rerouted if the changed bandwidth load is smaller than what was used by the connections that use the trunk.

19. If LMI/ILMI is provided by the BCC:

The maximum possible number of ports on the BPX 8600 that can be configured with LMI/ILMI enabled is 52. However, each BPX will support up to a total of 16 feeder trunks and each feeder trunk will have LMI enabled. That is, if a BPX 8600 is configured with only two feeder trunks, then only (52 - 2) = 50 ports can have LMI/ILMI enabled.

If LMI/ILMI is provided by the BXM firmware:

20. Virtual Path Connections with cells whose VCI values are above 4095 will be transmitted correctly only if the path is exclusively through BXM trunks and terminate at BXM ports.

21. The feature of CIR=0 for Frame Relay connections is not supported for connections terminating between FRM cards in IGX nodes and FRSM cards in an MGX 8220 shelf.

22. SVC connections are derouted after decreasing the allocated bandwidth (increasing Statistic Reserve). It is the design intent that increasing the statistical reserve will cause SVC conns to derouted and not be rerouted (CSCst92308).

23. For the loadrev operation, it is important that the Cisco Wan Manager/TFTP buffers are maintained at their default size.

24. Due to a hardware limitation, the BNI trunk will send 13-15 percent more traffic than what it is configured for when the trunk is configured for less speed (cps) than the maximum port speed. This is especially important when the BNI trunk is connected to IMATM pairs, which carry less than T3 bandwidth.

25. When using the shift/no-shift feature on a BPX 8600 node's port card, controlled via the cnfport command, the other end of the connection must have the same setting. Otherwise, there will be a loss of continuity.

26. Due to trunk-based loading, any commands having to do with trunk loading and the load model (dspload chklm dsplm, and so on.) need to be done only after waiting a certain period of time. This time is a direct function of the trunk load update interval time (as configurable) plus the conditional update latency time.

27. The external ABR segment control loop on ForeSight (ABRFST) is an option at the user interface. It is supported by UXM-E/BXM-E but is not supported by UXM/BXM hardware. The user should not enable this option on ForeSight connections (CSCdi92451). In any case, there is no coupling between the loops.

28. The interface between a BXM feeder trunk and an MGX 8220 feeder is always considered to be an NNI interface. (CSCdj16808)

29. When adding more than 4000 connections on a BPX node, the VC polling rate must be changed to a higher interval, to accommodate the additional time needed to poll for the statistics for each VC. The cnfsysparm command, parameter 24, must be changed according to the following:

30. Given a connection that terminates on an IGX 8400 FRM at one end and an ASI on the other end, tstdelay initiated at the FRM end may not work if the ASI firmware is below the appropriate revision and does not support OAM cells as opposed to supervisory cells. This is because the updated BTM on the IGX will always generate OAM cells. Please check the Compatibility Matrix.

31. Because the detailed card error event log is not retained within BRAM, this information will be lost should a processor rebuild occur. Therefore, when issuing a dspcderrs command on a particular slot, the display will not show the detailed card error information should a rebuild event occur. This functionality has not been modified from previous releases.

32. When a physical-layer failure (for example, LOS) is detected on the BXM, a Major Alarm is generated, and any connection routed over that port is downed (fail state). The software sends a command to the remote end of the connection to generate AIS in the egress direction (CSCdj30543).

Impact:

Since the connection is in a failed state, AIS is generated in the upstream direction (in addition to the downstream direction). Although this does conform to the letter of the I.610 standard, this is not necessarily what a user would expect to see, because it interferes with the RDI response from the end-to-end connection termination point. (A fault in the downstream direction causes a fault in the upstream direction.)

Reason for the current implementation:

The BNI can not generate AIS. If there is a fault at a BNI trunk, the current mechanism is to cause AIS to be generated by the BXM port by downing the connection. Since the BXM can generate only OAM cells from the RCMP, and the RCMP is in the ingress path, the cells must be backward routed to the egress (egress QE). Also, since end-to-end OAM cells are required, the ingress QE must be configured to drop ALL cells in the ingress path. This creates a break in continuity in the opposite direction, and AIS cells must also be generated at the other end of the same connection, in the upstream direction of the original fault.

33. There are problems in the downgrade mechanism that can cause database corruption. If a downgrade is performed immediately after upgrading, the Stby_Info revision fields are not yet filled in on the new active CC. They don't get filled in until there is an upcard response from the new locked CC. This causes a restart instead of a switchcc. If the locked CC is reset, then downgrade immediately, a restart will occur instead of a switchcc. (CSCdj30811).

34. In order to test/simulate the Y-redundant switchover of ASI T3 or E3 pairs the resetcd command must be used, or by pulling out the active card. It will not be correctly simulated by doing a dncd (down card) on the active card. Using dncd will cause cell discards (CSCdj08923).

35. UBR traffic gains an advantage over ABR traffic when UBR and ABR PVCs are combined on the same network. This is because UBR and ABR PVCs share the same Qbin (Class of Service Queue) on the BXM card. ABR PVCs use a flow control mechanism, VSVD, which ensures that traffic sources slow down when the Qbin usage exceeds the EFCI threshold. However, UBR PVCs do not have this throttling mechanism. Therefore, ABR will throttle back whereas UBR will not. This unfair advantage is not considered a problem, since the decision to share a Qbin for ABR and UBR traffic was intentional. Any best-effort service that one would route over UBR can be routed over ABR(VSVD), with the additional benefit of protecting resources in the network. If UBR and ABR PVCs are required then:

Option 1: Consider adding all best-effort PVCs as UBR

Option 2: Isolate the ABR and UBR paths by using cnfpref command to ensure that ABR and UBR PVCs do not share the same queues.

Option 3: To provide UBR service on a connection, rather than setting up a UBR connection, do the following:

---

Step 1   Set up an ABRSTD connection.

Step 2   Enable VSVD.

Step 3   Disable FCES (Flow Control External Segment).

Step 4   Disable DEFAULT EXTENDED PARAMETERS.

Step 5   Choose policing option "4" to allow access as UBR.1 (PCR policing only). This connection has ABR VSVD in the network and allows UBR.1 access. The MCR for such ABRSTD connection may be set at the minimum acceptable value of 6 cells per second (explained later to do so).

---

To provide ABR service on a connection, set up an ABRSTD connection, enable VSVD and enable FCES to allow RM cells to be passed to and from customer equipment. The MCR for such ABRSTD connections can be set at any user-desired value.

When the network is experiencing congestion, all the affected ABRSTD connections, regardless of the services (ABR or UBR) they are carrying, will all be throttled back at the VSVD points at the network edge. During network congestion, connections carrying UBR services are virtually stopped (to a throughput of a mere 6 cps) while connections carrying ABR services can send at a much higher, user-desired MCR. This option would avoid that UBR service gains an unfair advantage over ABR service while sharing the same CoS queue.

36. Combining Frame Based Traffic Control (FBTC) and non-FBTC connections within a Class of Service can cause FBTC connections to not receive a fair share of bandwidth. For example, if VBR connections are added at a terminating port, and some of these VBR connections have FBTC enabled while other VBR connections have FBTC disabled, the VBR connections with FBTC disabled may obtain all of the excess bandwidth before the connections with FBTC enabled receive any of the excess bandwidth. The same holds true for ABR or UBR connections. This is relevant only where FBTC and non-FBTC connections share a Qbin, either at a port or at a trunk.

37. The maximum number of VC PARMs supported: 749 for BCC-32 MB, 2,999 for BCC-64 MB. (CSCdj48589).

VC PARMs are Virtual Circuit Parameters combinations/sets. One set of VC Parameter is used for each unique Virtual Circuit that has been provisioned. Identically provisioned VCs (exclusive of end points) use the same set of parameters. Thus, on a 32MB BCC, a total of 749 uniquely configured Virtual Circuits can be provisioned.

38. Care must be taken when changing the Deroute Delay parameter, which is controlled by the cnftrk command. This defaults to zero, but if set to anything but zero, connection rerouting, due to a trunk failure, will be delayed as provided by the parameter.

Required Workarounds

1. When adding a node into an existing network, ensure that its node number is unique prior to a actually adding it into the network. Use the rnmnd command, and renumber the individual node while it is still stand-alone. This will make the joining of this node much simpler, and will avoid the problem of a node renumbering an active network, as described below.

2. There is a problem with node renumbering. Node renumbering (the rnmnd command) should be executed only during a stable network environment and only if absolutely necessary. A stable network environment would be, for example, one in which no connection was added for the past 30 minutes and no topology change was made in the last hour and there are no alarms or node unreachabilities. Node renumbering must be done only when the network is stable to reduce the possibility of certain temporarily blocked messages during the node renumbering process from being delivered to the wrong nodes. This would occur after the completion of the node renumbering process. It is recommended that a node be renumbered prior to being added to the network.

3. The settling time for network-wide updates can take a long time in certain situations. Specifically, the settling time for updates due to network-wide topology changes and connections in a large network when a processor switchover occurs can take a long time. The time is proportional to the number of nodes as well as the number of connections. A general estimate would be 30 seconds per node. During the period of transitions (when the updates are occurring) some network operations such as adding connections might in some cases take somewhat longer to complete.

4. When using Cisco Wan Manager, there could be a problem with communicating with a node that just had a processor switchover. The problem is within the SPARCstation itself and its caching of EtherNet addresses. It can be solved by execution the following command on the workstation as the superuser: # arp -d <node_name>

5. Users may not use the command addcon slot.1-24 v to add 24 voice connections to a CVM/UVM at once. Instead, they must separate this activity into two or more commands, so that no more than 16 connections are added at once. This is an issue only for voice connections. Data connections can be added using the "1-24" syntax. This also applies when the CVM/UVM circuit line is an E1, in which case "1-32" would apply (CSCdj14319).

6. Statistics must be disabled prior to the start of an upgrade, prior to the issuing of the first loadrev command. Statistics should be disabled from the Cisco Wan Manager, which is the Statistics collection manager.

7. Statistics sampling must be disabled prior to the start of an upgrade (using off1/off2), prior to the issuing of the first loadrev command. Statistics sampling state machines should be disabled from the Command Line Interface.

8. When a switchcc is executed on a BPX 8600 configured with two BCC-4 cards and contains a BXM-622 trunk card, there may be a bad clock path problem reported. It is indicated as a Minor Alarm - bad clock path. This is a transitory problem, although the alarm indication persists. To clear this, execute the clrclkalm command.

Additional Documentation

The command dspbpnv can be issued to verify if the node has the new backplane or the old backplane. The following chart details the bit fields for the BCC Backplane NOVRAM format, the values in bytes numbered 4 and 5 describe the back plane type.

The command cnfbpnv can be used to configure the backplane, if backplane is so enabled.

On the node on which it is executed, it creates a loopback within the port such that the cells do not leave the card.

On the node on which it is executed, it creates a loop such that incoming cells are looped back to the other end.

Removes the loopback added by either of the above two commands.

This will enable the card-synchronization feature.

This will disable the card-synchronization feature.

In order for the feature to work, the line statistics sampling should always be enabled (via on2 1 command) and the front card installed must support the card-synchronization feature. The dspcd command provides an easy way to determine whether the front card supports this new feature. If the front card supports the feature, the following message is shown on the dspcd screen:

Additional debug commands are added to allow synchronization between the interface card and the CC database:

The <slot_number> is for a particular slot that supports the card synchronization feature;
* For all cards that support the card-synchronization feature.

This command displays the number of connections reconciled during the synchronization process after a switchcc for different slots.

* For all slots supporting this feature.

Compatibility Notes

For a complete list of firmware revisions supported, see the Compatibility Matrix document, which is included in this release package.

This release will run with Release 4.0.0x, 4.1.0x, or 5.0.0x of the MGX 8220.

Compatibility Matrix

BPX 8600 Firmware Compatibility

IGX 8400 Firmware Compatibility

---

Note   IGX-UVM model E supersedes models A, B, and C firmware. A, B, and C are obsoleted and should not be used.

---

MGX 8220 Firmware Compatibility

MGX 8250 1.1.3x Firmware Compatibility

MGX 8850 1.1.3x Firmware Compatibility

BPX 8600 Hardware Compatibility

IGX 8400 Hardware Compatibility

Known Anomalies

The following is the list of known anomalies in this Switch Software delivery. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the release note enclosure of the problem record in Bug Navigator.

Known Anomalies from Previous Releases Closed in 9.2.41

The following is the list of known anomalies in previous Switch Software deliveries. Included with each is a brief description of the problem. A more in depth description is available in the release note enclosure of the problem record in Bug Navigator.

Problems Resolved in Release 9.2.41

Following is the list of fixed problems in 9.2.41 Switch Software release. Included with each is a brief discussion of the problem.

Problems Resolved in Release 9.2.40

Following is the list of fixed problems in 9.2.40 Switch Software release. Included with each is a brief discussion of the problem.

Known Anomalies from Previous Releases Closed in 9.2.40

The following is the list of known anomalies in previous Switch Software deliveries. Included with each is a brief description of the problem. A more in depth description is available in the release note enclosure of the problem record in Bug Navigator.

Problems Fixed in Release 9.2.38

Following is the list of fixed problems that were fixed in the 9.2.38 Switch Software release. Included with each is a brief discussion of the problem.

Problems Fixed in Release 9.2.37

Following is the list of fixed problems in the 9.2.37 Switch Software release. Included with each is a brief discussion of the problem.

Problems Fixed in Release 9.2.36

Following is the list of fixed problems in the 9.2.35 Switch Software release. Included with each is a brief discussion of the problem.

Problems Fixed in Release 9.2.35

Following is the list of fixed problems in the 9.2.35 Switch Software release. Included with each is a brief discussion of the problem.

Problems Fixed in Release 9.2.34

Following is the list of fixed problems in the 9.2.34 Switch Software release. Included with each is a brief discussion of the problem.

Problems Fixed in Release 9.2.33

Following is the list of fixed problems in the 9.2.33 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.32

Following is the list of fixed problems in the 9.2.32 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.31

Following is the list of fixed problems in the 9.2.31 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.30

Following is the list of fixed problems in the 9.2.30 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.23

Following is the list of fixed problems in the 9.2.23 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.22

Following is the list of fixed problems in the 9.2.22 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.21

Following is the list of fixed problems in the 9.2.21 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.20

Following is the list of fixed problems in the 9.2.20 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.10

Following is the list of fixed problems in the 9.2.10 Switch Software release. Included with each is a brief description of the problem.

Problems Fixed in Release 9.2.01

Following is the list of fixed problems in the 9.2.01 Switch Software release. Included with each is a brief description of the problem.

Additional Deliverables

SNMP MIB

The SNMP IGX/BPX switch SNMP MIB is being provided with the delivery of Release 9.2.38 Switch Software. The MIB is in standard ASN.1 format and is located in the ASCII text files agent.m, ilmi.m, ilmi_ctl.m, ilmiaddr.m, switch.m, swtraps.m, and errors.m which are included in the same directory as the Switch Software images. These files may be compiled with most standards-based MIB compilers.

Switch MIB changes of Release 9.2

The following Switch MIB changes were introduced since Release 9.2.00. The changes include Obsolete objects, Modified objects, and New objects:

switchIfTable

New objects:

Modified objects:

atmPortTable:

New objects:

Modified objects:

atmPortQueueTable:

Modified objects:

connTable:

Modified objects:

atmEndptTable:

New Objects:

Modified objects:

atmBwClassTable:

Modified objects:

The following objects are associated with the switchShelf configuration branch.

New objects:

shelfSlotInfoTable:

Modified objects:

sonetIfTable:

Modified objects:

sonetStatsTable:

New objects:

Modified objects:

atmTrunks table:

Modified objects:

rsrcPartiTable:

New objects:

Modified objects:

serialPortTable:

New objects:

Modified objects:

Default Values

BPX 8600 Nodes

The default values for BXM and Enhanced-BXM cards are the same.

BNI-T3

BNI-E3

BXM-T3

BXM-OC12

BNI-155-OCS

BXM-E3

IGX 8400 Nodes

NTM-E1

NTM-T1

NTM-SR

UXM-E3

UXM-T1

UXM-E1/30

BTM-T3

BTM-E3

BTM-HSSI

UXM-T1

UXM-E1

Appendix A BXM Firmware MFU Release Notes

About the Firmware MFU

BXM Firmware version M.F.U. supports all the existing interfaces and models of BXM hardware. Following table outlines various levels of hardware revisions supported for BXM firmware version M.F.U.

Front Cards

New Features supported in BXM Firmware MFU:

Bug fix only

New Features supported in BXM Firmware MFT:

Bug fix only. This image includes a fix for the bug CSCdw54957.

New Features supported in BXM Firmware MFR:

Bug fix only.

New Features supported in BXM Firmware MFP:

New Features supported in BXM Firmware MFN:

New Features supported in BXM Firmware MFM:

Bug fix only.

New Features supported in BXM Firmware MFK:

LCN cac with policing parameters set by PNNI controller. (Look at "Notes Cautions & Clarifications" for warnings).

New Features supported in BXM Firmware MFJ:

Bug fix only.

New Features supported in BXM Firmware MFH:

1. Dynamic partitioning feature is supported on BXM card by default. Remote Shell Feature through the BCC CLI provides a mechanism to turn off this feature.

2. SPVC feeder support.

New Features supported in BXM Firmware MFF

1. Use of separate qbin to guarantee bandwidth resources for the control channels of VSI controllers.

New Features supported in BXM Firmware MFE

Bug fix only

Note: Support for APS 1:1 added for VSI

New Features supported in BXM Firmware MFD

Bug fix only

New Features supported in BXM Firmware MFC

1. Support for SES (PNNI controller)

2. BootCore enhancement to support multi-vendor flash-SIMMs

3. 1 msec granularity for tstdelay measurement.

New Features supported in BXM Firmware MFB

1. Multiple VSI (2.2) partition feature. Three partitions are supported

2. Hitless Connection Density Upgrade for BXM

3. SCR and PCR policing at less than 50 CPS for T3/E3 BXMs

4. Control Traffic Shaping

New Features supported in BXM Firmware MFA

1. Multiple VSI (2.2) partition feature. (Two partitions)

Note: First release in MF branch of firmware

New Features supported in BXM Firmware MEC

There is no new feature in release MEC

New Features supported in BXM Firmware MEB

There is no new feature in release MEB

New Features supported in BXM Firmware MEA

1. VSI version 2.2 (single partition)

2. ITUT Annex B and configurable Signal Degrade (SD) and Signal Failure (SF) thresholds for SONET Linear APS on BXM-OC3 and BXM-OC12 (1+1, 2 card, 1:1).

The current default thresholds are as follows:

New Features supported in BXM Firmware MDA

1. Support for Virtual Trunking

2. Support for BXM Multi-Level Channel Statistics

3. SONET Linear APS on BXM-OC3 and BXM-OC12 (1+1, 2 card, 1:1)

4. Support for card based LMI and ILMI

5. Upgrade from VSI 1.1 to VSI 2.2 is supported in this release. See upgrade section on next page.

Special Installation/Upgrade Requirements

APS Issues

Upgrading from MEK and lower firmware to MFU when feeder trunks are utilized with APS while the BPX node does not have APS requires the following procedure:

1) Change the POP1 feeder to use APS1+1 unidirectional AND disable K1K2 processing (may need to delete and then add back APS). On the BPX temporarily configure to use unidirectional mode.

2) After POP1 dspapsln shows both lines OK, delete the APS line on the BPX.

3) Proceed to upgrade the BXM cards as if YRED.

4) After both cards are MFU, add back the APS on the BPX.

5) Reconfigure both POP1 and BPX to use the appropriate APS configurations.

BXM cards with M.C.B/M.D.A firmware or later can be smoothly migrated to the M.F.A or above version of firmware by using y-cable redundancy. To upgrade a BXM card pair in y-red configuration, first upgrade the standby card with the MFA or above firmware version and wait for all the configuration to be downloaded into the card. Do a switchyred to switch to the card with firmware M.F.A or above version and burn the other card also with desired version MFA or above firmware. Follow the standard firmware upgrade procedure for downloading and burning the firmware into the cards.

If BCC swsw version is 9.1.18 and dspnovram shows 0 or 4 for Number of Channel Stats it should be OK to go directly to MFC or above versions from MCC.

Channel Stats Issues

1. While upgrading from firmware, on OC3, 1 port OC12 BXM cards, if stats level on BXM is greater than 1, the upgrade should take place according to the one of the upgrade procedures below

---

Step 1   swsw should be upgraded to 9.2.30 or higher first,

Step 2   upgrade the firmware to MFU.

---

Step 1   firmware should be upgraded to MEC

Step 2   upgrade the swsw to 9.2.30 or higher revision

Step 3   upgrade the firmware to MFU.

The procedure above will avoid card mismatch.

Burn firmware should not be interrupted. Card resets in the middle of burn firmware will result in the BXM being maintained in the core state (Identified by blinking yellow LED), or failed state (Identified by a solid red led). In this case the dspcds screen will report the card as FAILED. This state can be recovered by reburning the firmware into the card.

Features Obsoleted

1. VSI 1.0 is obsoleted by VSI 2.2 in the MDA release onwards.

2. From versions MFJ to MFN channel statistics level 0 is no longer supported for BXM-155-4, BXM-155-8, BXM-622, BXM-622-2, BXM-T3-8, BXM-T3-12, BXM-E3-8, BXM-E3-12 models.

In all other models channel statistics level 0 is supported by all firmware versions i.e. (BXM-155-8DX, BXM-155-8D, BXM-155-4DX, BXM-155-4D, BXM-622-2DX, BXM-622-2D, BXM-622-DX, BXM-T3-12EX, BXM-T3-12E, BXM-T3-8E, BXM-E3-12EX, BXM-E3-12E, BXM-E3-8E)

Notes, Cautions & Clarifications

1. BXM Model F firmware is intended for use with 9.3 switch software. BXM Model F firmware may be used to upgrade BXMs during the upgrade process from switch software release 9.2 to 9.3. BXM Model F firmware has not been tested for compatibility with release 8.4, 8.5, and 9.1 switch software. It is compatible with IOS version 12.05t2 or greater for MPLS.

2. M.F.E is a not on CCO, as it an orion specific release.

3. Protection Switching based on BER on BXM may not comply to standards. The GR-253 & ITU-T G.783 requires that switching be completed within 60 msec from the time the error starts. BXM is unable to detect BER threshold crossing until the next poll, which occurs every 250 msec. Thus, switching time may be up to 250 msec under certain circumstances.

4. In APS 1+1 default configuration, both backcard LEDs show green when primary card is active and selection is from PROT line. When primary card is active and it is selecting from PROT, PROT backcard should be green, since it is carrying traffic. WORK backcard should also be green since that is the physical path for the primary (and active) card to pass traffic. So backcard LED green means the backcard is directly or indirectly carrying traffic and pulling the backcard will cause traffic disruption. (CSCdm53430)

5. In APS 1+1 default configuration and a manual W->P is on and a switchyred is issued, a manual W->P event is logged. By default, on switchyred the new active card comes up in "clear" state. But in this case since there is a manual W->P on, the APS line switches to PROT and the switching is logged. (CSCdm53404)

6. In APS 1+1 default configuration if the selected line is PROT and last user request is clear and a switchyred is issued, line switches to WORK. If the last user request is "clear", full automatic APS switching is in effect with the working line being active by default. When there is no last user switch request to switch to any particular line, the working line will become active. (CSCdm53420)

7. When APS Annex B is added to local end which has the Secondary card active, the APS trunk goes into Comm Failure for few seconds and then clears. If Secondary card is active, then do a switchyred to make Primary card active and then add APS Annex B. (CSCdm46359).

8. MFK and above versions support LCN cac for class of services. Controller will reserve some LCNs for control VC as default. These reserved LCN can not be used by any class of service any more in MFU. If all the LCNs for the partition has been used in a version earlier than MFK, after MFU is updated in the switch, some connections may not be added because they try to use LCNs reserved for control VC which is not allowed. You need to configure more LCNs for the partition to make sure there is enough LCNs for all the connections.

9. The OC-3 MultiMode Fiber backcards do not support Y-cable redundancy.

10. APS 1:1 is not supported for VSI in versions before MFE. (Bug CSCdp42996) APS 1:1 should not be configured on ports intended to be used by PNNI or MPLS, as after switchover traffic flow is stalled on the protection line for releases before MFE. However in MFE and above, this problem is fixed.

11. Total BW allocated to all VSI partitions on a BXM should not be more that OC12 rate i.e., 1412832 cells/s. Currently BCC swsw allows uses to configure more than OC12 rate, in which case all the PNNI connection commit requests would be NACKed by BXM

12. In firmware versions prior to MFF signalling bandwidth for SES controller was not guaranteed. In MFF and above the signalling Qbin feature has been added (with Sw/Sw 9.3.10 and above and SES image 1.0.10 and above) to guarantee signalling bandwidth.

13. In version MFP and above Stats Level 0 is not supported. If a card was configured with Stats Level 0 with VSI enabled in a previous release of firmware, upon upgrading to MFU, mismatch will occur. Customers will have to reconfigure their card to Stats Level 1 or above before upgrading, otherwise VSI operation will be impacted.

Known Anomalies

The following is the list of known anomalies for the BXM firmware:

Bugs Fixed in MFU

Bugs Fixed in MFT

Bugs Fixed in MFR

Bugs Fixed in MFP

Bugs Fixed in MFN

Bugs Fixed in MFM

Bugs Fixed in MFL

Bugs Fixed in MFK

Bugs Fixed in MFJ

Bugs Fixed in MFH

Bugs Fixed in MFF

Bugs Fixed in MFE

CSCdp05098 Symptom: Cell discards occur for ABRFST/ABRSTD conns when the traffic burst is greater than the MBS Condition: This occurs when the traffic burst size is fixed to 140000 cells at 70000 cps. The conn are configured with PCR=72000/72000, MBS=1000/1000 and ICR 7200/7200. This is the expected behavior since the configured MBS < the actual burst size. Workaround: Increase the MBS and ICR using cnfcon. CSCdr59731 Symptom: port 11.1 is connected to 11.2 and ILMI are up and running on both ports. Enable neighbor discovery on 11.1, then 11.2. The 0x71 responses/traps from BXM fw is not predictable. At least two variations are observed: Variation 1. port 11.2 has it's neighbor's info but port 11.1 doesn't. Variation 2. both port 11.1 and 11.2 only know the IP addresses of their neighbors. The Neighbor's IFName are missing. Problem was observed in MF17, but code changes in more recent builds had already repaired the problem. Condition: when ILMI session restarts, remnants of IfName, IpAddr from previous session left. Clr/reset IfName,IpAddr in MIB, on ILMI session restart In FMSStart, pIlmiProcessFsmStart() calls a new function IlmiClrPeerAndSendTopoTrap(pcb_ptr->session_id) CSCdr79936 Symptom: Stats files not generated/missing on some 15 minutes intervals. Conditions: When system time is changed at 15 minutes boundaries. Workaround: Minimize system time and card config changes. CSCdm16800 Symptom Card error 0xc000007 appears in the card error log. Cause This error indicates that an unknown type of cell which is not expected has arrived in the egress QE. Resolution: Engineering has done in-depth investigation into this case. We are convinced the problem does not affect user traffic or the node in any other way. Therefore, the symptom will not be reported as a card error. The fix has been incorporated into MEE firmware. CSCdp22930 Symptom: N/A Conditions: cbus rd/wr operations set up in the PUUMBA chip when performing cbus rcv/xmit. Workaround: None CSCdp74680 Symptom: Even if the interface is in LOS, the SPVC's do not generate ingress AIS into the network. Condition: Connection is added after the interface goes into LOS. Workaround: None CSCdr44250 Symptom: Private image did not allow as many OAM cells to flow as public image. Condition: This occurred by undoing a hardware fix in a private image. Workaround: This was never introduced into the Public view and no workaround is required. CSCdr45986 Symptoms: Standby and active block checksum value do not match and resync happens on switchover. Conditions: When active card has many SPVC connections derouted it happens. Workaround: None. CSCdr71473 Symptom: Unreachable BXM, sw errors and cd errors on the BPX. Condition: LMI is enabled when controller either slow to respond or un-reachable. Workaround: Disable LMI. CSCdp97307 Symptoms: When executed "rsh <slot> vsi cm VsiIs " without parameter. The card will crash,. Condition: Always. Workaround. Pullout the card and reinsert. CSCdr86894 Symptoms: Many ports have VC failure because BXM has no resource to build the CVC. Conditions: intermittent Workaround: Reset BXM card. CSCdr57712 Symptom: Multi_partition fails to report all virtual trunks. Condition: In case of virtual trunks with different partition. Workaround Reset the BXM card. CSCdr77238 Symptom: Switch General Info does not contain bulk set capability bit. With newer images of PXM bulk set will not work with BXM images prior to MFD. Condition: PXM Images later than 07/06/2000 contains logic to identify the bulk set capability of the slave. BXM images prior to 07/06/2000 will not have this bit set because it is newly introduced parameter in VSI spec. Workaround: No workaround. Need to upgrade to MFD.