Table Of Contents
1.0.12 Version Software Release Notes
Cisco WAN SES PNNI Software
About These Release Notes
About the 1.0.12 Release
Phased Release Strategy
Software Release 1.0.12
Service Expansion Shelf (SES) PNNI and SVC Controller
Clarifications
Special Installation/Upgrade Requirements
General
Upgrade Procedure
Upgrade the Backup Boot Image
Upgrade the SES PNNI Runtime Image
Procedure for Upgrading BXM Firmware and 9.3 Switch Software Releases
SES PNNI Controller Bring Up Procedure
Compatible Releases
Notes & Cautions
Limitations
Recommendations:
Required Workarounds
Compatibility Notes
Known Anomalies
Problems Fixed in Release 1.0.12
Problems Fixed in Release 1.0.11
Problems Fixed in Release 1.0.10
Problems Fixed in Release 1.0.01
Additional Deliverables
SNMP MIB:
Default Values
Obtaining Service and Support
Cisco Connection On-line
BXM Firmware MFL Release Notes
About the Firmware MFL
New Features supported in BXM Firmware MFL:
New Features supported in BXM Firmware MFK:
New Features supported in BXM Firmware MFJ:
New Features supported in BXM Firmware MFH:
New Features supported in BXM Firmware MFF
New Features supported in BXM Firmware MFE
New Features supported in BXM Firmware MFD
New Features supported in BXM Firmware MFC
New Features supported in BXM Firmware MFB
New Features supported in BXM Firmware MFA
New Features supported in BXM Firmware MEC
New Features supported in BXM Firmware MEB
New Features supported in BXM Firmware MEA
New Features supported in BXM Firmware MDA
Clarifications:
Special Installation/Upgrade Requirements
Features obsoleted
Notes & Cautions
Known Anomalies
Logic to calculate actual cell transmission rate in a BXM card is as follows (CSCdm94372):
Firmware Filenames and Sizes
1.0.12 Version Software Release Notes
Cisco WAN SES PNNI 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 1.0.12 Release
The 1.0 software release supports the Cisco WAN switching products: BPX 8600 series with SES controller.
Phased Release Strategy
This is the fifth release of software for the SES PNNI controller. New features will be added in subsequent releases.
Software Release 1.0.12
Service Expansion Shelf (SES) PNNI and SVC Controller
SES PNNI Release 1.0.12 is compatible with the BPX 8600 series software Release 9.3.11 and with the later 9.3 releases. The SES PNNI Controller is connected to the BPX 8600 series switch via a BXM-155 (or T3/E3) port configured as a trunk. Redundant SES systems contain two controller cards which offer APS protection on the ports connecting to the BPX.
Feature Overview
The SES is a VSI (Virtual Switch Interface) controller which provides a BPX 8600 series wide-area switch the capability to create Switched Virtual Circuits (SVCs) and Soft Permanent Virtual Circuits (SPVCs) using the UNI and PNNI protocols. One SES is required for each BPX 8600 series node that will be originating, transporting, or terminating SVC/SPVC connections. The SES is offered in redundant or non-redundant configurations.
Detailed Feature Information
As networks grow in size, PNNI becomes a critical element in the ability to scale a network. PNNI provides a standard, interoperable, and scalable method to grow PVC (SPVC) networks to large sizes. In addition, applications such as voice, video, and LAN require WAN switches to provide dynamic connection capabilities in the form of SVCs. The SES provides the BPX 8600 series switch with a centralized controller for establishing SPVCs and SVCs in both BPX 8600 series networks and in mixed vendor environments. The BPX 8600 series switch in combination with the SES Controller
(Release 1.0) supports the following features:
•
ATM UNI 3.0/3.1 (CBR, VBR, UBR)
•Point to Point SVCs, SPVCs, and SPVPs
•PNNI 1.0 Single Peer Group
•IISP with PNNI Inter-networking
•E.164 & AESA/NSAP (DCC, ICD, E.164) addressing
•Address filtering (source and destination)
•ILMI 4.0
•SPVC and SPVP endpoint provisioning (incl. ABR)
•OC-3/STM-1, T3/E3 interfaces
•OC-12/STM-4 interfaces
•Intelligent CAC
•Call Processor Redundancy (calls stable across switchover)
•APS on controller uplinks to BPX
•Connection and Path Trace facilities
•Integrated management via CWM, SNMP MIBs
•50K connections (SVC+SVP+SPVC+SPVP) per node
•100K max endpoints per node (if all 50K conns are DACS)
•99 UNI/PNNI SVC ports per node
•100 calls per second
•Dynamic partitioning and soft partitioning
•SPVC support on feeder trunks
•Dedicated Q-bin for control signalling
•Graceful upgrade from SES PNNI 1.0.10 and 1.0.11 to l.0.12
Clarifications
N/A
Special Installation/Upgrade Requirements
General
This section covers the procedure for upgrading the Backup Boot and Runtime for the following hardware:
1. Redundant Controller Card
2. Single Controller Card (the PXM)
Upgrade Procedure
Upgrade the Backup Boot Image
This section provides instructions for upgrading the Backup Boot images from 1.0.10 to 1.0.11. Boot upgrade can be graceful or non-graceful, depending on the type of card to be upgraded and the configuration of the node.
Note If the new Runtime Image requires a new boot, upgrade the Boot image before the Runtime Image.
Backup Boot Upgrade Procedure for Redundant Systems
Note The procedure for upgrading the boot on active controller cards is the same procedure for ugrading the boot on redundant controller cards. The difference is that you need to do this procedure on the standby card and not on the active card, thus keeping the node in service while doing the upgrades. Before you upgrade, FTP new Backup Boot firmware, pxm1_001.000.011.001_bt.fw, to disk (should be the same as PXM FW procedure.)
To upgrade the boot on active controller cards on redundant systems, follow these steps:
Step 1 Use the following procedure to transfer the Backup Boot image to the card disk.
a. Use the dspipif command at the active controller card to find the Node's IP address.
The field internet address is the Node IP address.
b. Enter ftp <Node IP address>.
c. Enter the username cisco.
d. Enter your password.
Note Your password is supplied with the image.
e. Enter cd C:/FW.
f. Enter bin (for a binary transfer).
g. Enter put <PXM Backup Boot image name>.
h. Enter bye.
Step 2 Enter the dspcds command to determine standby card slot.
Step 3 Use the following procedure to verify that the Boot IP for both the active and standby card is unique:
a. Use the bootchange command to find the Boot IP address for the active and standby card.
b. Press enter until you see host inet on ethernet (e). This is the Boot IP address for both active and standby PXM.
c. To change this address to make it unique, type a new address at this prompt.
Step 4 Use the cc command to change to the standby card.
Step 5 From shellConn on the standby card, follow this procedure:
a. Type sh to go to the shellConn.
b. issue sysBackupBoot command.
c. Press Return after you see disk sync message to get back to active PXM.
Step 6 Exit or open a new telnet window and telnet into standby IP host inet address from Step 4. An alternate way to get to the standby card is via the console port on the standby. Use the following procedure to reset the card:
a. Verify that the card is at the pxm1bkup> prompt. If it is not, reissue the sysBackupBoot shellConn command on the standby card.
b. Enter the sysPxmRemove command.
After you issue the sysBackupBoot command, it takes about one minute for the active PXM to reset the card. If the active PXM resets the standby PXM, wait until it comes to the standby state (approximately four or five minutes), then telnet into the standby and repeat Step 5. After the sysPxmRemove command is issued the active PXM can not reset the standby.
Step 7 Issue the cd C:/FW" command from pxm1bkup> prompt to get the FW directory.
Step 8 Enter the ls command to verify that the boot firmware file is there.
Step 9 Enter the sysFlashBootBurn boot firmware file name command
pxm1bkup>sysFlashBootBurn"pxm1_001.000.011.001_bt.fw"
a. Enter Y for Yes.
b. When the pxm1bkup> prompt returns, issue the reboot command.
Flash Download completed...
Step 10 Login to active PXM.
a. Enter the dspcds command to ensure the standby is in standby state.
b. Enter the dspcd <standby slot #> command to verify the firmware was loaded successfully.
Step 11 Load the Backup Boot onto the active PXM.
a. Enter the switchcc command to change cards.
b. Login to the SES controller.
c. Perform Step 5 through Step 10 on the new standby PXM.
Upgrade the Backup Boot on Non-Redundant Systems
The upgrade of the boot on a non-redundant controller card is non-graceful. This means the traffic gets disrupted on the card during this operation. The upgrade can only take place when the card is in the BOOT stage. Because there is only one controller card, there will be a node outage as well.
For non-redundant systems, follow these steps to upgrade the Backup Boot:
Step 1 Transfer Backup Boot image to the card disk using ftp as follows:
a. Use the dspipif command at the active controller card to find Node's IP address.
The field internet address is the Node IP address
b. Enter the ftp <Node IP address> command.
c. Enter the username cisco.
d. Enter your Password
Note Your password is supplied with the image.
e. Enter cd C:/FW.
f. Enter bin (for binary transfer).
g. Enter put <PXM Backup Boot image name>.
h. Enter bye.
Step 2 Login to the SES.
Step 3 At the shell, execute the sysBackupBoot command to put the controller card into the PXM Backup prompt stage.
The PXM card resets.
Step 4 Login to the PXM.
Step 5 Enter the cd FW command at the pxm1bkup> prompt to get the FW directory.
Step 6 Enter ls command to verify the boot firmware file is there
Step 7 Enter sysFlashBootBurn boot firmware file name command.
pxm1bkup>sysFlashBootBurn"pxm1_001.000.011.001_bt.fw"
a. Enter Y for Yes
b. At the pxm1bkup> prompt, enter the reboot command.
c. The node resets.
d. Login to the node.
Step 8 Login to active PXM
Step 9 Use the dspcd <active card> command to determine if the upgrade was successful.
Upgrade the SES PNNI Runtime Image
This section provides instructions for upgrading the Runtime Images from 1.0.10/1.0.11 to 1.0.12.
The upgrade of the Runtime on the redundant controller card is graceful. This means the traffic will not be disrupted. The new Runtime Image for 1.0.12 is pxm1_001.000.012.001_ses.fw.
Upgrade the Runtime Image on Redundant Systems
Follow these steps to upgrade the Runtime Image on redundant systems:
Step 1 Use FTP to transfer the Runtime Image to the card disk.
a. Use dspipif at the active controller card to find Node's IP address.
The internet address field is the Node IP address.
b. Enter ftp <Node IP address>.
c. Enter the username cisco.
d. Enter your password.
Note Your password is supplied with the image.
e. Enter cd C:/FW.
f. Enter bin (for binary transfer).
g. Enter put <PXM Runtime Image name>.
h. Enter bye.
Step 2 Enter the dspcds command to determine the standby slot.
Step 3 Enter the loadrev <standby slot> <image version> command to set the new version of run-time Image on controller card, as in the following example:
ses1.1.PXM.a>loadrev 2 1.0(12.1)
The standby card is reset and will come up in the new revision.
Step 4 When the standby card is in the STANDBY state, execute the runrev <standby slot> <image version> command to run the new version of Runtime Image on the controller card, as in the following example:
ses1.1.PXM.a>runrev 2 1.0(12.1)
The active card resets and the standby takes over as active. Both cards are running the new revision.
Step 5 When the standby card is in STANDBY again, you can use the abortrev <standby slot> <image version> command to abort this upgrade if needed, as in the following example:
ses1.1.PXM.a>abortrev 1 1.0(12.1)
Step 6 Execute the commitrev <standby slot> <image version> command to commit the new version of Runtime Image of controller card, as in the following example:
ses1.1.PXM.a>commitrev 2 1.0(12.1)
Step 7 The the dspcd command to verify successful upgrade.
Runtime Upgrade Procedure for Non-Redundant Systems
The upgrade of the Runtime on the a non-redundant controller card is non-graceful. That means the traffic gets disrupted on the card during this operation.
For non-redundant systems, follow these steps.
Step 1 Use FTP to transfer the Runtime Image to the card disk as follows:
a. Use dspipif at the active controller card to find Node's IP address.
The internet address field is the Node IP address.
b. Enter ftp <Node IP address>.
c. Enter the username cisco.
d. Enter your password.
Note Your password is supplied with the image.
e. Enter cd C:/FW.
f. Enter bin (for binary transfer).
g. Enter put <PXM Runtime Image name>.
h. Enter bye.
Step 2 Set the new version of Runtime Image on controller card as in the following procedure:
a. Enter the loadrev <slot> <image version> command as in the following example:
ses1.1.PXM.a>loadrev 1 1.0(12.1)
Note No cards will reset.
b. Reply Yes to the proceed question.
c. Enter the dspcd command in the following example:
The secondary revision on the PXM is set to new image version.
Step 3 Enter runrev to run the new version of Runtime Image on controller card.
a. runrev <slot> <image version>
b. ses1.1.PXM.a>runrev 1 1.0(12.1)
c. Card will reset and will run the new revision when it returns.
d. dspcd
e. Example: ses1.1.PXM.a>dspcd 1
Step 4 At this point you can still abort this upgrade if needed. Use abortrev if needed.
f. ses1.1.PXM.a>abortrev 1 1.0(12.1)
Step 5 Execute commitrev to commit the new version of Runtime Image of controller card
a. commitrev <slot> <image version>
b. dspcd 1
Procedure for Upgrading BXM Firmware and 9.3 Switch Software Releases
Perform the following steps:
Step 1 Upgrade BXM firmware to MFL. See Release Notes for BXM MFL firmware in Appendix A.
Step 2 Upgrade BCC switch software to Release 9.3.11
Please use SES PNNI 1.0.11 Backup boot, pxm1_001.000.011.001_bt.fw.
Please refer to 9.3.11 Release Notes for BCC switch software upgrades
SES PNNI Controller Bring Up Procedure
For detailed procedure changes, please see the on-line SES PNNI Controller Software Configuration Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/ses/pnnicnf/index.htm
Compatible Releases
SES PNNI version 1.0.12 works and has been tested with the following releases:
•BPX SWSW version 9.3.11 or later (see S/W Compatibility Notes Matrix, first and second bullets)
•BXM Firmware version MFL or later (see S/W Compatibility Notes Matrix, first and second bullets)
•Cisco View version 5.0
•CWM version 10.4
•BCC-3-64
•BPX-BCC-4V or BPX-BCC-4V/B
•MGX 8850 R1 1.1.32
•MGX 8220 5.0.15
For further information on the BXM card, please see Appendix A.
Note The SES PNNI 1.0.12 is compatible with MFL BXM (See Table 1 for more information.)
Notes & Cautions
Limitations
Release 1.0.12 of the SES has the following system limitations:
•The number of connections on a card is always less then the max con value used in the addpart command. This is due to the fact that each card needs 1 LCN for control VC. If it is PNNI, there is another VC for RCC. Therefore, if the max con value is set to 9000 connections, only 8999 or 8998 connections can be added.
•The dspcons command does not support ranges for vpi/vci. If the users enters dspcons -vpi 2, this will display all SPVCs with vpi >= 2 not just the SPVCs with vpi = 2.
•The Route Optimization algorithm is node-by-node and based on connection mastership; it is not distributed across the node. For example, if Node A is connected to Node C via Node B, Node A only knows about the connections from A to B and not about the connections from B to C. This limitation will not allow Node A to use route optimization for connections from B to C.
•There is no check for preventing multiple masters of SPVC conns from pointing to the same slave. When provisioning a second connection to a slave UPI/UCI that is already used, there will be no warning at the CLI that the connection has failed.
• In a large network, it can take up to 30 seconds (or more) to be able to accept new calls after a switchover. This is because PNNI relearns the topology on a switchover. For the existing connections, the control plane and the data plane doesn't get affected on a switchover.
•Node names are not required for each node. A node name can be entered and is distributed but there is no check for uniqueness of it within the network. Multiple nodes with the same name doesn't cause any inconsistencies in PNNI routing.
•BXM interface (OC and T3) traffic policing only works if cell rate is higher than 50 cells per second.
•When master endpoint is deleted, slave endpoint is also deleted.
Recommendations:
•Provisioning of SPVC connections is performed using a two-ended provisioning model, similar to the way connections are provisioned using AR. This provisioning model enables more robust management (including fault conditions) of both connection endpoints than does a model which only provisions the master endpoint.
In order to establish a DAX or a routed SPVC, users need to first provision the slave endpoint then provision the master endpoint to set up a connection. The traffic parameters and QoS parameters on both master and slave endpoints must match in order to have a SPVC established.
Interoperability with other equipment using a single-ended provisioning model is supported, but the provisioning must be done carefully. The operator must ensure that the slave provisioning matches exactly with the parameters signaled from the master endpoint.
•For each SPVC add, delete, or modification, SES will generate a trap to CWM so that CWM can sync up connection management database with SES/BPX switch in real time. The trap information exchange between CWM and SES is handled by inter-system communication protocol. The trap-handling rate normally is much slower than the script driven SPVC setup or delete rate. When a user uses a script to do burst SPVC addition or deletion, due to limited trap queue size, the trap queue may overflow and cause trap loss. If burst SPVC add/delete size is more than 1K connections, it is recommended that user to pace his setup/delete rate to be 1 connection per sec to avoid trap loss.
•The minSvccVci value for the partition is defaulted to 35 and the vci 33 and 34 are marked for future control plane use.
•In the case of obtaining optimized routes while performing PNNI on demand route lookup it is recommended to change the routing policy to best fit option.
Required Workarounds
N/A
Compatibility Notes
Table 1-1 SES Controller - Hardware Compatibility Matrix
Board Pair
|
SES PNNI Version
|
Latest Boot Code Version
|
Minimum
Boot Code
Version
|
BXM Firmware
|
SWSW
|
CWM
|
PXM1
|
1.0.00
|
pxm1_001.000.000.000_bt.fw
|
1.0.00
|
MFC
|
9.2.33
|
10.2
|
PXM1
|
1.0.01
|
pxm1_001.000.001.000_bt.fw
|
1.0.01
|
MFD
|
9.3.05
|
10.2
|
PXM1
|
1.0.10
|
pxm1_001.000.001.000_bt.fw
|
1.0.01
|
MFH
|
9.3.10
|
10.3
|
PXM1
|
1.0.11
|
pxm1_001.000.011.001_bt.fw
|
1.0.11
|
MFJ
|
9.3.10
|
10.4
|
PXM1
|
1.0.12
|
pxm1_001.000.011.001_bt.fw
|
1.0.11
|
MFL
|
9.3.11
|
10.4
|
Table 1-2 SES Controller - Hardware Compatibility Matrix
OC3 Combinations (Shipping/Customer Configurations)
|
No.
|
Description
|
Front Card (PXM)
|
PXM UI Back Card
|
PXM Uplink Back Card
|
1
|
MMF OC3
|
SES-PXM-CNTL-4-155
(with 4 port OC3)
P/N 800-06454-01 or later
|
PXM-UIA
Rev: B3 or later
|
MMF-4-155
Rev: F0 or later
|
2
|
SMF-OC3, Intermediate Range
|
SES-PXM-CNTL-4-155
(with 4 port OC3)
P/N 800-06454-01 or later
|
PXM-UIA
Rev: B3 or later
|
SMFIR-4-155
Rev:A0 or later
SMFIR-4-155/B
Rev:F0 or later
|
T3/E3 Combinations (Shipping/Customer Configurations)
|
No.
|
Description
|
Front Card (PXM)
|
PXM UI Back Card
|
PXM Uplink Back Card
|
1
|
T3
|
SES-PXM-CNTL-2T3E3
(with 2 port T3E3)
P/N 800-06699-01
|
PXM-UIA
Rev: B3 or later
|
BNC-2T3
Rev: B2 or later
|
2
|
E3
|
SES-PXM-CNTL-2T3E3
(with 2 port T3E3)
P/N 800-06699-01
|
PXM-UIA
Rev: B3 or later
|
BNC-2E3
Rev: B2 or later
|
Table 1-3 Feeder SW tested with SES SPVCs - Hardware Compatibility Matrix
Feeder
|
MGX 8850 R1
|
MGX 8220
|
Release
|
1.1.32
|
5.0.15
|
HW Cards
|
PXM-1
PXM1-2T3E3
PXM1-4OC3
PXM1-OC12
SRM-3T3
CESM-8E1
CESM-8T1
AUSMB-8E1
AUSMB-8T1
CESM-T3
CESM-E3
FRSM-8E1
FRSM-8T1
FRSM-HS2
FRSM-2CT3
FRSM-2T3
FRSM-2E3
FRSM-HS1/B
VISM-8T1
VISM-8E1
RPM
RPM-PR
|
FRSM-4T1/4E1/4T1-C/4E1-C
SRM-T1E1
SRM-3T3
CESM-4T1/4E1
CESM-8T1/8E1
AUSM-4T1/4E1
FRSM-8T1/8E1
AUSM-8T1/8E1
AUSMB-8T1/8E1
AUSMB-8T1/8E1
FRSM-HS1
FRSM-HS1/B
FRSM-HS2
IMATM-T3T1/E3E1
IMATMB-T1/E1
|
Known Anomalies
The following is the list of known anomalies in this SES PNNI 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.
The following bugs are applicable on to the PXM software:
Table 1-4 PXM Software Bugs
Bug ID
|
Description
|
S1 BUGS
|
None
|
S2 BUGS
|
|
CSCds86171
|
Title:
IF status on SES controller shows port stuck in ILMI query state.
Symptoms:
Ports stay in ilmi query and don't go to operational status.
Conditions:
In cases of congestion or burning new firmware if ilmi responses are lost from the card for all retries during resync.
Workaround:
Down and up port from SES controller should solve the problem.
|
CSCdt04834
|
Title:
PXM 1slot is corrupted to 0 if nodename is configured through SNMP
Symptoms:
Some or all cards in the node failed to come up. The log shows the following errors: 01-00005 12/21/2000-16:38:42 DB2C-5-DBCLNT_CTCAPI dbClnt 0x8017063c Error 0 on call to ctcCntrL SlotNumGet
01-00006 12/21/2000-16:38:43 TRAP-5-TRAPCL_INVSLOT trapCITask 0x802831b4 Invalid Controller logical slot in "Trap Client Resolve Server Name"
Condition:
Configuring the Node Name through the SNMP interface causes the PXM logical slot number to be changed to zero.
Workaround:
Do not use SNMP (eg. CWM) to configure a node's name. Use the CLI cnfname command instead.
|
CSCdt34888
|
Title:
MBSM: SPVC conn stays in FAIL for rt-VBR & nrt-VBR when EFD is enable.
Symptoms:
VBR3 and UBR2 routed SPVC connection remain in FAIL state. Dspcon on that connection shows "Unsupported combination of traffic parameters" as the Last Fail Cause.
Conditions:
If frame discard is requested on the VBR3 or UBR2 SPVC connections (via addcon/cnfcon), then these connections fail to route.
Workaround:
Do not program frame discard on pep (addcon/cnfcon with frame discard disable)
|
CSCdt37734
|
Title:
Failed to configure SPVC Prefix
Symptoms:
Fail to configure spvc prefix
Conditions:
Spvc prefix can only be configured if there is no connection in the node, unfortunately, there are six dangling legs in CM for three dax connections.
Workaround:
None
Status:
Unreproducible
|
S3 BUGS
|
|
CSCds10778
|
Title:
SLT: Stdby PXM reset by redman during massive reroute/provisioning.
Symptoms:
Standby PXM gets reset by Active PXM.
Conditions:
Rerouting is going on massive scale, we have spvc journaling also at the same time and user executes provisioning commands which requires disk writes and standby journaling updates. At that time sometimes standby is reset by active pnRedman.
Workaround:
When massive rerouting is going on avoid too many provisioning commands on the system.
|
CSCds15154
|
Title:
Port in building VC after SIG VCI and PNNI VCI are changed.
Symptoms:
Port goes into Building VC
Conditions:
When configuring the signaling parameters for a given port. If sigvci and rccyci have been changed and then brought back to their default values of 5 and 18 respectively, the port may go to Building VC occasionally.
Workaround:
Down the port and up the port should bring the port to UP again.
|
CSCds87891
|
Title:
SES: addcon screen help report the range of vci 32 to 65535 and vpi.
Symptoms:
addcon screen help is not correct for the VCI range
Conditions:
when addcon is issued
Workaround:
None
|
CSCdt12510
|
Title:
Need more intuitive error message when add SPVC with existing vpi/vci
Symptoms:
Intuitive error message when connection is added on an existing endpoint
Conditions:
When connection is added on an existing end point
Workaround:
Don't try to add a connection on an existing end point.
|
CSCdr40795
|
Title:
No command is available to clear spvc stats
Symptoms:
No command available for clearing connection statistics
Conditions:
Clearing connection statistics
Workaround:
None
|
CSCds62761
|
Title:
SPVC allow setup connection between AINI and PNNI interface fixed
Symptoms:
SPVC are allowed to be added on failed PNNI interface
Conditions:
addcon on failed PNNI interface
Workaround:
Don't add SPVC on failed PNNI interface
|
CSCds55940
|
Title:
Cannot remove core redundancy alarm.
Symptoms:
Card alarm is generated when core redundancy is lost.
Conditions:
Even when core redundancy is disabled using cnfndparms
Workaround:
None
|
CSCdt15090
|
Title:
Orion fails to maintain non-revertive switch on BPX.
Symptoms:
SES APS line reverts when it is configured for non-revertive mode.
Conditions:
APS line is set for bi-direction and non-revertive mode.
Workaround:
No work around.
|
CSCdp43597
|
Title:
Need proper trap definition for upper threshold line voltage alarm condition.
Symptoms:
Confusing trap sent when voltage is above threshold.
Conditions:
When DC voltage is above threshold an event is logged that specifies an "Above threshold" alarm. However, a "Below threshold" trap is generated.
Workaround:
None
|
CSCds69318
|
Title:
Need to suppress alarms in dspcd output on standby PXM
Symptoms:
dspcds command output shows alarms.
Conditions:
dspcds command executed on standby PXM card.
Workaround:
Ignore alarms displayed on the standby PXM card.
|
CSCds88721
|
Title:
ENVMON: No alarm reporting when system boot w/o any fan trays.
Symptoms:
When system rebooted without any fan trays, no alarms or traps generated.
Conditions:
Both fan trays are unable or physically removed.
Workaround:
None.
|
Problems Fixed in Release 1.0.12
Table 1-5 Problems Fixed in 1.0.12
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdt11833
|
Title:
SLT: clrcnf cause disk sync problem, standby failed after loadrev.
Symptoms:
Standby controller card goes to failed state.
Conditions:
Upon performing loadrev after a clrcnf.
Workaround:
Do a setrev on slot 14(for Orion) or slot 32(for POPEYE2) with version number 0.0
|
CSCds65556
|
Title:
Task pnCcb: Mem fragmentation due to port list.
Symptoms:
The controller was out of memory and restarted.
Conditions:
Seems a rare scenario caused probably due to links repeatedly going up and down resulting in deroute plus reroute of 50000 spvcs.
Workaround:
None.
|
CSCds73043
|
Title:
AXSM: ilmiSync Task suspension - caused by sync RAM IOV search excep
Symptoms:
Task suspends during its sync process.
Conditions:
Sending a single buffer to peer under ipcMblk resource contrain might cause an exception since syncRam tries to access the memory which is taken by other task already.
Workaround:
None.
|
S2 BUGS
|
|
CSCds82333
|
Title:
Connections in Fail state on slave side & ok state from Master side.
Symptoms:
Call is released on one node but does not get released on the peer.
Conditions:
Caused when lot of status enquiry happens when the nodes are highly congested. This happens very rarely.
Workaround:
Clearing the connection manually.
|
CSCdt20186
|
Title: MGX8850 should check Action Indication even it is a illegal length.
Symptoms: Connection cannot be set up.
Conditions: When a Generic Identifier Transport IE of an invalid length (more than 33 bytes including the IE header) is received, the whole message is discarded. Therefore, connection cannot be set up.
Workaround: Avoid sending Generic Identifier Transport IE of invalid length.
|
CSCdt41939
|
Title:
Connections show up on GUI as incomplete. Updates on conns don't work.
Symptoms:
Connections as displayed by CWM are incomplete. Modifications on the connections don't show up on the CWM GUI. Connections exist on the switch and don't show up in CWM.
Conditions:
This can happen when there is a high volume of traps, for example when a script is being run to delete a large volume of connections.
Workaround:
A configuration upload could be done to correctly synch the CWM with the switch after the script has finished.
Another work around is, if a user needs to add/delete more than 1000 connections at one time, he/she should pace the SPVC connections add/delete rate to avoid trap overflow. The recommended rate is 1 conns/sec.
Further Problem Description: When there is a high volume of traps, especially on an SES node, traps can be silently discarded by the switch after a burst of about 1000 traps has been generated on a given card.
|
CSCdr50289
|
Title:
Buffer corruption when multicasting xbar info.
Symptoms:
XBAR plane available Multicast event buffer got corrupted.
Condition:
When XBAR plane available multicast is generated, which happens after standby inserted.
Workaround:
None.
|
CSCds63497
|
Title:
Got Tlb Load Exception; Task: FtpdServ1. This happened on 50k cons node
Symptoms:
TLB exception on one of the ftp tasks.
Conditions:
Noticed only once - on a heavy loaded system. On the PXM card only.
Workaround:
If redundancy is enabled, conduct a switchover. On a standalone card, you would need to reset the system. When the exception happens, one of the 4 ftp tasks on the pxm will no longer be available to process requests.
|
CSCds89112
|
Title:
Upg: 1 SPVC connection failed to come up after power cycle.
Symptoms:
SPVC connection failed to come up after power cycle.
Condition:
Slave connection has not been released while master still try to reestablish the call.
Workaround:
Do PXM switchover using switchcc
|
CSCds07908
|
Title:
Route agent choose virtual trunks for VP conns.
Symptoms:
lower E3 bank spvp's in error after power cycle
Conditions:
shelf power cycle off/on
Workaround:
None
|
S3 BUGS
|
|
CSCds68731
|
Title:
IpConn task dies when Trunk Back Card is absent in Orion.
Symptoms:
PXM card never goes active or standby. After a period of time, card is reset.
Condition:
PXM1 backcard is removed/not present. This can cause access to the disk to be slower than usual. OPCONN task expects disk access to be complete in 1 minute. If not, IPCONN task refuses to go active.
Workaround:
None if PXM1 backcard is required to be removed.
|
CSCds70657
|
Title:
CES: Customer request that last fail cause use cell rate not available.
Symptoms:
Last Fail Cause need to be more intuitive.
Condition:
SPVC was provisioned on an interface where correct SCT was not configured for the interface.
Workaround:
None.
Close Comments: The DDTS is closed with the following reasons:
We cannot return a cause value other than the defined values in the UNI/PNNI spec. in the RELEASE/RELEASE COMPLETE message. There are issues related to UNI/PNNI conformance testing which prevents from sending proprietary/new cause values.
|
Problems Fixed in Release 1.0.11
Table 1-6 Problems Fixed in 1.0.11
Bug ID
|
Description
|
S1 BUGS
|
|
CSCds64807
|
Title:
SPVC cons shouldn't be allowed more than the configured Icns.
Symptoms:
After you add the connections, then you change the number of LCNs in your partition, if the number of the connections is more than LCN number, some of the connections would be failed. If you reset the Service module, the connections failed routing may be no deterministic. That is, before routed connection may be failed while some failed connections may be successfully routed.
Conditions:
Workaround:
Do not change the LCN number below the provisioned SPVCs.
|
CSCds69959
|
Title:
SES-FDR:pnCcb crash caused by dspconstat command
Symptoms:
System reload due to pnCccb crash
Conditions:
dspconstats
Workaround:
None
|
CSCds84187
|
Title:
SLT: standby PXM keep resetting after loadrev from 1.0.10 to 1.0.11
Symptoms:
After loadrev standby PXM keeps resetting
Conditions:
1. Forced download was ON or Standby PXM did not have correct image file
2. Running an old boot code that does not have a fix for CSCds85557
Workaround:
abortrev to bring up standby to old release.
Make sure forced download is OFF _ see CSCds72007
Use boot with fix for CSCds85557.
|
S2 BUGS
|
|
CSCdr64839
|
Title:
Back card insertion not reported to shm if back card put in.
Symptoms:
Remove the TBC from the standby PXM's slot, then remove the active PXM, forcing a switchover. Now, reinsert the TBC in the active (previously the standby) PXM's slot.
Condition:
The TBC reinsertion event was not being reported to the SHM, causing incorrect information to be displayed by commands such as dspcds.
Workaround:
None.
|
CSCdr91876
|
Title:
SLT: PXM stuck in INIT state after power cycling SES shelf.
Symptoms:
After a power cycle to the shelf.
Conditions:
Standby PXM1 card is stuck in Init state
Workaround:
Reset the standby PXM1 card
|
CSCds01154
|
Title:
SLT: Some SPVC connections at outage state after switchcc
Symptoms:
Sometimes some connections are in discontinuity state
Conditions:
Multiple PXM switchovers
Workaround:
Wait for resync to be over
|
CSCds04661
|
Title:
SPVCs have AIS after resetsys at one end point only.
Symptoms:
Conns are in AIS
Conditions:
a. resetcd (PXM or BXM)
b. dnpnport/uppnport (PNNI trunk)
c. rebooting via nodes
Workaround:
on PXM shellconn, issue following command:
vsim_debug_reset_slave_sesId (slaveIpc), where slaveIpc is the any valid BXM slot no - 1
|
CSCds07843
|
Title:
SLT: APS switchover does not display any message after SWO fail.
Symptoms:
This problem manifests itself only when a switchapsln CLI command is executed by the user on the active front-card.
When the user issues a switchapsln command to either cause a (a) manual, or (b) forced APS line switchover, the command returns without a feedback message to the user whether the switch was completed successfully, or if it failed.
Conditions:
At present, the APS module doesn't care about the actual result of the APS switchapsln command. It assumes that the user will issue a subsequent dspapsln to verify the effect of the APS switchover command previously issued.
Workaround:
In the absence of the output message from the switchapsln CLI command, the user should issue a dspapsln CLI command to verify that the switchover command had the desired effect.
|
CSCds13879
|
Title:
SLT: Port in the building state after overnight dn & up port testing.
Symptoms:
The port ends up in Building Vc state.
Conditions:
The port is brought up and down multiple times.
Workaround:
Bring the port down and up once.
|
CSCds14865
|
Title:
SLT: 50k SPVC connections sometime take 2,3 hours reroute
Symptoms:
Sometimes it takes approximately 2 hours to re-route 50K spvc connections.
Conditions:
The occurrence is very rare. It happens sometimes when switchover is done multiple times
Workaround:
None.
|
CSCds17876
|
Title: System allow add SPVC call with VCI less than 35.
Symptoms:
The node allows SPVCs with VCI less than 32 to be added.
Conditions:
With the port's minsvccvci set to 32, attempts to add SPVCs with VCI less than 32 are not rejected.
Workaround:
In order to properly use SPVCs with VCI values less than 35 (default), perform the command before adding SPVCs with low VCI values.
cnfpnportrange <portid> -minsvccvci <desired minimal VCI value>
Since the VCI range below 32 is not recommended by ATM Forum and more control VCs are reserved below VCI=35, a warning message listed below will be displayed when the minSvccVci is changed to be below 35:
Note MinSvccVci HAS BEEN ASSIGNED A VALUE LESS THAN 35.
|
CSCds18228
|
Title:
CLI needed to configure reroute retry
Symptoms:
If a connection fails to route in its first attempt, the subsequent reroute will be only after 5 seconds. This constant cannot be modified by cli.
Conditions:
A single connection, upon a failure to reroute the first time may take 5-6 seconds to reroute.
WorkAround:
None
|
CSCds18328
|
Title:
Default of minSvccVci should be 35 instead of 32.
Symptoms:
The switch has changed the default value of SvccVci from 32 to 35. This has not been reflected in the MIB variable cwspMinSvccVci in CISCO-WAN-SVC-MIB.my.
Conditions:
From the MIB, a user would assume the SvccVci value is 32, yet when the user tries to configure SVC or SPVC, the switch only allow configuration for 35 and above.
Workaround:
The user can configure SVC or SPVC with VCI only from 35 or above if the user decides to use the default value. The user can also do an snmp GET of this variable for the interface.
|
CSCds25863
|
Title:
delpnport needs to be blocked if there is SPVC on it.
Symptoms:
delpnport deletes all SPVCs on it
Conditions:
When delpnport is issued on PXM
Workaround:
Don't issue delpnport when there is a SPVC on it
|
CSCds36438
|
Title:
SLT: Standby in pxm1 state when a restoreallcnf was done to active.
Symptoms:
Standby card does not come up after a restoreallcnf.
Conditions:
The database for the standby card is corrupted.
Workaround:
Perform sysClrallcnf on the standby card.
|
CSCds47032
|
Title:
SNMP Stuck for get and set
Symptoms:
SNMP subagent does not respond to requests.
Conditions:
This problem occurs only if the memory partition used by the SNMP subagent runs out of memory. This was seen when many connections were being added and deleted from a test system in the presence of a memory leak in connection add.
Workaround:
Switchover to standby card
|
CSCds56895
|
Title:
pnni ports stuck in auto-config after power cycled ses/bpx(SLT)
Symptoms:
Some ports with ILMI on will be stuck in autocfg state.
Condition:
Power cycle the ses and bpx.
WorkAround:
Bring the port down & up administratively and the port will be up.
|
CSCds57013
|
Title:
Subagent Memory Leak
Symptoms:
Dsplog command will show an entry for memory allocation fail. And this is usually logged by an SNMP process (snmpMA, snmpMgmt, for example). The system may switch side when this happens.
Conditions:
When adding connections on SES, there is a memory leak in SNMP subagent.
Workaround:
User can add connections from CLI. There is no workaround for user using snmp to add connections at this time.
|
CSCds59748
|
Title:
SES-FDR: dspcons does not display ABIT fail in state
Symptoms:
dspcons does not have an option for a bit failure connections
Conditions:
dspcons
Workaround:
None
|
CSCds60816
|
Title:
On doing resetsys, the active card comes up as standby
Symptoms:
After resetsys, previous Standby card becomes Active
Condition:
After executing the resetsys command
Workaround:
None
|
CSCds61996
|
Title:
Subagent memory leak due to deletion of connections
Symptoms:
Dsplog command will have an entry for memory allocation fail. And this is usually logged by an SNMP process (snmpMA, snmpMgmt, for example). The system may switch side when this happens.
Conditions:
When deleting connections on SES, there is a memory leak in SNMP subagent. Workaround: User can delete connections from CLI.
Workaround:
None.
|
CSCds63933
|
Title: AUT: Invalid release cause detected
Symptoms:
When T301 timer times out, the PXM displays the explanation for the cause code as invalid.
. > cause code - cause = (0x13)Invalid, IE_cause = (0x13)Invalid, location = Private Network.
Conditions:
This occurs only when user has dbgsig turned on while the T301 timer expires The PXM should display: (0x13)no answer from user (user alerted).
Workaround:
The problem only occurs when user has dbgsig turned on.
|
CSCds65708
|
Title:
SVPC calls retried with same VPI on PNNI links after crankback
Symptoms:
SVPCs calls are retried with same VPI on PNNI links after crankback due to VPI not being available.
Conditions:
During SVPC connection routing/derouting
Workaround:
None
|
CSCds72034
|
Title:
Connection stuck in AIS when UNI port is pull out and pull in.
Symptoms:
SPVC conns are in AIS
Conditions:
Pull out and pull in of UNI port
Workaround:
Down and up the UNI port using dnpnport and uppnport cmd on PXM
|
CSCds79424
|
Title:
Got building vc problem after pulling out and putting in the bxm.
Symptoms:
Port stuck in building-vc.
Conditions:
A card is pulled out and put back-in.
Workaround:
Use one of the following options:
1. Down the port and up it again
2. Pull out the card and put it back-in.
|
CSCds82333
|
Title: Connections in Fail state on slave side & Ok state from Master side
Symptoms:
Call is released on one node but does not get released on the peer.
Condition:
Caused when lot of status enquiry happens when the nodes are highly congested. This happens very rarely.
Workaround:
Clearing the connection manually.
|
S3 BUGS
|
|
CSCdr52821
|
Title: SLT: after put back card in, ports still stay in provisioning state.
Symptoms:
Given a redundant SES with the PXM in slot 1 active and PXM in slot 2 standby. Have ports provisioned with connections on them. Remove TBC from slot 2. Next, remove the active PXM from slot 1, causing a PXM switchover. Now, reinsert the TBC in
slot 2.
Condition:
Once the PXM in slot 2 has taken over as the active PXM, the ports stay in the Undefined state.
Workaround:
None.
|
CSCdr63291
|
Title:
nrt-vbr1,2,3, cbr1 PVCs with maximum parameters are not getting converted.
Symptoms:
While converting PVCs with maximum traffic parameters through CWM conn_proxy, conversion fails frequently for nrt-vbr1, vbr2, vbr3, cbr1 subtypes.
Conditions:
This problem is not reproducible.
Workaround:
None.
|
CSCdr87238
|
Title:
SLT: addpnni-node command give confusing syntax info.
Symptoms:
The addpnni-node command has confusing syntax. The syntax says lowest ---if true, the pnni node is set to the lowest level. But when entered true in the command it gives error. The actual thing to enter is lowest. This was modified in the syntax help.
WorkAround:
None
|
CSCdr95869
|
Title:
PXM1 does not handle 4k NvRam
Symptoms:
Programming the new Novram fails.
Condition:
The new Novram(AT93C66) required a different programming sequence.
Workaround:
None.
|
CSCds08804
|
Title: cnfpnportcac cant change minbw from 50 to 90
Symptoms:
Cannot change minbw to a value greater than some value (which can vary from port to port) using cnfpnportcac.
Conditions:
None
Workaround:
None
|
CSCds10860
|
Title:
dsppnni-ptse with - detail false shows incomplete information
Symptoms:
dsppnni-ptse with -detail option was not displaying the complete information.
Condition:
When, user selects -detail option true, ptse print function was not calling CLI next adopter.
Workaround:
In ptse print function modified the return code to allow the print function to print all the information
|
CSCds11973
|
Title:
SLT: Active and standby side display different port RSRC information.
Symptoms:
dsppnportrsrc displays different portrsrc information on Active and Standby.
Conditions:
Change in rsrc information in switch is not updated to Redman.
Workaround:
Added warning when command is executed on standby Warning: Resource values are not in sync with the active and may not be valid
|
CSCds12952
|
Title:
SLT: All three nodes total conns out of sync after overnight testing.
Symptoms:
Calls are released on the active card but not on the standby PXM.
Conditions:
Delete of a port goes to the standby card before bulk release calls does.
Workaround:
None.
|
CSCds23132
|
Title:
SNMP: Error message displayed on console of PXM1 repeatedly
Symptoms:
Incoming SNMP requests generate the following error on the console:
Illegal call: getSnmpPduHeaderInfo unsupported in the PXM1 version of POPEYE2.1
Conditions:
PXM1 systems using Release 2.1 of the Cisco MGX88 50 firmware
Workaround:
None.
|
CSCds26236
|
Title:
New PXM-DC-8-T3e3-32 controller type for PXM-1
Symptoms:
Controller type DC-8-T3E3 that support for PXM-1 had the same id as DC-8_T3E3 that support for AXSM-1. Conditions: Same controller type for the DC-8-t3E3 was using for different target.
Workaround:
None.
|
CSCds32434
|
Title:
SPVC Established should not be one of Last Fail Cause
Symptoms:
When a SPVC is call is established it's corresponding FAIL causes also will be recorded if there is any. So if a SPVC call goes through without any problems then the corresponding FAIL cause should be as No Fail
Condition:
After establishing the call execute dspcon to see the status of the call and see the Fail cause if there is any. If the call goes through without errors the Last Fail cause field was showing as SPVC Established which is not appropriate. So on request from COVAD the Last Fail cause for a call with no errors was changed to No Fail.
Workaround:
None
|
CSCds49105
|
Title:
Add support for synching bootChange info from Active PXM to Stby
Symptoms:
Taking the standby PXM from one node and placing into the standby of another node can cause the LAN interface of the old node to become disabled.
Conditions:
On a node with redundant PXMs, the boot IP and disk IP addresses for the LAN are the same.
Workaround:
Pull ethernet cable when switching cards between nodes.
|
CSCds54170
|
Title:
Called Party Number IE is AESA < 20 bytes is allowed
Symptoms:
SETUP with incorrectly coded Called/Calling Party Number IE is allowed.
Condition:
This occurs when the Called/Calling Party Number is an AESA less than 20 octets in length. It should be treated as IE with invalid content.
Workaround:
The problem will occur only if the Called/Calling Party Number is an AESA less than 20 octets in length.
|
CSCds56244
|
Title:
Call not rejected when max peak-to-peak CDV exceeded
Symptoms:
The cause code in the Release message will not carry QOS unavailable when the end to end CDV or CTD fails.
Conditions:
Whenever a call is initiated with an end to end CTD or CDV value which cannot be supported on the node, the routing failure cause code will be only Destination Unreachable.
Workaround:
None.
|
CSCds62587
|
Title:
GCOE: tstdelay issued at cli does not return any value
Symptoms:
When user executes tstdelay no information displayed on console.
Condition:
When no error in command syntax
Workaround:
Added display message to display Test started; Use dspcon to see test results when user executes tstdelay or tstconseg
|
CSCds63506
|
Title:
atmsig_msg.h doesn't prevent multiple inclusion of header file
Symptoms:
No defect will be exposed to user.
Workaround:
None
|
CSCds65459
|
Title:
Ambiguous err code of Network busy while prov spvc on exist vpi/vci
Symptoms:
Ambiguous err code of network busy during connection provisioning
Conditions:
When provision an SPVC for a master endpoint where slave endpoint is already busy with another master endpoint.
Workaround:
None
|
CSCds68717
|
Title:
AUT: Failed to access cwspCacConfigTable
Symptoms:
The MIB table 'cwspCacConfig' cannot be accessed.
Conditions:
The reason this table cannot be accessed is because an enum structure change was not reflected in agent.
Workaround:
User can examine Cac parameters from CLI. There is no workaround for user using snmp to access this table at this time.
|
Problems Fixed in Release 1.0.10
Table 1-7 Problems Fixed in Release 1.0.10
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdr76366
|
Title:
operStatus of Atm Conn mib has OK value for FAIL connection
Symptoms:
SNMP GET on mib variable cwaChanOperStatus returns OK even the connection is in FAIL state.
Conditions:
The reason for this bug is that when Conn Oper Status is determined, only the connection state is checked but not the state of the interface. So when SNMP gets retrieving this variable, it returns a wrong value.
Workaround:
None.
|
CSCdr76372
|
Title:
Failed to commit connections on BXM(SLT)
Symptoms:
Traffic does not pass with few connections.
Conditions:
1. resetcd BXM
2. burning BXM fw
Workaround:
On PXM shellconn, issue following command:
vsim_debug_reset_slave_sesId (slaveIpc), where slaveIpc is the any valid BXM slot no - 1
|
CSCdr80672
|
Title:
Dax connection are in failed state due to congestion. [blocking]
Symptoms:
Port may stay in down in progress due to nodal congestion and nodal congestion is always on.
Conditions:
Some failed testing or too much svc traffic. But this occurrence is very rare
Workaround:
None
|
CSCdr83226
|
Title:
Delete Partition on bpx cause pxm reboot
Symptoms:
The node will perform system reload.
Conditions:
When delete partition on BPX for BXM ports.
Workaround:
None.
|
CSCds06087
|
Title:
CNTL QBIN:pnCcb crash during spvc rerouting
Symptoms:
The problem is an unexpected system reload.
Conditions:
When a crankback occurs due to AVCR not available, the source node processing this crankback will have this problem.
Workaround:
None
|
CSCds09752
|
Title:
pnCcb crash in atmCore_RmDebug
Symptoms:
The problem is an unexpected system reload.
Conditions:
When a load info from the service module is received and it is processed, such load info processing will have this problem.
Workaround:
None.
|
CSCds09897
|
Title:
CNT QBIN: pnCcb crash caused by Route Agent crash in AvCr update
Symptoms:
The problem is an unexpected system reload.
Conditions:
Under rare conditions, when a crankback occurs due to AVCR not available and when the node is also not reachable, the system will have this problem.
Workaround:
None
|
CSCdp93160
|
Title:
Injecting error in the working APS line shows up errors on prot line
Symptoms:
When errors are injected on the working line, the working line status changes from OK to an alarm state (depending on the bit-error rate, the state could be SigF, ALM or some other state). The protection line should still be OK and APS should switch to the protection line.
If CSCdp93160 (this bug) happens, the errors injected on the working line also show up on the protection line, causing its status to change from OK to one of SigF, ALM or other similar alarm states. Therefore, the APS sub-system (wrongly) thinks that both lines are in error and switches back and forth between the two as and when it finds the protection line toggling between OK and alarm states. Due to this, traffic may be impacted.
Conditions:
Unknown.
Workaround:
None.
|
S2 BUGS
|
|
CSCdr47657
|
Title:
remove addmaster/addslave/addchan/cnfchan
Symptoms:
Rarely some SPVC connections can not be added back after deletion.
Conditions:
Delete large SPVE connection and re-add same set of connections.
Workaround:
None.
|
CSCdr51004
|
Title:
cli lock out after doing dsppnni-path awubr
Symptoms:
The CLI prompt takes some time to appear after entering q to quit from the display commands.
Conditions:
It is seen for commands like dsppnports, dsppncons, dsppnni-path and other commands involving multiple pages of output.
Workaround:
None.
|
CSCdr54204
|
Title:
After setup/release svc for a while, some of svc failed(SLT)
Symptoms:
Calls will not get routed through the nodes in the network.
Conditions:
Some calls will not get rerouted problem.
Workaround:
None.
|
CSCdr62399
|
Title:
System crash at task tDbgCmdTask after unplug pxm back card
Symptoms:
When a PNNI command is executed when the cli is displaying the prompt indicating that the cli is in the init state, it can cause the cli command task for that session to get a task exception.
Conditions:
When the cli is displaying the prompt with a .i (for example: hostname.7.pxm.i>) it means that the system is still booting up. Some commands are currently not blocked in this state.
Workaround:
Do not issue configuration commands until the cli issues the prompt: hostname.7.pxm.a>
|
CSCdr63937
|
Title:
redCoveringSlot is not 0 when the primary is not protected.
Symptoms:
redCoveringSlot field in the PXM redundancy MIB is not 0, when the primary slot is Active.
Condition:
When the primary slot is Active, PXM redundancy MIB does not give the correct.
redCoveringSlot.
Workaround:
None.
|
CSCdr68627
|
Title:
Ports stuck in building vc after upgrade pxm and bxm fw(SLT)
Symptoms:
Port/ports on a node stays in building VC.
Conditions:
The problem occurs once when BXM and PXM software are upgraded simultaneously.
Workaround:
Reload the BXM card(s), which is having the port(s) stuck in building VC.
|
CSCdr68691
|
Title:
SLT-Node does not come out of congestion
Symptoms:
Spvc calls does not try to re-route
Conditions:
This problem may not be easy to reproduce, but a configuration of two or more switches with SPVC's and resetting the BXM cards while there were lots of connections may cause it to happen.
Workaround:
None
|
CSCdr70711
|
Title:
SLT: ports stuck w/Interface status=DOWN w/no LOS on BXMs
Symptoms:
Interfaces remain in Down State though interface is physically up and ILMI on the interface is also up.
Conditions:
This has been observed only once and happened when BPX-SES was undergoing overnight script based testing. As part of the test, the following sequence of operations were being performed continuously:
1. Down all ports.
2. Wait for 5 minutes.
3. Perform PXM switchover.
4. Wait fro 5 minutes.
5. Up all ports.
6. Wait for 30 minutes.
7. Perform PXM switchover.
8. Repeat the above sequence 1 -7.
Workaround:
None
|
CSCdr74666
|
Title:
RTM MIB Implementation does not take care of internal wrap around
Symptoms:
RTM Proxy software module in CWM (Cisco Wan Manager) misses traps from the switch
Conditions:
RTM Proxy in CWM tries to Upload traps (snmp mib walk) from the Upload table. Sometimes, the trap in question is not available in the switch.This is happening in a normal case (where there are not too many traps being sent from the switch).
Workaround:
None.
|
CSCdr76381
|
Title: Send out trap 60307 followed by 60304 when do dncon in CLI
Symptoms:
The user may notice that a connection shows FAIL on CWM GUI while the same connection showed DOWN state on CLI.
Conditions:
When dncon is executed from CLI, the switch will send a cwaChanDown(60307) trap followed by a cwaChanFail(60304). On CWM side, the CONN FAIL state overwrites CONN DOWN states in its database. However executing dspcon of the same connection, the same connection will have DOWN state.
Workaround:
None.
|
CSCdr78847
|
Title:
SLT: Many daxcons in fail state after 48K daxcons were provisioned
Symptoms:
The system stopped routing and stayed in congestion.
Conditions:
When the slave don't have enough resources for all the connections or slave failed.
Workaround:
Change the slave configuration and give enough resource. Then, switch-over.
|
CSCdr82247
|
Title:
SPVC call can't reroute after unplug and plug all BXM card
Symptoms:
DAX SPVCs will remain in Fail state.
Conditions:
This condition will happen when there is a large number of DAX connections and the PXM or BCC is switched to the redundant cards or if the BXM is rebooted or if the BXM cards are pulled out and plugged back in.
Workaround:
None.
|
Problems Fixed in Release 1.0.01
Table 1-8 Problems Fixed in Release 1.0.01
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdr28772
|
Title:
ORIONSLT: Many ilmi ports on other cards go down after reset BXM
Symptoms:
Some pnni ports with ILMI on go down temporarily and come up. The calls are de-routed and re-routed back.
Conditions:
This happens on a large network which has 50k spvc endpoints. The node has at least 14 trunks spread across 6 BXM cards. Pull out one of the cards and re-insert the card.
Workaround:
None.
|
CSCdr40383
|
Title:
Exception log from crash is lost from dsperr after system reset
Symptoms:
The exception log from crash is lost from dsperr after system reset.
Conditions:
Task monitor automatically resets a card when it crashes.
Workaround:
None.
|
CSCdr45402
|
Title:
SLT: node struck in congestion-VSIM doesn't inform CCM of abatement
Symptoms:
In some rare situation, vsi congestion bit was set. This resulted in the number of connections fail to route.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr45891
|
Title:
1k call drop after unplug PXM active card(SLT)
Symptoms:
1K call drop after unplugging the active PXM card.
Conditions:
The connection pending counter was 1532 (threshold is 500). This was due to message drops on the SIGAPI Epid.
Workaround:
None.
|
CSCdr46104
|
Title:
SLT:pnCcb exception occurred when SPVCs were routed over IISP links.
Symptoms:
Exception in pnCcb task causing the active processor to
reset.
Conditions:
Observed on de-routing and re-routing SPVCs over an IISP link.
Workaround:
None.
|
CSCdr46257
|
Title:
SLT:Ports failure for a while after every 20 M SWO for overnight.
Symptoms:
SPVCs are getting re-routed on different NNI ports. They are released and then gets routed on different port.
Conditions:
If we do many ( >4) consecutive switchovers then sometime this happens.
WorkAround:
Please avoid doing more than 3-4 consecutive switchovers or overnight switchovers.
|
S2 BUGS
|
|
CSCdr42002
|
Title:
SLT:CLI locks up in shellcon during lkup
Symptoms:
If the lkup command is left at the prompt Type <CR> to continue, Q<CR> to stop: when the session times out or if ctl-C is hit when the lookup command is at this prompt then the terminal port may become locked and unusable.
Conditions:
Unknown
Workaround:
Do not leave the CLI session idle while executing lkup and do not use ctl-C to exit from a lkup command. No other known workarounds.
|
CSCdr43767
|
Title:
SLT: System reload at trapSrvTask after unplug BXM card
Symptoms:
Crash of Trap Server task (trapSvrTask) on the SES-PXM.
Conditions:
This problem occurs when there are more the 10K SPVCs setup and the BXM is unplugged. The problem is intermittent.
Workaround:
Do not unplug the BXM cards during operation.
|
CSCdr45917
|
Title:
Orion SLT - Dropped Connections in network.
Symptoms:
In some rare situation, SPVCs connections are getting dropped. This resulted in the number of connections do not match at nodes and specifically at both ends of the links.
Conditions:
Unknown.
WorkAround:
None.
|
CSCdr46108
|
Title:
SLT: Active PXM hung when trying to quit from dsppnni-ptse.
Symptoms:
Node stopped responding on quitting dspnni-ptse. The CLI was unavailable for typing any further commands.
Conditions:
This one time occurrence was on a PNNI node attached to a RADCOM simulator that simulates around 100 PNNI nodes and links. The node had 5 IISP links.
Workaround:
None.
|
CSCdr47016
|
Title:
SLT:SPVCs can not be added back after they are deleted.
Symptoms:
Some spvc connections can not be added back after deletion
Conditions:
Delete large spvc connection and re add same set of connections
Workaround:
None
|
CSCdr47505
|
Title:
SLT: Sscop will reset sometime during system switchover
Symptoms:
After repeated switchovers, few connections may re-route along other links. The connections and the link do recover. This is because SSCOP on a link with connections routed on it may go to Reset state temporarily and come back up.
Conditions:
Repeated switchovers at around one per 30 minutes.
WorkAround:
None
|
CSCdr47720
|
Title:
NULL svcBlock->softVcInfo in atmSoft_receiveReleaseComplete
Symptoms:
SPVC_ERROR receiveReleaseComplete: null svc or softVcInfo
seen in system error log.
Conditions:
Observed while derouting and rerouting SPVCs over IISP links by downing and upping IISP links.
Workaround:
None
|
CSCdr47782
|
Title:
Standby PXM reset due to SRAM timeout on active
Symptoms:
Standby PXM reloads
Conditions:
When there is too much traffic going on to standby from Active, sometimes connection path gets congested and it may take more than 5 sec.
WorkAround:
None
|
CSCdr47903
|
Title:
SLT:rutime image corrupted when FTPing-PXM pair has same boot IPaddr
Symptoms:
Runtime image corrupted when FTPing; PXM pair has some boot IPaddr.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr47937
|
Title:
Wrong SPVC status in atm_connection table
Symptoms:
CWM shows connection as OK after upload.
Conditions:
After doing an upload.
Workaround:
Query for chan state.
|
CSCdr47997
|
Title:
SLT: Task tDbgOutTsk is suspended after down and up PNNI link many ti
Symptoms:
Task tDbgOutTsk is suspended after down and up PNNI link many time.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48012
|
Title:
SLT:System switchover after can not access shell mode for a while
Symptoms:
System switchover after cannot access shell mode for a while.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48230
|
Title:
Trunk port goes into building VC when cnfrsrc is done.
Symptoms:
Trunk port goes into building VC when cnfrsrc is done.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48427
|
Title:
SLT:PNNI trunk in ILMI Query after burning FW
Symptoms:
PNNI trunk in ILMI Query after burning FW.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48563
|
Title:
ORIONSLT:unplug feeder trunk, some spvc calls still stay
Symptoms:
Ports in Provisioning state with active calls.
Conditions:
Congestion caused by faulty feeder trunk. This is a very infrequent.
Workaround:
None.
|
CSCdr48832
|
Title: pnni database took too long to update after down/up link(SLT)
Symptoms:
PNNI database took too long to update after down/up link (SLT).
Conditions:
Unknown
Workaround:
None.
|
Additional Deliverables
SNMP MIB:
The SES PNNI Controller MIB is being provided with the delivery of Release 1.0.00 of the SES PNNI Controller software on CCO. The MIB is in standard ASN.1 format and is included in the same directory where the SES PNNI Controller software is located within CCO. The SNMP SES PNNI Controller MIB file can be compiled with most standards-based MIB compilers.
Refer to Appendix E, SNMP Management Information Base, in the BPX SES PNNI Controller Software Configuration Guide, Release 1.0.01 for a description of the MIBs supported by the SES PNNI controller.
Default Values
There have been no changes.
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 On-line (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 On-line
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, product documentation, 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.
You can access CCO in the following ways:
•WWW: http://www.cisco.com
•WWW: http://www-europe.cisco.com
•WWW: http://www-china.cisco.com
•Telnet: cco.cisco.com
•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.
BXM Firmware MFL Release Notes
About the Firmware MFL
BXM Firmware version M.F.L. supports all the existing interfaces and models of BXM hardware. Following table outlines various levels of hardware revisions supported for BXM firmware version M.F.L.
Table 1-9 Front Cards
Model Num
|
Description
|
FW model
|
HW Rev
|
FW Rev
|
BXM-155-4
|
4 port OC3 Line Module (Front Card)
|
F
|
B
|
MFL
|
BXM-155-8
|
8 port OC3 Line Module (Front Card)
|
F
|
B
|
MFL
|
BXM-622
|
1 port OC12 Line Module (Front Card)
|
F
|
D
|
MFL
|
BXM-622-2
|
2 port OC12 Line Module (Front Card)
|
F
|
D
|
MFL
|
BXM-T3-8
|
8 port T3 Line Module (Front Card)
|
F
|
B
|
MFL
|
BXM-T3-12
|
12 port T3 Line Module (Front Card)
|
F
|
B
|
MFL
|
BXM-E3-8
|
8 port E3 Line Module (Front Card)
|
F
|
B
|
MFL
|
BXM-E3-12
|
12 port E3 Line Module (Front Card)
|
F
|
B
|
MFL
|
BXM-155-8DX
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-155-8D
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-155-4DX
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-155-4D
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-622-2DX
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-622-2D
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-622-DX
|
1 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-T3-12EX
|
12 port T3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-T3-12E
|
12 port T3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-T3-8E
|
8 port T3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-E3-12EX
|
12 port E3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-E3-12E
|
12 port E3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-E3-8E
|
8 port E3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
Table 1-10 Front Card for APS Compatibility
Model Num
|
Description
|
FW model
|
HW Rev
|
FW Rev
|
BXM-155-4
|
4 port OC3 Line Module (Front Card)
|
F
|
C
|
MFL
|
BXM-155-8
|
8 port OC3 Line Module (Front Card)
|
F
|
C
|
MFL
|
BXM-622
|
1 port OC12 Line Module (Front Card)
|
F
|
E
|
MFL
|
BXM-622-2
|
2 port OC12 Line Module (Front Card)
|
F
|
E
|
MFL
|
BXM-155-8DX
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-155-8D
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-155-4DX
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-155-4D
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-622-2DX
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-622-2D
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFL
|
BXM-622-DX
|
1 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFL
|
Table 1-11 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 MFL:
Bug fix only.
New Features supported in BXM Firmware MFK:
LCN cac with policying parameters set by PNNI controller. ( Look at "Notes & Cautions" entry 10 for warnings).
New Features supported in BXM Firmware MFJ:
Bug fix only.
New Features supported in BXM Firmware MFH:
1. Dynamic partitioning feature is supported on the BXM card by default. Remote Shell Feature through the BCC CLI provides a mechanism to turn off this feature.
2. SPVC feeder support.
New Features supported in BXM Firmware MFF
Bug fix only
New Features supported in BXM Firmware MFE
Bug fix only
New Features supported in BXM Firmware MFD
Bug fix only
New Features supported in BXM Firmware MFC
1. Support for SES (PNNI controller)
2. BootCore enhancement to support multi-vendor flash-SIMMs
3. 1 msec granularity for tstdelay measurement.
New Features supported in BXM Firmware MFB
1. Multiple VSI (2.2) partition feature. Three partitions are supported
2. Hitless Connection Density Upgrade for BXM
3. SCR and PCR policing at less than 50 CPS for T3/E3 BXMs
4. Control Traffic Shaping
New Features supported in BXM Firmware MFA
Multiple VSI (2.2) partition feature. (Two partitions)
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 9.
3. APS 1:1 is not supported for VSI. (Bug CSCdp42996) APS 1:1 should not be configured on ports intended to be used by PNNI or MPLS, as after switchover traffic flow is stalled on the protection line for releases before MFE. However in MFE, this problem is fixed.
4. Total BW allocated to all VSI partitions on a BXM should not be more that OC12 rate i.e., 1412832 cells/s. Currently BCC swsw allows uses to configure more than OC12 rate, in which case all the PNNI connection commit requests would be NACKed by BXM
Special Installation/Upgrade Requirements
BXM cards with M.C.B/M.D.A firmware or later can be smoothly migrated to the M.F.A or above version of firmware by using y-cable redundancy. To upgrade a BXM card pair in y-red configuration, first upgrade the standby card with the MFA or above firmware version and wait for all the configuration to be downloaded into the card. Do a switchyred to switch to the card with firmware M.F.A or above version and burn the other card also with desired version MFA or above firmware. Follow the standard firmware upgrade procedure for downloading and burning the firmware into the cards.
If BCC swsw version is 9.1.18 and dspnovram shows 0 or 4 for Number of Channel Stats it should be OK to go directly to MFC or above versions directly from MCC.
Features obsoleted
1. VSI 1.0 is obsoleted by VSI 2.2 in this release.
2. Channel statistics level 0 is no longer supported for BXM-155-4, BXM-155-8, BXM-622, BXM-622-2, BXM-T3-8, BXM-T3-12, BXM-E3-8, BXM-E3-12 models. However it is still supported for all the other models (BXM-155-8DX, BXM-155-8D, BXM-155-4DX, BXM-155-4D, BXM-622-2DX, BXM-622-2D, BXM-622-DX, BXM-T3-12EX, BXM-T3-12E, BXM-T3-8E, BXM-E3-12EX, BXM-E3-12E, BXM-E3-8E)
Notes & Cautions
1. BXM Model F firmware is intended for use with 9.3 switch software. BXM Model F firmware may be used to upgrade BXMs during the upgrade process from switch software release 9.2 to 9.3. BXM Model F firmware has not been tested for compatibility with release 8.4, 8.5, and 9.1 switch software. It is compatible with IOS version 12.05t2 for MPLS.
2. M.F.E is a not on CCO, as it an orion specific release.
3. While upgrading from firmware, on OC3, 1 port OC12 BXM cards, if stats level on BXM is greater than 1, the upgrade should take place according to the one of the upgrade procedures below
–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 MFL.
–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 MFL to avoid the card mismatch.
4. 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.
5. 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.
6. 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)
7. 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)
8. 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)
9. 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).
10. MFL supports LCN cac for class of services. Controller will reserve some LCNs for control VC as default. These reserved LCN can not be used by any class of service any more in MFL. If all the LCNs for the partition has been used in a version earlier than MFL, after MFL is updated in the switch, some connections may not be added because they try to use LCNs reserved for control VC which is not allowed. You need to configure more LCNs for the partition to make sure there is enough LCNs for all the connections.
Known Anomalies
The following is the list of known anomalies for the BXM firmware:
Table 1-12 Known Anomalies for the BXM Firmware
Bug ID
|
Description
|
Apply to SES
|
CSCdt36089
|
Symptom:
BXMs on the via node do not detect ais cells from AXSM.
Condition:
100K spvc routed through via node. Not all conns. at remote end see AIS when failure occurs.
Workaround:
None
|
YES
|
CSCdt32588
|
Symptom:
Cells continuously get dropped when pumping traffic on spvcs.
Conditions:
Cells get corrupted when pumping traffic in SPVCs
Workaround:
no workaround
|
YES
|
CSCdt29821
|
Symptom:
Connections are in failed state
Conditions:
Stats was enabled when spvcs were added
Workaround:
Delete some SPVCs and then re-add them with stats disabled.
|
YES
|
CSCdt29475
|
Symptom:
Egress QE dropping packets result in loss of connection.
Condition:
Ports were stuck in provisioning state while connections were routing.
Workaround:
None.
|
YES
|
CSCdt27294
|
Symptom:
After executing resetsys on the redundant pxm1 cards, the SES becomes unreachable on the bpx.
Condition:
The Orion node (SES / BPX) has redundant pxm1 card and 96K spvc were configured.
Workaround:
UNKNOWN.
|
YES
|
CSCdt26321
|
Symptom: Card error 0xb0000005 causes BXM in failed state when the number of connections for one card goes to 31.6k.
Condition:
intermittent.
Workaround:
None.
|
YES
|
CSCdt21547
|
Symptom:
There is no command available to clear SPVC statistics on SES controller.
Condition:
Function not implemented.
Workaround:
None.
|
YES
|
CSCdt13171
|
Symptom:
After dellp, traffic is not right when VP connection and cnfln VC shaping enabled.
Condition:
reproducible.
Workaround:
None.
|
YES
|
CSCdt21569
|
Symptom:
CAC policy not downloaded to some BXM, causing connection fails or building VC.
Conditions:
Intermittent
Workaround:
None.
|
YES
|
CSCds78285
|
Symptom:
CAC policy not downloaded to some BXM cards.
Condition:
Ports go into building VC state
Workaround:
None
|
YES
|
CSCds16136
|
Symptom:
Channel Mismatch appears as status even though LOS was still present.
Conditions:
In near succession, recovery of LOS on Working line and appearance of
LOS on Protection line.
Workaround:
No.
|
YES
|
CSCds47753
|
Symptoms:
Card error will happen in standby "VrmDekConnEndPoint Try to delete"
Condition:
When standby syncs up with active, it tries to delete a not existing connection.
Workaround:
The card error indicates that there is a invalid try of deleting a non-existing connection. It should not create any problem in existing or new connection. Still this problem will be analyzed more.
|
YES
|
CSCdr85398
|
Symptom: 2 nodes with 2 PNNI controllers cnfpnportrange command used to force a LOC, missing COA point trap dnpnport/uppnport, restarting ILMI session, results in COA trap.
Conditions:
when ILMI session is first initialized, or restarted, if SysUpTime doesn't change, COA trap shouldn't not be sent to controller. When an LOC is detected by ILMI on BXM and it is followed by a "Loss of Attachment Point" when connectivity is re-established, ILMI on slave does not give a "Loss of Attachment Point" trap.
WorkAround:
None
|
YES
|
CSCdr06316
|
Symptoms:
VPC connection drops cells over BXM trunks.
Condition:
reproducible.
Workaround:
None
|
NO
|
CSCdr11810
|
Symptoms:
BXM does not report Abit when SPVC fdr is provisioned w/o AR fdr segment.
Conditions:
Reproducible.
Workaround:
None.
|
NO
|
CSCdr45464
|
Symptom:
0B card error are reported. on BXM-oc3 cards.
Condition:
When the cards in yred. Most probably a bad hardware.
Workaround:
No workaround.
|
NO
|
CSCds01128
|
Symptom:
LOS occurs sometimes on several trunks.
Conditions:
Unknown. According to the bug report, once in a while for a couple of minutes.
Workaround:
recovers on it's own.
|
NO
|
CSCds21403
|
Symptom:
After downing the NNI ports, ports went into provisioning state due to running buffer leakage.
Condition:
Seen only once
Workaround:
Reset the card and continue, no known workaround
|
YES
|
CSCdr45566
|
Symptom:
cnftrafficgen does not work correctly
Conditions:
Unsupported.
Workaround:
None
|
NO
|
CSCds69832
|
Symptoms:
0x52 message returns default value for the UBR connection.
Conditions:
UBR connection get command issued by BCC.
Workaround:
No work around
|
NO
|
Table 1-13 Bugs Fixed in MFL
CSCds15145
|
Symptom:
Max BW could be configured as less than Min.
Condition:
This might happen as the policy parameter might not be checked for the consistency.
Workaround:
Do not configure Max below min.
|
CSCds06835
|
Symptom:
Nodes become unreachable if CC traffic traverses to the destination node via a UXM-BXM virtual trunk.
Conditions:
CC traffic is passed across virtual trunks.
Workaround:
Change the trunk configuration with cnftrk command to restrict CC traffic on virtual trunks.
|
CSCds75221
|
Symptom:
When Issuing the command dspconstats for abr or ubr connection it does not report the CLP0 and CLP1 correctly.
Conditions:
Statistics for abr and ubr not updated.
Workaround:
None
|
CSCdt38554
|
Symptom:
After executing resetsys on the node(svcpop2) pxm1 cards. there
are two ports stuck in building vc.
Condition:
The node(svcpop2) has 100k routed spvc connections.
Workaround:
UNKNOWN
|
CSCdt45966
|
Symptom:
Checksum calculation is not correct in BXM.
Condition:
Connection conditioning via bulk set cmd.
Workaround:
Uppnport/dnpnport on UNI and NNI port and do switchyred to kick resync.
|
CSCdt48062
|
Symptom:
Port gets stuck in building VC state.
Condition:
Connection admission control.
Workaround:
Establish connections of various service type and bandwidth requirements.
|
Table 1-14 Bugs Fixed in MFK
CSCdt21322
|
Symptom:
BXM load info returned to controller is wrong when maxbw set to 0
Condition:
reproducible
Workaround:
None.
|
CSCdp16050
|
Symptom:
maxvc functionality for CAC not working
Conditions:
reproducuble
workaround:
none.
|
CSCdt04632
|
Symptoms:
For a vsi partition, the reporting available number of LCN is greater than the maximum number of LCN configured for that partition.
Conditions:
When the port group unused LCN is less than the maximum LCN configured for the partition and the unused LCN for the port group plus the LCN that still left from the reserved (min-curr) is greater than the max of the partition.
Workaround:
None.
|
CSCds85653
|
Symptom:
BXM card error of "cb_if.c 1588 CbCoreTxEvent(): Failed core_cbmsg_put: return.
Condition:
Continually doing switchcc with large amounts of AR/SPVC connections
Workaround:
Reset BXM card
|
CSCds76142
|
Symptom:
BXM card shows standby-failed status
Condition:
Download firmware on standby card
Workaround:
Reset BXM card.
|
CSCds65105
|
Symptom:
When pumping the ATM CBR traffic at the rate over = of port line rate (BXM-622), at the egress dspchstats shown the number of cells. From Network' twice larger than 'To Port'.
Conditions:
DAX conn from BXM-622 port 1-2 on the same node with ADTECH generate traffic.
Workaround:
None
|
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
Conditions:
APS Line switches to stby line because of SD/SF condition. dspapsln will still show OK for both the lines. This way, user will never get to know when this line has come out of SD/SF condition.
Workaround:
Use rsh command to get all the aps line's status.
|
Table 1-15 Bugs Fixed in MFJ
CSCds61912
|
Symptom:
After downloading new firmware(MF30), card in failed state.
Condition:
Downloading MF30 firmware release.
Workaround:
Don't use MF30 which is a development release between MFH and MFJ.
|
CSCds11506
|
Symptom: Min guaranteed cell rate shows a cell less than configured.
Conditions: Setting min BW to say 3333334 and policy BW % to 5859
Workaround: Increase the minBW by few cells.
|
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
Conditions:
APS Line switches to stby line because of SD/SF condition. dspapsln will still show OK for both the lines. This way, user will never get to know when this line has come out of SD/SF condition.
Workaround:
Use rsh command to get all the aps line's status.
|
CSCds32845
|
Symptom:
Connection commits rejected with reason: "no resources even when resources are actually available".
Condition:
Enabling/disabling a virtual trunk.
Workaround:
Resetting the BXM after disabling a VT on any interface on the card.
|
CSCds37237
|
Symptom:
When upgrade BXM firmware image to BXMMFH from images between BXMMFC-BXMMFF, if the network migration flag was enabled in a card before the upgrading, then after burning the new image to the card, the network migration flag becomes disabled mistakenly.
Condition:
The problem only happens to the card whose previous image is BXMMFC-BXMMFF, and the network migration flag was enabled before upgrading, and BXMMFH has to be the new image.
Workaround:
Upgrading to image BXMMFH+ (not including BXMMFH), will not have any problem. network migration flag is always enabled, and no user command available any more to disable it.
Only for the situation you need to upgrade image to BXMMFH and your card's previous images is BXMMFC-BXMMFF, you may see the problem. The workaround is, issue either the
"rsh <slot> cdcfg netwotk dis" command before the upgrading, or
"rsh <slot> cdcfg netwotk ena" after the upgrading, to enable the netwotk migration flag on BXMMFH.
|
CSCds59710
|
Symptom:
Loss of traffic on a VPC connection added with VPI=0
Conditions:
SWSW: 9.3.10
BXM FW: MFF
The port on which the VPC connection has been added has a VSI ctrlr attached to it and the Ctrlr is usingVPI=0 and VCI=x for its signalling channel.
Workaround:
If a VPC connection exists with VPI=0, on the port to which a Ctrlr is to be added, configure the signalling channel on the controller side to use a VPI other than 0.
|
CSCds63578
|
Symptom:
SW errors 105 logged on BXM while adding VSI connections. Subsequent card errors saying CB_TASK restarted.
Condition:
This error sometimes happen when a VSI partition is enabled/disabled many times.
Workaround:
Reset the BXM.
|
CSCds65105
|
Symptom:
When pumping the ATM CBR traffic at the rate over = of port line rate (BXM-622), at the egress dspchstats shown the number of cells "From Network" is twice as large than 'To Port'.
Conditions:
DAX conn from BXM-622 port 1-2 on the same node with ADTECH generate traffic.
Workaround:
None
|
CSCds67854
|
Symptom:
SPVC cannot be routed over the virtual trunk even when enough bandwidth and lcn are available. Routed connections discard some traffic.
Condition:
Routing connections of different service types over the virtual trunks.
Workaround:
None.
|
CSCds04137
|
Symptom:
Channels remain mismatch after lockout is cleared
Conditions:
In ITU-T Annex B protocol for APS, when a condition causes a switch to occur while a lockout request is present, the channel change will not resynchronize even after the lockout is cleared.
Workaround:
No
|
CSCds53645
|
Symptom:
ABR connections (PNNI) not programmed properly for redundant slave.
Condition:
Switchyred
When connection is added, redundant card is not there and inserted at later stage.
When connection is added, no redundant config, addyred at later stage.
Workaround:
None
|
Table 1-16 Bugs Fixed in MFH
CSCds14495
|
Symptom:
Dynamic Partitioning and SPVC AIS generation would not work on a card until a rsh command is issued to enable the network migration flag and reset the card.
Conditions:
When a card comes up and has never enabled the network migration flag for
life time. This network migration flag is used for enabling dynamic partitioning and SPVC AIS, status report generations. By default, the flag is disabled.
Workaround:
Use the "rsh <slot> cdcfg netmig en/dis" command to enable/disable the flag, then reset the card once in a liftime.
|
Table 1-17 Bugs Fixed in MFF
CSCds08448
|
Symptom:
ERS (explicit rate stamping) is working only first virtual trunk and NOT for subsequent VTs (standard ABR)
Condition:
When ERS is enabled on a card basis using "cnfabrparm", the mapping is done on a port-by-port basis. The port_vi is used but for virtual trunks, this mapping does not hold true. Need to change the mapping to the physical port.
Workaround:
On any physical port, just set up one virtual trunks. Or a physical trunk. Multiple VTs on the same physical port will cause a problem
|
CSCdr79610
|
Symptom:
Change booking factor for a class of service, get rejected.
Condition:
When there are some connections established, and some of the class of service have used bandwidth exceeding their reserved, change booking factor for any class of the service may get rejected.
This is because it fails the check which should only be called when cos_min_bw in
the policy parameters is changed. This check should not be called when booking factor is changed.
Workaround:
Disable that partition, change the booking factor, then enable the partition again. Or keep the used_bw for all cos under teh cos_min_bw, you will be able to change booking factor freely.
|
CSCdr76334
|
Symptom:
Connect OC3 port on BXM with 7200 router, connect 2 OC3 ports back to back. enable ILMI on router, and ILMI, protocol on card cnfrsrc VSI part 1 disable NebDiscovery on ports.when running cnfnodeparm 56 0|1 and With VSI disabled, peer info is transmitted to peer. delcntrl, and cnfrsrc deleting VSI partition, fails to disable Peer information as well.
Condition:
ilmi_enable_from_contrl bit was not cleared when delctrlr, or vsi partition deleted, thus vsi code kept issuing get requests and responding to peer information.
in AR/VSI hybrid networks, and for backward compatibility either BXMs w/o NebDisc, or swsw versions. Topo traps are not sent to downrev'd swsw versions, and are controllable by sw software for versions including the feature.
Code was added to properly support disabling of VSI functionality using delctrlr or cnfrsrc @ Bcc in addition to existing dnpnport
@ the vsi controller. support for backrev'd cards added, and corrections to logic in Ilmi FSM state machine to properly send TopoTrap to BCC.
Workaround:
NONE:
|
CSCdr79936
|
Symptom:
Stats files not generated/missing on some 15 minutes intervals.
Conditions:
When system time is changed at 15 minutes boundaries.
Workaround:
Minimize system time and card config changes.
|
CSCdr83144
|
Symptom:
Card error of:
N. Fatal from 0x17: 0x25120075 0x809b5f90 0x367e 0x1
Conditions:
switchyred, switchcc or reset PXM when there are spvc connections with stats enabled.
Workaround:
None
|
CSCds11484
|
Symptom:
Available cell rate reported by BXM is incorrect.
Conditions:
Sum of the minimum bandwidths of all the interfaces on a BXM reaches OC12.
Workaround:
Reduce minimum BW on all interfaces by half.
|
CSCdr89217
|
Symptom:
Software Error Log of 9098
Conditions:
cnfrsrc of partition 3 using MEB firmware
Workaround:
None
|
CSCdr89966
|
Symptom:
Card Error of 0x41030006
Conditions:
PXM controller is upgraded/re-booted
Workaround:
None
|
CSCdp89085
|
Problem:
The total call count becomes negative on the BXM interface. However,
this problem has not been reproducible.
Symptoms:
If this problem happens, the following card error is displayed:
'vsi_rsrc_pfns.c 483 VrmRetLcnResources 3, 16316'
workaround:
A related bug CSCdr86894 which reported an incorrect number of total
call counts, has been found to be the result of an uninitialized variable in
vsi_rsrc_conn_pfns.c: VrmRsrcClrRCMP().
The debugging information embedded in this function may be helpful in
verifying the negative call count problem if it is reproduced.
|
Table 1-18 Bugs Fixed in MFE
CSCdp05098
|
Symptom:
Cell discards occur for ABRFST/ABRSTD conns when the traffic burst is greater than the MBS
Conditions:
This occurs when the traffic burst size is fixed to 140000 cells at 70000 cps. The conn are configured with PCR=72000/72000, MBS=1000/1000 and ICR 7200/7200. This is the expected behavior since the configured MBS < the actual burst size.
Workaround:
Increase the MBS and ICR using cnfcon.
|
CSCdr59731
|
Symptom:
port 11.1 is connected to 11.2 and ILMI are up and running on both ports. Enable neighbor discovery on 11.1, then 11.2.
The 0x71 responses/traps from BXM fw is not predictable. At least two variations are observed:
Variation 1. port 11.2 has it's neighbor's info but port 11.1 doesn't.
Variation 2. both port 11.1 and 11.2 only know the IP addresses of their neighbors. The Neighbor's IFName are missing. Problem was observed in MF17, but code changes in more recent builds had already repaired the problem.
Conditions:
when ILMI session restarts, remnants of IfName, IpAddr from previous session left. Clr/reset IfName,IpAddr in MIB, on ILMI session restart In FMSStart, pIlmiProcessFsmStart() calls a new function IlmiClrPeerAndSendTopoTrap(pcb_ptr->session_id)
Workaround:
None
|
CSCdr79936
|
Symptom:
Stats files not generated/missing on some 15 minutes intervals.
Conditions:
When system time is changed at 15 minutes boundaries.
Workaround:
Minimize system time and card config changes.
|
CSCdm16800
|
Symptom:
Card error 0xc000007 appears in the card error log.
Conditions:
This error indicates that an unknown type of cell which
is not expected has arrived in the egress QE.
Workaround:
Engineering has done in-depth investigation into this case. We are convinced the problem does not affect user traffic or the node in any other way. Therefore, the symptom will not be reported as a card error. The fix has been incorporated into MEE firmware.
|
CSCdp22930
|
Symptom:
N/A
Conditions:
cbus rd/wr operations set up in the PUUMBA chip when performing
cbus rcv/xmit.
Workaround:
None
|
CSCdp74680
|
Symptom:
Even if the interface is in LOS, the spvc's do not generate ingress AIS into the network.
Conditions:
Connection is added after the interface goes into LOS.
Workaround:
None
|
CSCdr44250
|
Symptom:
Private image did not allow as many OAM cells to flow as public image.
Conditions:
This occurred by undoing a hardware fix in a private image.
Workaround:
This was never introduced into the Public view and no workaround is required.
|
CSCdr45986
|
Symptoms:
Standby and active block checksum value do not match and resync happens on switchover.
Conditions:
When active card has many spvc connections derouted it happens.
Workaround:
None.
|
CSCdr71473
|
Symptom:
Unreachable BXM, sw errors and cd errors on the BPX.
Conditions:
LMI is enabled when controller either slow to respond or un-reachable.
Workaround:
Disable LMI.
|
CSCdp97307
|
Symptoms:
When executed "rsh <slot> vsi cm VsiIs " without parameter. The card will crash,.
Conditions:
Always.
Workaround:
Pullout the card and reinsert.
|
CSCdr86894
|
Symptoms:
Many ports have VC failure because BXM has no resource to build the CVC.
Conditions:
intermittent
Workaround:
Reset BXM card.
|
CSCdr57712
|
Symptom:
Multi_partition fails to report all virtual trunks.
Condition:
In case of virtual trunks with different partition.
Workaround:
Reset the BXM card.
|
CSCdr77238
|
Symptom:
Switch General Info does not contain bulk set capability bit. With newer images of PXM bulk set will not work with BXM images prior to MFD.
Condition:
PXM Images later than 07/06/2000 contains logic to identify the bulk set capability of the slave. BXM images prior to 07/06/2000 will not have this bit set because it is newly introduced parameter in VSI spec.
Workaround:
No Workaround. Need to upgrade to MFD.
|
Table 1-19 Bugs Fixed in MFD
CSCdr29278
|
Symptom:
Originally the card used to get frozen not responding to any request from the controller, as the TCB database was corrupted. But it has been protected now. But whenever a null pointer is being inserted into the TCB list a card error is being flagged. It is a harmless card error (not service affecting)
Conditions:
The cause is unknown.
Workaround:
none.
|
CSCdp63445
|
Symptom:
ABR and UBR connections loose traffic when VC shaping is turned on.
Conditions:
Enabling of VC shaping on port terminating ABR and UBR connections
Workaround:
Leave VC shaping disabled.
|
CSCdr30454
|
Symptom:
Connections (LCNs) can not satisfied because of insufficient memory
Condition:
When channel stat level is set to 0
Workaround:
Use chan stat level (cnfcdparm) 1, 2 or 3
|
CSCdr14247
|
Symptom:
The correct state of an SPVC is not reflected in connection bulk traps for large number of connections (> 1000). Sometimes Connection states keep toggling between AIS and CLR state when the conns are actually inAIS state
Conditions:
AIS cells generated by the RCMP on different connections arrive too close to each other in the same second. This sudden burst of cells overwhelm the Class of service buffers (QBINs) in the Egress direction and get discarded. This causes remote end of the trunk to detect a loss of AIS cells and declare connection a CLR.
Workaround:
NONE
|
CSCdr40204
|
Symptom:
Service rate for VBR traffic when WFQ is enabled is at SCR (instead of PCR) even when there is no congestion for enhanced cards (1210 QE & Sabre)
Condition:
For enhanced cards, when WFQ is enabled, the local congestion is monitored at the Egress side by the hardware. In order to do this, a few variables that need to be initialized. There were some problems with the initialization routine, causing inaccurate tracking of the congestion level.
Workaround:None. Has been fixed.
|
CSCdr42885
|
Symptom:
All the ports on a BXM slave go into provisioning state.
Condition:
Controller looses communication with the BXM. This happens when AAL5 driver in the BXM mal-functions and does not free the message buffers of the application processes (ILMI/VSI etc). Eventually BXM runs out of message buffers.
Workaround:
Reset the BXM card.
|
CSCdr49056
|
Symptom: Invalid Part id in SPVC stats after controller is added.
Condition:
This problem happens when SFM receives the vsi message before adding the controller. This is possible to happen when there is a delay between 52 and 61 message. Since 52 add the control vc it will receive the frame and give it SFM task. But SFM won't have any information for that partition and will report the error saying that invalid partition. Since this is possible to happen as per design, the card is removed now.
|
CSCdr40234
|
Symptom:
Service rate for UBR traffic when WFQ is enabled much lower than PCR even when there is no congestion for enhanced cards (1210 QE & Sabre)
Cause:
For enhanced cards, when WFQ is enabled, the local congestion is monitored at the Egress side by the hardware. In order to do this, a few variables that need to be initialized. There were some problems with the initialization routine, causing inaccurate tracking of the congestion level.
Workaround:
None. Has been fixed.
|
CSCdr49060
|
Symptom:
When doing a cnfcon for ABR connection, service rate drops to MCR rate even when there is no congestion. This is when WFQ is enabled and the inherent VSVD is not used.
Cause:
There are a certain parameters associated with WFQ that are required in order for WFQ to work. However, for ABR connections, when a cnfcon is done, once it is detected that VSVD is not enabled, the structure (Sabre rate RAM) which holds all these parameters is cleared out. This would cause WFQ not to operate properly.
Workaround:
No need. Fix is done.
|
CSCdr43012
|
Symptom:
All the ports on a BXM slave go into provisioning state.
Condition:
Controller looses communication with the BXM as AAL5 driver in BXM gets stuck.
Workaround:
Reset the BXM card.
|
CSCdr52195
|
Symptom:
All the ports on a BXM slave go into provisioning state.
Condition:
Controller looses communication with the BXM as AAL5 driver in BXM gets stuck.
Workaround:
Reset the BXM card.
|
CSCdr36963
|
Symptom:
When PNNI controller goes down then comes up, it couldn't establish its control call to the BXM partition, thus VC failure is displayed in PNNI controller for that partition.
Condition:
This problem only happens under the following conditions:
1. The policy parameters for the partition have been configured as nonzero at some of the class of service,i.e. the reserved minimum bandwidth of some class of service are nonzero.
2. Delete/disable that partition. BXM suppose to release all resources. However, it only released resources at partition level, but leave the reserved resources at cos level unchanged. As result, when this partition is enabled again, the internal CAC calculation at partition level became negative. That caused the first control call setup request fail.
Workaround:
Reset the BXM card will clear the VC failure.
|
CSCdr33867
|
Symptom:
Connect OC3 port on BXM with 7200 router, enable ILMI on router, and ILMI, protocol on card and Neighbor Discover, Object 0x31, Peer's IfName is not null terminated.
Conditions:
Some peer.ifName's are null terminated, some aren't a PDU containing valid nonzero length peer.ifName doesn't always include'\0'; and is stored accordingly in the MIB. added a test if peer.ifName is non-zero in length, and isn't null terminated, concatenate the'\0'char and bump peer.ifNameLen++ count Added logic CbIlmiStatsReport, ilmi_proc.c pIlmiFsmGetResponseEventAtS3, pIlmiFsmGetResponseEventAtS9, ilmi_fsm_evt.c to ensure TopoTrap, and ILMIStats report are correctly formated.
Workaround:
NONE:
|
CSCdp48306
|
Symptom:
on NNI side, when cross connect is established with VPI>1000 (0x3e8) the first nibble is getting chopped off and traffic is flowing on VPI 0xe8 due to bad programming of connection.
Conditions:
this happens if on NNI side VPI > 0xff.
Workaround:
none.
|
CSCdr51875
|
Symptom:
Virtual Trunking causing Unreachability
Conditions:
•At least Two virtual trunks share a common port at one node, but their remote endpoints terminate on different nodes.
•The virtual trunks are used to carry networking (rt_op) traffic.
•The simplest example follows below:
node_A ---- vtrk ---- /---- vtrk ---- node_C
/
/
node_B
(vtrks share 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".
Workaround:
•Customers who are already using VT wraparound should continue to do so under 9.2.3x until the fix is available.
•BXM virtual trunking (no VT wraparound) can still be implemented using software release 9.2.2x.
•If virtual trunks are not yet in use, the VT wraparound solution can be implemented in release 9.2.3x
|
CSCdr57805
|
Symptom:
Card errors show up indicating "CB_TASK is ready"
Condition:
CB_TASK gets busy processing VSI messages and this causes root task to incorrectly assume that CB_TASK is not in a sane state. Actually a firmware change incorrectly reduced the polling interval by the root task such that it was polling the states of tasks sooner than it is supposed to.
Workaround:
None. Ignore these card errors as these are benign.
|
CSCdr56931
|
Symptom:
After resetsys on PXM or bouncing the feeder/control port or reset of BXM card, some virtual trunks go into vc failure/building vc state.
Condition:
resetting PXM or pulling out the cable connecting the BXM feeder port to the controller or resetting the BXM cause the interface set policy parameters to be sent to the BXM. This cause ingress BW to be recomputed. CB_TASK passes VI numbers 0 to 31 to the CAC module which expects the range 0 to 15. This caused the problem by over-indexing the CAC structures.
Workaround:
NONE
|
CSCdr59241
|
Symptom:
Building VC status on UNI ports after repeated enabling/disabling of partition with the control port
Cause:
Controller does not send policy parameters for control port upon enabling of partition. When disabling partition, COS max bandwidth was zeroed out. With no policy parameters from which to obtain the new values, COS max bandwidth is stuck at zero; thus not allowing ant control to be established.
Workaround:
Older PXM image does send policy parameters even for the partition with the control port. Control port does not require policy parameters to be sent from controller. Default it to the max bandwidth configured for the partition.
|
CSCdr51970
|
Symptom:
Change CAC policy parameters will cause the available BW for some cos to be negative.
Condition:
Current implementation does not validate the CAC policy parameter change. It will always take the value. However, in some cases, improper policy parameters change will cause the avail_bw at cos level go negative. In this particular scenario, the current used bandwidth of a cos is equal to its reserved minimum bandwidth.Then the user changed the policy parameter to make this cos min_bw to smaller number. Now current_used_bw for this cos is greater than its reserved, and it has to obtained bw from the common pool to maintain its currently used bw. However, the user changed the policy parameter again, to increase the reserved bw for another cos, which caused the common pool to be zero.Therefore, by normal calculation, the previous cos avail_bw becomes to negative. Decreasing cos_min_bw to be less than it is currently used_bw is an invalid operation and should get rejected, otherwise it will mess up the CAC.
Workaround:
Delete some connections to release bandwidth before decreasing cos minimum bandwidth.
|
CSCdr66273
|
Symptom:
The encoding is in the reverse of the expected value by UNI4.0 spec.
Conditions:
STD ABR connections.
Workaround:
No work around.
|
Table 1-20 Bugs Fixed in MFC
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.
|
CSCdr11396
|
Symptom:
Data transfer has affected while running OAM loopback
Conditions:
All user data is dropped when send in 960 cps of oam.
Workaround:
None
|
CSCdp11511
|
Symptom:
BPX treats segment oam loopback different from end-to-end oam loopback cells
Conditions:
Workaround:
|
CSCdr13208
|
Symptom:
BXM CD errors while running OAM cells
Conditions:
1. One PVC has 2880 cps of data and 960 cps of oam cells,
2. Another PVC has 2880 cps of data and 960 cps of oam cells,
Workaround:
None
|
CSCdr13196
|
Symptom:
BPX reports SWERR 105
Conditions:
SWERR105 logged while running OAM loopback test
Workaround:
None reset the BXM card
|
CSCdr13182
|
Symptom:
tstdelay/tstcon/tstconseg for all PVCs on that card will fail.
Conditions:
When user sending in >= 960 cps of oam loopback cells
Workaround:
|
CSCdr13151
|
Symptom:
dspportstats always show Tx port = 0
Conditions:
sending in >= 960 cps of oam loopback cells
Workaround:
|
The following bugs are fixed in MFB
Table 1-21 Bugs Fixed in MFB
CSCdm52254
|
Symptom:
Random BIP-8 errors show up on T3 when running in direct map (HEC) mode. There is no such thing as a BIP-8 error in the direct map mode. But this counter should report 0 in this mode.
Conditions:
This is totally random due to the fact that an uninitialized (don't care) counter variable is accumulated in every poll period. This counter is not even read from hardware in the HEC mode.
Workaround:
Ignore BIP-8 errors when the T3 trunks are configured in the HEC mode.
|
CSCdp58969
|
Symptom:
cb_get.c CB_VPC_STATUS_POLL SoItcSend Failed upon VSI Failure
Conditions:
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
Conditions:
This happens when both Ingress and Egress queue 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
Conditions:
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 executed 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 does not 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
Conditions:
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
Conditions:
After the standby card comes out of reset, its S/UNI states are not reliable for a period of 1.5 seconds and the S/UNI reports LOS clear on the WORK line. This gets conveyed to the active card and then the Manual switch gets priority and becomes the current local request. This causes a switch back to WORK. When the active card's S/UNI monitors the WORK line, it discovers that the line is in LOS and immediately switches back. The oscillations continue and the line goes into LOCKOUT due to excessive switching. In the Lockout mode only the WORK line is active and thus the defect.
Workaround:
None.Upgrade to MEF or newer version of firmware.
|
CSCdp65320
|
Symptom:
Need a trap when BPX puts APS in lockout
Condition:
Send the traps in the right sequence. First send the Lockout trap and then the failed to switch trap if there is a switch attempt while lockout is in effect.
Workaround:
None.Upgrade to MEF or newer version of firmware
|
CSCdp25130
|
Symptom:
APS Non-revertive bidirectional feature
Condition:
Resolved
Workaround:
None
|
CSCdp79156
|
Symptom:
TDP signalling cross connect VSI request rejected by BXM
Conditions:
If BPX is configured with trunks and virtual trunks the virtual trunks are initialized properly with qbin size.
Workaround:
None.Upgrade to MEF or newer version of firmware
|
CSCdp62213
|
Symptom:
Switching from bi-direction APS to un-directional APS generates mismatch err
Condition:
The alarms generated while the line was in bi-dir mode was not cleared when it was changed to uni-dir mode. Fixed by clearing all alarms when re-configuring the lines.None.
Workaround:
None.Upgrade to MEF or newer version of firmware
|
CSCdp89972
|
Symptom:
Node rebuild caused 3 BXM cards failed
Condition:
Moved the allocation and initialization of the Connection database to the SoCoEnterStandby function instead of in the 0x50 handler (SoCdUp)
Workaround:None.Upgrade to MEF or newer version of firmware
|
CSCdp86147
|
Symptom:
The removal of Rx cable of APS trunk leading to loss of Frm and Prot Sw Byt Fail
Condition:
While removing the Rx cable of APS working line (configured to trunk) working line goes to Loss of Frm and dsptrks shows the trunk in alarm. After connecting cable back the APS Alarm status shows "Prot Sw Byt FAIL"
Workaround:
None.Upgrade to MEF or newer version of firmware
|
CSCdp84386
|
Symptom:
Connectivity w/BXM lost due to missing DMA completion interrupts
Conditions:
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
Conditions:
re-impose the selector and bridge states on both ACTIVE and STANDBY cards after
a Y-red switchover, re-discover the line states and re-execute and external requests.Also include a STABILITY timer before the line state is processed.
Workaround:
None.Upgrade to MEF or newer version of firmware
|
CSCdm92931
|
Symptom:
APS line switchover occurs upon 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
Conditions:
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.
Conditions:
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
|
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
|
CSCdp59729
|
Symptom:
addlnlocrmt causes node unreachable.
Conditions:
addlnlocrmtlp causes node unreachable even though there are other parallel trunks.
Workaround:
No known workaround
|
CSCdp67673
|
Symptom:
dspapsln does not show ARCH_MIS any more
Conditions:
dspapsln does not show ARCH_MIS when caused for the second time on the same trunk.
Workaround:
No known workaround
|
CSCdp46399
|
Symptom:
Need a documentation explains how to setup port groups for FW MEF (me26)
Conditions:
Workaround:
No known workaround
|
CSCdp49749
|
Symptom:
node unreachable after resetting two nodes in the network
Conditions:
when combus message 0x52 is sent down to BXM, we were not handling the case when message says activate the lcn, but delete the vpi-vci pair specified in the command
Workaround:
None.Upgrade to MFB
|
CSCdp28931
|
Symptom:
No RDI-P generated when loss of Cell Delineation occurs
Condition:
Workaround:
|
CSCdp59727
|
Symptom:
Addlnlocrmt causes node unreachable
Conditions:
Workaround: Reset the BXM card
|
The following bugs are fixed in MFA
Table 22 Bugs Fixed in MFA
CSCdm53420
|
Symptom:
switchyred causes APS line to switch when last user request is clear
Conditions:
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.
Conditions:
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.
Conditions:
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
Conditions:
After LOS condition on the feeder trunk
Workaround:
Reset the feeder trunk
|
CSCdm16505
|
Symptom:
AIS not sent on VP ABRFST/ABRSTD connection
Conditions:
LOS on trunk between 2 nodes
Workaround:
none
|
CSCdm81534
|
Symptom:
ICR of abrfst on BXM-155 falls down to MCR after resetcd
Conditions:
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.
Conditions:
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.
Conditions:
BXM slot errors on a BCC3 node
Workaround:
None
|
CSCdk80483
|
Symptom:
TX cell loss counts in dsptrkerrs increase continuously.
Conditions:
When there is trunk configured.
Workaround:
None.
|
CSCdm04312
|
Symptom:
The problem is a false failure is declared against the SIMBA Multicast Record RAM.
Conditions:
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.
Conditions:
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.
Conditions:
Card running in standby mode under heat condition
Workaround:
none
|
CSCdm09882
|
Symptom:
Log non fatal message related to the RCMP errors
Conditions:
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
Conditions:
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.
Conditions:
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 also with the CR value.
|
CSCdp17741
|
Symptom:
2-portgroup card reports 1 port group at the channel stats level 2 and 3.
Condition:
When channel stats level 2 or 3 are configured on BXm-622-2 port and BXM-155 reports only one port group.
Workaround:
Auto Route connections are not affected by this. But for VSI connections there is no work around.
|
CSCdp22930
|
Symptoms:
Intlock missing for rd/wr operation
Workaround:
Reassert intLock on commbus ISR to prevent SCC access from getting interrupted
|
CSCdp33894
|
Symptom:
standby APS line shows status as Path AIS upon switchyred or on APS switchover on LOS
Conditions:
switchyred on APS, the prot. line report Path AIS
Workaround:
NONE. upgrade to ME26/MED or later versions of BXM firmware
|
CSCdp36324
|
Symptom:
last user request affects switching on BPX.
Conditions:
Workaround:
|
CSCdp31325
|
Symptom:
UBR cells are policed unnecessarily below PCR.
Conditions:
Always.
Workaround:
none.
|
CSCdp36155
|
Symptom:
BXM-E OC3/OC12 does not show supporting APS HW 1+1 in dspcd command and otherwise also.
Condition:
BXM-E OC3/ OC12 card with HW rev < 'C'
Workaround:
None.
|
CSCdp32853
|
Symptom:
The BXM enhanced cards keep getting reset and card errors are logged and node may go into degraded mode, when command "addapsln slot1.port1 slot2.port2 1"
is issued.
Conditions:
BXM enhanced OC3 cards with 4 port and FW rel earlier that M.E.22/M.F.09
Workaround:
Use one of the following options:
1. Do not addapsln on second port onwards for BXM-E OC3 4 port card.
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 display 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.
Conditions:
SWSW 9.1 with ME level of firmware. Trunks or VTs configured on BXM/BXM-E.
Workaround:
None
|
The following bugs are fixed in MEC.
Table 1-23 Bugs Fixed in MEC
CSCdm66131
|
Symptom:
After addapsln trunk goes to LOS
Conditions:
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.
Conditions:
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.
Conditions:
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:
None
|
CSCdm65813
|
Symptom:
APS switches back o working line incorrectly.
Conditions:
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:
None
|
CSCdm77212
|
Symptom:
When addshelf command is executed, it comes back with a communication breakdown.
Condition:
channel level stats is set to 0 so that BXM reports wrong max channels.
Workaround:
|
CSCdm74316
|
Symptom:
Re-adding VSI shelf does not work until a resetcd is executed on the LSC control port.
Conditions:
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:
None
|
CSCdm75722
|
Symptom:
No control VC after BXM is reset.
Conditions:
When resync request comes down from the VSI controller with 19 checksum blocks, the length check done on BXM does not include padding.
Workaround:
None
|
CSCdm74968
|
Symptom:
0B card error causing BXM to reset
Conditions:
Over night jobs running on controller cards.
Workaround:
|
CSCdp02190
|
Symptom:
tstdelay timed out when going through BNI trunk
Conditions:
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
Conditions:
primary and secondary port has two different VPI range.
Workaround:
|
CSCdm26752
|
Symptom:
Card errors continuously logged with "SoItcSend failed" message.
Conditions:
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
Conditions:
oamlpbk is enabled with high oam traffic on large number of connections.
Workaround:
|
CSCdm52254
|
Symptom:
BIP-8 code errs occurs on routing trunks
Conditions:
T3 card used in HEC mode can randomly have this problem.
Workaround:
None
|
CSCdm44183
|
Symptom:
BXM-155 4DX was not able to recover after resetting the card
Conditions:
Traffic is sent at a rate >= 383 cps on a terminated connection on BXM-E card and then card is reset.
Workaround:
None
|
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:
None
|
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 configuration, ILMI/LMI protocol is enabled as CARD based.
Workaround:
None
|
CSCdm82688
|
Symptom:
Traffic Shaping problems with VT with and without wrap-around solution
Conditions:
Large deviations in CDV values
Workaround:
None
|
CSCdm94372
(see explanation below)
|
Symptom: Trunks sometimes drop cbr traffic
Conditions: If a trunk is configured to full line rate on BXM cards, then traffic is dropped
Workaround:
None
|
CSCdp00063
|
Symptom:
Node unreachability is experienced on VTs (virtual trunks)
Conditions:
Multiple VTs are configured on a trunk interface of the BXM/BXM-E
Workaround:
Configure only one VT per trunk interface
|
Logic to calculate actual cell transmission rate in a BXM card is as follows (CSCdm94372):
if (configured cell rate == full line cell rate) then transmitted cell rate = full line cell rate
else transmitted cell rate = from equation below or from table 1
Example 1-1
If a trunk is configured at 100,000 CPS, the actual transmitted cell rate is then 98,013 CPS any traffic sent over 98,013 CPS would be discarded. Therefore, only rates in the table or computed from the equation should be used. Otherwise cell loss may be experienced
The following is the list of bugs fixed in release MEB.
Table 1-24 Bugs Fixed in MEB
CSCdm50469
|
Symptom:
Software error 105 and malloc card errors happened continuously
Conditions:
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.
Conditions:
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.
Conditions:
When tx cell rate of a trunk is reduced to zero, BXM card fails with break point error (division by zero).
Workaround:
None
|
The following is the list of bugs fixed in release MEA:
Table 1-25 Bugs Fixed in release MEA
CSCdm09882
|
Symptom:
Log non fatal message related to RCMP errors.
Conditions:
It is mainly seen in the heat chamber.
Workaround:
None
|
CSCdm18186
|
Symptom:
AIS status could be randomly be displayed in dspcon
Conditions:
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
Conditions:
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.
Conditions:
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.
Conditions:
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.
Conditions:
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.
Conditions:
Annex B configuration if hitless rebuild is done when active line is PROT, then switchapsln does not work after hitless rebuild.
Workaround:
None
|
The following is the list of bugs fixed in release MDA:
Table 1-26 Bugs Fixed in release MDA
CSCdm38647
|
Symptom:
MDA fw may report incorrect number of port-groups when APS channels are set to halved.
Conditions:
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.
Conditions:
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.
Conditions:
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.
Conditions:
BXM fw allowed configuration of networking channel to be bidirectional only.
Workaround:
None
|
Firmware Filenames and Sizes
BXMMFL.000 65536
BXMMFL.001 65536
BXMMFL.002 65536
BXMMFL.003 65536
BXMMFL.004 65536
BXMMFL.005 65536
BXMMFL.006 65536
BXMMFL.007 65536
BXMMFL.008 65536
BXMMFL.009 65536
BXMMFL.010 65536
BXMMFL.011 65536
BXMMFL.012 65536
BXMMFL.013 65536
BXMMFL.014 65536
BXMMFL.015 65536
BXMMFL.016 65536
BXMMFL.017 65536
BXMMFL.018 65536
BXMMFL.019 65536
BXMMFL.020 65536
BXMMFL.021 65536
BXMMFL.022 65536
BXMMFL.023 65536
BXMMFL.024 60128
BXMMFL.025 14
BXMMFL.026 2
BXMMFL.IMG 784
BXMMFL.img 784
Feedback
