9.2.40 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.20
BPX/IGX
A-bit Notification
GA
9.2.20
BPX/IGX
Real-Time VBR
GA
9.2.20
IGX
Support Enhanced UXM
GA
9.2.20
BPX
Support Enchanced BXM
GA
9.2.20
BPX
Support for 16K connections
GA
9.2.10
BPX
Support for Virtual Switch Interface (VSI) 2.2
GA
This interface is available in 9.2.10. Use of this interface is dependent upon other products, for example IOS.
BPX
Support for APS Annex B
GA
9.2.10
IGX
Support for UXM VP tunneling
GA
9.2.10
BPX
Include SONET line protection: APS on BXM-OC3 and BXM-OC12 (1+1)
GA
9.2.01
BPX
Support for Virtual Trunking on the BXM card
GA
9.2.01
BPX
Include SONET line protection: APS on BXM-OC3 and BXM-OC12 (2 card, 1:1)
GA
9.2.00
BPX
Support for LMI/ILMI on BXM card
GA
9.2.00
BPX/IGX
Alarms for all service-affecting events
GA
9.2.00
BPX/IGX
Support for feature mismatch on BXM and UXM cards
GA
9.2.00
BPX/IGX
Support for Hitless Rebuild including Disable Auto Bus Diagnostics
GA
9.2.00
BPX/IGX
Support for IGX and BPX trunk reconfiguration without outage
GA
9.2.00
BPX/IGX
Support for Revision Interoperability between 9.1 and 9.2
GA
9.2.00
BPX/IGX
Support for UXM and BXM Multilevel Channel Statistics
GA
9.2.00
BPX/IGX
Support ports and trunks on the same UXM and BXM cards
GA
9.2.00
IGX
Support for ATM Forum Standard Compliant IMA Trunking with UXM Firmware Model B
GA
9.2.00
IGX
Support for Virtual Trunking on the UXM card
GA
9.2.00
IGX
Support VC traffic shaping on UXM port
GA
9.2.00
IGX
Support for Idle code suppression for video on UVM and CVM cards
GA
9.2.00
Software Release 9.2.40
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.40.
This is a maintenance release including all features supported up to Release 9.2.30.
Software Release 9.2.30
Includes all features supported up to Release 9.2.20 and introduces the following additional features:
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 commands 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.
For enhanced BXM cards, upgrade to 9.2.30 software first and then burn the BXM card with the MEE or higher firmware, BXM will report 2-port groups for 2-port cards all the time. The smooth transition between the earlier 1-port group and the newly reported 2-port groups also displays the message in dspcd "Inconsistency with logical PG #" (port group number). All earlier software will "mismatch" the card.
If the BXM card is programmed with MEC or earlier firmware revision, the channel statistics for level 2 or 3 will report 1-port group for enhanced BXM cards. Burning an MEE or higher image will result in 2-port groups, but for backwards compatibility the software will not do the recomputation of LCNs based on the new port groups. In its logical database, this will not impact the AutoRoute connections.
For VSI controllers the reported value will be higher than the actual available LCNs. That means a VSI controller may not be able to add connection even though the available connections are non-zero. If the user wishes to remove the above discrepancy, the card must be brought to the standby mode.
Note that the newly configured card or the card in standby mode programmed with MEE or higher image brought to the active state will not have above discrepancy.
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 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. An LCN Resynchronization feature was developed to maintain consistency between NPM and UXM connection databases when a switchcc occurs. IGX Software release 9.2.37 or later and UXM firmware Release ABK or later are required to implement this feature.
Special Installation/Upgrade Requirements
General/Upgrade Procedure
Please consult your Support Representative before performing any software upgrade.
1. The earliest release supported for graceful upgrade is 9.1.03.
2. The 9.2 switch software requires a minimum of MED firmware for BXM Model E non-enhanced cards; MEE is the minimum required firmware for enhanced BXM cards.
3. Before upgrading to this release when UXM cards are to be used, certain legacy card firmware must be upgraded. See the compatibility matrix for cards affected and the exact versions to be used.
Note Standards-compliant IMA is not compatible with the proprietary IMA protocol used in
revision A firmware. Both ends of an IMA trunk must have the same protocol.
Caution Failure to follow this procedure may result in the card not operating. The card should be returned to Cisco if this occurs:
Step 1 Verify current boot code version
In order to run Model B firmware on UXM, the card needs to be running boot code revision 6 or greater. To determine the boot code running on the card, issue the following command from CLI (user must be logged in as Service level or greater to use this command):
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 MEC, and
BXM OC3/OC12 interface and the BXM is configured to channel statistic level 2 or higher.
Perform the following steps to avoid card mismatch for all BXM enhanced cards:
Step 1 Upgrade BXM firmware to MEC.
Step 2 Upgrade BCC software to 9.2.30 or higher.
Step 3 Upgrade BXM firmware to MEE or higher.
For all other cases, do the following steps:
Step 1 Upgrade BXM firmware to MED or higher.
Step 2 Upgrade BCC software to 9.2.30 or higher.
Note See the Compatibility Matrix for the exact versions to be used.
7. Procedure for adding new BCC cards as a part of upgrading to the 9.2 release.
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
Upgrade all the BXM cards in the node to Model E, which is VSI Version 2 and CoS capable. After each BXM card is downloaded with the Model E image, it temporarily experiences VSI outage until the BCC software is upgraded. The VSI outage during the upgrade is caused by the Model E firmware not being backward compatible with VSI Version 1 features.
Note that from the TSC perspective, after a BXM is upgraded to the Model E image, the interfaces that used to be on the card will "disappear." The TDP sessions that were on the interfaces will be lost. When all the BXMs are upgraded to the Model E while still running Release 9.1 software on the BCC, the node will experience a complete outage of MPLS traffic. AutoRoute will have a hitless upgrade.
Step 3 Upgrade the BCC.
As the BCC is upgraded from software Release 9.1 to the desired 9.2.3x release. The BCC recognizes the Model E BXMs and downloads the VSI partition configuration. This causes the BXMs to issue ifc cfg traps to the TSC, allowing the TSC to rediscover all the MPLS interfaces on the BPX. The TDP sessions are reestablished and MPLS traffic starts flowing again through the BPX.
Note The VSI 1.1 and VSI 2.2 are not interoperable.
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 ABJ or later
BXM model MED or later for non-enhanced BXM cards
BXM model MEE or later for enhanced BXM 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-4
H.E.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 for Release 9.2.40
None.
Additional Notes for Release 9.2
1. Switch Software Release 9.2 is not compatible with UXM firmware Model A.
2. If attempting to burn UXM firmware Model B into UXM firmware Model A with 9.2 software, the firmware Model B will not be burned into the UXM card due to the incompatibility of software 9.2 and UXM firmware Model A. The UXM has to be returned to Cisco for service.
3. If using MEC or earlier BXM firmware and upgrading to MEE or later, the version of switch software has to be upgraded first so that the enhanced BXM cards will report 2-port groups for 2-port cards all the time. The smooth transition between the earlier 1 port group and the newly reported 2-port groups also displays message in dspcd "Inconsistency with logical PG #" (port group number). All earlier software will mismatch the card. This applies to BXM-OC3 or BXM-OC12 and configured to channel statistic level 2 or higher.
4. Firmware MED and earlier supports APS Redundancy on Legacy BXM only.
5. Because of hardware limitations, BXM hardware is not able to recognize all user-programmed cell transmission rates. Rather only discrete transmission rates can be used instead.
The equation below shows what the BXM hardware actually transmits given a user configured cell rate. The transmitted cell rate is always less than or equal to the configured cell rate. To prevent any cell loss, the transmitted cell rate must be equal to the configured rate. To do so, a cell rate must be chosen from the table below.
The rate table below lists the highest 200 cell rates supported be BXM such that if used, will result in no cell loss (given cell traffic is less than configured cell rate). Additional rates can be calculated using 1470588/[n + (1/256)], where n is an integer.
The logic to calculate the actual cell transmission rate in a BXM card is as follows:
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 MEH and later 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. For UVM cards, there will be no new revisions of Model A firmware. When attempting to download Model A firmware to a UVM, software will give the user an error message indicating that the firmware does not match the card type. Note that there is no problem with continuing to use existing UVM cards running the old firmware(CSCdp08741).
6. There is a new traffic class added in Release 9.2.20 that causes a trunk parameter conflict with pre-9.2.20 node. The conflict fails adding trunk between 9.2.20 BTM/ATM and pre- 9.2.20 BTM/ATM.
All ATM traffic classes are set for BTM/ALM trunks and is hidden to the user. The introduction of rt-VBR traffic class in 9.2.20 makes it different from pre-9.2.20 BTM/ALM trunk traffic class. The user can not change the ATM traffic class for BTM/ALM trunk.
This problem exists with a new BTM/ALM trunk on an upgraded 9.2.20 node but does not exist with an upgraded BTM/ALM trunk since the rt-VBR traffic class is not set while upgrading (CSCdm64345).
7. The cloud port to which a virtual trunk is connected should have ILMI polling disabled. Otherwise, it could lead to a virtual trunk being clear on one end and declaring Virtual Trunk Path Failure at the other end (CSCdm52909).
8. In a BPX that contains BCC cards with 64MB, there is no limitation. All 12 available slots can contain BXM or Enhanced-BXM cards.
In a BPX that contains BCC cards with 32MB, a maximum of 10 legacy BXM cards are allowed. If some Enhanced-BXM cards are used in place of BXM, then each Enhanced-BXM will count as two BXM cards.
9. For performance reasons, AIS status of connections is not sent to the standby BCC. After switchcc, it may take a few minutes to update the AIS status of connections. If dspcon does not show the proper status of AIS or the dspalms screen shows an incorrect number of AIS, (after switchcc) wait for few minutes so that the status gets updated. (The dspalms and dspcon commands show the status of AIS.)
10. Hitless rebuild has similar limitations to that of a switchcc and full rebuild:
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.
11. UVM cards in Y-redundancy will mismatch if one is burned with Idle Code Suppression Firmware and the other is not.
When installing/burning Idle Code Suppression Firmware on UVM pairs, the Y-redundancy must be removed, firmware in both UVM cards burned, and then the Y-redundancy can be restored.
12. Mismatch is reported when replacing a BXM card with another BXM card that has a different port group, even though both BXM cards have the identical channel number.
13. When upgrading from Release 9.1 to 9.2, the 9.1 statistics on BXM/UXM cards are supported to maintain compatibility. However, once a user configures a statistics level in 9.2, the statistics cannot be configured back to 9.1 statistics.
There is no 9.1 statistics support for BXM/UXM cards that were shipped with 9.2 firmware since the BXM/UXM card has the default level 1 statistics.
Therefore, when using a UXM with 9.2, a user must either:
Leave the statistics level untouched (this will work for UXM cards upgraded from 9.1)
OR
Set level 2 on the card
14. The BXM and UXM channel statistics level feature gives these cards the capability of collecting more than four statistics per connection. However, it is the controller card's limitations, available memory, and performance, that indicates how many statistics can actually be collected from the cards and then reported to the Cisco Wan Manager (CWM).
The BCC-3-64 can collect at most three interval statistics per connection when there are 16,000 AutoRoute (AR) connections configured on the node. (Interval statistics are those statistics that are reported to the CWM. They are often referred to as TFTP statistics.)
You can collect approximately 48,000 statistics (3 x 16,000) on the BCC-3-64. This is approximate because there are many variables that will affect this value, such as are peaks enabled, how many buckets are collected, are all connection of the same type, are trunk, line or port statistics enabled, and so on.
With this approximation of 48,000 statistics on the BCC-3-64, this then means that as a rough estimate you could enable 32 statistics on 1,500 connections, 48 statistics on 1,000 connections or nine statistics on 5,000 connections, and so on. The approximation formula being:
15. In Release 9.1, the UXM card ran a proprietary IMA communication protocol. This protocol matched that used on the MGX 8220 4 IMATM-B cards and hence could be connected together to form a trunk. In Release 9.2, standards-compliant IMA are supported on the UXM card and standards-compliant IMATM-B on MGX 8220 5.0.x must be used to form a trunk. There should be no effect on UXM-IMA trunks connected to other UXM-IMA trunks in 9.1 to 9.2 interoperability mode.
16. The transmit rate on an IGX IMA trunk can be altered at the local node with any trunk outage. It is possible that the transmit rates are different at the two ends of an IMA trunk. After this trunk is deleted, it cannot be added back unless the transmit rates are the same.
17. When doing a grouped upgrade from Release 9.1 to 9.2, the software error 1427 may be logged on the BPX/IGX node during a non-graceful upgrade. This error can be ignored since it is harmless to the network (CSCdm14613).
18. Reconfiguring trunk parameters might cause connections to be rerouted if the changed bandwidth load is smaller than what was used by the connections that use the trunk.
19. If LMI/ILMI is provided by the BCC:
The maximum possible number of ports on the BPX 8600 that can be configured with LMI/ILMI enabled is 52. However, each BPX will support up to a total of 16 feeder trunks and each feeder trunk will have LMI enabled. That is, if a BPX 8600 is configured with only two feeder trunks, then only (52 - 2) = 50 ports can have LMI/ILMI enabled.
If LMI/ILMI is provided by the BXM firmware:
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.
20. Virtual Path Connections with cells whose VCI values are above 4095 will be transmitted correctly only if the path is exclusively through BXM trunks and terminate at BXM ports.
21. The feature of CIR=0 for Frame Relay connections is not supported for connections terminating between FRM cards in IGX nodes and FRSM cards in an MGX 8220 shelf.
22. SVC connections are derouted after decreasing the allocated bandwidth (increasing Statistic Reserve). It is the design intent that increasing the statistical reserve will cause SVC conns to derouted and not be rerouted (CSCst92308).
23. For the loadrev operation, it is important that the Cisco Wan Manager/TFTP buffers are maintained at their default size.
24. Due to a hardware limitation, the BNI trunk will send 13-15 percent more traffic than what it is configured for when the trunk is configured for less speed (cps) than the maximum port speed. This is especially important when the BNI trunk is connected to IMATM pairs, which carry less than T3 bandwidth.
25. When using the shift/no-shift feature on a BPX 8600 node's port card, controlled via the cnfport command, the other end of the connection must have the same setting. Otherwise, there will be a loss of continuity.
26. Due to trunk-based loading, any commands having to do with trunk loading and the load model (dspload chklm dsplm, and so on.) need to be done only after waiting a certain period of time. This time is a direct function of the trunk load update interval time (as configurable) plus the conditional update latency time.
27. The external ABR segment control loop on ForeSight (ABRFST) is an option at the user interface. It is supported by UXM-E/BXM-E but is not supported by UXM/BXM hardware. The user should not enable this option on ForeSight connections (CSCdi92451). In any case, there is no coupling between the loops.
28. The interface between a BXM feeder trunk and an MGX 8220 feeder is always considered to be an NNI interface. (CSCdj16808)
29. When adding more than 4000 connections on a BPX node, the VC polling rate must be changed to a higher interval, to accommodate the additional time needed to poll for the statistics for each VC. The cnfsysparm command, parameter 24, must be changed according to the following:
0-3999 connections
Polling Rate: 5 Minutes (or higher)
4000-7999 connections
Polling Rate: 10 Minutes (or higher)
> 8000 connections
Polling Rate: 15 Minutes
30. Given a connection that terminates on an IGX 8400 FRM at one end and an ASI on the other end, tstdelay initiated at the FRM end may not work if the ASI firmware is below the appropriate revision and does not support OAM cells as opposed to supervisory cells. This is because the updated BTM on the IGX will always generate OAM cells. Please check the Compatibility Matrix.
31. Because the detailed card error event log is not retained within BRAM, this information will be lost should a processor rebuild occur. Therefore, when issuing a 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.
32. When a physical-layer failure (for example, LOS) is detected on the BXM, a Major Alarm is generated, and any connection routed over that port is downed (fail state). The software sends a command to the remote end of the connection to generate AIS in the egress direction (CSCdj30543).
Impact:
Since the connection is in a failed state, AIS is generated in the upstream direction (in addition to the downstream direction). Although this does conform to the letter of the I.610 standard, this is not necessarily what a user would expect to see, because it interferes with the RDI response from the end-to-end connection termination point. (A fault in the downstream direction causes a fault in the upstream direction.)
Reason for the current implementation:
The BNI can not generate AIS. If there is a fault at a BNI trunk, the current mechanism is to cause AIS to be generated by the BXM port by downing the connection. Since the BXM can generate only OAM cells from the RCMP, and the RCMP is in the ingress path, the cells must be backward routed to the egress (egress QE). Also, since end-to-end OAM cells are required, the ingress QE must be configured to drop ALL cells in the ingress path. This creates a break in continuity in the opposite direction, and AIS cells must also be generated at the other end of the same connection, in the upstream direction of the original fault.
33. There are problems in the downgrade mechanism that can cause database corruption. If a downgrade is performed immediately after upgrading, the Stby_Info revision fields are not yet filled in on the new active CC. They don't get filled in until there is an upcard response from the new locked CC. This causes a restart instead of a switchcc. If the locked CC is reset, then downgrade immediately, a restart will occur instead of a switchcc. (CSCdj30811).
34. In order to test/simulate the Y-redundant switchover of ASI T3 or E3 pairs the 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).
35. UBR traffic gains an advantage over ABR traffic when UBR and ABR PVCs are combined on the same network. This is because UBR and ABR PVCs share the same Qbin (Class of Service Queue) on the BXM card. ABR PVCs use a flow control mechanism, VSVD, which ensures that traffic sources slow down when the Qbin usage exceeds the EFCI threshold. However, UBR PVCs do not have this throttling mechanism. Therefore, ABR will throttle back whereas UBR will not. This unfair advantage is not considered a problem, since the decision to share a Qbin for ABR and UBR traffic was intentional. Any best-effort service that one would route over UBR can be routed over ABR(VSVD), with the additional benefit of protecting resources in the network. If UBR and ABR PVCs are required then:
Option 1: Consider adding all best-effort PVCs as UBR
Option 2: Isolate the ABR and UBR paths by using cnfpref command to ensure that ABR and UBR PVCs do not share the same queues.
Option 3: To provide UBR service on a connection, rather than setting up a UBR connection, do the following:
Step 1 Set up an ABRSTD connection.
Step 2 Enable VSVD.
Step 3 Disable FCES (Flow Control External Segment).
Step 4 Disable DEFAULT EXTENDED PARAMETERS.
Step 5 Choose policing option "4" to allow access as UBR.1 (PCR policing only). This connection has ABR VSVD in the network and allows UBR.1 access. The MCR for such ABRSTD connection may be set at the minimum acceptable value of 6 cells per second (explained later to do so).
To provide ABR service on a connection, set up an ABRSTD connection, enable VSVD and enable FCES to allow RM cells to be passed to and from customer equipment. The MCR for such ABRSTD connections can be set at any user-desired value.
When the network is experiencing congestion, all the affected ABRSTD connections, regardless of the services (ABR or UBR) they are carrying, will all be throttled back at the VSVD points at the network edge. During network congestion, connections carrying UBR services are virtually stopped (to a throughput of a mere 6 cps) while connections carrying ABR services can send at a much higher, user-desired MCR. This option would avoid that UBR service gains an unfair advantage over ABR service while sharing the same CoS queue.
36. Combining Frame Based Traffic Control (FBTC) and non-FBTC connections within a Class of Service can cause FBTC connections to not receive a fair share of bandwidth. For example, if VBR connections are added at a terminating port, and some of these VBR connections have FBTC enabled while other VBR connections have FBTC disabled, the VBR connections with FBTC disabled may obtain all of the excess bandwidth before the connections with FBTC enabled receive any of the excess bandwidth. The same holds true for ABR or UBR connections. This is relevant only where FBTC and non-FBTC connections share a Qbin, either at a port or at a trunk.
37. The maximum number of VC PARMs supported: 749 for BCC-32 MB, 2,999 for BCC-64 MB. (CSCdj48589).
VC PARMs are Virtual Circuit Parameters combinations/sets. One set of VC Parameter is used for each unique Virtual Circuit that has been provisioned. Identically provisioned VCs (exclusive of end points) use the same set of parameters. Thus, on a 32MB BCC, a total of 749 uniquely configured Virtual Circuits can be provisioned.
38. Care must be taken when changing the Deroute Delay parameter, which is controlled by the 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.
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
MEK
MEB
BXM-T3-8/12
BXM-T3
BXM
F
MFM
MFJ
BXM-E3-8/12
BXM-E3
BXM
E
MEK
MEB
BXM-E3-8/12
BXM-E3
BXM
F
MFM
MFJ
BXM-155-4/8
BXM-155
BXM
E
MEK
MEB
BXM-155-4/8
BXM-155
BXM
F
MFM
MFJ
BXM-622/622-2
BXM-622
BXM
E
MEK
MEB
BXM-622/622-2
BXM-622
BXM
F
MFM
MFJ
BXM-T3-8E/12E/12EX
BXM-T3
BXM
E
MEK
MED
BXM-T3-8E/12E/12EX
BXM-T3
BXM
F
MFM
MFJ
BXM-E3-8E/12E/12EX
BXM-E3
BXM
E
MEK
MED
BXM-E3-8E/12E/12EX
BXM-E3
BXM
F
MFM
MFJ
BXM-155-4D/8D/4DX/8DX
BXM-155
BXM
E
MEK
MED
BXM-155-4D/8D/4DX/8DX
BXM-155
BXM
F
MFM
MFJ
BXM-622-2D/DX/2DX
BXM-622
BXM
E
MEK
MED
BXM-622-2D/DX/2DX
BXM-622
BXM
F
MFM
MFJ
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
CAF
CAE
IGX-ALM/B
ALM
ALM-B
B
CBL
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
ZAV
ZAN
IGX-UFM-4C/8C
UFM
UFM-C
B
ZBE
ZBA
IGX-UFM-8C
UFM
UFM-C
C
n/s
n/s
IGX-UFM-U
UFMU
UFM-U
A
YAN
YAH
IGX-UFM-U
UFMU
UFM-U
B
YBD
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
ABL
ABJ
IGX-UXME
UXM
UXM
B
ABL
ABJ
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.
MGX 8220 Firmware Compatibility
5.0
4.1
4.0
PCB Description
CW2000 Name
Latest F/W
Min F/W
Latest F/W
Min F/W
Latest F/W
Min F/W
ASC F/W
ASC
5.0.16
5.0.10
4.1.10
4.1.00
4.0.21
4.0.04
ASC Boot
ASC
1.0.03
1.0.01
1.0.03
4.0.04
1.0.01
4.0.03
ASC/2 FW
ASC
5.0.16
5.0.10
4.1.10
4.1.00
4.0.21
4.0.09
ASC/2 Boot
ASC
1.0.03
1.0.01
1.0.03
4.0.04
1.0.01
4.0.04
ASC/2F FW
ASC
5.0.16
5.0.10
4.1.10
4.1.05
4.0.21
4.0.21
ASC/2F Boot
ASC
1.0.03
1.0.01
1.0.03
1.0.01
1.0.01
1.0.01
BNM-T3
BNM-T3
n/a
n/a
n/a
n/a
n/a
n/a
BNM-E3
BNM-E3
n/a
n/a
n/a
n/a
n/a
n/a
BNM-155
BNM-155
n/a
n/a
n/a
n/a
n/a
n/a
FRSM-4T1
FRSM-4T1
4.0.22
4.0.19
4.0.23
4.0.13
4.0.19
4.0.04
FRSM-4E1
FRSM-4E1
4.0.22
4.0.19
4.0.23
4.0.13
4.0.19
4.0.04
FRSM-4T1-C
FRSM-4T1-C
4.0.22
4.0.19
4.0.23
4.0.13
4.0.19
4.0.04
FRSM-4E1-C
FRSM-4E1-C
4.0.22
4.0.19
4.0.23
4.0.13
4.0.19
4.0.04
FRSM Boot
FRSM-4T1
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
FRSM Boot
FRSM-4E1
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
FRSM Boot
FRSM-4T1-C
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
FRSM Boot
FRSM-4E1-C
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
SRM T1E1 (B)
SRM-T1E1
n/a
n/a
n/a
n/a
n/a
n/a
SRM 3T3
SRM-3T3
n/a
n/a
n/a
n/a
n/a
n/a
CESM-4T1
CESM-4T1
4.0.17
4.0.15
4.0.17
4.0.11
4.0.15
4.0.04
CESM-4E1
CESM-4E1
4.0.17
4.0.15
4.0.17
4.0.11
4.0.15
4.0.04
CESM Boot
CESM-4T1
4.0.01
4.0.01
4.0.01
4.0.00
4.0.01
4.0.00
CESM Boot
CESM-4E1
4.0.01
4.0.01
4.0.01
4.0.00
4.0.01
4.0.00
CESM-8T1
CESM-8T1
5.0.14
4.1.05
4.1.09
4.1.00
n/s
n/s
CESM-8E1
CESM-8E1
5.0.14
4.1.05
4.1.09
4.1.00
n/s
n/s
CESM-8 Boot
CESM-8T1
1.0.01
1.0.01
1.0.01
4.1.00
n/s
n/s
CESM-8 Boot
CESM-8E1
1.0.01
1.0.01
1.0.01
4.1.00
n/s
n/s
AUSM-4T1
AUSM-4T1
4.0.21
4.0.19
4.0.21
4.0.13
4.0.19
4.0.04
AUSM-4E1
AUSM-4E1
4.0.21
4.0.19
4.0.21
4.0.13
4.0.19
4.0.04
AUSM Boot
AUSM-4T1
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
AUSM Boot
AUSM-4E1
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
4.0.00
FRSM-8T1
FRSM-8T1
5.0.15
5.0.10
4.0.24
4.0.13
4.0.19
4.0.04
FRSM-8E1
FRSM-8E1
5.0.15
5.0.10
4.0.24
4.0.13
4.0.19
4.0.04
FRSM-8T1 Boot
FRSM-8T1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.00
FRSM-8E1 Boot
FRSM-8E1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.00
AUSM-8T1
AUSM-8T1
5.0.14
5.0.10
4.0.24
4.0.14
4.0.20
4.0.04
AUSM-8E1
AUSM-8E1
5.0.14
5.0.10
4.0.24
4.0.14
4.0.20
4.0.04
AUSMB-8T1
AUSMB-8T1
5.0.14
5.0.10
4.0.24
4.0.19
4.0.20
4.0.19
AUSMB-8E1
AUSMB-8E1
5.0.14
5.0.10
4.0.24
4.0.19
4.0.20
4.0.19
AUSM-8T1E1 Boot
AUSM-8T1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.00
AUSM-8T1E1 Boot
AUSM-8E1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.00
AUSM-8T1E1 Boot
AUSMB-8T1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.00
AUSM-8T1E1 Boot
AUSMB-8E1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.00
FRSM-HS1
FRSM-HS1
5.0.14
4.0.16
4.0.20
4.0.11
4.0.16
4.0.04
FRSM-HS1/B
FRSM-HS1/B
5.0.14
4.0.16
4.0.20
4.0.11
4.0.16
4.0.04
FRSM-HS1 Boot
FRSM-HS1
1.0.01
1.0.01
1.0.01
4.0.00
1.0.01
4.0.00
FRSM-HS1 Boot
FRSM-HS1/B
1.0.01
1.0.01
1.0.01
4.0.00
1.0.01
4.0.00
FRSM-HS2
FRSM-HS2
5.0.13
5.0.10
n/s
n/s
n/s
n/s
FRSM-HS2 Boot
FRSM-HS2
1.0.01
1.0.01
n/s
n/s
n/s
n/s
IMATM
IMATM-T3T1
n/s
n/s
4.0.22
4.0.13
4.0.19
4.0.04
IMATM
IMATM-E3E1
n/s
n/s
4.0.22
4.0.13
4.0.19
4.0.04
IMATM
IMATMB-T1
5.0.14
5.0.10
4.0.22
4.0.13
4.0.19
4.0.04
IMATM
IMATMB-E1
5.0.14
5.0.10
4.0.22
4.0.13
4.0.19
4.0.04
IMATM Boot
IMATM-T3T1
n/s
n/s
1.0.02
4.0.01
1.0.01
4.0.01
IMATM Boot
IMATM-E3E1
n/s
n/s
1.0.02
4.0.01
1.0.01
4.0.01
IMATM Boot
IMATMB-T1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.01
IMATM Boot
IMATMB-E1
1.0.02
1.0.01
1.0.02
4.0.01
1.0.01
4.0.01
MGX 8250 1.1.3x Firmware Compatibility
PCB Description
CW2000 Name
Latest F/W
Min F/W
PXM1
PXM-1
1.1.32
1.1.32
PXM1-2-T3E3
PXM1-2T3E3
1.1.32
1.1.32
PXM1-4-155
PXM1-4OC3
1.1.32
1.1.32
PXM1-1-622
PXM1-OC12
1.1.32
1.1.32
MGX-SRM-3T3/C
SRM-3T3
n/a
n/a
AX-CESM-8E1
CESM-8E1
10.0.21
10.0.21
AX-CESM-8T1
CESM-8T1
10.0.21
10.0.21
MGX-AUSM-8E1/B
AUSMB-8E1
10.0.21
10.0.21
MGX-AUSM-8T1/B
AUSMB-8T1
10.0.21
10.0.21
MGX-CESM-T3
CESM-T3
10.0.21
10.0.21
MGX-CESM-E3
CESM-E3
10.0.21
10.0.21
AX-FRSM-8E1/E1-C
FRSM-8E1
10.0.21
10.0.21
AX-FRSM-8T1/T1-C
FRSM-8T1
10.0.21
10.0.21
MGX-FRSM-HS2
FRSM-HS2
10.0.22
10.0.22
MGX-FRSM-2CT3
FRSM-2CT3
10.0.22
10.0.22
MGX-FRSM-2T3E3
FRSM-2T3
10.0.22
10.0.22
MGX-FRSM-2T3E3
FRSM-2E3
10.0.22
10.0.22
MGX-FRSM-HS1/B
FRSM-HS1/B
10.0.21
10.0.21
MGX-VISM-8T1
VISM-8T1
2.0.(1)
1.5.05
MGX-VISM-8E1
VISM-8E1
2.0.(1)
1.5.05
MGX-RPM-128M/B
RPM
12.1(5.3)T_XT
12.1(5.3)T_XT
MGX-RPM-PR
12.1(5.3)T_XT
12.1(5.3)T_XT
CWM
10.4
10.4
MGX 8850 1.1.3x Firmware Compatibility
PCB Description
CW2000 Name
Latest F/W
Min F/W
PXM1
PXM-1
1.1.32
1.1.32
PXM1-2-T3E3
PXM1-2T3E3
1.1.32
1.1.32
PXM1-4-155
PXM1-4OC3
1.1.32
1.1.32
PXM1-1-622
PXM1-OC12
1.1.32
1.1.32
MGX-SRM-3T3/B
SRM-3T3
n/a
n/a
MGX-SRM-3T3/C
SRM-3T3
n/a
n/a
AX-CESM-8E1
CESM-8E1
10.0.21
10.0.21
AX-CESM-8T1
CESM-8T1
10.0.21
10.0.21
MGX-AUSM-8E1/B
AUSMB-8E1
10.0.21
10.0.21
MGX-AUSM-8T1/B
AUSMB-8T1
10.0.21
10.0.21
MGX-CESM-T3
CESM-T3
10.0.21
10.0.21
MGX-CESM-E3
CESM-E3
10.0.21
10.0.21
AX-FRSM-8E1/E1-C
FRSM-8E1
10.0.21
10.0.21
AX-FRSM-8T1/T1-C
FRSM-8T1
10.0.21
10.0.21
MGX-FRSM-HS2
FRSM-HS2
10.0.22
10.0.22
MGX-FRSM-2CT3
FRSM-2CT3
10.0.22
10.0.22
MGX-FRSM-2T3E3
FRSM-2T3
10.0.22
10.0.22
MGX-FRSM-2T3E3
FRSM-2E3
10.0.22
10.0.22
MGX-FRSM-HS1/B
FRSM-HS1/B
10.0.21
10.0.21
MGX-VISM-8T1
VISM-8T1
2.0.(1)
1.5.05
MGX-VISM-8E1
VISM-8E1
2.0.(1)
1.5.05
MGX-RPM-128M/B
RPM
12.1(5.3)T_XT
12.1(5.3)T_XT
MGX-RPM-PR
12.1(5.3)T_XT
12.1(5.3)T_XT
CWM
10.4
10.4
BPX 8600 Hardware Compatibility
Card Type
Part Numbers
Latest H/W
Min. H/W
Controller Cards
BPX-BCC-32M (Non-Orderable)
73-213840-00
P
A
BPX-BCC-64M (Non-Orderable)
800-04008-04
A
A
BPX-BCC-BC (Non-Orderable)
73-211380-00
D
A
BPX-BCC-3-32M (Non-Orderable)
800-04004-04
R
J
BPX-BCC-3-64M
73-3720-02
R
J
BCC-3BC
800-02916-01
E
A
BPX-BCC4V
800-03580-06
E
C
BPX-BCC4V/B
800-06483-02
C
A
Alarm Group
BPX-ASM
800-04009-01
C
A
BPX-ASM-BC
73-211910-00
C
A
ASM-LM
800-211910-10
B
A
BroadBand Switch Group
BPX-BXM-T3-8
800-02777-07
H
A
BPX-BXM-E3-8
800-02779-07
H
A
BPX-BXM-T3-12
800-02776-07
H
A
BPX-BXM-E3-12
800-02778-07
H
A
BPX-T3/E3-BC
73-2759-02
A
A
BPX-BXM-155-8
800-02664-07
H
B (C for APS)
BPX-MMF-155-8-BC
800-03255-01
B
A
BPX-SMF-155-8-BC
800-03257-01
B
A
BPX-SMFLR-155-8-BC
800-02593-02
B
A
BPX-BXM-155-4
800-02666-07
H
B (C for APS)
BPX-MMF-155-4-BC
800-03256-01
B
A
BPX-SMF-155-4-BC
800-03258-01
B
A
BPX-SMFLR-155-4-BC
800-02594-02
B
A
BPX-BXM-622
800-02646-10
L
D (E for APS)
BPX-BXM-622-2
800-02638-10
L
D (E for APS)
BPX-622-2-BC
73-2884-01
D
A
BPX-SMF-622-BC
800-03249-01
C
A
BPX-SMF-622-2-BC
800-03251-01
C
A
BPX-SMFLR-622-BC
800-03250-01
C
A
BPX-SMFLR-622-2-BC
800-03252-01
D
A
BPX-XLR-622
800-02738-01
C
A
BPX-XLR-622-2
800-02739-01
C
A
BPX-BME
800-02855-04
B
A
BPX-BME-OC12
73-2469-07
F
A
BPX-BXM-E-T3-8E
800-03933-02
A
A
BPX-BXM-E-E3-8E
800-03928-02
A
A
BPX-BXM-E-T3-12E
800-03931-02
A
A
BPX-BXM-E-E3-12E
800-03929-02
A
A
BPX-BXM-E-T3-12EX
800-03934-02
A
A
BPX-BXM-E-E3-12EX
800-03930-02
A
A
BPX-BXM-E-155-4D
800-03094-02
A
A
BPX-BXM-E-155-4DX
800-03093-02
A
A
BPX-BXM-E-155-8D
800-03092-02
A
A
BPX-BXM-E-155-8DX
800-03091-02
A
A
BPX-BXM-E-622-DX
800-03151-02
A
A
BPX-BXM-E-622-2D
800-03150-02
A
A
BPX-BXM-E-622-2DX
800-03149-02
A
A
RDNT-SMF-155-4R
800-03677-01
J
A
RDNT-SMF-155-8R
800-03679-01
K
A
RDNT-LR-155-8R
800-03678-01
J
A
RDNT-LR-622-2R
800-03676-01
F
A
RDNT-SMF-622R
800-03675-01
F
A
RDNT-SMF-622-2R
800-03674-01
J
A
BPX-T3/E3
800-03058-02
E
A
BPX-E3-BC
73-213070-01
E
A
BPX-MMF-2-BC
73-214290-00
D
A
BPX-SMF-2-BC
73-216270-00
D
A
BPX-SMFLR-2-BC
73-216270-01
D
A
BPX-STM1-EL-4
800-03716-02
A
A
BNI-3-T3/C
800-02858-02
A
A
BNI-3-E3/C
800-02859-02
A
A
SMF-LM-OC3
800-216270-10
C
A
SMF-LM-OC3-LR
800-216270-11
C
A
MMF-LM-OC3
800-214290-10
B
A
LM-3T3
800-213070-10
D
A
LM-3E3
800-213070-11
D
A
IGX 8400 Hardware Compatibility
Card Type
Part Numbers
Latest H/W
Min. H/W
* Note Below
Controller Cards
IGX-NPM-32
73-2894-01
W
A
IGX-NPM-64
73-2895-01
W
A
IGX-NPM-32B
73-2554-04
L
A
IGX-NPM-64B
73-2363-02
C
A
IGX-SCM
73-3341-01
Y
A
Revision X or later for nodes with UXM IMA trunks
Alarm Group
IGX-ARM
73-218230-00
B
A
BC-512011
73-212360-00
D
A
Trunk Group
IGX-NTM
73-2296-04
E
A
BC-6271A-TI
73-207380-00
M
A
BC-6171A-E1
73-207370-01
P
A
BC-6083A-SR
73-208540-00
J
A
BC-550150-Y1
73-210820-01
D
A
IGX-BTM/B
73-3005-02
B
A*
"*Show AIT H/W Rev, BTM(B)=AIT+ACM1"
ACM1
73-2921-03
W
A
BC-571110A-T3
73-2879-01
L
A
BC-571210A-E3
73-2679-01
K
A
BC-571310A-E2
73-215940-00
D
A
AIT BC HSSI/E2
BC-571410A-HSSI
73-216370-00
A
A
AIT GIM HSSI
IGX-ALM/A
73-2558-03
J
A
IGX-ALM/B
73-2558-03
J
A
BC-UAI-1T3
73-217040-00
C
A
BC-UAI-1E3
73-2986-01
E
A
IGX-UXM
73-2511-03
D
A
BC-UAI-4-155-SMF
73-2703-03
D
A
BC-UAI-4-155-MMF
73-2705-03
D
A
BC-UAI-2-155-SMF
73-2699-03
C
A
BC-UAI-6-T3
73-2952-02
A
A
BC-UAI-3-T3
73-2954-02
A
A
BC-UAI-6-E3
73-2953-02
A
A
BC-UAI-3-E3
73-2955-02
A
A
BC-UAI-8-E1-BNC
73-2932-02
C
A
BC-UAI-4-E1-BNC
73-3061-01
C
A
BC-UAI-8-T1-DB15
73-2941-02
C
A
BC-UAI-8-E1-DB15
73-2942-02
C
A
BC-UAI-4-T1-DB15
73-3059-01
C
A
BC-UAI-4-E1-DB15
73-3060-01
C
A
BC-UAI-4-STM1E
73-3364-02
A
A
Port Group
IGX-FTM
73-2519-01
M*
A*
"*Show FTC H/W Rev, FTM=FTC+ACM1A"
ACM1A
73-2930-03
W
A
BC-6351A-V35
73-213240-00
E
A
FPC-V.35
BC-6352A-T1
73-213420-00
C
A
FPC-T1
BC-6353A-E1
73-213410-00
B
A
FPC-E1
BC-6354A-X21
73-214120-00
C
A
FPC-X21
IGX-HDM
73-2853-02
H
F
"*Show SDP H/W Rev, HDM=SDP+ACM2"
ACM2
73-2922-03
T
A
BC-5082A-V35
73-2450-01
K
A
BC-5083A-RS449
73-204850-00
V
A
BC-5084B-RS232
73-2723-01
W
A
IGX-LDM
73-207250-00
K
A
"*Show LDP H/W Rev, LDM=LDP+ACM1A"
BC-5286A-RS232
73-207180-01
L
A
LDI-4RS232
BC-5287A-RS232
73-207180-00
L
A
LDI-8RS232
IGX-CVM-DSOA
73-3002-02
D
A*
"*Show CDP H/W Rev, CVM=CDP+ACM1A"
IGX-CVM-T1EC
73-3003-03
E
A*
"*Show CDP H/W Rev, CVM=CDP+ACM1A"
IGX-CVM-E1EC
73-209660-00
H*
A*
"*Show CDP H/W Rev, CVM=CDP+ACM1A"
BC-6271A-TI
73-207380-00
M
A
BC-6171A-E1
73-207370-01
P
A
BC-550100-J1
73-210820-00
C
A
IGX-FRM
73-2517-03
N
A
IGX-FRM-31
73-2517-03
N
A
IGX-FRM-2
73-2519-01
M*
A*
"*Show FRP H/W Rev, FRM-2=FRP+ACM1A"
BC-6251B-V35
73-3253-01
M
A
FRI-4V.35-2
BC-6254A-X21
73-211440-00
H
A
FRI-X.21
BC-6355A-X21
73-214120-01
C
A
FRI-2X21
IGX-UFM-4C
73-2531-05
N
A
IGX-UFM-8C
73-2531-05
N
A
BC-UFI-8T1-DB15
73-2444-02
D
A
BC-UFI-8E1-DB15
73-2445-02
D
A
BC-UFI-8E1-BNC
73-2449-02
D
A
IGX-UFM-U
73-2349-04
D
A
BC-UFI-12V35
73-2711-01
D
A
BC-UFI-12X21
73-2712-01
D
A
BC-UFI-4HSSI
73-2693-01
C
A
IGX-UVM
73-2361-04
K
A
BC-UVI-2E1EC
73-2420-01
B
A
BC-UVI-2T1EC
73-2373-01
C
A
BC-UVI-2J1EC
73-2374-01
A
A
Known Anomalies
The following is the list of known anomalies in this Switch Software delivery. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the release note enclosure of the problem record in Bug Navigator.
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:
None.
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 SWSW computes the the be/bc values internally when the non-standard parameter set is in use.
UFM FW version Y.A.F is also required to fix this issue.
CSCdk91790
Symptom:
SWSW system idle time is below 30% when more than 10 UVMs are activated.
Conditions:
SWSW polls each activated UVM for modem status every 1 second for each port. SWSW 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 FW has supported asynchonous 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.
Further Problem Description:
None.
CSCdm22426
Symptom:
While using jobs to down or up the connection based on a job trigger, 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.
CSCdp33410
Symptom:
Swerr 9083 was logged although nothing corresponded in the log during that time frame.
Swerr 9083 is due to a CBUS message to card FW that gets dropped between the CC and the SM, in this case, the BCC and the ASI card. A CBUS trace has been setup and captured to investigate what the message was that was dropped. This issue never interupted service.
CSCdp98648
Symptom:
Equipment MGR can not tell the different between BXM legacy or enhance version.
Workaround:
Log into the BPX node and do dspcd XX and determine from number of channel support. 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.
Workaround:
Use the CLI commands to delete feeder trunks.
CSCdr26161
Symptom:
burnfwrev on a UXM card says "Already burning firmware. Try again later" for a very 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).
Already burning firmware. Try again later Next Command:
Conditions:
Reset must be done after all burn addresses are updated.
Workaround:
Do not reset the card during burnfw process.
CSCdr45021
Symptom:
SCT 1 is the default SCT reserved for MPLS. When an SES trunk is provisioned and if the default SCT is not changed to SCT 3, the trunk will fail to come up.
Conditions:
A warning message on the configuration screen indicates that the default is SCT 1 for MPLS and should be changed to SCT 3 for SES will be useful.
Workaround:
Check that SES uplink uses SCT 3 as service template class.
CSCdr89767
Symptom:
Software error 945 logs continuously.
Conditions:
Ongoing failure with normal network conditions
Workaround:
None. Note that reconfiguration of nwip and lanip did not help
CSCds21195
Symptom:
The node becomes unavailable at the U/I. Several cards removed and reinserted themselves. Software error 112 logs repeatedly.
Workaround:
Identify the faulty card using the information in the SWLOG Assistant, remove it from the node and replace it.
CSCds27806
Symptom:
BPX lan becomes unreachable intermitently via telnet.
Conditions:
swsw 9.2.30
Workaround:
Manipulate the lanip and gateway ip then return to original config.
The display attempts to display the port on the via trunk before it is properly set.
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.
CSCdt07203
Symptom:
The hitless rebuild log fills due to repeated failed switchccs.
Conditions:
A bad standby BCC is required. The node must be running at least 9.2.
Workaround:
Clear the hitless log with the command dsphitless c or switchcc less often so that the hitless rebuild log tried get a chance to age out of the log.
CSCdt11023
Symptom:
Frame Relay foresight connection discard traffic when routed over a OC3 virtual trunk.
Condition:
The customers network consisists of IGX switches mainly using NTM subrate trunks.
The OC3 virtual trunk is currently the only one in use.
All system conditions are normal non foresight traffic is transmitted successfully over the OC3 virtual trunk.
Workaround:
Remove foresight from the connections and increase the MIR value on the connections.
Further Problem:
None.
CSCdt14469
Symptom:
After configuring LMI/ILMI on BME ports, software errors 319 and 524 are logged.
Conditions:
This will occur when attempting to enable, disable or configure LMI/ILMI on a BME port. Moreover, once LMI/ILMI has been enabled on the port, any new port programming will re-trigger the logging of these two software errors.
Workaround:
Do not enable LMI/ILMI on BME cards. ILMI/LMI is not supported on BME cards, we should not be attempting to enable, or configure it. If LMI/ILMI is currently enabled on a BME port, use the CLI command [cnfport] to disable it, and then clear the software error log of the 319 and 524.
CSCdt22924
Symptom:
Bad clock source during dn/upcd.
Condition :
dncd/upcd causes the clock failure " Minor bad clock source".
Workaround :
clrclkalm will clear the clock failure.
CSCdt25359
Symptom:
Connections failed after APS redundancy was deleted then re-added.
Conditions:
A BPX running 9.2.32 with APS on a bxm-155-8dx.
Workaround:
switchyred fixed problem
CSCdt31282
Symptom:
dsptrkutl command shows wrong values for feeder trunks. It shows all terminated connections as Frame relay connections.
Conditions:
It happens only on feeder trunk connected to a feeder.
Workaround:
Look for the terminated connections using dspcons.
CSCdt42620
Symptom:
Swerr 9000 logged on CVM. Function code 0x88. Not associated with any log events. Non-impacting.
Conditions:
SWSW 9.2.34. CVM with firmware DBF. Occurence is rare. Noted after swsw upgrade from 9.1.x.
Workaround:
No workarounds available at this time.
Further Problem Description:
Occurences of swerr are intermittent and do not appear to be triggered by anything noted in the switch event log. Errors on card do not impact operation or service of the card. Occurence of error on cards is rare. Does not impact all cards of same type in same network.
CSCdt43014
Symptom:
SWLOG error 557 on BPX node occurs when deleting connections.
Conditions:
BPX 9.3.11 MGX:1.1.32.
Workaround:
None.
CSCdt55864
Symptom:
The Cisco Wan Manager's Statistics Collection Manager cannot parse the TFTP statistics file received from the IGX node.
Conditions:
This problem will only occur when the IGX node has FastPad connection enabled, and is collecting TFTP statistics on those connections.
Customer Impact:
When this problem occurs the customer will not be able to collect TFTP interval statistics from the IGX node.
Workaround:
There is no work around for collecting the FastPad connection statistics. However, if you disable statistics collection on the FastPad connections, you will be able to collect all of the other statistics.
Further Problem Description:
When writing the variable key length for the various FastPad connection types, an extra byte is added. This then throws off the CWM's parsing and it has no way of recovering, therefore the entire statistics file is discarded as corrutped or bad.
CSCdt66696
Symptoms:
AIT-E3 backcard is displayed as BTM-E3 in CLI.
Condition:
AIT-E3 backcard is displayed as BTM-E3 in switch CLI.
Workaround:
None.
CSCdt72052
Symptom:
UVM card did not initialize the signalling to default causing calls to fail. Upon executing cnfxmtsig and cnfrcvsig for the connection on UVM card it displays ? for signalling (i.e:R/TxAbit, R/TxBbit, R/TxCbit and R/TxDbit).
Conditions:
When a UVM card is first inserted, all its lines are initialized for voice channels and we set all the various voice channel related parameters viz. Signaling Qualifiers etc. for each line. However, when a line is downed, all the data structures are cleaned and all channels' configuration is defaulted to the uni data type channels.
Workaround:
Manually configure TX and Rx bits for appropriate signalling type using cnfxmtsig/ cnfrcvsig.
CSCdu00161
Symptom:
"Port Cells Received" on the dspchstathist> screen is 4-5% higher than the real(true) value.
Conditions:
None. Occurs on any connection with any VC sample rate.
Workaround:
None.
CSCdu15686
Symptom:
Internal port diagnostics fails for V35/X21 ports. use "tstport" command.
After the above test, card goes to "Active-F" state as seen in "dspcds".
Condition:
The above problem is seen only when port is configured as DCE and not
seen with DTE ports.
Tested with UFMU F/W version YAM and YAN and seen the same problem.
Workaround:
None.
CSCdu16679
Symptom:
Virtual trunk does not process traps received from ATM cloud, e.g. when the associated cloud VPC goes down.
Conditions:
(1) (a) ILMI protocol for the virtual trunk is running on the BCC (BNI virtual trunk) AND (b) the cloud port is NOT a BPX/IGX OR BPX/IGX with ILMI running on the BXM/UXM.
OR
(2) (a) ILMI protocol for the virtual trunk is running on the BXM or UXM AND (b) ILMI on the cloud port is running on the BCC/NPM of a BPX/IGX.
Workaround:
(1) If ILMI is running on the BCC at the virtual trunk end (BNI virtual trunk): (a) if the ATM cloud is a BPX/IGX, make the protocol run on the BCC/NPM. (b) if the ATM cloud is not a BPX/IGX, there is no workaround. However, the ILMI implementation on virtual trunk will find the VPC status using GET_REQUEST.
(2) For BXM virtual trunks and for UXM virtual trunks with protocol on the card (a) if the ATM cloud is a BPX/IGX, make the protocol to run on the card. (b) if the ATM cloud is not a BPX/IGX, there should be no problem. The trap is recognized and processed.
CSCdu17188
Symptom:
The via connection counts give by [dspviacons <nodename> s] are not correct, they are not including the via connections contributed by the node with node number 223 (the last node number).
Conditions:
This discrepency will only occur when dspviacons is run on the a node that has via connections from node number 223.
Workaround:
None.
CSCdu40956
Symptoms:
cbrt command displays obselete options "a" and "l".
Conditions:
This problem can be reproduced by executing "cbrt a" "cbrt l" commands.
Workaround:
Avoid entering the "a" and "l" options for this command.
CSCdu43755
Symptom:
cnfoamlpbk is nolonger support in 9.2. it is should be blocked from the user.
Conditions:
CLI from BPX node 'cnfoamlpbk'.
Workaround:
None.
CSCdu43858
Symptoms:
In a BCC-4, if a hitless rebuild is performed, the prompt indicates that the card is BCC-3 instead of a BCC-4.
Conditions:
This happens when the command "resetcd <card_no> r" is executed where <card-no> is the active card (either 7 or 8).
Workaround:
Proceed with the command, the system displays an incorrect model of BCC (i.e BCC-3 instead of BCC-4).
CSCdu45358
Symptom:
The switchover occured on bpx node when the active card was pulled out. The empty slot for this card was shown in the CLI, but the Network Browser was showing that the active card was still present.
Conditions:
None.
Workaround:
None.
CSCdu50924
Symptom:
Random failure of cons all over the network. No trunk or line failures reported. It took approximately 15 minutes to reroute.
Conditions:
Very large size of network more than hundred bpx nodes Provisioning, and ever increasing size of network cnfprefroute was being run (some of them over failed trunks) cnfcmparm parm 15 was set from 10 to 4 and cnfcmparm parm 9 was set from 2 to 900
Workaround:
Restored the cnfcmparm parameter 9 from 900 to 2. The random failures of cons stopped.
Further Problem Description:
None.
CSCdu54186
Symptoms:
Software error 532s are logged when the CLI command [cnfcos] is invoked and given junk values. This problem exists in previous releases as uninitialised variables. The problem appears intermittently in 9100 to 9320 depending on state of the stack.
Conditions:
This problem can be reproduced by:- invoking [cnfcos] and then any junk value such as XYZ, abc, etc.
At this point if you either wait for approximately 10 seconds, or if you cancel the command with the [del] key, the 532s will be logged.
Workaround:
Avoid entering junk values for this command.
Clear the event log after these values occur.
CSCdu55421
Symptoms:
Software error 1415 is logged when the CLI command [cnfpref] is invoked in a Cost-Based Routing network.
Conditions:
Cost base routing is on, cost delay option is off - cnfpref <connection vpi/vci> <explicit path>.
By chance, SW Err 1415 is logged, depends on whether the uninitialized random data is out of range or not. It could generates swerr 1423 too (OUT_OF_RANGE_LTRK).
Workaround:
Turn off cost base routing. Add the prefer path. Enable the cost base routing again.
CSCdu55966
Symptom:
Every 10 seconds a software error 111 or 190 is logged.
Conditions:
This occurs when running internal test software 9.3.3T software or later and you have:- a BXM-OC3-8 card with all 8 interfaces up, or - a T3/E3 card with 8 interfaces up and all T3/E3 stats enabled
This will occur in existing customer shipped software if you have:- a BXM-T3/E3 card with 9 or more interface up and all T3/E3 stats enabled.
Workaround:
Down interfaces on the card, - or use the [off2] command to disable line statistiscs polling (line stat sampling). - or disable some of the T3/E3 statistics.
Note that if disabling line stats polling, statistics will not work on lines and trunks. This is all statistics, the summary stats viewable via dsptrkstats, some dspportstats, the user interval stats viewable via dsplnstathist, dspphyslnstathist, dsptrkstathist, tftp stats reported to the CWM as well as any SNMP RTC stats related to lines or trunks, all will be stopped by disabling this stat polling.
Moreover, auto statistics which are used for statistical alarms will also stop.
CSCdu56959
Symptom:
On a BXM port, cnfrsrc displays the details of the first VSI partition by default and the second VSI partition only on request. This could be misleading.
Condition:
BXM port with VSI enabled.
Workaround:
As it is known that there are two VSI partitions, user should check each individually. Additionally, dspvsiif displays status of all VSI partitions.
CSCdu59784
Symptom:
Route Cost field is not displayed properly in the dspcon screen due to line overflow.
Conditions:
This problem is observed in the case of Voice connections where fields like compression are displayed and cost based routing is enabled.
Workaround:
1. dsprts can be used to see the Route Cost for a connection.
CSCdu60727
Symptom:
IGX doesn't send correct Abit status down SES trunk.
Conditions:
SES connects to IGX as a feeder. One end of the connection affected terminates on the SES service module, another end terminates on the remote BPX port. Because of the bug the SES considers the connection to be in FAILED ABIT ALARM condition and therefore customer equipment can't use it to transfer data.
Workaround:
Clrcnf on the IGX.
Further Problem Description:
None.
CSCdu61769
Symptom:
HDM connexion bouncing since 9.2.38 SWSW Release. Lead RxD (pin 3) is bounce from Idle state to active state with high frequence (once or twice every second).
Conditions:
This happen only if connexion rate below 64K.
Workaround:
Upgrade connexion to 64k.
Further Problem Description:
None.
CSCdu63593
Symptom:
The swsw will not check newly burned fw checksum for crc errors. The fw will not perform a checksum either. The newly burned card will boot and go into service with corrupted dram. The outcome can vary and may be service impacting.
Conditions:
Fwrev upgrade on all releases and swsw.
Workaround:
Physically reseat the bxm attempt to reburn fw replace hardware if in production. The outcome can be service impacting pending on outcome or root cause of dram corruption.
CSCdu64553
Symptom:
CLP 1 tagged traffic in a multi-vc environment cannot be differentiated from CLP 0 with the present default drop method on TAGCOS Qbins, EPD.
Conditions:
EPD is the configured default. In order to differentiate CLP 1 marked traffic, CLP hysteresis instead should be configured.
Workaround:
No workaround.
Further Problem Description:
None.
CSCdu64801
Symptom:
Using cnflan to change default gateway to None does not work. Invalid gateway IP address.
Conditions:
Normal.
Workaround:
None.
Further Problem Description:
None.
CSCdu65259
Symptom:
The user cannot use the [cnfsct] command unless they know all of the acceptable service class names.
Conditions:
This occurs whenever a users that is not completely knowledeable with the service class names attempts to use this command.
Workaround:
Execute the [dspsct] command to get a listing of the service classes, then execute [dspsct index] to get a listing of the applicable service class names.
CSCdu75709
Symptom:
When placing a UFMU front and 12 port v.35 back card in a slot previously occupied by a FRM and 4 port v.35 back card, the port query in the Informix database reports the ports from the previous card, 4.
Conditions:
All other updates, front and back cards,etc. via Informix queries, CiscoView and CLI appear to be correct .
Workaround:
The Informix port query does not update to 12 (the number of ports associated with the new card) until each port is manually upped via CLI or CiscoView.
CSCdu76163
Symptom:
There is not event log indicating when a feeder has been deleted.
Conditions:
Delete a feeder from the routing node.
Workaround:
None.
CSCdu84891
Symptom:
The symtoms are different between 9.3.30 and earlier releases.
[] For 9.3.30 release, the software error 3120 is logged when the command "dspospace" is executed on the IGX, or an SNMP WALK is performed on the connTable, or an SNMP GET is performed on any of the following objects. - connMstOSpacePkts - connMstOSpaceCells - connMstOSpaceBdaCmax - connMstOSpaceBdbCmax - connSlvOSpacePkts - connSlvOSpaceCells - connSlvOSpaceBdaCmax - connSlvOSpaceBdbCmax
Also, the values of the ms_lcl_vpc_conids_avail and sm_lcl_vpc_conids_avail parameters are invalid in the "dspospace" case. Since these parameters are not in the connTable, this is not a problem for the SNMP interface.
[] For ealier releases, no software error is logged, and only the ms_lcl_vpc_conids_avail and sm_lcl_vpc_conids_avail parameters are invalid in the "dspospace" case. The SNMP interface is not impacted.
Conditions:
The problem occurs when the "dspospace" command is executed, or the SNMP WALK is performed on the connTable, or the SNMP GET is performed on the objects mentioned in the Symptom section.
Workaround:
None.
CSCdu88501
Symptom:
Software Error 925 logged when switchcc. The slot has a UVM Card.
Conditions:
switchcc performed.
Workaround:
N/A.
Further Problem Description:
The swerr 925 was logged against INACTIVE line so this is informational and NOT service impacting.
CSCdu89124
Symptom:
Software error 26 occurs when a mib walk is done on a node when a card is down.
Conditions:
1. On a bpx node that has a card with sonet interface. The card is configured with trunk(s).
This SWLOG was observered while doing graceful upgrade from 9.2.4C to 9.2.4D
In igx node.
Workaround:
None.
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
CSCdk45222
This problem does not exist in 9.2
CSCdm01239
This problem was fixed in the first release of 9.2
CSCdm60702
Given the automatic recovery and the implementation of hitless rebuild in 9.2 and removal of many bus error triggers, this issue will not be addressed at this time. This bug has been closed.
CSCdm60707
Given the automatic recovery and the implementation of hitless rebuild in 9.2 and removal of many bus error triggers, this issue will not be addressed at this time. This bug has been closed.
CSCdp98648
This is currently in the 'I' state requesting more information from the submitter.
CSCdr25275
This has been closed with the recommendation that the customer submit a PER.
CSCdr25281
This has been closed with the recommendation that the customer submit a PER.
CSCdr75042
This bug has been closed and the issue addressed by modifying ABR-related flow control parameters.
CSCds33823
This has been closed as unreproducible.
CSCds34151
This bug has been closed and PER# 2699 has been opened for this issue.
CSCds57049
This is fixed in 9.2.40.
CSCdt16892
This bug is in the `C' (Closed) state because it works as designed.
CSCdt26312
This was closed as a duplicate of CSCdk48180 which was fixed in 9.2.38.
CSCdt62019
This was fixed in CWM 9.2.09
CSCdt97285
This is fixed in 9.2.40
CSCdu25641
This is fixed in 9.2.40
Problems Fixed in Release 9.2.40
Following is the list of fixed problems in 9.2.40 Switch Software release. Included with each is a brief discussion of the problem.
Bug ID
Description
CSCdr58334
Symptom:
Swerr 503 logged intermittently in extremely busy network.
Conditions:
This problem only occurs when the node attempts to send software revision information and network traffic is so dense that low priority network messages are dropped.
Workaround:
None.
CSCdr83230
Symptom:
Software errors 9093 and 9093 logged on IGX node.
Conditions:
Errors are logged when user attempts to modify an ATM port using CWM.
Workaround:
Use the CLI to modify the ATM port configuration.
CSCdr91680
Symptom:
1000003 abort in SNMP process while traversing SVC hash table. The hash table is traversed to add, delete, or find an SVC.
Conditions:
VNS/SVC call setup and deletes. This problem has been observed on a small percentage of nodes in a network. The unique characteristics of this small percentage of nodes that have the problem have not been identified.
Workaround:
None known, except to stop SVC provisioning. A rebuild can be avoided by having a redundant NPM. The rate of occurance has been low enough that no nodes have rebuilt.
Further Problem Description:
The source of the corruption to the SVC hash table has not been identified. Software has been added to detect the corruption and correct the problem. A software error 507 will be logged to provide additional information.
Each swerr may leave allocated memory blocks that have not been freed. The SE should monitor the memory utilization on the nodes that have this swerr and issue a switchcc if memory limitations are observed. The maximum number of blocks which may not be freed with each swerr 507 is 5 (with a maximum SVC ID from NMS being 512). The "dspprf r t" screen will show how many blocks are available in the "DYNM" region and the overflow regions.
Decode of swerr 507:No. Type Number Data(Hex) PC(Hex) PROC SwRev Date Time 1. Error 507 FFFFEB30 302204B0 SNMP 9.1.w5 08/22/00 16:10:10
bad pointer = FF FF EB 30 index = 00 02 (index into linked list headers) LL entry = 00 03 (entry in linked list) Last Ptr = 30 AC E9 F0 (last valid linked list entry) Last Svc ID = 00 CA (last valid SVC ID in linked list) Svc ID = 01 F6 (SVC ID of SVC being added) First Rebuild = 00 00 00 01 (first time rebuilding this list)
CSCdr95566
Symptom:
During BPX upgrade from 8.4.21 to 9.1.21, on 3 parameter 1 "Stby Heap memory init" was set to enabled.
Conditions:
BPX upgrade from 8.4.21 to 9.1.21.
Workaround:
Issue on3 to set the desired setting after upgrade.
Further Problem Description:
None.
CSCds26907
Symptom:
snmpwalk on BPX trunk connected to Popeye reports trunk port off by 1.
Conditions:
snmpwalk on BPX trunk connected to Popeye.
Workaround:
None.
Further Problem Description:
None.
CSCds52009
Symptom:
Empty slot reads reserved for BCC-3 when a BCC-4 is removed.
Conditions:
Problem is seen after removing the BCC-4 card from the slot.
Workaround:
None.
Further Problem Description:
This problem is because we dont have an independant card type for the BCC-4 card. Both BCC-4 and BCC-3 has same card types i.e. BCC-3.
CSCds57049
Symptom:
Card in active-F status when 2 or more lines of the card are in major alarm.
Conditions:
2 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.
Further Problem Description:
This problem only applies to ufm and not uxm. Also 9.1.xx works fine. 9.2 and 9.3 are affected.
CSCds62123
Symptom:
In the customer's network, the CNFCMB value for NTS is set to approximately 170 to allow lower speed NTS connections (g729a without VAD) to place two FastPackets in each ATM cell. This causes about 21 milliseconds of additional delay in each direction, or about 42 milliseconds or round-trip delay. This added delay is causing the echo.
Conditions:
The echo is caused by the fix for CSCdp58545 which causes the null-timing delay for NTS connections to correctly take into account the configured CNFCMB timer.
Workaround:
None.
Further Problem Description:
Echo on voice traffic over CVM-TT Nx64 connections. In the customer's network, the CNFCMB value for NTS is set to approximately 170 to allow lower speed NTS connections (g729a without VAD) to place two FastPackets in each ATM cell. This causes about 21 milliseconds of additional delay in each direction, or about 42 milliseconds or round-trip delay. This added delay is causing the echo.
What the customer would like is for the null-timing delay calculation (performed in the get_nulltms function in the vdp_cmds.c file) to NOT always add the configured NTS combinatorial delay to the calculated null-timer value.
Instead, they need the calculated null-time delay to include the SMALLER of - the configured combinatorial delay. or - 110% of the theoretical inter-FastPacket arrival time
For a 8x64 connection with 8/8 coding (3047 FastPackets/second), that would be about 360 MICROseconds.
It is important that this change be made ONLY for NTS connections and NOT voice connections since NTS connections are always building FastPackets with no possibility of interruption of the stream of FastPackets. Consequently. it is never possible to exceed the theoretical inter-FastPacket interval by much. Conversely. Voice connections (which use VAD) often experience interruptions in the flow of FastPackets.
CSCdt12153
Symptom:
IGX commands cnffrcls and cnfcon allow user to configure ECN threshold to be greater than VCQ depth.
Conditions:
Observed in IGX 9.2.35. Problem is not related to any traffic conditions.
Workaround:
Do not configure ECN threshold to be greater than the VCQ depth using the cnffrcls and cnfcon commands.
Further Problem Description:
This change/solution is working only when all the parameters are entered - i.e., when both the VC Qdepth and the ECN threshold along with the other parameters are specified in the command line, (it works) it shows an error message if VCqdepth < ECN threshold.
If only a few parameters are specified, for ex. the existing VCQ = 10000, ECN threshold = 6550. and now, i enter, VCQ = 5000, the value is accepted and no ERR message is shown.
CSCdt39231
Symptom:
Memory accumlation occurs after using TFTP to upload firmware.
Conditions:
This will occur whenever we upload new FW using TFTP.
Customer Impact:
Eventually, after an extremely long time, the node could run out of memory due to this memory leak, which could lead to memory allocation failures for important systems. A memory failure would cause a switchcc or a hitless rebuild.
However, it should be noted that the memory leak size is only 26 bytes which equates to 1 memory block (i.e. 1 256b dynamic region memory block) while the total amount of memory available on the system is approximately 32M or more.
Note:This is a very small memory leak and would require many, many, many TFTP FW uploads for this to be noticeable by the customer.
Workaround:
For a CC-redundant system, switching to the secondary CC would clean up the memory leak.
For a non-CC-redundant system, a full rebuild will clean up the firmware memory leak.
CSCdt39873
Symptom:
LMI and ILMI port stats are collected incorrectly when the secondary card of a Y-red pair is active on an IGX.
Conditions:
The dspportstats would show erroneous result of ILMI/LMI messaging if the secondary card of the Y-red pair becomes active.
Workaround:
Switch back to the primary card of the Y-red pair.
Further Problem Description:
None.
CSCdt40533
Symptom:
If we put a dnld.fw/dnld.sw file without the pathname a 1M3 abort is logged.
Conditons:
This problem happens if the Pathname or any other field is missing or misspelled in the start file.
Workaround:
Use the pathname field in the dnld.sw/dnld.fw instead of using the default pathname.
CSCdt45926
Symptom:
SW error 9098 is logged after the BCC is hitless rebuilt.
Conditions:
1. There are multiple enabled partitions in BXM card and BXM has more than one port group
2. One partition disabled and it will cause the mc_vsi_end_lcn less than before. the new mc_vsi_end_lcn will is invisible from dsplogcd, it can be seen after the BXM reset and in this bug ( BCC rebuilt)
Since the BCC will send the 0x62 msg to BXM with the new end lcn, this cmd will be rejected by BXM since it has invalid obj 6 (end lcn which is mc_vsi_end_lcn).
Workaround:
Reset the BXM will resyn all VSI connection and will fix this problem.
CSCdt60246
Symptom:
IGX feeder or SES has persistent local abit failure.
Conditions:
IGX feeder or SES is connected to an IGX with a UXM feeder trunk. After the feeder trunk experiences a physical alarm(Red/Yellow ...) the local abit status on the IGX feeder or SES may still indicate local abit failure.
Workaround:
All workarounds are executed on the IGX. The selection of a workaround depends on the number of connections affected, if few connections are affected, use workaround 1 or 2.
1. Perform a dncon/upcon on the connection
2. Delete and readd the connection delcon/addcon
3. Perform a switchcc
4. Perform a hitless rebuild resetcd <cmdArg>slot r<noCmdArg>
Further Problem Description:
The IGX is not properly integrating abit status changes received on the UXM feeder trunk via the LMI protocol.
CSCdt73112
Symptom:
dspcurclk display is not correct on BPX.
Conditions:
When dspcurclk is done on BPX, it does not show the trunk #s for the path to the clock source.
Workaround:
None.
CSCdt82310
Symptoms:
When a Virtual Trunk (VT) is upped on a BNI-OC3 interface, it comes up with the default of 1459 connection channels (Maximum is 1459 * 11 VTs = 16049 LCN). When the VT is re-configured to increase the LCN number, SwSw does not allow to configure more than the following value [3836 - channels in use by the other VT's of the same port].
For example,
1. If OC3 interface has a VT using 2500 LCNs, then bringing up the second VT will default to 1459 LCN, with total of 3959 LCNs. 2. Now if the 2nd VT's LCN is re-configured, SwSw does not allow to configure more than 1336 LCNs [3836 - 2500 = 1336]. 3. Instead, it is possible to bring up all the VTs (11) with the default value of 1459 LCNs without re-configuration.
Problem can be seen whenever a VT is re-configured with values of LCNs more than the value of [3836 - channels in use by the other VT's of the same port].
Workaround :
None.
CSCdt89196
Symptom:
Switch is low on memory.
Conditions:
Trunks go in and out of alarms continuously for a very long period.
Workaround:
switchcc will release the accumalated memory blocks.
CSCdt90475
Symptom:
cnfcon command cannot be added into job (using addjob or editjob command) in IGX.
Conditions:
Entering cnfcon command into a job in IGX. This problem does not occur on BPX.
Workaround:
None.
CSCdt92054
Symptom:
The dspcd command shows the Line Mode on a UXM-OC3 briefly and then it is blanked out. After dspcd is executed and screen updates occur, some lines on the right hand side of the display appear to be briefly blanked out, then re-written.
Conditions:
The Line Mode problem will occur if the UXM has firmware that supports CRC-4 configuration. It occurs because "Front Card Supports CRC-4 configuration)" is too long for the line and it wraps to the next line, erasing it. Any card that supports CRC-4 configuration will have this problem, it just may not be apparent if "Front Card Supports CRC-4 configuration" is the last line on the right side of the display.
The other problem with some lines being briefly overwritten on the right side of the display can be seen on all cards. The lines that are overwritten are the ones across from "Status:" and "Revision" on the display.
Workaround:
These are display problems only, there is no operational effect. There is no workaround.
CSCdt92193
Symptom:
VPC connections may not get bundled while routing
Conditions:
When VPC connections are rerouted (either during node rebuild or thro cli rrtcon ), they do not get bundled (can be see thro cli dsprrst). But this is not a service affecting bug. The conections are routed correctly (but may take a bit longer time reroute then when bundled).
Workaround:
None.
CSCdt93721
Symptom:
An extra character ("E" for E1 cards and "T" for T1 cards) is displayed between the "Config" word and the line format (T1 or E1) in the dsptrk and cnftrk screens
Conditions:
On a UXM IMA virtual trunk and the virtual trunk number is two digit. Eg:9.1(5).10
Workaround:
None. Just ignore the extra "E" for E1 cards and "T" for T1 cards.
CSCdt96759
Symptom:
OAM Rx State of AIS/RDI for a local connection is not updated correctly.
Conditions:
Local connections on the same card and port.
Workaround:
dspchstats <connection> will set the correct AIS/RDI status for the connection.
CSCdt97285
Symptom:
In strata.mib atmEndptSubType var has atfst value as (6) but is not defined in description following as other sub-types. need MIB update.
VC shaping is blocked on the CLI interface. But using the SNMP interface, VC shaping field in the atmTrunks MIB can be set, which thus causes the card to be programmed for VC shaping in trunks.
Conditions:
When configuring trunks using SNMP set commands, setting theatmTrkVc Shaping in atmTrunk MIB causes VC shaping to be programmed on card for the trunks.
Workaround:
None.
CSCdu18109
Symptom:
Slot 32 cons of remote IGX appear on slot 15 ( on the BPX) after inter-release upgrades.
Conditions:
After an inter-release upgrade, on the BPX side, the connection is displayed as terminating on slot 15 instead of slot 32.
Workaround:
User Traffic is not affected. Only way to clear up the display is to delete and re-add the connection.
Further Problem Description:
None.
CSCdu19452
Symptom:
The Standby NPM may abort logging SW Error 1000003 when "clrphyslnerrs" is entered.
Conditions:
When "clrphyslnerrs <slot.port>" is entered. Applicable to IGX only. SwSw Releases:All 9.1 releases, Rel 9.2 and Rel 9.3 prior to this fix.
Note that the abort is logged on the Standby controller card and NOT on the Active controller card. Since it is getting logged on the standby, there will not be any switchover but only a temporary loss of redundancy until the Standby controller card is updated
Workaround:
None.
Further Information:
A similiar fix for BPX (CSCdj31091) has been integrated in Release 8.4.05.
CSCdu19705
Symptom:
Software Error 614s are logged and two connections are auto-deleted when configurations are restored with about 800 connnections or more on IGX nodes.
Conditions:
This problem occurs when there VC indices 708 and 709 are used. The VC records are corrupted during the restore process.
Workaround:
Identify the connections lost and add them back manually.
CSCdu20243
Symptom:
AIS is not generated on a downed connection.
Conditions:
The line endpoint of the connection goes in and out of alarm that requires the conditioning of the connections.
Workaround:
Up the connection and then down the connection again after the line is in OK state.
CSCdu20347
Symptom:
dlm screen gets overwritten.
Conditions:
One or more of the LMI trace messages are lenghty.
Workaround:
There is no perfect workaround. Check the lengthy message sequence no. in column 1 and do clrscrn. Use dlm <#> command to directly display the lengthy message.
CSCdu24322
Symptom:
Network Browser(NWB) of Cisco Wan Manager(CWM) displays BXM for BXM-T3-8E and BXM-E3-8E cards.
Conditions:
Occurs when a BPX node has one of the following card types:BXM-T3-8E or BXM-E3-8E.
Workaround:
None.
CSCdu25344
Symptoms:
Software error (error code 9082) logged on IGX.
VP tunneling connections of type rt-VBR are not properly programmed. The connections don't pass traffic as a result.
VP tunneling connections of type rt-VBR do not display a valid type string when using dspcon or dspcons commands. The type field is blank.
Conditions:
Adding rt-vbr VP Tunneling Connection on UXM. The software errors are logged in pairs, one for each endpoint of the connection.
Workaround:
None.
CSCdu25641
Symptoms:
Adding a UVM(CVM) to FTM connection causes data base corruption and the connection is deleted after switchcc. Symptoms of the corruption are as follows:
Multiple software errors (code 384) logged at slave node when adding CVM-FTM or UVM-FTM connections.
Some of the FTM endpoints terminate on non-existent FTM ports.
Software errors are seen at the slave node of a UVM-FTM or CVM-FTM connection after a CC switch. Software errors of type 614, 961, 372, and 384 may be observed.
Conditions:
IGX nodes terminating voice connections on FTM cards.
The user executes addcon, attempting to add a range of CVM(UVM) channels to a single FTM channel, which is not a valid configuration. Command syntax is as follows:
A switchcc occurs at the FTM endpoint node after adding connections as described above.
Workaround:
The command syntax described above is invalid. Do not attempt connection addition in that manner.
If the system software release contains the fixes for both CSCdt37502 and CSCdt90019, executing a subsequent switchcc clears the corruption. Otherwise, Please see CSCdt37502 and CSCdt90019 for further information.
CSCdu27936
Symptom:
ILMI does not work on BXM virtual trunks. ILMI does not work on UXM virtual trunks, if the protocol in enabled on card.
Conditions:
If the first virtual trunk on the BXM/UXM interface is downed, The ILMI session is deactivated for all the virtual trunks on that interface.
Workaround:
(1) Hitless rebuild and switchcc reprgrams the ILMI lcn.
OR
(2) BXM/UXM card reset OR full rebuild will also clear the problem.
CSCdu28559
Symptom:
With 2-segment SIW-T connection from AXIS/FRSM to BXM Port on same BPX, return traffic is dropped to FRSM. Traffic is marked as non-compliant on BXM port and dropped. Connection is ABRFST type.
Condition:
If connection is added from BNI trunk to BXM Port, traffic is dropped. If connection is added from BXM Port to BNI trunk, traffic is not dropped.
Workaround:
Add connection from BXM to BNI only.
CSCdu35011
Symptom:
Cannot configure framing to OFF for UFM-C line.Software does not allow CRC to be disabled.
Conditions:
With cnfln command unable to disable CRC. Switch Software releases 9.2.35 and later.
Workaround:
None.
Further Problem Description:
The problem has come due to wrong logic used during the condition checking.
CSCdu35456
Symptom:
Low IDLE time on CWM gateway node. The dspprfhist command shows real-time usage increases in the NETW and PROT processes after CWM is enabled. The nwstats command show "Rx Buff Full" discards and very high Rx messages with function code 0x E1 (messages to CWM). The "dspsvmsg 2" will show a large number of robust trunk updates relative to other types of robust updates.
Conditions:
CWM enabled, robust notification enabled, trunk bandwidth changes in the network.
Workaround:
There are two recommended workarounds to this problem:1. Use cnfrobparm to change the "Robust State wakeup timer" and "Robust update timer" from their default value of 10 seconds to 60 seconds. This will extend the update interval for all robust updates to 60 seconds. Please make sure there are no CWM or VNS applications which depend on the 10 second update interval. 2. The document "CWM Design and Implementation, CWM Traffic Routing Options" by Robin Smith states that using in-band NMS traffic and "nwip_off" is "Not recommended in more than a 15 node network". This recommendation is consistent with the recommendation from several SWSW DEs that there should be 20 or less nodes per IP Relay subnet.
Further Problem Description:
The defect correction CSCdm12139 added robust trunk bandwidth updates for local trunks (trunks with an endpoint on the reporting node) whenever there is a bandwidth change due to connection routing or trunk configuration. A defect in CSCdm12139 caused robust trunk updates to be sent for the local trunks when remote trunk bandwidth changed. This defect is corrected in CSCdu35456.
CSCdu38022
Symptom:
IGX commands cnffrcls and cnfcon allow user to configure ECN threshold to be greater than VCQ depth.
Conditions:
Observed in IGX 9.2.35. Problem is not related to any traffic conditions. Problem occurs when incomplete set of parameters are specified in cnffrcls.
Workaround:
Specify complete set of parameters in cnffrcls.
CSCdu40248
Symptom:
After upgrading from 9.1.19 to 9.2.36, the dsptrkutl command gives inaccurate information for virtual trunks.
Workaround:
None.
Further Problem Description:
This problem is not related to upgrade. dsptrkutl for vtrk works for 9.1 and was broken in later release of 9.2.
CSCdu49568
Symptom:
The following commands cause an abort (1M3 swerr) when they are executed with an address of the format slot.start_port-end_port.
The abort occurs when the end_port is greater than 8.
Workaround:
Avoid executing the commands mentioned with the endport > 8.
CSCdu52374
Symptom:
dsplmistats command cant be used by users with privilege 1-6.
Conditions:
When log in as user, dsplmistats will not work for BPX in 9.2 and 9.3. They work fine for IGX though.
Workaround:
None.
Further Problem Description:
There is discrepency in release document and actual implementation for BPX 92 and 9.3 swsw release. Users at all levels should be able to use this display command. as documented.
CSCdu61462
Symptom:
Software error 2099,2057,894 logged on igx nodes
Condition:
The errors occur when TFTP trunk statistics are not enabled for UXM trunks, and a UXM trunk is subsequently activated.
The errors could potentially fill the error log, but are otherwise benign.
Workaround:
Include UXM trunk statistics when enabling TFTP trunk statistics.
CSCdu70098
Symptom:
A Software error 55 is logged when a BXM card that has a line interface on it is reset or downed.
Condition:
This problem occurs when:
1) you reset or down a BXM card that has a line interface
2) a CWM is attached
Workaround:
Configure the CWM so that it does not request line alarm status.
CSCdu77043
Symptom:
When adding lines to uxm IMA group, trunk goes into inverse mux failure and connections fail. They don't reroute as the other end of the connection says ok.
The trunk declares inverse mux failure even though there are sufficient "OK" links to sustain the trunk. The command dspphyslns verifies this. The inverse mux failure condition clears once the new physical line is activated on both ends of the trunk, and are clear of alarms.
Conditions:
Attempting to add new physical lines to existing IMA trunks, using UXM firmware that contains the fix for CSCdp65736.
Workaround:
Route traffic off of IMA trunk prior to adding the new physical line.
Further Problem Description:
The fix for CSCdp65736 introduced new IMA link fail messages which were not recognized by software. The software was modified to support these additional messages.
CSCdu82392
Symptom:
ChState and OE ChState are wrong in dcct display.
Conditions:
For VOICE connection, dcct shows ChState and OE ChState INACTIVE even when channels is active.
Workaround:
None.
Further Problem Description:
VC_VOICE_DB *)vc_ptr)->vc_chan_state is used for dcct display and was never updated except in loop mode and this is wrong.
CSCdv01127
Symptom:
dsptech command shows incorrect values for FDR parameter, shows as feeders attached even though there are no feeders connected to the node.
This problem is seen on three IGX nodes running with 9.2.4D image.
Condition:
Problem is observed only after ALM-A lines are upped.
Workaround:
None.
Problems Fixed in Release 9.2.38
Following is the list of fixed problems that were fixed in the 9.2.38 Switch Software release. Included with each is a brief discussion of the problem.
Bug ID
Description
CSCdj38754
E3 trail trace string is not transmitted by lines on BXM-E3 cards.
CSCdj75848
dsppwr shows all power supplies as "AC Failed."
CSCdk48180
The bcc card is WDT reset and suddenly logs swerr52.
CSCdk77478
SNMP walk for statistics causes excessive card polling
CSCdm87370
swerr 526 occurs when command cnfchfax issued on IGX.
CSCdm94164
swerr 3028 logged after 9.2.2U upgrade
CSCdp49466
swerr 529 logged on BPX as a result of tstcon fault isolation.
CSCdp57264
ILMI manages to work only on one subinterface
CSCdp66407
dspchstats may display truncated value for Avg. CPS if cells exceed 21474836.
CSCdr33931
When active APS line in Yellow, Trunk is OK, but CWM is not informed.
CSCdr42274
Dspload doesn't display all existing trunks
CSCdr84212
BXM connection to slot 32 on a remote IGX is reported as being terminated on slot 15
CSCds05558
dspportcnf displays terminal port information instead of Frame Relay data.
CSCds07518
SNMP authentication error format non standard -- HPOV cant recognize
CSCds41674
dsppwr displays incorrect information in 9.1.22 with IGX8 nodes
CSCds84776
APS 1:1 line experiences a SigDegrade BER alarm that never clears.
CSCds88886
Flash type information for BXM card is only accessible through the rsh command.
CSCds89384
swerr 56 logged while running jobs for dncd/upcd with y-redundancy on HDM cards.
CSCdt06177
User viewing actual bit rate per sec rather than the 100's of bits per second per the MIB.
CSCdt12153
cnffrcls and cnfcon allow ECN threshold to be greater than VCQ depth.
CSCdt12595
swerr 527 logged when winkstart enabled for CVM-E1, Model B, FW rev D cds
CSCdt19038
Trunk or line fails when APS line redundancy is deleted
CSCdt24951
TFTP stat files not created but the CLI command dspstatparms shows stats enabled.
CSCdt31369
When tstber terminates before it is finished, BCC crosspoint test may log swerr 55.
CSCdt34566
BPX command tstber always reports that the BCC crosspoint test is active.
CSCdt35616
The dspstatsinfo command does not tally ports that are in the LOOPED state.
CSCdt39500
swerr 526 (NEG_FILL_REQ) occurs when doing dsptrkerrs/dsplnerrs/clrtrkerrs
CSCdt42261
Errors are recorded on the now active line and not the standby line.
CSCdt48334
dsprevs considers 'Secondary Loaded' revision to select the 'Lowest revision running in network'
CSCdt58349
The IGX or BPX node logs a swerr 516 or aborts with an error code of 1m3 (1000003)
CSCdt64027
Physical trunks on a BPX are defaulting to trunks that do not route the clock.
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.38 Switch Software. The MIB is in standard ASN.1 format and is located in the ASCII text files agent.m, ilmi.m, ilmi_ctl.m, ilmiaddr.m, switch.m, swtraps.m, and errors.m which are included in the same directory as the Switch Software images. These files may be compiled with most standards-based MIB compilers.
Switch MIB changes of Release 9.2
The following Switch MIB changes were introduced since Release 9.2.00. The changes include Obsolete objects, Modified objects, and New objects:
switchIfTable
New objects:
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:
New Objects:
atmEndptOeOamStatus
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.40 Aug. 13 2001 16:19 GMT
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 9.4
Appendix A BXM Firmware MEK Release Notes
About the Firmware MEK
BXM Firmware version M.E.K. supports all the existing interfaces and models of BXM hardware. Following table outlines various levels of hardware revisions supported for BXM firmware version M.E.K.
Front Cards
Model Num
Description
FW model
HW Rev
FW Rev
BXM-155-4
4 port OC3 Line Module (Front Card)
E
B
MEKMEK
BXM-155-8
8 port OC3 Line Module (Front Card)
E
B
MEK
BXM-622
1 port OC12 Line Module (Front Card)
E
D
MEK
BXM-622-2
2 port OC12 Line Module (Front Card)
E
D
MEK
BXM-T3-8
8 port T3 Line Module (Front Card)
E
B
MEK
BXM-T3-12
12 port T3 Line Module (Front Card)
E
B
MEK
BXM-E3-8
8 port E3 Line Module (Front Card)
E
B
MEK
BXM-E3-12
12 port E3 Line Module (Front Card)
E
B
MEK
BXM-155-8DX
8 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-155-8D
8 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-155-4DX
4 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-155-4D
4 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-622-2DX
2 port OC12 Line Module (Front Card)
E
A0
MEK
BXM-622-2D
2 port OC12 Line Module (Front Card)
E
A0
MEK
BXM-622-DX
1 port OC12 Line Module (Front Card)
E
A0
MEK
BXM-T3-12EX
12 port T3 Line Module (Front Card)
E
A0
MEK
BXM-T3-12E
12 port T3 Line Module (Front Card)
E
A0
MEK
BXM-T3-8E
8 port T3 Line Module (Front Card)
E
A0
MEK
BXM-E3-12EX
12 port E3 Line Module (Front Card)
E
A0
MEK
BXM-E3-12E
12 port E3 Line Module (Front Card)
E
A0
MEK
BXM-E3-8E
8 port E3 Line Module (Front Card)
E
A0
MEK
Front Card for APS Compatibility
Model Num
Description
FW model
HW Rev
FW Rev
BXM-155-4
4 port OC3 Line Module (Front Card)
E
C
MEK
BXM-155-8
8 port OC3 Line Module (Front Card)
E
C
MEK
BXM-622
1 port OC12 Line Module (Front Card)
E
E
MEK
BXM-622-2
2 port OC12 Line Module (Front Card)
E
E
MEK
BXM-155-8DX
8 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-155-8D
8 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-155-4DX
4 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-155-4D
4 port OC3 Line Module (Front Card)
E
A0
MEK
BXM-622-2DX
2 port OC12 Line Module (Front Card)
E
A0
MEK
BXM-622-2D
2 port OC12 Line Module (Front Card)
E
A0
MEK
BXM-622-DX
1 port OC12 Line Module (Front Card)
E
A0
MEK
Back Cards
Model Num
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 MEK
There is no new feature in release MEK
New Features supported in BXM Firmware MEJ
For APS ITUT Annex A, SF and SD conditions are sent with high priorty. 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 12
.
Special Installation/Upgrade Requirements
BXM cards with M.C.B/M.D.A or a later firmware supports Y-redundancy. All the images with Y-redundancy can be smoothly migrated from one revision to other. E.g., to migrate the M.E.J version of firmware by using y-cable redundancy, upgrade a BXM card pair in y-red configuration, first upgrade the standby card with the MEK 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.K and burn the other card also with M.E.K 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 & Cautions
1. M.E.K 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
Upgrading from firmware revision MEA or higher.
Step 1 swsw should be upgraded to 9.2.30 or higher first,
Step 2 upgrade the firmware to MEK.
Upgrading from firmware revision lower than MEA
Step 1 firmware should be upgraded to MEC
Step 2 upgrade the swsw to 9.2.30 or higher revision
Step 3 upgrade the firmware to MEK. to avoid the card mismatch.
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:
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 behaviour since the configured MBS < the actual burst size.
Workaround: Increase the MBS and ICR using cnfcon.
Bugs Fixed in MEK
The following bugs are fixed between MEJ & MEK
CSCdt58185
Symptom:
The CESM-E8 dropped cells after 1/2 hrs. (When closely observed one can See there is a clock synchronisation problem).
Conditions:
When selecting a clock from the trunk or passing the sync along the trunk. BXM-OC3-D or DX (enhanced) card did not behave properly.
Workaround:
Use any other type of BXM card except for the BXM-OC3 enhanced.
.
Note : Although in this time frame there were some other bug fixes were checkedin, this release does not contain them. This release was specially made to fix the problem at a customer site. To make sure there are not further variables the other bug fixes were not included.
Bugs Fixed in MEJ
The following bugs are fixed between MEH & MEJ
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 stby line because of SD/SF condtion. dspapsln will still show OK for both the lines. This way, user will never get to know when this linehas comeout of SD/SF condtion.
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 supercedes 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
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-dir to uni-dir mode APS generates APS architecture mismatch error
Condition: When APS pair is configured from bi-dir mode to uni-dir mode the other side indicates APS architecture mismatch error, and then the other side is also configured from bi-dir mode to uni-dir 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)
Condition: .
Workaround: .
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 behaviour 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 SWERR 105 when running OAM test
Conditions: SWERR 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
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 stdby card affect APS line
Condition:Series of commands excuted in stdby 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 doesnot occur after dncd/upcd execution on Annex B 1+1 APS
Condition:When the dncd command is executed, SWSW 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 cuurent 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 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 stdby 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 intialized 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 itwas changed to uni-dir mode. Fixed by clearing all alarms when re-configuringthe 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 aftera 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 upone 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 th 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
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
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 releated 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 arround.
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 unncessarily 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: SWSW 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
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 seqeunce 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: chanel 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 th VT/port onwards.
Workaround:
CSCdm78335
Symptom: dspvsistatus rarely shows the VSI programming status as Done
Condition: primary and seconday 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 occurrs 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 reseting 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 onfiguration, ILMI/LMI protocol is enabled as CARD based.
Workaround:
CSCdm82688
Symptom: raffic Shaping problems with VT with and without raparound solution
Condition: arge 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 ards, 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: onfigure 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.
Otherewise cell loss may be experienced.
Table 1: BXM Transmitted Cell Rate
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.
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 release MEA
The following is the list of bugs fixed in release MEA:
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 release MDA
The following is the list of bugs fixed in release MDA:
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
BXMMEK.000 65536
BXMMEK.001 65536
BXMMEK.002 65536
BXMMEK.003 65536
BXMMEK.004 65536
BXMMEK.005 65536
BXMMEK.006 65536
BXMMEK.007 65536
BXMMEK.008 65536
BXMMEK.009 65536
BXMMEK.010 65536
BXMMEK.011 65536
BXMMEK.012 65536
BXMMEK.013 65536
BXMMEK.014 65536
BXMMEK.015 65536
BXMMEK.016 65536
BXMMEK.017 65536
BXMMEK.018 65536
BXMMEK.019 65536
BXMMEK.020 65536
BXMMEK.021 65536
BXMMEK.022 65536
BXMMEK.023 14
BXMMEK.024 2
BXMMEK.IMG 784
BXMMEK.img 784
~
Appendix B UXM ABL Firmware Release Notes
ABL 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
ABL firmware is compatible with Switch Software 9.1 and 9.2
Hardware
ABL 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
CSCds08193
Symptom:
Although the trunk operates fine, the dspportstats will show the old delay value even though the actual delay on the line is different. IMA trunk statistics will not show the correct delay value when the delay is toggled rapidly.
Condition:
Whenever the delay is changed rapidly on one of the links in an IMA group the dspportstats on that trunk is not updated. The errors seen are related to the SX/12 tester operation. No errors are seen when the SX/13 is used.
Workaround:
Change the delay with gaps of approximately a minute between changes.
Upgrade Instructions
Upgrade boot code to boot 07 before upgrading to ABL.
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 ABL. If this is attempted, burnfwrev will fail leaving firmware revision ABL in the flash.
Boot Code Requirements
Boot Code revision boot_07 is needed for the ABL 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.