9.2.36 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.
Product
Feature Name
FCS/GAStatus
Minimum Release
IGX
Support for UXM XLR card
GA
9.2.30
BPX
Support Multiple VSI Partitions
GA
9.2.30
IGX
HDM/LDM Control Lead Trap
GA
9.2.30
IGX
Support UXM Feeder
GA
9.2.30
IGX
SES Feeder to IGX
GA
9.2.23
BPX
Include SONET line protection: APS on BXM-OC3 and BXM-OC12 (1+1)
GA
9.2.20
BPX
Include SONET line protection: APS on BXM-OC3 and BXM-OC12 (2 card, 1:1)
GA
9.2.20
BPX
Support for 16K connections
GA
9.2.20
BPX
Support for LMI/ILMI on BXM card
GA
9.2.20
BPX
Support for Virtual Trunking on the BXM card
GA
9.2.20
BPX
Support for Virtual Switch Interface (VSI) 2.2
GA
This interface is available in 9.2.20. Use of this interface is dependent upon other products, for example IOS.
BPX/IGX
A-bit Notification
GA
9.2.20
BPX/IGX
Alarms for all service-affecting events
GA
9.2.20
BPX/IGX
Support for feature mismatch on BXM and UXM cards
GA
9.2.20
BPX/IGX
Support for Hitless Rebuild including Disable Auto Bus Diagnostics
GA
9.2.20
BPX/IGX
Support for IGX and BPX trunk reconfiguration without outage
GA
9.2.20
BPX/IGX
Support for Revision Interoperability between 9.1 and 9.2
GA
9.2.20
BPX/IGX
Support for UXM and BXM Multilevel Channel Statistics
GA
9.2.20
BPX/IGX
Support ports and trunks on the same UXM and BXM cards
GA
9.2.20
IGX
Support for ATM Forum Standard Compliant IMA Trunking with UXM Firmware Model B
GA
9.2.20
IGX
Support for Virtual Trunking on the UXM card
GA
9.2.20
IGX
Support VC traffic shaping on UXM port
GA
9.2.20
BPX
Support for APS Annex B
GA
9.2.20
BPX/IGX
Real-Time VBR
GA
9.2.20
IGX
Support Enhanced UXM (GA)
GA
9.2.20
IGX
Support for Idle code suppression for video on UVM and CVM cards
GA
9.2.20
IGX
Support for UXM VP tunneling
GA
9.2.20
Software Release 9.2.36
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.36.
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:
Support for Multiple Partitions
Support for UXM Feeder
Support for HDM/LDM Control Lead Trap
Support for UXM XLR Back Card
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:
Support for Real-Time VBR (rt-VBR)
Support for Early A-bit Notification (This feature is an enhancement to the Early A-Bit Notification feature in release 9.1)
Support the Service Extension Shelf (SES) Feeder to IGX
Software support for Enhanced BXM and UXM cards
Software Release 9.2.10
Includes all features supported up to Release 9.2.01 and introduces the following additional features:
Support for Virtual Switch Interface (VSI) 2.2
Support for 16K connections
Support for UXM VP tunneling
Support for APS Annex B
Support for Multiple Protocol Label Switching (MPLS); MPLS-Virtual Private Network (VPN); and MPLS Class of Service (COS). See clarifications section for more details.
Software Release 9.2.01
Includes all features supported in Release 9.2.00 and introducing the following additional features:
Support for Virtual Trunking on the BXM card
Includes SONET line protection: APS on BXM-OC3 and BXM-OC12 (1+1)
Software Release 9.2.00
Introduces the following features:
Support for Virtual Trunking on the UXM card
Support for both ports and trunks simultaneously on the same UXM and BXM cards
Support for Hitless Rebuild including Disable Auto Bus Diagnostics
Support for UXM and BXM Multilevel Channel Statistics
Alarms for all service-affecting events
Support for Revision Interoperability between 9.1 and 9.2
Support for IGX and BPX trunk reconfiguration without outage
Support for ATM Forum Standard Compliant IMA Trunking with UXM (IGX 8400) Firmware Model B
Include SONET line protection: APS on BXM-OC3 and BXM-OC12 (2 card, 1:1)
Support for LMI/ILMI on BXM card
Support for feature mismatch on BXM and UXM cards
Support for Idle code suppression for video on UVM and CVM cards
Support VC traffic shaping on UXM port
Support for UXM STM-1 Electrical back card
Clarifications
1. 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.
where slot.port specifies the feeder trunk to configure. The details of the other parameters are as follows:
Timer
Description
Range (sec.)
Default (sec.)
T396
LMI polling timer
5-30
10
T393
SPC STATUS ENQUIRY timer
5-30
10
T394
SPC UPDATE STATUS timer
5-30
10
N394
Max retry count for SPC STATUS
ENQUIRY/ REPORT procedures
1-10
5
N395
Max retry count for SPC UPDATE
STATUS / ACK procedures
1 -10
5
2. In Release 9.2.31 the system parameter 2 (cnfsysparm2) 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.
3. 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.
4. 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.
5. Release 9.2.30 introduced four new commands in BPX:
addctrlr to add VSI capabilities to a trunk interface to which a Feeder of type AAL5 is attached. This command is basically run as the second step in adding a PNNI controller.
delctrlr to delete VSI capabilities from a trunk interface to which a Feeder of type AAL5 is attached. This command is basically run as the first step in deleting a PNNI controller.
cnfvsipart to configure VSI partition characteristics. Currently, we can only enable VSI ILMI functionality using this command.
dspvsipartcnf to display VSI partition characteristics. Currently, this command only displays information about VSI ILMI functionality.
6. There are changes in the following command starting from Release 9.2.30:
cnfrsrc
Allow start VPI = 0 for a VSI partition on a port interface, provided there is only one VSI partition on the port interface.
Prevent second VSI partition from being enabled on a port interface if the first VSI partition uses a start VPI = 0.
Prevent a VSI partition from being disabled on a trunk interface if a PNNI controller is attached to the trunk interface controlling partition being disabled.
cnfport
Prevent disabling ILMI protocol on a port interface, if a VSI ILMI session is active on a VSI partition on the port interface.
Prevent configuring ILMI protocol on port interfaces to run on the BCC, if a VSI ILMI session is active on a VSI partition on the port interface.
cnftrk
Prevent configuring ILMI protocol on a trunk interface to run on the BCC, if a VSI ILMI session is active on a VSI partition on the trunk interface.
addshelf
Prevent adding a feeder to a trunk, if VSI ILMI session is active on a VSI partition on the trunk interface.
7. 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.
8. 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.
Upgrading to 9.2.30 software first and then burning the BXM card with the MED 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 are level 2 or 3 will report 1-port group. Burning an MED image will result in 2-port groups, but for backward 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 MED image brought to the active state will not have above discrepancy.
9. 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 card 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.
40000 blocks maximum total (34000 blocks for 9.2 releases up to 9.2.23)
10. The minimum software required to run MPLS are:
BPX Switch Software Release 9.2.10 or later
BXM firmware must be MEA or later
IOS Software Release 12.0(5)T (refer to IOS Release Note)
Virtual Switch Interface (VSI) 2.2
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.
11. 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.
12. 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:
Support for only one partition, that is, a port or a trunk can be partitioned into one VSI partition along with AutoRoute.
A Virtual Trunk interface cannot have both VSI and AutoRoute simultaneously. It has to be either VSI or AutoRoute only.
There are nine Service Class Templates (SCTs) defined. SCT 1 is used for interfaces exclusively for MPLS. SCT 2 and 3 are respectively used for ports and trunk interfaces, which are exclusively used for PNNI. SCT 4 onwards are used for interfaces that are used for both MPLS and PNNI.
Master Redundancy is supported, that is, multiple controllers can control the same partition.
Only one controller can be added per trunk interface.
13. 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.
14. 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.
15. On the BXM and UXM, for the OC-3 MultiMode Fiber back cards, Y-Redundancy/hot standby is not supported due to hardware restrictions.
16. The trunk reconfiguration feature does not support IMA trunks.
17. HDM to UVM interworking for Nx64K connections is not supported in this release.
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 MEB or MEJ firmware for BXM Model E cards, or MFA to MFF firmware for Model F 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):
rsh <slot #> sys version
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:
cnftrkparm
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
9.1 or 9.2 or earlier than 9.2.30 switch software
BXM firmware earlier than MEB
BXM OC3/OC12 interface and the BXM is configured to channel statistic level 2 or higher.
Perform the following steps to avoid card mismatch:
Step 1 Upgrade BXM firmware to MEB.
Step 2 Upgrade BCC software to 9.2.30 or higher.
Step 3 Upgrade BXM firmware to MEC or higher (optional).
For all other cases, do the following steps:
Step 1 Upgrade BXM firmware to MEB 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.
If new BCC cards are to be installed as part of the upgrade to Release 9.2, then the physical card upgrade procedure described below must be completed as a separate activity from the Switch software upgrade.
If upgrading to BCC-4 cards on BPX 8600 nodes, complete the software upgrade first, followed by the BCC-4 physical card upgrade. If BCC-4 is already installed then upgrade as normal.
If any other type of BCC cards are being physically upgraded, complete the physical upgrade of the cards first, followed by the software upgrade.
Statistics collection must be disabled prior to and during the software upgrade process. The disabling must be done prior to the issuing of the first loadrev command.
Statistics sampling must be disabled prior to the issuing of the first loadrev command at the start of an upgrade. (Use the service level command off1/off2, turn off line statistic sampling, port statistic sampling, trunk statistic sampling, and connection statistic sampling.)
Note See the Compatibility Matrix for the tested/supported versions of other firmware and
software that work with this 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
All the BXM cards in the node are upgraded to Revision E, which is VSI Version 2 and CoS capable. After each BXM card is downloaded with the Revision E image, it temporarily experiences VSI outage until the BCC software is upgraded to the 9.2.34 image. The VSI outage during the upgrade is caused by the Revision E firmware not being backward compatible with VSI Version 1 features.
Note that from the TSC perspective, after a BXM is upgraded to the Revision 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 Revision 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 Release 9.2.35, the BCC recognizes the Revision 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.
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.
The interoperability functionality uses network lowest revision for:
Blocking the new feature unless network lowest revision is greater than or equal to the minimum supported revision for the feature
dspblkdfuncs
Version 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:
Any MGX 8220 Release 4.0, 4.1, and 5.0
Cisco WAN Manager (Cisco StrataView Plus) version 9.2
CiscoView version 2.00
UXM model ABB or later
BXM model MEB or later for Model E cards, MFA or later for Model F cards
Switch Software Release 9.2 is not compatible with UXM Firmware Model A.
Switch Software Release 9.2 is not compatible with BXM Firmware Model C or earlier.
Switch Software Release 9.2 is interworking with VNS 3.1.
DAS interworking with Release 9.2 is not supported.
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.
BCC Type
Firmware
BCC-32
H.B.J
BCC-3-32
H.C.M
BCC-3-64
H.D.M
BCC-4V
H.H.M
NPM Type
Firmware
NPM-32
R.B.S
NPM-64
R.C.S
NPM-32B
R.E.S
NPM-64B
R.F.S
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
Starting from Release 9.2.00, the IPX is no longer supported.
VSI 1.0 is no longer supported.
FastPAD is no longer supported.
The noncompliant IMA trunking (Cisco proprietary) supported in Model A of UXM firmware is not supported in Release 9.2.
Notes and Cautions
Additional Notes:
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 MEA/MEB/MEC BXM firmware and upgrading to MED or later, the 9.2.30 or later software has to be upgraded first so that the 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 message in dspcd "Inconsistency with logical PG #" (port group number). All earlier software will mismatch the card. This applied 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:
if (configured cell rate == full line cell rate) then
transmitted cell rate = full line cell rate
else
transmitted cell rate = from equation below or from table below
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.
1464865
56552
28832
19348
14559
11670
9738
8355
733860
54458
28278
19097
14416
11579
9674
8308
489558
52513
27744
18852
14277
11488
9611
8261
367288
50703
27231
18614
14139
11399
9549
8215
293888
49013
26736
18381
14005
11311
9487
8169
244938
47432
26258
18154
13872
11225
9426
8124
209966
45950
25798
17933
13743
11140
9366
8079
183733
44558
25353
17717
13616
11056
9307
8035
163327
43247
24923
17506
13491
10974
9248
7992
147001
42012
24508
17300
13368
10892
9190
7948
133642
40845
24106
17099
13248
10812
9133
7906
122509
39741
23717
16902
13129
10733
9077
7863
113088
38695
23341
16710
13013
10656
9021
7822
105012
37703
22976
16522
12899
10579
8966
7780
98013
36761
22623
16339
12787
10503
8912
7739
91889
35864
22280
16159
12677
10429
8858
7699
86485
35010
21947
15983
12568
10355
8805
7659
81681
34196
21625
15812
12462
10283
8753
7619
77383
33419
21311
15643
12357
10212
8701
7580
73515
32676
21007
15479
12254
10141
8650
7541
70014
31966
20711
15318
12153
10072
8599
7502
66833
31286
20423
15160
12053
10003
8549
7464
63927
30634
20143
15005
11955
9936
8500
7427
61264
30009
19871
14853
11859
9869
8451
7389
58814
29409
19606
14705
11764
9803
8403
7352
.....
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:
At least two virtual trunks share a common port at one node, but their remote end points terminate on different nodes.
The virtual trunks are used to carry networking (rt_op) traffic.
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."
The problem is caused by a misprogrammed trunk networking channel. In the above example, the misprogramming occurs at "node_B." A channel that should be programmed for ingress and egress operation is programmed as egress only.
Workarounds:
BXM firmware MFD contains the fix for this bug (CSCdr51875).
BXM virtual trunking (no VT wraparound) can still be implemented using Software Release 9.2.20 and higher.
If virtual trunks are not yet in use, the VT wraparound solution can be implemented in release 9.2.30 and higher (CSCdr51875)
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. Switch Software 9.2.30 or later and BXM firmware MFC and later support the attachment of multiple MPLS controllers.
Switch Software 9.2.30 or later and BXM firmware MFB and later support the attachment of a PNNI controller.
6. 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).
7. For a virtual trunk on a BXM/UXM, the Transmit Trunk Rate (the transmit rate of the virtual trunk) is configurable to match the PCR value of the subscribed public VPC service. In this release, the actual shaping rate for a virtual trunk is higher than the configured Transmit Trunk Rate (CSCdm80482). The actual virtual trunk shaping rates are 1/(n x 680 x 10-9) cells per second, where n is an integer from 1 to 29,411. In this release, the user-configured Transmit Trunk Rate is rounded to the next higher (as opposed to lower) actual shaping rate for shaping.
To configure a virtual trunk so that the actual shaping rate is not greater than the PCR value of the subscribed public VPC service, the following steps can be taken:
Step 1 Determine the n such that 1/(n x 680 x 10-9) cps (the actual shaping rate) is no greater than the PCR value of the subscribed public PVC service. For example, if the PCR value of the subscribed public PVC service is 10 Mbps or 23,585 cps, the n will be 63 and the actual shaping rate is 23,342.67 cps.
Step 2 Configure the Transmit Trunk Rate for the virtual trunk to be less than 1/(n x 680 x 10-9) cps but greater than 1/((n+1) x 680 x 10-9) cps. For example, if the PCR value of the subscribed public VPC service is 10 Mbps or 23,585 cps, configure the Transmit Trunk Rate for the virtual trunk to be less than 1/(63 x 680 x 10-9) = 23,342.67 cps but greater than 1/(64 x 680 x 10-9) = 22,977.94 cps.
8. 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).
9. 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).
10. 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.
11. 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.)
12. Hitless rebuild has similar limitations to that of a switchcc and full rebuild:
On IGX nodes, there is a four second continuity break. (Same as in a switchcc.)
There might be brief communication breaks with other nodes in the network. This will be logged in the event log of the node. There is no traffic loss or trunk failures. (This is similar to a switchcc and depends highly on the network and number of connections.)
Some line/trunk cards that are in the standby state may reset during a hitless rebuild.
The statistics that are collected by the Cisco Wan Manager will not be maintained across a rebuild.
Some will be re-enabled automatically. These include:
Auto statistics
Summary statistics
Real-Time statistics
All other statistics have to be re-enabled for collection after a hitless rebuild takes place. These mainly include the user statistics.
13. 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.
14. 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.
15. 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:
Leave the statistics level untouched (this will work for UXM cards upgraded from 9.1)
OR
Set level 2 on the card
16. 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:
17. 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. The standards-compliant IMATM-B on MGX 8220 5.0 is not yet released. Hence, when the network is upgraded to 9.2., the UXM will be running compliant IMA protocol and the IMATM-B will still be running the proprietary IMA communication protocol. They will no longer communicate and the trunk will fail. This will be fixed in the MGX 8220 5.0 release containing IMATM-B. However, it should be noted that an upgrade at that time will also incur some amount of downtime as there will be a difference in timing between the MGX 8220 upgrade and the switch software upgrade. There should be no effect to UXM-IMA trunks connected to other UXM-IMA trunks in 9.1 to 9.2 interoperability mode.
18. 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.
19. 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).
20. 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.
21. 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:
There is no limitation on the number of ports that can have LMI/ILMI enabled.
When running ILMI on the BXM, ILMI version 3.1 WITHOUT address registration is supported.
22. 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.
23. 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.
24. 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).
25. For the loadrev operation, it is important that the Cisco Wan Manager/TFTP buffers are maintained at their default size.
26. 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.
27. 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.
28. When deleting trunks, there is a known limitation with the switch software. The deltrk command should always be executed on the node that remains as part of the network, rather than from the node that ends up being removed from the network. This is to ensure that all the necessary updates are sent to the rest of the network (CSCdi85134). Also if the command is not used as recommended here, a software error 419 could occur (CSCdi91285).
29. 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.
30. 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.
31. On a heavily loaded BPX 8600 node, during connection rerouting, the status of a particular connection is indicated as OK even though the line status of the other end of the connection is listed as failed. The connection is in fact OK, because the conditioning of the connection (to update the status for both ends) is done by a low-priority process so that the rerouting of the connections can be given high priority. The status will be eventually updated. (CSCdj10762)
32. A node whose number is greater than 63 cannot have a clrcnf operation performed on it. This is a design limitation. A clrallcnf can be done, or the node must be renumbered to less than 63 before running clrcnf (CSCdj14920).
33. The interface between a BXM feeder trunk and an MGX 8220 feeder is always considered to be an NNI interface. (CSCdj16808)
34. 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:
0-3999 connections
Polling Rate: 5 Minutes (or higher)
4000-7999 connections
Polling Rate: 10 Minutes (or higher)
> 8000 connections
Polling Rate: 15 Minutes
35. 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.
36. 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 dspcderrscommandon 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.
37. 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.
38. 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).
39. In order to test/simulate the Y-redundant switchover of ASI T3 or E3 pairs the resetcdcommand 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).
40. 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.
41. 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.
42. 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.
43. Care must be taken when changing the Deroute Delay parameter, which is controlled by the cnftrkcommand. 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 (usingoff1/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.
9. Currently, T3-3 and T3-2 back cards are not interchangeable between ASI and BNI front cards, as this has been the case since the introduction of these cards. The back cards must be configured using cnfbkcd (with setnovram) so as to avoid back card mismatch (CSCdj41999).
Additional Documentation
In order to take advantage of the dual SIU when upgrading to the BCC-4, the BPX 8600 node must have a new backplane which has dual traces incorporating with the BCC-4.
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.
16-Bit Word
Byte # (hex)
Contents
0
0,1
Hardware revision
1
2,3
Backplane Type (usually 0x65=101 decimal)
2
4,5
Backplane version (0x0000:old 0x0001:new)
3
6,7
Backplane serial number in ASCII - MSB
4
8,9
"
5
A,B
" LSB
6
C,D
Board FAB number, in ASCII - MSB
7
E,F
"
8
10,11
"
9
12,13
"
A
14,15
"
B
16,17
" LSB
C
18,19
Unused
D
1A,1B
Unused
E
1C,1D
Unused
F
1E,1F
Checksum bytes - CURRENTLY NOT SUPPORTED
The peak intervals are controlled to be only those values for which peaks can be accurately collected. The rules for peak intervals are as follows:
It cannot be 0.
It must be a multiple of the polling interval.
It must be a factor of the bucket interval.
It can be the same as the bucket interval.
There are additional commands to control trunk and line loopbacks in this release:
addlnlocrmtlp <trunk> | <line>
On the node on which it is executed, it creates a loopback within the port such that the cells do not leave the card.
addlnloclp <trunk> | <line>
On the node on which it is executed, it creates a loop such that incoming cells are looped back to the other end.
dellnlp <trunk> | <line>
Removes the loopback added by either of the above two commands.
The card synchronization (Hitless-switchcc) feature can be turned on/off using on3/off3 command. For example, enter at the command line:
on3 4
This will enable the card-synchronization feature.
off3 4
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:
Front card supports card synchronization
Additional debug commands are added to allow synchronization between the interface card and the CC database:
synccd <slot_number>|*
The <slot_number> is for a particular slot that supports the card synchronization feature; * For all cards that support the card-synchronization feature.
dspsyncstats <slot_number>|*
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
PCB Description
dspcds Name
Card Name in FW Image
Model
Latest F/W
Min F/W
BCC boot
BCC
BCC
B
HBJ
HBJ
BCC3-32 boot
BCC-3
BCC
C
HCM
HCM
BCC3-64 boot
BCC-3
BCC
D
HDM
HDM
BCC4 boot
BCC-4
BCC
E
HEM
HEM
BCC4-128 boot
BCC-4
BCC
H
HHM
HHM
ASI 2T3/2E3
ASI-T3
ASI
C
UCF
UCF
ASI 2T3/2E3
ASI-E3
ASI
C
UCF
UCF
ASI-155-E
ASI155E
ASI-155
E
WEC
WEC
ASI-155
ASI-155
ASI-155
H
WHC
WHC
ASM
ASM
A
GAC
GAC
BNI-3T3/3E3
BNI-T3
BNI
C
TCM
TCM
BNI-3T3/3E3
BNI-E3
BNI
C
TCM
TCM
BNI-155
BNI-155
BNI-155
B
VBR
VBR
BNI-155-E
BNI155E
BNI-155
D
VDR
VDR
BXM-BME
BME
BME
K
n/s
n/s
BXM-T3-8/12
BXM-T3
BXM
E
MEJ
MEB
BXM-T3-8/12
BXM-T3
BXM
F
n/s
n/s
BXM-E3-8/12
BXM-E3
BXM
E
MEJ
MEB
BXM-E3-8/12
BXM-E3
BXM
F
n/s
n/s
BXM-155-4/8
BXM-155
BXM
E
MEJ
MEB
BXM-155-4/8
BXM-155
BXM
F
n/s
n/s
BXM-622/622-2
BXM-622
BXM
E
MEJ
MEB
BXM-622/622-2
BXM-622
BXM
F
n/s
n/s
BXM-T3-8E/12E/12EX
BXM-T3
BXM
E
MEJ
MED
BXM-T3-8E/12E/12EX
BXM-T3
BXM
F
n/s
n/s
BXM-E3-8E/12E/12EX
BXM-E3
BXM
E
MEJ
MED
BXM-E3-8E/12E/12EX
BXM-E3
BXM
F
n/s
n/s
BXM-155-4D/8D/4DX/8DX
BXM-155
BXM
E
MEJ
MED
BXM-155-4D/8D/4DX/8DX
BXM-155
BXM
F
n/s
n/s
BXM-622-2D/DX/2DX
BXM-622
BXM
E
MEJ
MED
BXM-622-2D/DX/2DX
BXM-622
BXM
F
n/s
n/s
Note BXM MFD firmware can be used to upgrade the BXMs during a switch software upgrade
from Release 9.2 to Release 9.3.
IGX 8400 Firmware Compatibility
PCB Description
dspcds Name
Card Name in Firmware Image
Model
Latest F/W
Min F/W
NPM boot
NPM
NPM
A
RAS
RAR
NPM 32 boot
NPM
NPM
B
RBS
RBR
NPM 64 boot
NPM
NPM|NPM-64
C
RCS
RCR
NPM-B 32 boot
NPM
NPM|NPM-32B
E
RES
RER
NPM-B 64 boot
NPM
NPM|NPM-64B
F
RFS
RFR
IGX-ALM/A
ALM
ALM-A
A
CAE
CAE
IGX-ALM/B
ALM
ALM-B
B
CBK
CBH
IGX-BTM/B
BTM
BTM
A
IAF
IAF
IGX-BTM/B
BTM
BTM
B
IBL
IBL
IGX-BTM/B
BTM
BTM
D
IDC
IDC
IGX-CVM-DS0A
CVM
CVM
A
DAF
DAF
IGX-CVM
CVM
CVM
B
DBF
DBF
IGX-CVM-TT
CVM
CVM
C
DCA
DCA
IGX-FRM
FRM
FRM
D
FDZ
FDZ
IGX-FRM-31
FRM
FRM-31
E
FEZ
FEZ
IGX-FRM-2
FRM
FRM-2
F
FFD
FFD
FRM (B)
FRM
FRM
H
FHB
FHB
IGX-FRM
FRM
FRM
J
FJB
FJA
IGX-FRM-31
FRM
FRM-31
K
FKB
FKA
IGX-FTM
FTM
FTM
B
JBJ
JBJ
IGX-FTM
FTM
FTM
C
JCB
JCB
IGX-HDM
HDM
HDM
C
SCF
SCF
IGX-LDM
LDM
LDM
C
LCC
LCB
IGX-NTM
NTM
NTM
E
NEK
NEK
IGX-NTM (B)
NTM
NTM
F
NFK
NFH
IGX-UFM-4C/8C
UFM
UFM-C
A
ZAT
ZAN
IGX-UFM-4C/8C
UFM
UFM-C
B
ZBD
ZBA
IGX-UFM-8C
UFM
UFM-C
C
n/s
n/s
IGX-UFM-U
UFMU
UFM-U
A
YAL
YAH
IGX-UFM-U
UFMU
UFM-U
B
YBC
YBA
IGX-UFM-U
UFMU
UFM-U
C
n/s
n/s
IGX-UVM
UVM
UVM
A
DAE
DAC
IGX-UVM
UVM
UVM
B
DBD
DBD
IGX-UVM
UVM
UVM
C
DCA
DCA
IGX-UVM
UVM
UVM
D
DDF
DDF
IGX-UVM
UVM
UVM
E
DEH
DEA
IGX-UXM
UXM
UXM
B
ABJ
ABB
IGX-UXME
UXM
UXM
B
ABJ
ABB
Note IGX-UVM model E is a superset of models A, B, and C firmware. A, B, and C are
obsoleted and should not be used.
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.
Bug ID
Description
CSCdk22430
Symptom:
Checksum word 15 of backplane nvram is not recalculated when words 0-14 are updated using cnfbpnv.
Conditions:
Observed with BPX 9.1.01.
Workaround:
No workaround is available at this time.
CSCdk69912
Symptom:
VCQdepth does not conform to configured values.
Conditions:
Frame Relay connections on UFM cards when non-standard Frame Relay parameters are in use on the switch. (via cnfsysparm)
Workaround:
None.
Further Description:
Regardless of the system setting for the use of standard/non-standard FR parameters (via cnfsysparm), the UFM configures the VCQ to 2(be+bc). The switch software computes the be/bc values internally when the nonstandard parameter set is in use. UFM FW version YAF is also required to fix this issue.
CSCdk77478
Symptom:
Large number of card polls are generated when an SNMP walk is done for connection or port stats, which greatly decreases the amount of idle time.
Conditions:
The excessive card polling occurs when an SNMP walk is done on IGX connection or port stats or on BPX port stats.
Workarounds:
None.
Customer Impact:
The impact is mainly performance. The system response time will slow down (but not stop) when these requests are occurring. The task that generates these polls is at the same priority as the other user input tasks, so important events such as reroutes, will not be blocked from running.
CSCdk91790
Symptom:
Switch software system idle time is below 30% when more than ten UVMs are activated.
Conditions:
Switch software polls each activated UVM for modem status every second for each port. Switch software also spends time in processing the responses of the modem polling.
When many UVMs are activated, the modem polling handling consumes a lot of system time and resources (buffer queue) which affect system performance. UVM firmware has supported asynchronous event to report modem event. SWSW needs to stop polling modem status if the FW in UVM supports the async event.
Workaround:
Use cnfnodeparm 46 to increase polling timer to improve system performance.
CSCdm22426
Symptom:
While using jobs to down or up the connection based on a jobtrigger, the job will fail if dspbob is executed while the control signal toggle.
Conditions:
Observed with IGX 8.2.56.
Workaround:
Retrigger the job after dspbob.
CSCdm60702
Symptom:
When a bus error occurs on a node and a rebuild results, other nodes in the network will see the rebuilding node in the degraded state. This shows up as "UNDeg" in the dspnds screen. A log message appears indicating that the rebuilding node is unreachable due to degradation. The unreachability will recover automatically.
Conditions:
Occurs only if a node rebuilds due to a bus error, and the degraded mode is enabled in cnfnodeparm. Will not occur if a node switches processors due to a bus error.
Workaround:
No workaround needed. No adverse effects.
CSCdm60707
Symptom:
Can take longer than expected to clear unreachability with a node that has rebuilt due to a bus error. Other nodes in the network will declare the node unreachable due to degradation ("UNDeg"). The unreachability will eventually clear automatically.
Conditions:
Occurs only if a node rebuilds due to a bus error, and if degraded mode is enabled in cnfnodeparm on that node.
Workaround:
None needed. Problem clears automatically.
CSCdm78849
Symptom:
The message "CMI message drop" appears occassionally on the UXM debug console. If this occurs 10 consecutive times, SWSW will declare a swerr 103 and subsequently reset the card. The chances of this occurring 10 consecutive times on the same message are extremely low.
Workaround:
None (not required).
CSCdp57264
Symptom:
On c7500, if multiple subinterface are configured on an ATM interface connected to BPX, each subinterface with 1 PVC and BPX is configured to send ILMI traps. When the PVCs' state is changed on BPX, BPX will send out a trap for all the PVCs but c7500 only brings down one subinterface (one pvc).
Conditions:
Unknown.
Workaround:
None.
CSCdp98648
Symptom:
Equipment MGR cannot tell the difference between BXM legacy or enhanced.
Workaround:
Log into the BPX node, execute dspcd XX to determine the number of channel supports. The enhanced version of the BXM card has 61K channels, and the BXM card has less than 61K channels.
CSCdr05291
Symptom:
switchIfService must be specified to delete feeder trunks, but not routing trunks.
Conditions:
This requirement confuses CiscoView users.
Workaround:
Use the CLI commands to delete feeder trunks.
CSCdr21149
Symptom:
Active BCC experiences a 1000003 (memory access error) abort.
Conditions:
Unknown
Workaround:
Switch software will switchover to standby BCC if available.
CSCdr25253
Symptom:
The AIS-Path alarm is not seen on a SONET line when an Path AIS is sent to it.
Conditions:
Using test equipment during compliance testing, an AIS-Path alarm is generated. The expected result is to 1. See AIS-P reported on StrataView/CWM 2. See the AIS-P statistic incremented 3. See the line in Major AIS-P alarm
Workaround:
None.
CSCdr25273
Symptom:
Switch software does not report an alarm when AIS-Line alarm is generated on a SONET line.
Conditions:
Using test equipment during compliance testing, an AIS Line alarm is generated. The expected result is see an AIS Line alarm on the line, have StrataView/CWM report an AIS-L alarm, and see the AIS statistic incremented
Workaround:
None.
CSCdr25275
Symptom:
An RFI-Line alarm does not occur when an RDI-L alarm is generated on a SONET line.
Conditions:
Using test equipment during compliance testing, an RDI Line alarm is generated on a line. The expected result is to see an RFI-L alarm on StrataView/CWM and for dsplns to show an RFI-L alarm on the line being tested
Workaround:
None.
CSCdr25281
Symptom:
When an RDI-Path alarm is generated on a SONET line, switch software does not produce the expected result.
Conditions:
Using test equipment during compliance testing, an RDI-Path alarm is generated for 2 +/- 0.5 seconds on a line. The expected result is that StrataView/CWM would report an RFI-P alarm condition and the dsplns command would show an RFI-P alarm on the line
In a second test, RDI-Line is generated continuously on a SONET line. The expected results are that StrataView/CWM would report an RFI-P alarm condition and the dsplns command would show a RFI-P alarm on the line.
Workaround:
None.
CSCdr26043
Symptom:
BXM cards are going to Active-F state.
Condition:
Background test enabled.
Workaround:
Replace the BXM card or the BCC card.
CSCdr26161
Symptom:
During a burnfwrev on a UXM card, a message "Already burning firmware. Try again later" appears for a long period of time (more than 10 minutes) if the UXM card is reset during the burnfw process (after the download is complete, i.e., after the Burn Addresses stop updating).
Conditions:
Reset must be done after all burn addresses are updated.
Workaround:
Do not reset the card during burnfw process.
CSCdr29721
Symptom:
SW log 9000 and 103 occurs during downgrade from 9.2.31 to 9.2.3g
Conditions:
This problem occurs during a loadrev 9.2.3g is tried when the primary was running 9.2.31, then ran runrev 0.0, and did a lanbtld. After a lanbtld swlog 9000 and 103 occured.
Workaround:
None
CSCdr30543
Symptom:
Cell loss and invalid frame format for a UXM-FRM connection
Conditions:
The traffic was pumped from UXM port, using the standard frame relay parameters.
Workaround:
None
CSCdr30911
Symptom:
Software error 3041 is logged after a specific sequence of commands are executed on a BXM trunk card.
Conditions:
This occurs if there is a connection routed through a BXM trunk and the following sequence of events occurs: 1) The card is downed (dncd) 2) The trunk is deleted from the network (deltrk) 3) The trunk is downed (dntrk) 4) The card is upped (upcd)
Workaround:
None. Recommend that this sequence not be executed.
CSCdr31598
Symptom:
This problem is the same as CSCdr41370 in BPX. The average cell per second values for the dspchstat screen does not always reflect the correct transmit rate. It ramps up to the transmit rate, sometimes very slowly, some times more quickly.
Conditions:
This problem will occur whenever the dspchstats command is issued.
Workaround:
For the dspchstats screen, the only values that are incorrect are the "Collection Time", and "Rate (cps)." Extrapolate this information from the TFTP or USER interval statistics which has a minimum granularity of 5, 10, or 15 minutes based on the number of connections they have in the network. If we divide the "Port Cells Received on Channel" statistic by the interval (5, 10, or 15 minutes) we will get the approximate average CPS.
Further Problem Description:
The root cause was that a timer's initialization was removed by a different defect fix. The result or removing this initialization is that the vcs_cur_ticks timer does not get reset so it contains the last time that the previous response was received rather than when this response was received, so the time value is too large.
Then when the average CPS is calculated, since the time value is too large, the average is way to small. It will eventually (over an extremely long period of time) approach the correct value, asymptotically.
The sequence is as follows:
t = A Normal statistics polling response is received from the card, vcs_cur_ticks is set to now (A).
t= B Command clrchstats is issued, which sets flags to drop the next sample (for summary statistics) and to re-init the vcs_cur_ticks field.
t = C Command dspchstats is issued, which will cause a statistics poll to be sent to the card and a response to be sent back nearly instantaneously.
When the response is received we see that the summary stat filter flag is set so we drop the first response (and we should set the vcs_cur_ticks field at this point but we don't).
t = D The dspchstats sends its second poll request, and we get back the response.
We update the data for cells RX/TX, etc. We calculate the amount of time this data is for by subtracting the vcs_cur_ticks count (A) from the current time (D) so the time delta is (D - A).
Here is the problem. This time value should be (D - C) but because the initialization code was removed it is (D - A), too big. The connection polling rate can be configured to 5, 10 or 15 minutes, therefore the amount of time that this can be off by is 4'59", 9'59" or 14'59". It can also coincidentally be correct if t = A and t = C are very close to each other.
CSCdr33931
Symptom:
Nether dsplog (it has no record) nor CWM (it didn't receive a trap) when APS active line is in Yellow alarm.
Conditions:
When APS line is in yellow, it is expected to log an entry in dsplog as well as set a trap in CWM. This bug is introduced because of a Release 9.2.32 fix for MR 000253 (CSCdr26613) where the trunk status is set to clear if the active line is Yellow and the standby line is OK. Use the dsptrks command to show the active line status and trigger the trap, unless a clean and easy path is found to send a trap without setting the trunk to the Yellow alarm status.
Workaround:
Use the dspapsln command to monitor APS line status. But do not reroute connections.
CSCdr41957
Symptom:
Software errors 506 and 589 are logged.
Condition:
The following procedure produces swerr 506 & 589
cp 5 55 05 2 1 2 3 12 c 0 /* Sec Trc Alarm */ Node 1 ------- addyred 2 3 uptrk 2.2 addtrk 2.2 (added to some other node, node2) addapsln 2.2 3.2 1 addlnloclp 2.2 rcp 5
Workaround:
None.
CSCdr45021
Symptom:
SCT 1 is the default SCT reserved for MPLS. A warning message in the configuration screen indicatez that the default is SCT 1 for MPLS and should be changed to SCT 3 for SES.
Conditions:
When an SES trunk is provisioned, if the default SCT is not changed to SCT 3, the trunk will fail to come up.
CSCdr47848
Symptom:
When a connection is added between an Axis feeder trunk and a BME card, the shelf goes unreachable, only if the shelf is added with NNI type headers.
Workaround:
Add the shelf using the UNI header or use standalone axis shelves.
CSCdr48000
Symptom:
During an upgrade from Release 9.1.09 to 9.2.30, connections over a UXM trunk suffer from approximately 20 second outages whereas a connection over NTM's suffers 3 seconds
CSCdr50690
Symptom:
When checking dspvsipartinfo, the available bandwidth may be incorrectly shown for existing partitions.
Workaround:
Software 9.2.30 is currently used.
CSCdr52621
Symptom:
Enabling channel statistics causes idle time on the node to drop to an unacceptable level.
Conditions:
Occurs when many channel statistics are enabled and/or many connections exist on the node.
Workaround:
None.
CSCdr56010
Symptom:
CBR connections are missing on three BPX nodes during the upgrade from 9.1.22 to 9.2.23.
Condition:
When the nodes were upgraded from 9.1.22 to 9.2.23, this occured once and could not be recreated. The cause for the missing conns are unknown at this time.
Workaround:
None.
CSCdr64541
Symptom:
dspcntrstats displays negative values for large real-time counters. Counter Cbrctxl has a negative value.
Conditions:
Observed on BPX with large values for real-time counters.
Workaround:
None.
CSCdr74046
Symptom:
Software log 1011 occurs on BPX node.
Conditions:
BCC reseated and no standby BCC. Software log indicates the BCC lost mastership requiring hardware support.
Workaround:
None.
CSCdr75042
Symptom:
The remote end of FRSM to FRSM encount the FECN when enable the NNI with FCES option
Conditions:
test set --> kiwica71 11.3.1.31 (chan 227) <--> kiwica82 11.7.12.31(BNI) <--> NNI <--> kiwica81 11.8.12.31(BNI) <-- >kiwica71 11.4.1.31 (chan 229) (loopback)
Workaround:
None
CSCdr78213
Symptom:
Switch software error 3000 logs after executing the following commands for NPM and UXM on IGX: resteccd <slot) (NPM card) upln <slot.port> (UXM card) . This error only logs the first time and did not reproduce if the upln command is repeated
Conditions:
This occurs in Switch Software Release 9.2.34 with IGX on NPM and UXM cards.
Workaround:
None available at this time.
CSCdr89767
Symptom:
Soft software 945 is logged continuously.
Conditions:
Ongoing failure. Normal network conditions
Workaround:
None at this time. Reconfiguration of nwip and lanip did not help
CSCdr91934
Symptom:
Deletion of connection loop on which a port loop is added does not block.
Conditions:
Local loop is added on the port with addloclp and the loop is deleted with dellp on one of the connections.
Workaround:
None.
Further Problem Description:
dellp issues message "Port Loopback - VPI/VCI must not be specified" but still allows the user to continue whether to delete the loop back. If user requests the loopback deletion, the loop back on either the port or the connection is not deleted and a software log 750 occurs.
CSCdr95450
Symptom:
Software log 105 occurred when removing and then adding active Y-Red BNI-155.
Conditions:
This may occur on a BPX node. It has not been seen on a BNI-E3 or BNI-T3 card. The cause is still under investigation.
Workaround:
None.
CSCdr98080
Symptom:
Software log 3052, 3017, and 362 are observed on a BPX node during switchcc.
Conditions:
This may occur on a BPX node during switchcc or a node rebuild. The cause is still under investigation.
Workaround:
None.
CSCds09938
Symptom:
Once IGX has been added as a feeder shelf on BPX, pass sync cannot be altered.
Workaround:
Configure pass sync before adding the IGX shelf on the BPX.
CSCds13050
Symptom:
addcon from the routing node to feeder node indicates SIW types of connections not applicable between ATM ports.
Conditions:
Connection type atfxfst from BXM-T3 card to FRSM-4T1 PVC.
Workaround:
None.
CSCds16693
Symptom:
Software log 1012 occurs on BPX when deleting a bundle of connections.
Conditions:
This may occur on an BPX node. The cause is still under investigation.
Workaround:
None.
CSCds18089
Symptom:
BPX cnfapsln displays "Signal Detect" instead of "Signal Degrade".
Conditions:
Configuring APS on BPX with cnfapsln.
Workaround:
None.
CSCds19443
Symptom:
Software log 3017 occurs on a BPX node BXM feeder trunk.
Conditions:
This may occur on an BPX node. The cause is still under investigation.
Workaround:
None.
CSCds20977
Symptom:
Signal Degrade cleared in internal BXM states, but SWSW still shows Signal Degrade.
Conditions:
SWSW less than 9.2.34, and SD condition cleared from line.
Workaround:
Upgrade SWSW to at least 9.2.34
Further Problem Description:
The problem exists because older switch software does not know how to interpret the "Clear SD" message coming from the new firmware. So, the firmware and SWSW states get out of synch.
CSCds21195
Symptom:
The node became unavailable at the U/I. Several cards removed and reinserted themselves. S/W error 112 was logged repeatedly.
Conditions:
None.
Workaround:
Identify the faulty card using the information in the SWLOG Assistant, remove it from the node and replace it.
CSCds24390
Symptom:
con_verify debug command is not supported in Release 9.2 and later.
Conditions:
All releases of 9.2 and 9.3.
Workaround:
None.
CSCds32703
Symptom:
IGX feeders connected to BPX become unreachable when upgrading IGX from Release 9.1.10 to 9.2.33.
Conditions:
The cause is still under investigation. The was observed on a single BPX in a test environment, and was reproducible on that node only.
Workaround:
A command can be run to send an event to the SAR state machine to clear the unreachability. The TAC should be consulted for assistance.
CSCds33823
Symptom:
After upgrading switch software from Release 9.1.08 to 9.2.34, 4.8kbps connections on LDMs may fail if using DFM.
Conditions:
The failed connections are seen immediately after upgrading the switch software. It appears only for connections where one endpoint is 9.1.08 and the other is 9.2.34.
Workaround:
Change the speed setting of the failed connections, or to disable DFM.
Further Problem Description: After the connections have failed due to too many routing attempts, issue the command rrtcon <connection_id>. Afterwards, issue rrtinf.
CSCds34151
Symptom:
There is no specific ALARMS when node in alarm such as LOC, LOC AIS-P PATH-RDI ALL we see is 'LineAlamTypeOTHER'
1) Connect the HP tester to the BXM OC3 port and the run CWM to manage this BPX node 2) Upline and port on the BXM card 3 At HP tester generate LOP or AIS-P or PATH RDI or LOC and verify the alarm was reporting on BPX 4 At the CWM, a) launch Equipment manager, b) select BPX node c) select BXM port and right click on the selected port d) and choose 'configure' then the popup 5 At the Line configure GUI, click 'BPX PhysicalLineconfigure' select 'BPX: Sonet LineConfigure'
Workaround:
None
CSCds34334
Symptom:
Traffic statistics on local BNI IMA trunk does not fail when the trunk card at the remote end is downed.
Conditions:
Connection between ASI-E3 and ASI-155E between two BPX nodes. Connection has a preferred route with d option through IMA trunk on BNI. IMA trunk between two BPX nodes through an AXIS node. Trunk card at remote end is downed.
Workaround:
None.
CSCds47567
Symptom:
Nodes declared unreachable intermittently.
Conditions:
Observed with IGX 9.2.33. Problem occurs even though trunks exists between the nodes and occurs after topology changes. Node remains in this state for 5-10 minutes before recovering.
Workaround:
None.
CSCds47570
Symptom:
Unable to set SCR to 6 cps through SNMP.
Condition:
This is due to an invalid atmEndptSCR and atmEndptOeSCR range 7 - 1412830 specified in switch.m. It should be 6 - 1412830
Workaround:
Use CLI commands cnfcon or addcon or cnfcls if SCR is configured to 6 cps.
CSCds47671
Symptom: dspcurclk displays incorrect trunk numbers in the clock path
eg. z5b 7--30z2a 24-- 9.1z3b
This should be 24.1 (the port is missing)
Conditions:
The following clock path in dspcurclk is needed for this problem to surface.
dsptech executed on the standby causes software log entry 1432. This log event is benign trying to get the net revision and can be ignored. dsptech is only supported on the active processor.
Conditions:
Executing dsptech on the standby.
Workaround:
Run dsptech on the active processor.
CSCds57049
Symptom:
Card in active-F status when two or more lines of the card are in major alarm.
Conditions:
Two or more lines in major alarm
Workaround:
Issue the command: resetcd [slot] f. This will only clear the status until the next time the card falls into the above conditions.
CSCds57315
Symptom:
Communication break observed between IGX feeder and IGX routing node following addshelf.
Conditions:
Observed with IGX 9.2.23 and UXM firmware CA19.
Workaround:
None.
CSCds58869
Symptom:
Resetsys causes software error to be logged on BPX.
Conditions:
Not exactly known.
Workaround:
None.
CSCds61240
Symptoms:
When adding connections on a BPX node, observe "Unknown Response (17)". This occurs while adding AUSM to AUSM connections.
Conditions:
On the remote end, 1. Sum of minutes exceeds the port speed. 2) Total number of connections exceed the number of connections that are allowed for the configured polling rate. BPX nodes running Release 9.3.10 MGX PXM firmware running 1.1.31 AUSM running 10.0.20.
Workaround:
Change the pooling rate to 10 minutes which allows up to 8000 connections using the cnfsysparm command
CSCds63710
Symptom:
deltrk/dntrk executed on virtual trunks causes software error 992.
Condition:
Delete then Down several virtual trunks on BPX.
Workaround:
None.
CSCds64587
Symptom:
copycons allows atfx connections to be added on FRM card which does not support atfx connections.
Conditions:
Observed on IGX. Addcon cannot add atfx connections to FRM card while copycons can.
Workaround:
None.
CSCds66861
Symptom:
Connections stop routing across a UXM trunk when the configured gateway connection limit is reached. By increasing the number of gateway connections supported on the trunk you can only route further connections until the gateway connection limit is once again reached. Then no further via connections will route and they report the failure as unable to find route. There is sufficient bandwidth and conid's to support the remaining failed connections.
Conditions:
UXM trunk card with CGW and SGW connections pref routed across it. Found in SWSW 9.1.19 and UXM BBJ on E3 trunk cards.
Workaround:
1. Down one of the connections that is a gateway connection on the trunk that has reached its limit for gateway connections. 2. Wait for all the failed connections to reroute and come to normal status. Add new via connections if required. 3. Up the connection that was downed in the first step.
CSCds68083
Symptom:
After BCC is rebuilt, PVCs are not programmed in standby BXM for Y-red and APS 1+1.
Conditions:
Occurs with Switch Software Release 9.2.32 and with Y-red cards with only ports.
Workaround:
Reset standby BXM after BCC is rebuilt which will reprogram all PVC in standby BXM.
Further Problem Description:
After BCC is rebuilt, tstconseg logs software error 9082.
CSCds68131
Symptom:
New PVCs are not programmed on standby BXM after switchcc or rebuild.
Conditions:
Occurs with Switch Software Release 9.2.32 for BXM Y-red pairs with ports only.
Workaround:
Reset standby BXM after switchcc or rebuild.
Further Problem Description:
Using tstconseg for the new added PVC will log software error 9082.
CSCds68363
Symptom:
dsplogcd shows the first_avail_lcn is UNKNOWN after switchcc or system rebuilt.
Conditions:
Occurs on the BXM card with only ports.
Workaround:
Issue addcon to add new PVC, dsplogcd will show correct first_avail_lcn.
CSCds69729
Symptom:
The following symptoms are related to this defect:
On IGX, tstconseg performs the entire number of iterations when the abort flag option is set and the test fails.
On BPX, the default value for the abort flag is "not to abort" but tstconseg stops at first encounter of failure when the abort flag option is not specified.
Conditions:
On IGX: The following conditions are needed for this problem to occur. 1) tstconseg is run on a connection with the abort flag option SET and Loop count > 1. 2) The test fails for the connection.
On BPX: The following conditions are needed for this problem to occur. 1) tstconseg is run on a connection with Loop count > 1 and the abort flag option is not specified. 2) The test fails for the connection.
Customer Impact:
1) On IGX, the test should abort after the first failure. Instead, it continues until for the entire count, blocking other commands and wasting CPU time. 2) On BPX, the test should continue after the first failure when the abort flag option is not specified. Instead, it stops and user may not know if the test will succeed on a retry.
Workaround:
Set loop count = 1.
CSCds72447
Symptom:
Cost-based route recovery allows route to exceed connection cost cap.
Conditions:
Cost-based routing could not find a path for the connection. New route calculated exceeded the connection cost cap yet the connection routed. Observed in 9.1.24 and 9.2.35.
Workaround:
Possible workarounds include using cnfpref to specify a preferred route. This will provide a route for the connection. Cost-based routing can be disabled using cnfcmparm. Also, the trunk cost can be tuned with cnftrk. The connection cost cap can be configured with cnfrtcost.
After upgrading IGX from Release 9.1.19 to 9.2.35.
Workaround:
None.
CSCds75929
Symptom
dspctrlrs output is truncated. It does not display the header "Intfc Type", rather it displays the header "Intfc" and truncates the "Name" of the feeder.
dspctrlrs output in BPX does not wraparound if more than one screen of controllers are added. The CLI neither queries the user for displaying more output nor the display is clear.
Condition
This problem is seen only in BPX and the screen display is cluttered only when the number of controllers exceeds 12 to display more than one page.
Workarounds
None. dspnode can help to identify the feeders and their type.
CSCds76087
Symptom:
Software error 3017 is logged during the software upgrade from Release 9.1.19 to 9.2.35
Condition:
Occurs on one particular IGX feeder node.
Workaround:
None.
CSCds80403
Symptom:
Communication failure(s) and Looped back alarms are getting cleared after hitless rebuild.
Condition:
This will occur only when 1) Communication failure(s), Looped back alarms exists and hitless rebuild occurs.
This will occur only on IGX platform.
Workaround:
None.
CSCds81526
Symptoms:
1. The BPX and IGX nodes are loaded to their conns. limit. 2. dncon COS 0 i, is issued on bpx03 3. It takes more that 2.5 hours to down about 70% of 16K conns. (Performance issue) 4. When the conns are downed, the master side and the slave side of the conn show a correct down state 5. Then, upcon COS 0 is issued to up all downed conns, the command is issued on bpx03 6. After CPU idle time reached 70%+ (steady-state) network wide, the master side of any conn. is upped correctly (OK state) but the slave side of the conn. is still in down state (it should be in up state as well) 7. The problem is upcon network messages are not propagated to the slave-side of the conn. The result is that in spite of issuing up conn. the master-side of the conn. is upped but the slave-side of the conn is still in a down state 8. This means upcon finite state machines could be timing out or handling of such an inconsistent state under heavy loading still needs to be accounted for
Setup/System Conditions:
1. Almost all 9.2.34+9.2.23 SWSW and SWFW features are provisioned 2. The nodes are loaded to their limit with max terminating conns, VTs, etc. 3. Topology is a tiered network with AXIS and IGX feeders, MPLS LSCs and LERs, and SES PNNI controllers
Workaround:
Upcon each individual connection one by one. Need to assign DE to provide a efficient solution
CSCds81894
Symptoms:
During the standby cards RAM being updated to the 12th or sometimes to the 13th block, the download process terminates and restarts. This process can go into a loop for a long time
Setup:
1. Almost all 9.2.34+9.2.23 SWSW and SWFW features are provisioned 2. The nodes are loaded to their limit with max terminating conns, VTs, etc. 3. Topology is a tiered network with AXIS and IGX feeders, MPLS LSCs and LERs, and SES PNNI controllers
System Conditions:
1. Most of the configurable elements such as number of connections, number of trunks, etc.were loaded to the switch limit.
Workaround:
Awaiting DE to be assigned to resolve the problem
CSCds82339
Symptom:
When a graceful upgrade is done on an IGX node, the IDLE time of the node may be reduced to < 10% for a long time. The TRNS task takes > 50% of the CPU. After this period of time, the node functions as normal - there are no other problems.
Condition:
This happens only if there are ATFR connections on the IGX node with the FR side as the master end of the connection. The more the number of ATFR connections with FR as the master on the node, the longer the TRNS process takes a lot of the CPU.
Workaround:
Do a cnfcon on all the ATFR connections with FR as the master end-point and modify at least one of the BW parameters.
Further Problem Description:
This problem happens because of a inconsistency between the BW parameters of the ATFR connections stored on the ATM side (can be IGX or BPX) and the FR side. This discrepancy arises only if the connection is added from the IGX node (on the FR side). When doing swithcc/upgrade, the master node will send BW updates of all its connections to all the slave nodes. If the slave node detects any discrepancy, it will respond back with a BW Change request. If there are large number of connections with this discrepancy, a BW change request is generated by the slave node for each of those connections - and these messages are processes by the TRNS task on the master node, thus utilizing many CPU cycles.
CSCds82793
Problem/symptoms:
Switch software error 9000 and 3018 are logged on igxr03 after the following actions:
1. All routing and feeder nodes were running 9.2.xx SWSW with no alarms, all nodes were in perfect condition 2. Before upgrade, LOS alarms were induced on purpose by upping line and trunk ports that do not have any cabling. This was done on all nodes 3. Out of 4 bpx and 3 igx nodes, 2 bpx and 2 igx routing nodes plus two IGX feeders were to be upgraded from 9.2.34 to 9.3.11 4. 1st LOS alarms were introduced as described above, then hitless rebuild, switchcc, and full rebuild was performed on the nodes that will not be upgraded (Note: all nodes are not upgraded yet, they are running 9.2.34 and 9.2.23) 5. Once item d (see above), was in progress the upgrade was performed on bpx01, bpx02, igxr01, igxr02, igxf01, and igxf02 sequentially. 6. After the upgrade was done, a hitless rebuilt was performed on the upgraded nodes to see if any problem arises. 7. After all the nodes settled and were in steady state SWSW error 9000 & 3018 was logged on igxr03, this node was not upgraded to 9.3.1 8. It was running 9.2.34 to verify interop. between 9.2.xx and 9.3.11 9. Note, all alarms in the NW were induced on purpose, they are not caused by the upgrade
Setup/System Conditions:
1. Almost all 9.2.34+9.2.23 SWSW and SWFW features are provisioned 2. The nodes are loaded to their limit with max terminating conns, VTs, etc. 3. Topology is a tiered network with AXIS and IGX feeders, MPLS LSCs and LERs, and SES PNNI controllers.
Steps to recreate the problem:
1. Not sure if reproducible 2. This is a rare issue and may only occur in interop. mode
Workaround:
Need assigned DE to provide the root cause.
CSCds84776
Problem/Symptoms
1. APS is configured as 1:1 2. Everything works fine at the physical layer 3. But the problem is SWSW is not getting update messages from BXM FW 4. The FW reports the working and protect lines are clear but switch software shows the Alarm status is in "SigDegrade BER" state 5. Card error on bpx04 card 13 was also generated (see description below)
Setup:
1. Almost all 9.2.34+9.2.23 SWSW and SWFW features were provisioned 2. The nodes were loaded to their limit with max terminating conns, VTs, etc... 3. Topology is of a tiered network with AXIS and IGX feeders, MPLS LSCs and LERs, and SES PNNI controllers 4. The APS setup is configured between bpx01 and bpx04 5. On bpx01 ports 5.1 & 5.2 are used and ports 13.1 & 13.2 are used on bpx04
System Conditions:
1. Most of the configurable elements such as no. of conns, no. of trks, etc... were loaded to the switch limit 2. The problem is independent of switch limit
Frequency:
1. Reproducible
Steps to recreate the problem:
1. Resetcd the card several times 2. Do a switch APS lines several times
Workaround:
1. Down the line and then up the line. The SigDegrade alarm should clear 1. Awaiting DE to be assigned to resolve the problem
CSCds89338
Symptom:
dspload shows negative load when a prefer path connection is routed.
Conditions:
The load for vbr/abr has to be asymmetrical. A connection with asymmetric load say ms/sm. If the trunk does not have enough ms trunk bandwidth but enough sm bandwidth, the connection still routed. But the ms direction in the dspload shows negative load.
Workaround:
None.
CSCds90571
Symptom:
When restrict cc traffic was done on trunk we still saw Comm break messages in the BPX log. Need to investigate why this occurs and if it's a bug.
Conditions:
BPX 9.2.32
Further Problem Description:
On BPX1 trunk 5.2, a cnftrk was done to change the stats reserve to maximum of 104510 to move traffic off the trunk (due to HCS and BIP8 errors). Stats reserve changed to 104510 on BPX1 end but did not change on the other end on BPX2 trunk 5.2. BPX2 trunk 5.2 still shows stat reserve as 1008.
Known Anomalies from Previous Releases
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.
Bug ID
Disposition of Anomaly
CSCdk04032
Closed. Please see note.
CSCdk53502
Closed. There is a hardware limitation that prevents the error reporting and it was determined that fixing this problem could create more errors.
CSCdm19535
Fixed in Release 9.2.30.
CSCdm20593
Fixed in Release 9.2.31.
CSCdm24020
Closed. The possibility of this problem occurring is extremely low and a workaround for the problem exists.
CSCdm50600
Closed. Please see note.
CSCdm60534
Closed. Please see note.
CSCdm62985
Closed. It was determined that this problem could not happen.
CSCdm78081
This was found in Release 8.5.05, but despite many attempts, it could not be Release 9.2. This problem is in the 'I' state since it was reported by the customer.
CSCdm79453
Closed. It was not possible to reproduce this problem.
CSCdp08741
Closed. The capability to burn model A firmware onto a UVM card is no longer supported.
CSCdp22655
Closed. This problem could not be consistently repeated, and a workaround exists.
CSCdp22795
Duplicate of CSCdr15924, which was fixed in Release 9.2.34.
CSCdp28704
This anomaly was junked when it was discovered that a file was incorrectly missing a MIB object.
CSCdp28999
Closed. Please see note.
CSCdp32245
Fixed in Release 9.2.31
CSCdp33870
Duplicate of CSCdp32422, which was fixed in Release 9.2.31
CSCdp34188
Fixed in Release 9.2.30
CSCdp34846
Closed after many failed attempts at reproducing this anomaly. Also, this problem could not be duplicated on different hardware.
CSCdp37938
Duplicate of CSCdp34188, which was fixed in Release 9.2.30
CSCdp57089
Closed after many failed attempts at reproducing this anomaly.
CSCdp61204
Closed. Please see note.
CSCdp63917
Closed after many failed attempts at reproducing this anomaly.
CSCdp65503
Duplicate of CSCdp76840, which was fixed in Release 9.2.31
CSCdp72652
No action is required with regard to the BPX switch's detection or behavior following a bad crosspoint. Automatic switchover would cause more problems than it would solve.
CSCdp74165
Closed. It was decided not to add a 9.3 feature to the 9.2 baseline.
CSCdp81106
Closed. Please see note.
CSCdp82740
Duplicate of CSCdp49749, which was fixed in BXM firmware release MEF
CSCdp85319
Duplicate of CSCdm29466, which was fixed in Release 9.2.33
CSCdp87448
Closed after many failed attempts at reproducing this anomaly. Failed to detect this problem while reviewing the code.
CSCdp89369
Closed. A workaround has been provided. The customer agreed it was sufficient.
CSCdp90745
Duplicate of CSCdm24140, which was fixed in 9.2.30
CSCdp96286
This anomaly is in the 'I' state. It could not be reproduced with a test version of 9.2.31 and a test version of MEF. More testing is required before closing the anomaly.
CSCdr22814
Closed. This bug was downgraded to Severity 6 after deciding that changing the software enhances the existing design.
CSCdr49091
Closed. This bug is a duplicate of CSCdr51875, which has been resolved
CSCdr56015
Closed. This bug is a duplicate of CSCdm12055, which has been resolved.
CSCdr58256
Closed. This bug was unreproducible.
Note These anomalies were closed because they were internally found (and not
customer-found). Also, in most cases, they either require significant effort to resolve, are
unreproducible, or have a benign effect on the system.
Problems Fixed in Release 9.2.36
Following is the list of fixed problems in the 9.2.36 Switch Software release. Included with each is a brief discussion of the problem.
Bug ID
Description
CSCdr82206
Symptom:
The active NPM in slot two cannot communicate with any of the UXM cards in the IGX shelf which has an active NTM trunk card. Some or all of the UXM cards in the IGX chassis are "Unavail" (dspcds).
Conditions:
This does NOT occur if the active NPM is in slot one or if the IGX does not have any active NTM trunk cards.
This may occur after one of the following events: 1. A node rebuild on NPM in slot two (resetcd 2 h) 2. Switchcc to switch to the NPM in slot two. 3. Cnfbusbw to increase the UBUs allocated to the UXM cards while NPM in slot two is the active NPM. 4. Activating a new UXM card
Workaround:
There are three workarounds. 1.Issue switchcc to make NPM in slot one the active NPM. Limitation: NPM in slot two becomes an unreliable standby NPM if the IGX still has at least one active NTM.
2. Deactivate all active NTM trunks on the IGX. Limitation: Cannot use the NTM (T1/E1) trunks in the IGX.
3. Avoid putting an active NTM in slot three. Putting an UXM (active or standby) in slot three reduces the chances that the problem would occur. UXM in slot 3 would ensure that UBU3 is allocated to UXM and prevent the NTM card corrupting the UBU2 which is allocated to NPM in slot two. Limitation: May have to rearrange cards in the IGX chassis and changes the configuration
The root cause of this problem is described in CSCdk43303.
CSCds87060
Symptom:
1.1M3 may abort. 2. Gateway LCNs may be configured as non-gateway LCNs and may drop traffic. This may lead to an inconsistent number of GLCNs available in the cm database.
Conditions:
1. This occurs if the junk value stored in the uninitialized pointer is a beyond range memory index, in which case we would abort. This is possible in both IGX (VIA nodes) and BPX (VIA nodes) during routing of connections. This memory space is on the stack and allocated at runtime.
2. This only occurs if the memory dereferenced (which is arbitrary) has a particular value (6). This only occurs on IGX VIA nodes and the possibility increases if the gwlcn limits are run.
Workaround:
None.
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.
Bug ID
Description
CSCdk19709
BPX may sync a neighbor test in error and report a suspected BCC failure
CSCdm07982
ALM/B and NTM reset with hardware errors after UFM card fails
CSCdm12139
Packet_line table not updating Bursty_a_load, Bursty_b_load
CSCdm42912
SNMPProxyAgent fails on SET of PrefRoute with 10 hops (switch rejects)
CSCdm60699
Async updates are sent incorrectly when VCQueue fills up.
CSCdp51531
Software log 21(9082) occurs when UBR con added and one of the endpoints is ASI-155
CSCdp53419
UXM trunk LCN verification not performed on card configuration
CSCdp56458
Software error 34 occurs when entering a three-part ASI address for many different UI commands
CSCdp73084
upport, dnport, cnfport do not show port speed due to screen overwrite
CSCdr03517
Info Bus A Reports 1 Error(s) (CNTL) logged frequently with LCC LDM FW
CSCdr53669
SLT:ILMI is not disabled after changing virtual trunk to line port.
CSCdr55450
Flood of swlog 992 kills ILMI task on BCC making all AXISs unreachable
CSCdr58956
10 hop connection only adds in one direction with cost-based routing
CSCdr65152
MIB variables not incrementing for fpTrkStatsEntry variables
CSCdr68507
dsplog shows wrong VPI/VCI when port loopback deleted
CSCdr70919
Interface Shelf Major alarm logged when changing protocol to run on BXM card
CSCdr71482
dsptrkstats tx and rx load percentage incorrect, sometimes greater than 100%
CSCdr71781
Auto Memory reserved is not set to zero (swerr 3000) after upln on BXM-E
CSCdr72296
snmp walk on shelfslotinfotable causes swerr 26 when UXM is missing a back card
CSCdr73183
111 when 23 ifcs (trk/prt) on a BXM slot, 23+ causes trunk/port statistic loss
CSCdr73442
Deleting a simulated AAL5 feeder causes 1M3 abort and swerrs 513, 589 and 502
CSCdr74031
cnfcmb parameters changes on IGX when adding BPX to network
CSCdr74447
VC Depth does not get set to the correct value during addition of PVC
CSCdr74841
Display Routing Table Contents does not work
CSCdr74919
bnni lights do not go out after a dntrk
CSCdr75723
Software error 938 PNA_SEND_ERR when lan default gateway is set to zero.
CSCdr76988
Rounding problem in calculating UBU on dspbusbw
CSCdr78202
Software error 1120 logged during upgrading from 9.3.1T to 9.3.1V
CSCdr78391
Software error 3074 when upgrading from 931T to 931V
CSCdr78404
UVM has excessive delay for g729 conn which route on uxme 2Mbps virtual trunk
CSCdr79123
During routing delay of path may be calculated incorrectly
CSCdr79195
Too many connections could be packed by pack_conns()
CSCdr80522
Investigate user commands included HIPRI login for problem caused by Pause_proc
CSCdr80662
Some connection parameters are reset to default on rebuild/switchcc
CSCdr81947
dspselftst stopped working due to fragmented dynamic memory
CSCdr82470
Port loopback for the local slave end of a daxcon fails
CSCdr83296
VSI partition addition, dntrk or cnftrk on virtual trunk causes unreachability
CSCdr85197
The random() function is deterministic
CSCdr86188
AIS generates bit set for slave end of ATM daxcon with line in LOS
CSCdr86717
Mismatched back cards are allowed in a Y-red configuration
CSCdr91284
Two software errors 997s are logged after addtrk <vtrk>
CSCdr92045
Communication failure on trunks creates software error 1417.
CSCdr95419
delapsln executes without confirmation
CSCdr95576
Software error 327 with switchcc and failed connections
CSCdr95604
Allow IGX transmit rate to change locally for an added trunk.
CSCdr95788
Enhancement for signalling Qbin support
CSCdr96358
Last line of dsptech is writing into the border
CSCdr96513
The first interface upped on BXM/UXM has an incorrect maximum discard threshold.
CSCdr98681
cnftrk on BTM or ALM causes software error 923
CSCds00854
Software error 1427 is generated.
CSCds01587
Switch sending cells rx/tx statistics as 0 to CWM
CSCds02627
cnfqbin cannot use the default discard threshold .
CSCds02931
ILMI interval statistics are not collected .
CSCds03275
No trunk statistics are collected for last slot of IGX . Caused by CSCdm04491 fix
CSCds05668
Node goes into degraded mode after upgrading from 931Y to 931b
CSCds07761
SLT:Software error 103 UBU allocation errors
CSCds08777
Incorrect card/image accepted in tftp request. Missing Cmi_fwdl_prefix.
CSCds08808
Changing trunk rate using cnftrk overwrites BXM OC-12/T3/E3 with OC-3 Q depths
CSCds09778
BXM:CBR traffic drops as trunk Qbin bandwidth does not change with connection. reroute/dncon/upcon
CSCds12523
LMI Interval statistics are not collected.
CSCds13718
Incompatibility between Switch Software Release 9.2.23 and BXM firmware MF27.
CSCds16795
Incorrect programming of ingress/egress MCR on a terminating UXM trunk
CSCds17902
Software errors 532 & 538 found on BPX
CSCds22399
dspcon shows error of connection does not exist when dspcons shows all connections
CSCds22519
Software error 9082 logged for UXM when NPM resetcd
CSCds31978
Inconsistent via connections routed over UXM trunk once gateway connection limit is reached.
CSCds32831
dsptrkstats on down BNI card produces software log 8096
CSCds35608
UXM is not configurable to NON-CRC-4 mode.
CSCds36582
BCC Clock failure not processed by switch software during switchcc
CSCds39545
dspfdr does not display the VSI channels correctly.
CSCds43387
Software error 1128 on executing dspbuses when standby bus is failed
CSCds50411
delyred executes without confirmation
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.
Bug ID
Description
CSCdk55887
dspport command moved from user-level-6 to user-level-2 in 8.1
CSCdm13655
VC bw parameter is not reused (initialized differently during upgrade vs provision)
CSCdp50091
data_channel table not updating with 9.1.15 switch software
CSCdp67775
BPX does not clear last user request after SF switch
CSCdp93955
Swlog 532 when doing a snmpwalk on the node
CSCdr08430
Non TS queue size not saved in bram; also strange queue size behavior
CSCdr09440
ASI Qbin config lost when programming 2ndary card in Y-Red set
CSCdr11698
TS cell discards on Virtual Trunks with overbooked f/relay traffic
CSCdr11823
BCC tstber channel could use VPI that is in the VSI range
CSCdr15924
Failure to receive proper traps w/ 2+ CWMs pointing to same network
CSCdr20925
Connection data stops when reverted to primary in Y-red
CSCdr21739
Node hung up and lost access after deleting trunk.
CSCdr22568
ILMI Disable Command not sent to BXM FW when ILMI is disabled on a port
CSCdr23432
Switch aborts when cnfport command is issued.
CSCdr25318
UFMU port reports active state when the back card is missing
CSCdr27853
cnfcmparm 9 (reroute timer) should be defaulted to 3 seconds
CSCdr32789
Gateway LCNs are not getting updated if the other end is BXM and cnfrsrc done at BXM
CSCdr33428
UXM number of channels mismatch after card rebuild
CSCdr36808
ORIONSLT:SPVC reroute failed due to cross commit fail but PXM, BXM have RSRC
CSCdr36819
Message 0x53 not sent when dntrk/deltrk is done on Egress/Ingress side
CSCdr38707
SLT: Total VSI min. bw > 1412830 should not be allowed on BPX.
CSCdr41814
Prevent AR/VSI conflicts for VPIs used by Feeders for LMI/IP - SNMP changes
CSCdr48340
dspnw on a nw with IMA virtual trunks causes swerr 1423 or 1M3
CSCdr49264
Add rt-vbr connection via CWM, CLI shows nrt-vbr and snmpget shows as rt-vbr
CSCdr49301
PVC does not route after preferred is not available
CSCdr51105
Software error 30 is logged while UXM is inserted
CSCdr56249
Transition counter stats (LOS,..) not updated when line goes into alarm
CSCdr58725
Selftests: Freq.value of < 40seconds causes consistent resetting of UXM cards
CSCdr64725
MIB variable switchIfOperStatus reports up when a trunk is actually added
CSCdr67236
SES have stats file 1 hour ahead of bpx stats file even time are same
CSCdr75146
Connections will not route due to lack of LCNs as seen in constats command
CSCdr79123
During routing delay of path may be calculated incorrectly
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.
Bug ID
Description
CSCdj14920
Unable to clrcnf on BPX node whose number is > 63
CSCdm04491
Swerr 921 flooding
CSCdm13655
VC bw parm is not reused (initialized differently during upgrade vs provision).
CSCdm29466
Cannot addtrk on the VSI network because of VPC conid mismatch
CSCdm31518
"Active CC failure (EEPROM, SAR) and standby unlock or reseat causes rebuild."
CSCdm38578
Echo Negotiation for telnet between AIX and BPX
CSCdm48790
SIU phase errors from all BXM cards in a node
CSCdm69629
Different values of statistical reserve for dsptrkcnf and dspload
CSCdm88055
Job run job experienced failed
CSCdp20486
UXM IMA physical line alarms are not sent to SV+
CSCdp50871
UP/Down Line on ALM-A behaves erratically.
CSCdp53961
Control card mastership error not properly detected by software
CSCdp58131
SNMP get function in atmTrunkStatsTable
CSCdp62387
APS Clear Trap 20100 does not distinguish various types of clear events.
CSCdp68440
Swerr 961(BAD_LCN_SPECIFIED) found after dnport/dnln
CSCdp72012
Swerr 129 (BAD_TYPE_LOGGED) found at BPX2
CSCdp73065
Background Tst card errors on active. Card has state ACTIVE-F w/ss
CSCdp73606
Port LED remains on when line is downed on UXM.
CSCdp78731
LCN and VPC conid count is not sending correctly in TBL
CSCdp83180
Swerr 614 AUTO_DEL_LCON and 612 AUTO_DEL_VC upon fallback from 9.3.0L
CSCdp83902
UVM Line pass through does not work on the second physical line on UVM
CSCdp87624
Autodel trunk when rebuilding a port with 32 vtrks
CSCdp93368
When up a line then switch software seems to program all cons on that card
CSCdp93728
Summary statistics overflow is not detected correctly for Port and VI stats
CSCdp94039
Swlog 2000 occurs when snmpwalk on an IGX node
CSCdp95286
Cross point failures on the bcc.
CSCdp95807
Robust object message for vtrunks appears to be reporting wrong channel count
CSCdp96768
VSI and SVC bandwidth is not eliminated while configuring egress hpqbn b/w.
CSCdp98970
VT session timeouts on particular page when running dsprts
CSCdp99622
"Burn UXM/FW using C-bus, gets aborted"
CSCdp99780
Inhibit line loop diagnostics for IMA line/trunk
CSCdr00360
A Tstdelay command cannot run while card is initilized
CSCdr04828
IP relay channel is not getting deprogrammed when AAL/5 feeder is deleted
CSCdr06086
A dsp_pa_fail0 switch statement falls through when it should not.
CSCdr06280
Conditional update should not be integrated for a trunk between T1 and E1
CSCdr08084
A 62 message is not send on addyred if the secondary card is running self-test
CSCdr08231
A clrtrkstats does not clear Trunk Qbin statistics
CSCdr08952
A addloclp on BNI feeder connection aborts a node under certain circumstances
CSCdr10473
A swerr 1012 (BAD_RS_NCHANS) occurs after hitless rebuild
CSCdr11310
Configure LMI on UXM port causing swerr 987
CSCdr11823
A non-Fatal card error occurs on red. BXM during PXM1 upgrade. Refer to bug CSC46785
CSCdr11837
The maximum channel limit for dspchoid command is incorrect
CSCdr12300
Switch MIB is inconsistent with the CLI
CSCdr14544
PNNI VPI.VCI 0.18 is blocked when path 0 is built on BXM.
CSCdr14558
Switch software updates wrong port DB and robust message after Y-Red UFM switch over.
CSCdr14935
Unable to add UFM UXM connections from UFM side and there is corruption of Be Bc.
CSCdr17056
Provide UNKNOWN state for serialPortLeadState
CSCdr19348
NTS connections get bit errors when Frame Relay bursts fill up trunk capacity
CSCdr20760
Incorrect prompt while deleting a trunk on IGX UXM card
CSCdr21739
Node hung up and lost access after deleting a trunk.
CSCdr26582
CD error after issuing a addctclr command (SLT)
CSCdr30234
Available Conids gets updated only on the nodes connected by the trunk.
CSCdr32875
"int_all_usr_updt, trkchans: kicks of reroute only for trunks attached locally."
CSCdr41370
Dspchstat from Port counter slowly ramps-up to send rate
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.
Bug ID
Description
CSCdk03916
Trunk information is inconsistent
CSCdr26613
"When active APS line has YEL, trunk fails."
CSCdr35085
Switchcc cannot be cancelled when updates pending
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.
Bug ID
Description
CSCdk15523
"Integer overflow results in computation in get_bc, get_be funcs"
CSCdk22052
Switchcc event logged under trapd.log when the command is cancelled
CSCdk45354
No data continuity between UVM & HDM for nx64 connection
CSCdk60213
HDM data errors with 1152 kb/s connections on 9.1.06
CSCdm10213
After upgrade or switchcc in 9.1, extra connections may appear
CSCdm20593
Switch software should not allow an ATFR connection between two UXMs
CSCdm26083
Dsptrkbob causes swerr 30 and 923 when performed on sec Y-Red card
CSCdm46032
SNMP identifies ALM/A line as ATM trunk
CSCdm47765
VT cause memory leak
CSCdm68968
"VC-Q depth setting at default value, Connection Manager, IGX, routing and feeder node"
CSCdm75577
UFM-C to BXM SIW/NIW connection discards 100% cells at BXM on BPX if the connection is between UFM-C on IGX to BXM on BPX.
CSCdm77271
Incorrect modem upgrade support
CSCdm87788
Unable to add connection with maximum rate on BXM-T3 port with direct mapping
CSCdm91529
"Screen flicker on dspnds, with more than 2 columns nodes"
CSCdp07967
Statistics files updating standby cause standby to hang in update state
CSCdp09854
The value for maximum pvc bw in rsrc partition displays wrong value
CSCdp15350
SNMP GET-NEXT does not work for frLportStatTable
CSCdp20534
Uninitialized variable in get_rrt_space() function
CSCdp27598
Disabling and enabling echo canceller produces Channel Pair Problem
CSCdp32245
BXM-OC3 DX performance monitoring is not implemented Bellcore 253 Sec 6.2.2.
CSCdp32422
addlnlocrmtlp does not loop traffic properly in APS 1+1 cross over circuit
CSCdp32490
Secondary CC went from UPGRADED to STANDBY after pull/reinsert CC-backcard
CSCdp32760
Updates/Upgrades of circuit lines can cause a memory leak on the standby
CSCdp32823
IGX FAIL handler causes high CPU utilization
CSCdp34687
BPXs running 9.2.22 experiences commBreak every 5 seconds and cleared.
CSCdp34935
connCurrRouteDesc description inconsistent with code
CSCdp35155
LDM cderrs and card failed in 9.2.3M
CSCdp37572
Addcon command does not include connection display
CSCdp39883
Con with 1/101 VPI/VCI added at BXM fdr trunk caused UNRCH of its fdr
CSCdp41410
Modem Silence duration can be set to a maximum of only 5.1 seconds
CSCdp42776
Cannot configure BXM port by runjob command
CSCdp43913
Dsprsrc displays confusing information about Topo Discovery
CSCdp45833
SVC deletions are sometimes incomplete (swerr 332 with FFF1)
CSCdp47053
ALM/B Y-Red does not work for upgrade 8.5.09->9.1.15->9.2.23
CSCdp47428
IFC failed when shelf is re-added (with 2 partition)
CSCdp47479
Unable to configure feeder LMI timers
CSCdp48792
"The dsplog/trapd show the APS alarm cleared, but dspapsln is in LOS"
CSCdp48797
All connection parms go to 0 when change vc q depth
CSCdp48797
All connection parms go to 0 when change vc q depth
CSCdp49215
Addtrk on Y-red card causes swerr 9082
CSCdp49860
Dncon causes other connections to be downed
CSCdp49951
BPX hanging up with TUNL task using up to 60% CPU RT
CSCdp50593
Updated information PNNI ctrlr not sent after addctrlr command
CSCdp51318
No alarm of the APSLN in dsplog/dspapsln after Signal Degrade/Failure
CSCdp52802
UVM ports do not pass data due to stuck CCS conditioning
CSCdp53212
Dspload from IGX on a remote BPX with trunk no.> 8 is not allowed
CSCdp53891
Addloclp and addrmtlp command causes yellow alarm on UVI interface
CSCdp54106
"BCC switchcc causes Comm failure, telnet failure"
CSCdp54803
BCC switches over when standby is in update statistic with bad Spurious Int
CSCdp55388
Dspchuse shows wrong number for max PVC configured.
CSCdp55442
Addjob/editjob and cnfport corrupts memory or can cause a 1M3 abort
CSCdp58545
Distortion on UVM-to-CVM connections routed on UXM Trunks when VAD Threshold reached.
CSCdp58869
Unintelligent response from cnfcon command
CSCdp59960
UVM does not send yellow alarm to PBX when it receives a yellow alarm from PBX
CSCdp61539
"Networking channel deletion problem for Transparent, Blind and Inter-nodal"
CSCdp64345
Virtual trunk in comm fail is chosen by route or after hitless rebuild
CSCdp65187
Multiple switchyred within 10 seconds causes line to go in LOS for APS
CSCdp66930
No failed traps for user lockout but traps for BPX lockout
CSCdp69003
"Decrease Comm Brk clear, reroute and recondition time after rebuild"
CSCdp69582
Unable to switchyred on upgrade from BXM to BXM-E due to Qbin size mismatch
CSCdp70093
Failure configuring VSI ILMI gives error message Unknown error for LCN un avail.
CSCdp70295
"UNI port MIB should show range 1-255, not"
CSCdp73719
ILMI on card can be disabled through SNMP even if VSI ILMI enabled.
CSCdp76840
Resetcd on Active should warn when standby is still in PRGM mode.
CSCdp79429
Dspselftst shows test attempts incrementing yet Status always shows Not Run
CSCdp79560
TFTP Channel Stats are not reported correctly
CSCdp79719
Cnftrk on an IMA trunk shows negative transmit trunk rate!
CSCdp82720
Y-red: standby UXM does not take over when FW is burned on active card
CSCdp84848
Dsplogcd for a VSI trunk attempts to use an uninitialized pointer
CSCdp85171
Flood of HW failure messages from BXM caused node rebuild
CSCdp85238
Alarm are not getting updated when delapsln and switchyred/resetcd is done.
CSCdp86269
Trunks and LNs on aps cds go into LOS and never recover during gr253 -> ITUT.
CSCdp90123
Cnftrk for a vtrk on an OC12 interface gives a line coding prompt
CSCdp90130
Cnfrsrc shows more bandwidth than the physical maximum for a feeder.
CSCdp98715
Swlog 514 and 589 when doing dncon.
CSCdr00072
Using unitialized num_ports variable in av_bkcd()
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.
Bug ID
Description
CSCdk36040
"Trap 20004-wrong value for varbind trapCardType, FRP back card"
CSCdk53336
Tstdelay not working on non-enhanced ASI-155
CSCdk87939
Dspchcnf shows inconsistent information after upgrade to 9106
CSCdm05502
Need cnfuvmchparm parameters 8 and 9 to configure UVM echo cancelers
CSCdm19532
A-bit status not propagating through network changing from NNI to UNI port
CSCdm19535
Channel program problems for BXM virtual trunks
CSCdm24140
Delcon on IGX causes IDLE RT to drop
CSCdm31990
CVM cbus message (0xA0) is not delivered when the secondary card is active.
CSCdm42254
When user ID is deleted subsequent users are reported one off.
CSCdm53182
Swerr 923 logged when dsptrkred command is used.
CSCdm65380
Allow conids lower than 4096 for VT wraparound
CSCdm72719
Unable to add BNI VT over ASI port in some cases
CSCdm74224
Unable to configure a port on OC-3 card when others are already configured.
Trunk Cell routing restriction is not prompted any more for ATM conn.
CSCdm30262
Incorrect logic for VTs in g_ima_grp_member()
CSCdm30359
Failed to add daxcon path connection due to incorrect VPI checking.
CSCdm30608
Software error 55 after addalmslot 16
CSCdm31674
Yellow alarm line conditioning for T1 lines
CSCdm32384
Node rebuild on BPX caused comm fail.
CSCdm33967
After upgrade 9.1.09 to 9.2.00 trunks went comm. failure and then OK
CSCdm34282
Dbs_Pre_9110 not initialized properly in Root()
Additional Deliverables
SNMP MIB
The SNMP IGX/BPX switch SNMP MIB is being provided with the delivery of Release 9.2.36 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:
switchIfCtrlVPI
switchIfCtrlVCIStart
Modified objects:
switchIfEntry
switchIfScTmpltId
atmPortTable:
New objects:
atmPortHcfShift
Modified objects:
atmPortEntry
atmPortMetro
atmPortQueueTable:
Modified objects:
atmPortQueueType
atmPortQueueDepth
connTable:
Modified objects:
connCurrRouteDesc
connPrefRouteDesc
atmEndptTable:
Modified objects:
atmEndptDesc
atmOtherEndptDesc
atmEndptSubType
atmEndptMCR
atmBwClassTable:
Modified objects:
atmBwClassConType
The following objects are associated with the switchShelf configuration branch.
New objects:
shelfCnfgFBTC
shelfCnfgSerialLeadTypeIndex
shelfCnfgSerialLeadMonitorTimer
shelfCnfgSystemTime
shelfSlotInfoTable:
Modified objects:
slotBackType
slotFrontNumPort
slotBackSonetMode
slotCardMinBusUBU
sonetIfTable:
Modified objects:
sonetIfType
sonetStatsTable:
New objects:
sonetStatsYelTcs
sonetStatsAisTcs
sonetStatsLocs
sonetStatsLops
sonetStatsPthAis
sonetStatsPthYels
sonetStatsSecBip8s
sonetStatsLnBip24s
sonetStatsLnFebes
sonetStatsPthBip8s
sonetStatsPthFebes
sonetStatsSecBip8Es
sonetStatsLnBip24Es
sonetStatsLnFebeEs
sonetStatsPthBip8Es
sonetStatsPthFebeEs
sonetStatsSecBip8Ses
sonetStatsSecSefs
sonetStatsLnBip24Ses
sonetStatsLnFebeSes
sonetStatsPthBip8Ses
sonetStatsPthFebeSes
sonetStatsLnUas
sonetStatsLnFarendUas
sonetStatsPthUas
sonetStatsPthFarendUas
sonetStatsHcsCrtblErrEs
Modified objects:
sonetStatsEntry
atmTrunks table:
Modified objects:
atmTrkType
atmTrkTrafCls
rsrcPartiTable:
New objects:
rsrcPartiVsiIlmiEnable
Modified objects:
rsrcPartiEntry
rsrcPartiVsiVpiEnd
serialPortTable:
New objects:
serialPortLeadState
Modified objects:
SerialPortEntry
serialPortLeadState
Default Values
BPX 8600 Nodes
The default values for BXM and Enhanced-BXM cards are the same.
hugo TN StrataCom BPX 8620 9.2.36 Date/Time Not Set
System-Wide Parameters
1 Max Time Stamped Packet Age (msec) ................................ 32
2 Allow CPU Starvation of Fail Handler .............................. No
3 Max Network Delay for 'v' connections (msec)....................... 14
4 Max Network Delay for 'c' connections (msec)....................... 27
5 Max Network Delay for 't' & 'p' connections (msec)................. 14
6 Max Network Delay for 'a' connections (msec)....................... 27
7 Max Network Delay for High Speed Data connections (msec)........... 32
8 Max Network Delay for CDP-CDP 'v' connections (msec)............... 64
9 Max Network Delay for CDP-CDP 'c' connections (msec)............... 64
10 Max Network Delay for CDP-CDP 't' & 'p' connections (msec)......... 64
11 Max Network Delay for CDP-CDP 'a' connections (msec)............... 64
12 Max Network Delay for CDP-CDP High Speed Data connections (msec)... 64
13 Enable Discard Eligibility......................................... No
14 Use Frame Relay Standard Parameters Bc and Be...................... No
15 Max Local Delay for Interdom CDP-CDP 'v' conns (msec).............. 27
16 Max Local Delay for Interdom CDP-CDP 'c' conns (msec).............. 27
17 Max Local Delay for Interdom CDP-CDP 't' & 'p' conns (msec)........ 27
18 Max Local Delay for Interdom CDP-CDP 'a' conns (msec).............. 27
19 Max Local Delay for Interdom CDP-CDP High Speed Data conns (msec).. 27
20 Max Local Delay for Interdom High Speed Data conns (msec).......... 28
43 ABR [ 80] 46 ABR [ 60] 51 ABR [ 80] 54 ABR [ 60]
This Command: cnftrkparm 16.1
Appendix A
BXM Firmware MEJ Release Notes
About the Firmware MEJ
BXM Firmware version MEJ supports all the existing interfaces and models of BXM hardware. Following table outlines various levels of hardware revisions supported for BXM firmware version MEF
Front Cards
Model Number
Description
FW Model
HW Rev
FW Rev
BXM-155-4
4 port OC3 Line Module (Front Card)
E
B
MEJMEJ
BXM-155-8
8 port OC3 Line Module (Front Card)
E
B
MEJ
BXM-622
1 port OC12 Line Module (Front Card)
E
D
MEJ
BXM-622-2
2 port OC12 Line Module (Front Card)
E
D
MEJ
BXM-T3-8
8 port T3 Line Module (Front Card)
E
B
MEJ
BXM-T3-12
12 port T3 Line Module (Front Card)
E
B
MEJ
BXM-E3-8
8 port E3 Line Module (Front Card)
E
B
MEJ
BXM-E3-12
12 port E3 Line Module (Front Card)
E
B
MEJ
BXM-155-8DX
8 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-155-8D
8 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-155-4DX
4 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-155-4D
4 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-622-2DX
2 port OC12 Line Module (Front Card)
E
A0
MEJ
BXM-622-2D
2 port OC12 Line Module (Front Card)
E
A0
MEJ
BXM-622-DX
1 port OC12 Line Module (Front Card)
E
A0
MEJ
BXM-T3-12EX
12 port T3 Line Module (Front Card)
E
A0
MEJ
BXM-T3-12E
12 port T3 Line Module (Front Card)
E
A0
MEJ
BXM-T3-8E
8 port T3 Line Module (Front Card)
E
A0
MEJ
BXM-E3-12EX
12 port E3 Line Module (Front Card)
E
A0
MEJ
BXM-E3-12E
12 port E3 Line Module (Front Card)
E
A0
MEJ
BXM-E3-8E
8 port E3 Line Module (Front Card)
E
A0
MEJ
Front Card for APS Compatibility
Model Number
Description
FW Model
HW Rev
FW Rev
BXM-155-4
4 port OC3 Line Module (Front Card)
E
C
MEJ
BXM-155-8
8 port OC3 Line Module (Front Card)
E
C
MEJ
BXM-622
1 port OC12 Line Module (Front Card)
E
E
MEJ
BXM-622-2
2 port OC12 Line Module (Front Card)
E
E
MEJ
BXM-155-8DX
8 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-155-8D
8 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-155-4DX
4 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-155-4D
4 port OC3 Line Module (Front Card)
E
A0
MEJ
BXM-622-2DX
2 port OC12 Line Module (Front Card)
E
A0
MEJ
BXM-622-2D
2 port OC12 Line Module (Front Card)
E
A0
MEJ
BXM-622-DX
1 port OC12 Line Module (Front Card)
E
A0
MEJ
Back Cards
Model Number
Description
HW Rev
FW Rev
MMF-155-4
4 port multi-mode fiber back card
A
na
MMF-155-8
8 port multi-mode fiber back card
A
na
SMF-155-4
4 port single-mode fiber intermediate-reach back card
A
na
SMF-155-8
8 port single-mode fiber intermediate-reach back card
A
na
SMFLR-155-4
4 port single-mode fiber long-reach back card
A
na
SMFLR-155-8
4 port single-mode fiber long-reach back card
A
na
SMF-622
1 port intermediate-reach OC12 back card
A
na
SMF-622-2
2 port intermediate-reach OC12 back card
A
na
SMFLR-622
1 port long-reach OC12 back card
A
na
SMFLR-622-2
2 port long-reach OC12 back card
A
na
XLR-622
1 port extra long-reach OC12 back card
A
na
XLR-622-2
2 port extra long-reach OC12 back card
A
na
BPX-T3/E3-12
12 port T3/E3 back card
A
na
BPX-T3/E3-8
8 port T3/E3 back card
A
na
RDNT-LR-622-2
2 port long-reach OC12 redundant back card
A
na
RDNT-SM-622-2
2 port intermediate reach OC12 redundant back cards
A
na
RDNT-SM-622
1 port intermediate reach OC12 redundant back cards
A
na
RDNT-LR-155-8
8 port long-reach OC3 redundant back cards
A
na
RDNT-SM-155-4
4 port intermediate-reach OC3 redundant back cards
A
na
RDNT-SM-155-8
8 port intermediate-reach OC3 redundant back cards
A
na
New Features Supported in BXM Firmware MEJ
For APS ITUT Annex A, SF and SD conditions are sent with high priority. In all other ITUT and GR-253 configurations SF and SD conditions are sent with low priority. This is per specifications.
New Features Supported in BXM Firmware MEH
BootCore enhancement to support multi-vendor flash-SIMMs
1 msec granularity for tstdelay measurement.
New Features Supported in BXM Firmware MEF
There is no new feature in release MEF
New Features Supported in BXM Firmware MEE
There is no new feature in release MEE
New Features Supported in BXM Firmware MED
There is no new feature in release MED
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:
BIP count
Condition
10^-4
SF detected
10^-5
SD detected & SF clear
10^-6
SD clear & SF clear
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
Clarifications
1. The OC-3 MultiMode Fiber backcards do not support Y-cable redundancy.
2. Upgrade from VSI 1.1 to VSI 2.2 is supported in this release. See upgrade section on page 10.
Special Installation/Upgrade Requirements
BXM cards with M.C.B/M.D.A firmware or later can be smoothly migrated to the M.E.H 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 MEJ 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.E.F and burn the other card also with M.E.H firmware. Follow the standard firmware upgrade procedure for downloading and burning the firmware into the cards.
Features Obsoleted
VSI 1.0 is obsoleted by VSI 2.2 in this release.
Notes and Cautions
1. M.E.E is fully compatible 9.2 Switch Software. It has not been tested for compatibility with 8.4, 8.5, or 9.1 Switch Software. It is compatible with IOS version 12.05t2 for MPLS
2. While upgrading firmware on OC3 or 2-port OC12 BXM cards whose statistics level is greater than 1 (command dspnovram "Number of Channel stats: shows 12 or higher"), the upgrade should take place according to one of the procedures below to avoid the card mismatch.
Upgrading from firmware revision MEA or higher:
Step 1 Switch software should be upgraded to 9.2.30 or higher.
Note Switch Software Release 9.1.x can be used with MEx firmware if VSI is not enabled.
Step 2 Upgrade the firmware to MEJ.
Upgrading from firmware revision lower than MEA:
Step 1 Firmware should be upgraded to MEC
Step 2 Upgrade the Switch Software to 9.2.30 or higher revision.
Note Switch Software Release 9.1.x can be used with MEx firmware if VSI is not enabled.
Step 3 Upgrade the firmware to MEJ.
3. 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.
4. 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.
5. 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)
6. 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)
7. 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)
8. 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)
Known Anomalies
The following is the list of known anomalies for the BXM firmware.
Bug ID
Description
CSCdp32247
Symptom: switchapsln/dsplog show no alarm at all but Popeye show alarms
Conditions:
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.
Bugs Fixed in MEJ
The following bugs are fixed between MEH & MEJ.
Bug ID
Description
CSCdr19696
Symptom: User never gets to know when the line is out of SD/SF condition.Both the aps lines always show in OK state in dspapsln.
Condition: APS Line switches to standby line because of SD/SF condition. dspapsln will still show OK for both the lines. This way, user will never get to know when this line has come out of SD/SF condition.
Workaround: Use rsh command to get all the aps line's status.
CSCdp87443
Symptom: The APS switch to working lines after finished burned FW.
Conditions:
Workaround: Upgrade to MEJ or newer version firmware
CSCdr55491
Symptom: Disconnect the working line of APS 1:1 lines will cause the active line is protective line and it is working fine after APS line switching.major alarm (Path Unavailable Secs.) on the trunk or line via this APS line pair.Also, the active APS line has the alarm "Path Unavailable" even the real.
Conditions: This problem only happens in 9.3 and APS 1:1 mode.
Workaround:
1. addapsln to APS 1:1 mode and uptrk or upln using upped APS line.
2. make sure the active line is working line, if not, switchapsln to manually switch it.
3. pull out the Rx cable of working line. the APS switching should happen.
4. the active line should be protective line after switching.
5. the "Active Line Alarm Status" is "Path Unavailable" and the trunk or line has major alarm "Path Unavailable Secs."
6. pull back the Rx cable of working line, alarms is gone.
CSCdp67775
Symptom: APS does not clear last user request after SF switch
Conditions: Jan. 1999 edition of GR-253-CORE (issue 2, Revision 2, section 5-92 which supersedes the document you are quoting)
Workaround: Upgrade to MEJ or newer version of firmware
Bugs Fixed in MEH
The following bugs are fixed between MEF & MEH.
Bug ID
Description
CSCdp63445
Symptom: ABR and UBR connections loose traffic when VC shaping is turned on.
Condition: Enabling of VC shaping on port terminating ABR and UBR connections
Workaround: Leave VC shaping disabled.
CSCdp62213
Symptom: Switching from bi-direction to uni-direction mode APS generates APS architecture mismatch error
Condition: When APS pair is configured from bi-direction mode to uni-dir mode the other side indicates APS architecture mismatch error, and then the other side is also configured from bi-direction mode to uni-direction mode, the APS architecture mismatch error does not clear.
Workaround: delete APS and then add APS again - it defaults to uni-dir
CSCdp46399
Symptom: Need a documentation explains how to setup port groups for FW MEF (me26)
CSCdr11396
Symptom: All user data is dropped when send in 960 cps of OAM
Condition: Data transfer has affected while running OAM loopback
Workaround: Upgrade to MEH or newer version of firmware
CSCdr11511
Symptom: Different behavior for segment and end-to-end OAM loopback
Conditions:
Workaround: Upgrade to MEH or newer version of firmware
CSCdr13151
Symptom: dspportstats always show TX port=0
Conditions: sending in >= 960 cps of oam loopback cell
Workaround: Upgrade to MEH or newer version of firmware
CSCdr13182
Symptom: tstdelay fails for all PVCs when they are > 960 cps of OAM
Conditions: When user sending in >= 960 cps of oam loopback cells
Workaround: Upgrade to MEH or newer version of firmware
CSCdr13196
Symptom: Too many software error 105 when running OAM test
Conditions: Software error 105 logged while running OAM loopback test
Workaround: Upgrade to MEH or newer version of firmware
CSCdr13208
Symptom: Too many OAM cells causes CD errors
Conditions: One PVC has 2880 cps of data and 960 cps of oam cells and Another PVC has 2880 cps of data and 960 cps of oam cells,
Workaround: Upgrade to MEH or newer version of firmware
CSCdp09419
Symptom: Granularity of tstdelay is 17 ms
Conditions:
Workaround: Upgrade to MEH or newer version of firmware
CSCdr51875
Symptom: Virtual Trunking causing Unreachable
Conditions:
Workaround: Upgrade to MEH or newer version of firmware
Bugs Fixed in MEF
Bug ID
Description
CSCdp58969
Symptom: cb_get.c CB_VPC_STATUS_POLL SoItcSend Failed upon VSI Failure
Condition: When VSI receives and transmits lot of VSI message AAL5 drive will get into deadlock problem if it had missed a DMA interrupt
Workaround: None. Upgrade to MEF or newer version of firmware
CSCdp57596
Symptom: CB_TASK on BXM goes into deadlock state causing VSI session to be lost
Condition: This happens when both Ingress and Egress qe semaphore is taken by IDLE_TASK and it never released in an error condition
Workaround:. None. Upgrade to MEF or newer versions of firmware.
CSCdp25220
Symptom: Avail Buffer on BXM = 0 on LVC flapping for xtag interfaces
Condition: Same as CSCdp58969. During this condition AAL5 driver doesn't release the transmission buffer.
Workaround: None. Upgrade to/MEF or newer versions of firmware
CSCdp59328
Symptom: EPD bit was not set for interslave control vc
Condition: When VSI get congestion (same as CSCdp58969)
Workaround:.None. Upgrade to/MEF or newer versions of firmware
CSCdp92916
Symptom: Commands executed on standby card affect APS line
Condition: Series of commands executed in standby card affects APS line
Workaround: None.Upgrade to MEF or newer version of firmware
CSCdp39723
Symptom: Aps not functioning in 9.2.21 w/FW ME18@sprintf for Bidirectional w/Nonrevertive
Condition: Reversion was happening due to spurious SF/SD events.Fixed by setting the right values for SF/SD thresholds
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp20848
Symptom: SF switchover does not occur after dncd/upcd execution on Annex B 1+1 APS
Condition: When the dncd command is executed, Switch Software sends 0x27 CBUS message. The handler for this message was putting the lines in loopback and shutting down the laser. Also it was changing the line state in SoCdDown() to DOWN state. This caused subsequent upcd (0x05/0x04) message to re-initialize the lines disabling the S/UNI interrupts in the process.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp24224
Symptom: WTR does not occur after LOS recovery on protection line
Condition: The meaning of primary and secondary channels were changed immediately upon switchover instead of waiting for the expiry of WTR. This caused the clearing of the failure to be accounted against the secondary channel and thus there was no WTR. Fixed by introducing a Preparation switch mode where-in the current active channel will remain as the secondary until a WTR occurs or a primary section mismatch pre-empts that state. At the expiry of WTR, the preparation switch mode is complete and the current active channel becomes the primary.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp32646
Symptom: WTR Timer does not work and reversion occurs during SF switchover
Condition: Added a preparation switch mode where the current active channel is the secondary channel. At the expiry of WTR, the secondary channel is changed to the become the primary channel.
Workaround: None.Upgrade to MEF or newer version of firmware
CSCdp35156
Symptom: BPX APS reverts back to the working line before WTR time has expired
Condition: TR was being pre-empted by a spurious SD condition. Fixed by setting the right thresholds for SF/SD based on BER
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp60696
Symptom: Both lines fail when only one line in alarm
Condition: After the standby card comes out of reset, its S/UNI states are not reliable for a period of 1.5 seconds and the S/UNI reports LOS clear on the WORK line. This gets conveyed to the active card and then the Manual switch gets priority and becomes the current local request. This causes a switch back to WORK. When the active card's S/UNI monitors the WORK line, it discovers that the line is in LOS and immediately switches back. The oscillations continue and the line goes into LOCKOUT due to excessive switching. In the Lockout mode only the WORK line is active and thus the defect.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp65320
Symptom: Need a trap when BPX puts APS in lockout
Condition: Send the traps in the right sequence. First send the Lockout trap and then the failed to switch trap if there is a switch attempt while lockout is in effect.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp25130
Symptom: APS Non-revertive bidirectional feature
Condition: Resolved
Workaround: None
CSCdp50624
Symptom: SVCs in progress get released when standby BXM is pulled
Condition: When the standby card reset, the pending number of tcbs agains grows more than 40 and retransmits to standby card for 2 seconds.Because of this master couldn't get response since no buffer and timeout.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp79156
Symptom: TDP signalling cross connect VSI request rejected by BXM
Condition: If BPX is configured with trunks and virtual trunks the virtual trunks are initialized properly with qbin size.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp62213
Symptom: Switching from bi-direction APS to un-directional APS generates mismatch err
Condition: The alarms generated while the line was in bi-dir mode was not cleared when it was changed to uni-dir mode. Fixed by clearing all alarms when re-configuring the lines.None.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp89972
Symptom: Node rebuild caused 3 BXM cards failed
Condition: Moved the allocation and initialization of the Connection database to the SoCoEnterStandby function instead of in the 0x50 handler (SoCdUp)
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp86147
Symptom: The removal of Rx cable of APS trunk leading to loss of Frm and Prot Sw Byt Fail
Condition: While removing the Rx cable of APS working line (configured to trunk) working line goes to Loss of Frm and dsptrks shows the trunk in alarm. After connecting cable back the APS Alarm status shows "Prot Sw Byt FAIL"
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp84386
Symptom: Connectivity w/BXM lost due to missing DMA completion interrupts
Condition: Aal5 driver will be in deadlock and never transmits and receives.
Workaround:None.Upgrade to MEF or newer version of firmware
CSCdp38148
Symptom: Resetcd slot 11 on BPX causes local APS switching
Condition: re-impose the selector and bridge states on both ACTIVE and STANDBY cards after a Y-red switchover, re-discover the line states and re-execute and external requests.Also include a STABILITY timer before the line state is processed.
Workaround: None.Upgrade to MEF or newer version of firmware
CSCdm92931
Symptom: APS line switchover occurs up one card removal when lockout is set
Condition:
Workaround: None Upgrade to MEF or newer version of firmware
CSCdp49749
Symptom: node unreachable after resetting two nodes in the network
Condition:
Workaround: None
CSCdp49640
Symptom: When FCES feature enable on BXM NNI data transfer stops
Condition: The ABR parameters like NRM,CRM,FRTT,MCR,ICR were not getting programmed when the FCES is turned on using cnfcon command.Adding the Connection with the FCES enabled behaved properly.
Workaround: None
CSCdm62817
Symptom: tstconseg command sometimes does not work.
Condition: execute tstconseg multiple times with high loop count (10).
Workaround: None
CSCdm84853
Symptom: BW reported via interface load info is erroneous.
Condition: When Forward & Backward BW for VSI connections is different.
Workaround: None
The following bugs are fixed between MEE & MEF
Bugs Fixed in MEE
Bug ID
Description
CSCdp40682
Symptom: BPX becomes un-reachable when slot 11 was active
Condition: Excessive APS switching occurs and node aborts when a software loopback is applied on an APS line with W and P cables pulled.
Workaround: Do not perform addlnlocrmtlp on an APS pair
CSCdp38148
Symptom: resetcd slot 11 on BPX causes local APS switch
Condition: When ACTIVE (and PRIMARY) card is monitoring the PROT line and STANDBY (and SECONDARY) card is monitoring WORK line, if the ACTIVE card is reset, then the SECONDARY card comes up as active and switches to WORK line by default
Workaround:. None. Upgrade to MED or newer versions of firmware.
CSCdp25220
Symptom: APS K2 bytes do not have the right info
Condition: When BPX APS pair is connected to an APS test equipment, the test equipment does not see a match between the sent K1 channel and the received K2 channel
Workaround: None. Upgrade to ME27/MEF or newer versions of firmware
CSCdp45555
Symptom: APS: signal degrade and signal fail threshold does not work
Condition: Configuring of SD and SD thresholds do not work on BXM-E cards
Workaround: Use defaults.
CSCdp52921
Symptom: BPX node sometimes sees signal degrade when run switchyred
Condition: Performing switchyred cause the line to stay stuck in SD condition
Workaround: Perform switchyred again
The following bugs are fixed between MED & MEE
Bugs Fixed in MED
The following bugs are fixed in MED
Bug ID
Description
CSCdm53420
Symptom: switchyred causes APS line to switch when last user request is clear
Condition: APS 1+1 configuration. The protection line was active and the "last user switch request" was clear. When a switchyred was performed, APS line switched to working line active
Workaround:
CSCdm93274
Symptom: OC3 back card LED is wrong after reset/pull cards
Condition: Multiple APS lines on a card and perform switchyred when Working line is active and Secondary card is active
Workaround: None.
CSCdm04312
Symptom: The problem is a false failure is declared against the SIMBA Multicast Record RAM.
Condition: The problem occurs when Self Test is activated against a Y-Redundant pair of BME Cards (BXM-622 cards loaded with the multicast BME firmware) that have more than 1000 connections programmed through them.
Workaround: Disable Self Test via the cnftstparm command.
CSCdm50659
Symptom: Trunk alarms are not generated when random bit errors are injected onto a trunk using an Adtech Sx14 test set at a rate of 10E-3. There are trunk statistics generated but no trunk alarm because the statistics that cause alarms on do not meet the threshold for MAJOR or MINOR alarms.
CSCdm50659
Symptom: Trunk alarms are not generated when random bit errors are injected onto a trunk using an Adtech Sx14 test set at a rate of 10E-3. There are trunk statistics generated but no trunk alarm because the statistics that cause alarms on do not meet the threshold for MAJOR or MINOR alarms.
Condition: This was generated in a lab environment with test equipment that was set to inject bit errors randomly through the entire bandwidth. Some HCS errors were generated as well as Path unavailable and Path Farend unavailable.
Workaround: Lowering the alarm threshold for MAJOR and MINOR HCS errors can help to generate a trunk alarm. Use the cnflnalm command and modify the Hcserr alarm thresholds to.01 for MAJOR and.0001 for MINOR. These thresholds are as low as they can be set currently.
CSCdk42527
Symptom: Rx Queue becomes full after LOS on the feeder trunk
Condition: After LOS condition on the feeder trunk
Workaround: Reset the feeder trunk
CSCdm16505
Symptom: AIS not sent on VP ABRFST/ABRSTD connection
Condition: LOS on trunk between 2 nodes
Workaround: none
CSCdm81534
Symptom: ICR of abrfst on BXM-155 falls down to MCR after resetcd
Condition: Change the ICR after resetcd before start sending traffic
Workaround: None
CSCdm61493
Symptom: When BIP8 errors are received on an E3 line or trunk at a rate of 10E-3, the line or trunk will not declare any alarm.
Condition: When high rates of BIP8 errors are received.
Workaround: None.
CSCdk81384
Symptom: BXM slot errors keeps on incrementing on a BCC3 node, but the reading of'EAP ARFD' should only be interpreted when using the dual receiver feature on a BCC4 node.
Condition: BXM slot errors on a BCC3 node
Workaround: None
CSCdk80483
Symptom: TX cell loss counts in dsptrkerrs increase continuously.
Condition: When there is trunk configured.
Workaround: None.
CSCdm04312
Symptom: The problem is a false failure is declared against the SIMBA Multicast Record RAM.
Condition: The problem occurs when Self Test is activated against a Y-Redundant pair of BME Cards (BXM-622 cards loaded with the multicast BME firmware) that have more than 1000 connections programmed through them.
Workaround: Disable Self Test via the cnftstparm command.
CSCdm09295
Symptom: Reconfig of FCES from enable to disable does not work, as a result traffic burst is restricted to MCR.
Condition: Every time changing an existing connection from FCES enable to disable.
Workaround: delete the connection and add back a new one with FCES disable
CSCdm39186
Symptom: Card fatal error occurred when running in standby mode under the heat condition. As a result, the card reset periodically.
Condition: Card running in standby mode under heat condition
Workaround: none
CSCdm09882
Symptom: Log non fatal message related to the RCMP errors
Condition: It is mainly seen in the heat chamber
Workaround: Please make sure the TEST FREQUENCY and TIMEOUT variables under cnftstparm for BXM are set to 4000/3700 level.
CSCdm31923
Symptom: AIS/YEL alarm doesn't go away even after the alarm is clear from the other end
Condition: It happens on the E3 when the LOOP TIME parameter is set to YES in the trunk or line configuration
Workaround: none
CSCdm92916
Symptom: Operational commands (dncd, resetcd, remove) on standby card impact active APS line
When active line is PROT line and a switchover of cards occur, WORK line becomes active line on the newly active cards.
Conditions: APS 1+1 Annex B and PROT is active line. switchyred or resetcd on the active card causes line to switchover from PROT to WORK.
Workaround: none
CSCdm92931
Symptom: APS line switchover occurs upon card removal/insertion when lockout is set
Conditions: When Lockout is set, removing/inserting the card makes it happen.
CSCdm52585
Symptom: DspVsiPartInfo shows very large Available LCN field.
Condition: When the sum of min-lcns is greater than the max(max lcns) on a port group.
Workaround: none.
CSCdp18840
Symptom:The CBR.2 Calls do not pass traffic above 50 Cells/second.
Condition:VSI controller establishes CBR.2 connection and it does not fill in the PCR field.
Workaround:Fill the PCR value aslo with the CR value.
CSCdp17741
Symptom:2-portgroup card reports 1 port group at the channel stats level 2 and 3.
Condition:When channel stats level 2 or 3 are configured on BXm-622-2 port and BXM-155 reports only one port group.
Workaround: Auto Route connections are not affected by this. But for VSI connections there is no work around.
CSCdp22930
Symptoms: Intlock missing for rd/wr operation
Workaround:
Reassert intLock on commbus ISR to prevent SCC access from getting interrupted
CSCdp33894
Symptom: standby APS line shows status as Path AIS upon switchyred or on APS switchover on LOS
Conditions: switchyred on APS, the prot. line report Path AIS
Workaround: NONE. upgrade to ME26/MED or later versions of BXM firmware
CSCdp36324
Symptom: last user request affects switching on BPX.
Conditions:
Workaround:
CSCdp31325
Symptom: UBR cells are policed unnecessarily below PCR.
Conditions: Always.
Workaround: none.
CSCdp36155
Symptom: BXM-E OC3/OC12 does not show supporting APS HW 1+1 in dspcd command and otherwise also.
Condition: BXM-E OC3/ OC12 card with HW rev < 'C'
Workaround: None.
CSCdp32853
Symptom: The BXM enhanced cards keep getting reset and card errors are logged and node may go into degraded mode, when command "addapsln slot1.port1 slot2.port2 1" is issued.
Condition: BXM enhanced OC3 cards with 4 port and FW rel earlier that M.E.22/M.F.09
Workaround:
1.Do not addapsln on second port onwards for BXM-E OC3 4 port card.
OR
2. Replace the BXM-E 4 port card with 8 ports card.
CSCdp17741
Symptom:2-portgroup card reports 1 port group at the channel stats level 2 and 3.
Condition: When channel stats level 2 or 3 are configured on BXm-622-2 port and BXM-155 reports only one port group.
Workaround:Auto Route connections are not affected by this. But for VSI connections there is no work around.
CSCdp11025
Symptom: Use the "dspapsln" to get the screen to dsiplay apsln status.When the working line is taken out the LOS appears on the working line. when the protection line is taken out both the working and protection display LOS. When the protection line is put back in the LOS/Alarms on the protection should clear. They do not.
Conditions:
Physically remove and add the rx or both rx and tx lines as follows:
1- remove the working line.
2- remove the protection line.
3- Add the protection line back.
Workaround
None
CSCdm73220
Symptom: Trunks or Virtual Trunks does not allow traffic going through.
Condition: Switch Software 9.1 with ME level of firmware. Trunks or VTs configured on BXM/BXM-E.
Work around: None
Bugs Fixed in MEC
The following bugs are fixed in MEC
Bug ID
Description
CSCdm66131
Symptom:
After addapsln trunk goes to LOS
Condition:
Both ends have secondary card active, add aps 1+1 to one end, then add aps to the other end, the trunk sometimes goes into LOS.
Workaround:
CSCdm64366
Symptom:
APS 1+1 manual switch sometimes does not work after a while after several manual switch and auto switch.
Condition: Secondary card is active and several manual switch and auto switches are performed.
Workaround:
CSCdm62809
Symptom:
APS 1+1 bidirectional non-revertive switches back to working line when line condition clears on working.
Condition:
APS 1+1 configured in bidirection non-revertive mode.
Working line is in LOS, current active line is protection, clear LOS on working line.
Workaround:
CSCdm69974
Symptom:
Card errors (0x25170076) occur when only one Virtual Trunk is configured in a physical port.
Workaround:
CSCdm65813
Symptom: APS switches back o working line incorrectly.
Condition: switch sequence W->P, P->W and then W->P, then cause LOS on WORK line and put the cable back, APS switches to Working line.
Workaround:
CSCdm77212
Symptom: When addshelf command is executed, it comes back with a communication breakdown.
Condition: channel level stats is set to 0 so that BXM reports wrong max channels.
Workaround:
CSCdm74316
Symptom: Re-adding VSI shelf does not work until a resetcd is executed on the LSC control port.
Condition: Load information on an interface is 4 bytes more that MAX_VSI_MSG,
So the message gets dropped on BXM, so VSI controller is in discovery state forever.
Workaround:
CSCdm75722
Symptom: No control VC after BXM is reset.
Condition: When resync request comes down from the VSI controller with 19 checksum blocks, the length check done on BXM does not include padding.
Workaround:
CSCdm74968
Symptom: 0B card error causing BXM to reset
Condition: Over night jobs running on controller cards.
Workaround:
CSCdp02190
Symptom: tstdelay timed out when going through BNI trunk
Condition: more that 12 VTs on an interface causes wrong port-vi mapping while considering STI_SHIFT/NO_SHIFT from 13 the VT/port onwards.
Workaround:
CSCdm78335
Symptom: dspvsistatus rarely shows the VSI programming status as Done
Condition: primary and secondary port has two different VPI range.
Workaround:
CSCdm26752
Symptom: Card errors continuously logged with "SoItcSend failed" message.
Condition: RAS oam_lpbk is on and switchyred is executed several times in a job.
Workaround:
CSCdm93839
Symptom: Card resets on receiving oam loopback cells at high rate
Condition: oamlpbk is enabled with high oam traffic on large number of connections.
Workaround:
CSCdm52254
Symptom: BIP-8 code errs occurs on routing trunks
Condition: T3 card used in HEC mode can randomly have this problem.
Workaround:
CSCdm44183
Symptom: BXM-155 4DX was not able to recover after resetting the card
Condition: Traffic is sent at a rate >= 383 cps on a terminated connection on BXM-E card and then card is reset.
Workaround:
CSCdm90997
Symptom: BXM-E trunk and port stats are always zero in TX direction.
Condition: port terminated on BXM-E card or trunk passing through BXM-E card.
Workaround:
CSCdm80991
Symptom: Unable to add 3 segment connections using CM GUI
Condition: feeder connected to BXM card of BPX routing node and for, BXM trunk invigoration, ILMI/LMI protocol is enabled as CARD based.
Workaround:
CSCdm82688
Symptom: traffic Shaping problems with VT with and without wraparound solution
Condition: large deviations in CDV values
Workaround:
CSCdm94372
(see explanation below)
Symptom: Trunks sometimes drop cbr traffic
Condition: If a trunk is configured to full line rate on BXM cards, then traffic is dropped
Workaround:
CSCdp00063
Symptom: Node unreachability is experienced on VTs (virtual trunks)
Condition: Multiple VTs are configured on a trunk interface of the BXM/BXM-E
Workaround: configure only one VT per trunk interface
Logic to calculate actual cell transmission rate in a BXM card is as follows (CSCdm94372):
if (configured cell rate == full line cell rate) then
transmitted cell rate = full line cell rate
else
transmitted cell rate = from equation below or from table 1
example:
if a trunk is configured at 100,000 CPS, the actual transmitted cell rate is then 98,013 CPS
any traffic sent over 98,013 CPS would be discarded.
Therefore, only rates in the table or computed from the equation should be used.
Otherwise cell loss may be experienced.
1464865
56552
28832
19348
14559
11670
9738
8355
733860
54458
28278
19097
14416
11579
9674
8308
489558
52513
27744
18852
14277
11488
9611
8261
367288
50703
27231
18614
14139
11399
9549
8215
293888
49013
26736
18381
14005
11311
9487
8169
244938
47432
26258
18154
13872
11225
9426
8124
209966
45950
25798
17933
13743
11140
9366
8079
183733
44558
25353
17717
13616
11056
9307
8035
163327
43247
24923
17506
13491
10974
9248
7992
147001
42012
24508
17300
13368
10892
9190
7948
133642
40845
24106
17099
13248
10812
9133
7906
122509
39741
23717
16902
13129
10733
9077
7863
113088
38695
23341
16710
13013
10656
9021
7822
105012
37703
22976
16522
12899
10579
8966
7780
98013
36761
22623
16339
12787
10503
8912
7739
91889
35864
22280
16159
12677
10429
8858
7699
86485
35010
21947
15983
12568
10355
8805
7659
81681
34196
21625
15812
12462
10283
8753
7619
77383
33419
21311
15643
12357
10212
8701
7580
73515
32676
21007
15479
12254
10141
8650
7541
70014
31966
20711
15318
12153
10072
8599
7502
66833
31286
20423
15160
12053
10003
8549
7464
63927
30634
20143
15005
11955
9936
8500
7427
61264
30009
19871
14853
11859
9869
8451
7389
58814
29409
19606
14705
11764
9803
8403
7352
Bugs Fixed in MEB
The following is the list of bugs fixed in release MEB.
Bug ID
Description
CSCdm50469
Symptom:
Software error 105 and malloc card errors happened continuously
Condition:
When jobs that cause reroutes of connections (e.g. switchcc, hitless rebuild) are run for a long time, sometimes BXM card freezes with malloc card errors and software error 105.
Workaround:
None
CSCdm50723
Symptom:
After deleting APS, switchyred causes temporary LOS when the other end still has APS.
Condition:
One end has APS 1+1, other end was added with APS 1+1 and line is up between the two ends. Then APS is deleted from one end. The primary card is active on non APS end. On switchyred on the non APS end there is a temporary LOS. If APS was never added to one end, then switchyred does not result in temporary LOS.
Workaround:
Instead of deleting APS first and then doing a switchyred, do a switchyred first and then delete APS. This does not result in temporary LOS.
CSCdm63038
Symptom:
BXM card fails with breakpoint error.
Condition:
When tx cell rate of a trunk is reduced to zero, BXM card fails with break point error (division by zero).
Workaround:
None
Bugs Fixed in MEA
The following is the list of bugs fixed in release MEA:
Bug ID
Description
CSCdm09882
Symptom:
Log non fatal message related to RCMP errors.
Condition:
It is mainly seen in the heat chamber.
Workaround:
None
CSCdm18186
Symptom:
AIS status could be randomly be displayed in dspcon
Condition:
When the connection AIS signal is constantly changing, the dspcon/dspchstats OAM status will not be accurate for all the connections on the card.
Workaround:
None
CSCdm26380
Symptom:
Software error 9098 occured during switchyred BXM
Condition:
This problem occurs on cards with the APS channels halved option set and then doing a cnfrsrc on a port that belongs to the second port group. Note that this fix will cause a card mismatch on active cards with channel halved option turned on.
Workaround:
None
CSCdm31923
Symptom:
AIS/YEL alarm doesn't go away even after the alarm is clear from the other end.
Condition:
It happens on the E3 when the LOOP TIME parameter is set to YES in the trunk or line configuration.
Workaround:
None
CSCdm37519
Symptom:
Trunks go to Communication Fail after burning firmware.
Condition:
When MC10 is burnt into BXM-OC12 with trunks.
Workaround:
None
CSCdm37709
Symptom:
APS line fails to clear channel mismatch after lockout.
Condition:
Bi-direction APS 1+1. Local end has locked out of protection set. Then WORK cable is pulled out on local end to cause LOS. Lockout is then cleared and then the WORK cable is put back. This causes a channel mismatch on the far end and the mismatch never clears.
Workaround:
None
CSCdm38647
Symptom: This bug has been fixed in MEA such that the firmware reports the correct number of port groups. The side effect of this fix is that the Switch Software could mismatch the BXM card. If there is a card mismatch then down all the lines/trunks on the card and up them again.
Condition: When the user loads the MEA firmware on the BXM card running MDA with APS halved channeled enabled, then the card will come up in mismatched state.
Workaround:
None
CSCdm46658
Symptom:
switchapsln command does not work for APS AnnexB line.
Condition:
Annex B configuration if hitless rebuild is done when active line is PROT, then switchapsln does not work after hitless rebuild.
Workaround:
None
Bugs Fixed in MDA
The following is the list of bugs fixed in release MDA:
Bug ID
Description
CSCdm38647
Symptom:
MDA fw may report incorrect number of port-groups when APS channels are set to halved.
Condition:
When user attempts to add all the channels available on the card on one port-group, it may be allowed even though the BXM may not have enough memory to support it. Also, this may cause a mismatch state when MDB firmware is burnt.
Workaround:
Down all the line/trunks on the card and up them again.
CSCdm23713
Symptom:
VI numbers are not modified by firmware.
Condition:
When one or more trunks are failed in the network, there may be a combreak in the network.
Workaround:
Set all the Virtual trunks to restrict CC traffic.
CSCdm23827
Symptom:
APS alarm may clear on switchyred.
Condition:
After a switchyred, an existing a LOS/LOF alarm may get cleared. This will only happen when the line has switched to protection before the card switchover is performed.
Workaround:
None
CSCdm23752
Symptom:
BXM fw does not allow a networking channel on VTs to configured for egress only.
Condition:
BXM fw allowed configuration of networking channel to be bidirectional only.
Workaround:
None
Firmware Filenames and Sizes
Filename
Size
BXMMEJ.000
65536
BXMMEJ.001
65536
BXMMEJ.002
65536
BXMMEJ.003
65536
BXMMEJ.004
65536
BXMMEJ.005
65536
BXMMEJ.006
65536
BXMMEJ.007
65536
BXMMEJ.008
65536
BXMMEJ.009
65536
BXMMEJ.010
65536
BXMMEJ.011
65536
BXMMEJ.012
65536
BXMMEJ.013
65536
BXMMEJ.014
65536
BXMMEJ.015
65536
BXMMEJ.016
65536
BXMMEJ.017
65536
BXMMEJ.018
65536
BXMMEJ.019
65536
BXMMEJ.020
65536
BXMMEJ.021
65536
BXMMEJ.022
13936
BXMMEJ.023
14
BXMMEJ.024
2
BXMMEJ.IMG
784
BXMMEJ.img
784
Appendix B
UXM ABJ Firmware Release Notes
ABJ is a new firmware release for the UXM card on IGX. Firmware is the same for UXM and UXM-E cards.
New Features
Flash memory drivers are upgraded to support more flash memory vendors so that more flash manufacturers can be used to source components.
Obsolete Features
None.
Compatibility
Software
ABJ firmware is compatible with Switch Software 9.1 and 9.2
Hardware
ABJ is compatible with UXM and UXM-E model H/W all models.
Previous Versions of UXM Firmware
On IMA trunks this version is not compatible with UXMs Model B firmware versions ABA to ABD.
On IMA trunks Model B firmware (AB*) is not compatible with model A (AA*) because model B is Standards compliant and model A is not. So IMA trunks must be upgraded together.
Bugs Fixed in this Release
Bug ID
Description
CSCdp55689
Symptom:
UXM card with OC3 (SMF/MMF) backcard is declared failed when the card has a line/trunk in LOS. The failure is declared in about 2-3 minutes after the line goes to LOS.
Workaround:
resetcd # f will clear the failure.
CSCdp01725
Symptom:
Cells received on a UXM port with 1 bit error in a cell header are discarded. These errors should be correctable and the cells forwarded over the PVC.
Conditions:
This occurs on all UXM's with firmware revision ABH and earlier, and with a T3 or E3 backcard connected to a line with bit errors.
Workaround:
None.
CSCdp98876
Symptom:
When a T3/E3 port is configured with HCS masking disabled, the port comes up as failed. In the case of E3 ports, Loss of Cell is seen while T3 ports do not pass traffic.
Conditions:
When a T3/E3 port is upped, it comes up with HCS masking enabled by default. The port fails if configured to disable HCS masking using cnfln.
Workaround:
Configure the line with HCS masking enabled.
CSCdp22759
Deleted a few prints on the UXM serial line.
Upgrade Instructions
Upgrade boot code to boot 07 before upgrading to ABJ.
Notes and Cautions
This firmware enables flash components from multiple new vendor to be used. Previous versions of firmware cannot write on to these new devices. For new cards with the flash devices from new vendors, firmware cannot be downgraded to versions prior to ABJ. If this is attempted, burnfwrev will fail leaving firmware revision ABJ in the flash.
Boot Code Requirements
Boot Code revision boot_07 is needed for the ABJ release.
Obtaining Service and Support
For service and support for a product purchased from a reseller, contact the reseller. Resellers offer a wide variety of Cisco service and support programs, which are described in the section "Service and Support" in the information packet that shipped with your chassis.
Note If you purchased your product from a reseller, you can access Cisco Connection Online
(CCO) as a guest. CCO is Cisco Systems' primary, real-time support channel. Your
reseller offers programs that include direct access to CCO's services.
For service and support for a product purchased directly from Cisco, use CCO.
Cisco Connection Online
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information,productdocumentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
Modem: From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
Note If you are a network administrator and need personal technical assistance with a Cisco
product that is under warranty or covered by a maintenance contract, contact Cisco's
Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To
obtain general information about Cisco Systems, Cisco products, or upgrades, contact
800 553-6387, 408 526-7208, or cs-rep@cisco.com.
