Table Of Contents
1.0.16 Version Software Release Notes
Cisco SES Controller Software
About These Release Notes
About the 1.0.16 Release
Software Release 1.0.16
Service Expansion Shelf (SES) PNNI and SVC Controller
Clarifications
Upgrade from SES 1.0.12, 1.0.13, 1.0.14, or 1.0.15 to SES 1.0.16
Upgrade the Backup Boot Image
Backup Boot Upgrade Procedure for Redundant Systems
Upgrade the Backup Boot on Non-Redundant Systems
Upgrade the SES PNNI Runtime Image
Upgrade the Runtime Image on Redundant Systems
Runtime Upgrade Procedure for Non-Redundant Systems
Procedure for Upgrading BXM Firmware and 9.3 Switch Software Releases
SES Controller Bring Up Procedure
Compatible Releases
Notes & Cautions
Limitations
Notes/Recommendations
Required Workarounds
Compatibility Notes
Known Anomalies
Problems Fixed in Release 1.0.16
Problems Fixed in Release 1.0.15
Problems Fixed in Release 1.0.14
Known Anomalies from Previous Releases
Problems Fixed in Release 1.0.13
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
BXM Firmware MFM Release Notes
About the Firmware MFM
New Features supported in BXM Firmware MFM
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
Upgrading from Firmware Revision MEA or Higher
Upgrading from Firmware Revision Lower than MEA
Known Anomalies
Firmware Filenames and Sizes
Related Documentation
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco.com
Technical Assistance Center
Cisco TAC Web Site
Cisco TAC Escalation Center
1.0.16 Version Software Release Notes
Cisco SES Controller 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.16 Release
The 1.0 software release supports the Cisco WAN switching products: BPX 8600 series with SES controller.
Software Release 1.0.16
Service Expansion Shelf (SES) PNNI and SVC Controller
Release 1.0.16 of the SES controller is compatible with the BPX 8600 series software Release 9.3.11 and with the later 9.3 releases. The SES 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 controller 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.12 and 1.0.13 to l.0.14
Clarifications
N/A
Upgrade from SES 1.0.12, 1.0.13, 1.0.14, or 1.0.15 to SES 1.0.16
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)
Note Some connectionions may take up to 60 minutes to recover after the controller is reset. For more information, see the "Limitations" section.
Upgrade the Backup Boot Image
This section provides instructions for upgrading the Backup Boot images from 1.0.12/1.0.13/1.0.14/1.0.15 to 1.0.16. Boot upgrade can be graceful or non-graceful, depending on the type of card to be upgraded and the configuration of the node.
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.016.000_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. From the SES, use the dspipif command at the active controller card to find the Node's IP address.
The field internet address for lnPci 0 interface is the Node IP address.
b. From the workstation containing the PXM Backup Boot image, 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 From the SES, 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 inet on ethernet (e). This is the Boot IP address for the active PXM1.
c. To change this address to make it unique, type a new address at the inet on ethernet (e) prompt.
Note Changing the boot IP address on the active PXM1 also changes it on the standby PXM1.
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 3. 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.016.000_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. From the SES, use the dspipif command at the active controller card to find Node's IP address.
The field internet address for the lnPci 0 interface is the Node IP address.
b. From the workstation containing the PXM Backup Boot image, 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 Log in 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.016.000_bt.fw"
Proceed as follows:
a. Enter Y for Yes
b. At the pxm1bkup> prompt, enter the reboot command.
The node resets.
c. 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.12/1.0.13/1.014/1.0.15 to 1.0.16.
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.16 is pxm1_001.000.016.000_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 1 1.0(16.0)
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 1 1.0(16.0)
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(16.0)
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 1 1.0(16.0)
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(16.0)
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>
ses1.1.PXM.a>runrev 1 1.0(16.0)
b. Card will reset and will run the new revision when it returns.
c. dspcd
Example: ses1.1.PXM.a>dspcd 1
Step 4 At this point you can still abort this upgrade if needed. Use abortrev if needed.
ses1.1.PXM.a>abortrev 1 1.0(16.0)
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 MFM. See Release Notes for BXM MFM firmware in Appendix A.
Step 2 Upgrade BCC switch software to Release 9.3.11.
Note Please use SES PNNI 1.0.16 Backup boot, pxm1_001.000.016.000_bt.fw.
Note Please refer to 9.3.11 Release Notes for BCC switch software upgrades
SES Controller Bring Up Procedure
For detailed procedure changes, please see the on-line Cisco 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.16 has been certified 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 MFN or later (see S/W Compatibility Notes Matrix, first and second bullets)
•Cisco View version 5.0
•CWM version 10.4.10
•BCC-3-64
•BPX-BCC-4V or BPX-BCC-4V/B
•MGX 8850 R1 1.1.32 and 1.1.34 (1.1.34 is not available as of 6/20/2001)
•MGX 8220 5.0.16
For further information on the BXM card, please see Appendix A.
Note The SES PNNI 1.0.16 is compatible with MFM BXM (See Table 1 for more information.)
Notes & Cautions
Limitations
Release 1.0.16 of the SES has the following system limitations:
•If ports are brought up and down many times between the time the controller is reset (e.g. via resetsys) and the time it is upgraded, there is a chance that some connection updates did not get to the standby card (See CSCdt78006). As the system switches over during upgrade and the new active card detects a mismatch between the PXM and the BXM, resync is triggered between PXM and the BXM where mismatched connections will be deleted and re-added. In the worst case scenario where all connections terminate on just one port and if there were 40000 connections, it may take up to 60 minutes for the last connection to recover.
•The number of connections 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.
•Starting from BXM firmware release MFL, due to limited memory space on the BXM card and code size increasing, channel statistics level 0 is no longer supported on BXM cards (BXM-155-4, BXM-155-8, BXM-622, BXM-622-2, BXM-T3-8, BXM-T3-12, BXM-E3-8, BXM-E3-12 models). When BXM card firmware is upgraded to MFL or any post MFL release, regardless how many connections have been provisioned, channel statistics level 0 is no longer supported. If a BXM card has channel statistics level 0 turned on, to upgrade its firmware to MFL or any post MFL release, two upgrade paths can be taken:
•Change the BXM card to run channel statistics level 1. Statistics level 1 supports a maximum of 16K connections on a card. If a card has more than 16K connections configured, some connections must to be relocated to other BXM interfaces to reduce the total number of connections to be less than 16K. Reset the card after changing to statistics level 1.
•Upgrade the BXM card to the BXM-E card. The BXM-E card can continue running statistics level 0. Statistics level 0 can support a maximum of 32K connections on a card.
Notes/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 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.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
|
PXM1
|
1.0.13
|
pxm1_001.000.013.000_bt.fw
|
1.0.13
|
MFM
|
9.3.11
|
10.4
|
PXM1
|
1.0.14
|
pxm1_001.000.013.000_bt.fw
|
1.0.13
|
MFN
|
9.3.11
9.3.24
|
10.4.10
|
PXM1
|
1.0.15
|
pxm1_001.000.013.000_bt.fw
|
1.0.13
|
MFN
|
9.3.11
9.3.24
|
10.4.10
|
PXM1
|
1.0.16
|
pxm1_001.000.016.000_bt.fw
|
1.0.16
|
MFN
|
9.3.11
9.3.24
|
10.4.10
|
Table 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: A0 or later
|
MMF-4-155
Rev: A0 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: A0 or later
|
SMFIR-4-155
Rev: A0 or later
SMFIR-4-155/B
Rev: A0 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: A0 or later
|
BNC-2T3
Rev: A0 or later
|
2
|
E3
|
SES-PXM-CNTL-2T3E3
(with 2 port T3E3)
P/N 800-06699-01
|
PXM-UIA
Rev: A0 or later
|
BNC-2E3
Rev: A0 or later
|
Table 3 Feeder SW tested with SES SPVCs - Hardware Compatibility Matrix
Feeder
|
MGX 8850 R1
|
MGX 8220
|
Release
|
1.1.34
|
5.0.16
|
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 4 PXM Software Bugs
Bug ID
|
Description
|
S1 BUGS
|
|
S2 BUGS
|
|
CSCdt08059
|
Symptoms:
Telnet daemon allowed user access into switch without authentication
Conditions:
While in boot mode, you can telnet to the node. Access via telnet during boot mode is not restricted.
Workaround:
None.
|
CSCdt12655
|
Symptoms:
Too many stat collection ftp errors.
Conditions:
Unknown
Workaround:
None
|
CSCdt78006
|
Symptoms:
Conditions:
Workaround:
|
CSCdu19130
|
Symptoms:
Node with 50K routed connections crashed, and there was no response to some CLI commands, such as dsppnports and dspcons. After executed the abortrev command on the other node in the network.
Conditions:
There are 50K routed connections between node pswpop7/pswbpx2 and orses18/svcbpx23 via node pswpop6/pswbpx6. I did loadrev and runrev to upgrade a the orses18 node from 1.0 to 1.1. Everything was fine after upgrade. Then I did abortrev to bring theorses18 node back to the 1.0 image. After abortrev was executed on the pswpop7 node, it suddenly crashed. Many tasks were deleted. No responses to some cli commands like dsppnports, dspcons, dspconinfo, etc. but dspdate, dsplogs, dsperrs worked fine.
Workaround:
None.
|
CSCdu22913
|
Symptoms:
The SSI_SRAM_WIN_TIMEOUT Redman Error causes the standby PXM1 reset.
Condition:
There are about 50k routed SPVC connections between two Orion/BPX nodes. One Orion node has redundant PXM1 cards. Pull out the Y-cable on the feeder trunk. The RedmanError SSI_SRAM_WIN_TIMEOUT causes standby PXM1 reset.
Workaround:
Unknown.
|
CSCdu24540
|
Symptoms:
The dbsvr command failed to upgrade after standby reset when used script to dncon/upcon.
Condition:
There were about 50K routed spvc connection between node orses18/svcbpx23 and node pswpop7/pswbpx2. Ran script to dncon/ upcon on orses18, at the same time reset standby PXM1 on orses18. dbsvr failed to upgrade.
Workaround:
Unknown.
|
S3 BUGS
|
|
CSCds74052
|
Symptoms:
Given a redundant SES node, pull out the trunk back-card from the active PXM's slot. This causes the active PXM to reboot and the standby PXM to take over as the active front-card. The previously-active PXM card should come up as the standby card but instead, it keeps rebooting.
Condition:
Not known as yet. It is suspected that some task is trying to access the NOVRAM on the (absent) trunk back-card.
Workaround:
None. Do not pull the trunk back-card out while the front-card is in either the active or standby role.
|
S4 BUGS
|
|
CSCdt85179
|
Symptoms:
Connectivity to BPX is lost. LMI root task has been deleted on the SES.
Conditions:
This happens when the "Run Protocol By card" option is run on the BXM, causing LMI to run on the BXM instead of the BCC.
Workaround:
Currently, BPX does not support LMI 4 on BXM, whereas it is required to run 4.0 on SES (because of IP connectivity features needed on the SES). Hence, DO NOT RUN Protocol by Card on the BXM.
|
Problems Fixed in Release 1.0.16
Table 5 PXM Software Bugs Fixed in Release 1.0.16
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdw56907
|
An error can occur with management protocol processing. Please use the following URL for further information:
http://www.cisco.com/cgi-bin/bugtool/onebug.pl?bugid=CSCdw65903
|
S2 BUGS
|
|
CSCdu20428
|
CBR.3:VSIM setting SCR equal to PCR0 instead of PCR0+1.
Symptom:
VSI master fills PCR(0) instead of PCR(0+1).
Condition:
Whenever CBR.3 cross commits are commited.
Workaround:
None
|
CSCdw44217
|
CBR.1 S-PVC is allows only through-put 50pcs
Symptom:
The CBR.1 S-PVC with PCR = 1000 cps only allowed traffic through-put at a rate
of 50 cps.
Conditions:
Initiate a CBR.1 S-PVC and verify that the UPC functions as specified by the traffic contract.
PCR = 1000 cps
CDVt = 150 us
CDV = 10000 us
CTD = 150 ms
Generate user traffic at a rate of 500 cps.
Workaround:
Reset interface cards (BXM) then the traffic can run at rate of 500 cps.
|
CSCdw46988
|
BPX SES returns incorrect value when doing SNMP query
Symptom:
Can't get CDVT for CBR for SNMP get
Conditions:
Do a SNMP get on CDVT for CBR connection
Workaround:
None
|
Problems Fixed in Release 1.0.15
Table 6 PXM Software Bugs Fixed in Release 1.0.15
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdu39060
|
Symptoms:
Active PXM resets during a loadrev to upgrade Standby.
Conditions:
DbSvrIO Tlb Load Exception on Active PXM.
Workaround:
None
|
Problems Fixed in Release 1.0.14
Table 7 PXM Software Bugs Fixed in Release 1.0.14
Bug ID
|
Description
|
S2 BUGS
|
|
CSCds78285
|
Symptoms:
Connections in failed or BuildingVC state.
Conditions:
CAC policy was not downloaded to some of the BXMs.
Workaround:
None
|
CSCdu65624
|
Symptom:
As the standby PXM coming up after loadrev on a node. Ram Sync Err occurred and the standby PXM went to Failed state.
Condition:
Upgrading the node.
Workaround:
None
|
Known Anomalies from Previous Releases
The following anomalies were identified in previous releases.
Bug ID
|
Description
|
CSCdt33599
|
Closed - problem was due to a wrong configuration.
|
CSCdt37734
|
Un-reproducible. Failed to configure SPVC Prefix.
|
CSCdt45706
|
Un-reproducible. Standby PXM has a state of "mismatch".
|
CSCdu32539
|
Duplicate of CSCds74267 - fixed in 1.0.13
|
Problems Fixed in Release 1.0.13
Table 8 PXM Software Bugs Fixed in Release 1.0.13
Bug ID
|
Description
|
S1 BUGS
|
|
CSCds75999
|
Symptoms:
The SSCOP reset happens after switch over to standby, and connections get derouted.
Conditions:
During any resync, failures occur on control VCs in the active card. The standby doesn't know the failure and doesn't unbind on the LCNs. This causes an inconsistency with the VSI proxy and causes the SSCOP to go down during switchover.
Workaround:
None.
|
CSCds76260
|
Symptoms:
Traps are not received from the switch. Some traps get lost, or no traps are delivered.
Conditions:
The following conditions result in a standalone PXM system:
1. On a redundant system, the standby PXM card is reset.
2. On a redundant system, the standby PXM is removed and never reinserted.
3. On a standalone system, a standby PXM is removed, and never gets re-inserted.
4. On a standalone system, a standby PXM is added, but fails.
Workaround:
When traps are not being received, reset the active pxm card.
Due to the bug introduced into the system, the trap client task flushes its queues and sends a lost trap to the CWM/external world. The shm generates a card removal for the standby PXM. In this event, flush the queues and stop sending out the traps. This problem persists until you insert a standby card and a card becomes available for the standby PXM, or until the active PXM card is rebooted.
Note Any time we get a card unavail from the standby pxm, this state persists until a card avail is received by the trap client task. Inserting a standby card and unplugging it will cause us to get into this state.
|
CSCds85557
|
Symptoms:
The standby card continuously resets.
Conditions:
This occurs when the operator replaces the standby card with a PXM which has an upgrade configuration.
Workaround:
Execute the sysClrallcnf command on the standby PXM only.
|
CSCds90529
|
Symptoms:
SSCOP links go into a Release/Reset state, causing all the connections to be rerouted/derouted or stay in fail state.
Conditions:
SSCOP and PNNI links could be reset or released due to errors while re-synchronization is happening. The connections are being removed from the Service Module (AXSM) causing SSCOP and PNNI failures.
Workaround:
Down the port and up it again.
|
CSCdt16078
|
Symptoms:
SPVCs derouted on newly active PXM card.
Conditions:
This problem is found in MGX 8850 shelf after runrev.
Workaround:
Waiting for all the connections to be rerouted.
|
CSCdt36063
|
Symptoms:
The dsppnports command on a PXM card does not show the output.
Conditions:
On executing dsppnports on a PXM card, pnCcb task is suspended.
Workaround:
Switchover to a standby PXM, or enter the resetsys command on the active PXM card.
|
CSCdt70757
|
Symptoms:
SPVC Connections did not route after node upgrade.
Conditions:
Upgrading the node.
Workaround:
None.
|
CSCdt74499
|
Symptoms:
The node rejects CLI commands.
Conditions:
This occurs when you execute the dsppnports and dsppnni-link commands.
Workaround:
None.
|
CSCdt87745
|
Symptoms:
When cong_display command is executed "outStanding status enquiry congestion" is persistently on.
Conditions:
An edge node that had SPVC connections routed via this node was rebooted.
Workaround:
None.
|
CSCdt96649
|
Symptoms:
1. dspcons shows conn in FAIL state, but dspconinfo shows conn in OK state 2. Alarm file contains status as clear 3. No trap is sent to CWM when a DAX conn in AIS
Conditions:
When an interface is failed
Workaround:
None
|
CSCdu17620
|
Symptoms:
PNNI tries to route a new call using VPI/VCI pair that has already been assigned to an active call over the PNNI trunk.
Conditions:
UNKNOWN
Workaround:
Issue the resetsys command to clear this condition.
|
S2 BUGS
|
|
CSCds54946
|
Symptoms:
VP connections are slow to route.
Conditions:
Some deroute might have failed, causing some dangling VC in AXSM. What it means that some VCs are left in use in AXSM.
Workaround:
After some time, RESYNC detects the error and connection is cleaned up at the AXSM.
|
CSCds68426
|
Symptoms:
Sometimes, after a non-graceful upgrade, some DAX SPVP stay in a failed state.
Conditions:
This condition can occur after a non-graceful upgrade which accompanies a system reboot. Happens for DAX connections.
Workaround:
None Enter the dncon and upcon commands to recover the connection.
|
CSCds77133
|
Symptoms:
Calls fail to re-route. Release cause: user not responding.
Conditions:
This occurs when an ABR traffic congestion flag is set on a Via-node
Workaround:
PXM Switchover will remove the problem on the newly active PXM.
|
CSCds77137
|
Symptoms:
A connection is not routed with master state as down VSI half and not in any queue and admin is up.
Conditions:
This occurs when you run the dncon, upcon, rrtcon commands while there are lots of connections in the routing queue.
Workaround:
Run dncon and upcon commands again.
|
CSCds79085
|
Symptoms:
When the dsppnports command is executed, the interface is in the "building-vc". state.
Conditions:
Multiple AXSM switchovers lead to this problem.
Workaround:
Once the interface is in the "building-vc" state, enter dnpnport followed by uppnport to bring the interface to oper-up.
|
CSCds86171
|
Symptoms:
Ports stay in ILMI query and do not 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.
|
CSCds86265
|
Symptoms:
Summary display of tasks is awkward to get from CLI.
Conditions:
Always.
Workaround:
Enter the dsptask command as follows:
|
CSCds86694
|
Symptoms:
When the resetcd command is given, an unexpected system reload occurs.
Conditions:
Unknown.
Workaround:
None.
|
CSCds87127
|
Symptoms:
SNMP does not respond, or lost traps occur after the switchcc command is executed on the redundant node. This problem is very rare.
Conditions:
1. When you execute the switchcc command on a node with a redundant PXM, the standby PXM becomes active, but any communication with the switch via SNMP does not get any response
2. The standby PXM might drop the first few traps when it becomes active because it could not transition fast enough.
Workaround:
None.
|
CSCds88236
|
Symptoms:
An SSCOP reset happens after a switch over to the standby, and connections get derouted.
Conditions:
During any resync failures on control VCs in the active, the standby doesn't know the failure and doesn't unbind on the LCNs. This causes an inconsistency with the VSI proxy and causes SSCOP to go down during switchover.
Workaround:
None.
|
CSCdt03684
|
Symptoms:
A pnport is stuck in building VC, preventing SVCs and new SPVCs from getting routed.
Conditions:
The upport/dnport command was executed on an AXSM port to get rid of some phony e-ais/rdi alarms
Workaround:
None.
|
CSCdt06911
|
Symptoms:
The pnport both side of the pnni-link goes to attempt state. The SSCOP on both sides is in established state. There are no alarms etc on any of the pnport, SSCOP, port of the line of both nodes.
Conditions:
The PNNI port goes into attempt when a delred, addred is followed very quickly by a switchcc.
Workaround:
By disabling the PNNI node using cnfpnni-node disable, and re-enabling it the link can be brought up. This is NOT service affecting.
|
CSCdt07085
|
Symptoms:
SPVCs stayed in conditioning state
Conditions:
The node terminating the master end of one of the two failed spvcs was rebuilt
Workaround:
UNKNOWN
|
CSCdt07366
|
Symptoms:
The pnport on the local side goes to vc building state and SSCOP
is in unknown state. The remote node shows that pnport is up and the pnni-link is in attempt state.
Conditions:
The pnport which has Y-red configured goes to building vc state. The SSCOP is in the unknown state on the local side. The condition occurred with switchcc after the the Y-red is deleted.
Workaround:
Bringing the pnport down (dnpnport) and up (uppnport) the pnport
come out from the vc building state.
|
CSCdt11521
|
Symptoms:
vsiProcessVxlCommitRsp: no leg, but has Pep error message keep pop up on PXM
Conditions:
Reset multiple AXSM cards
Workaround:
It'll stop generate error message after AXSM comes up
|
CSCdt12043
|
Symptoms:
After multiple switchcc failed to telnet to a node.
Conditions:
Disk IP address not configured for LAN (lnPci0). During switchover, no ARP broadcast sent to declare new IP address <--> MAC address mapping.
Workaround:
Make sure the Disk IP address (lnPci0) of this node is configured.
|
CSCdt12816
|
Symptoms:
Adtech conformance tests for SSCOP give an inconclusive result
Conditions:
the Adtech does not expect a response to BGREJ PDU in idle state
Workaround:
None.
|
CSCdt14860
|
Symptoms:
dsplog shows some event log are getting dropped
Conditions:
This occurs when the same event is generated multiple times in a short period of time. The default interval is 1 tick = 1/100 second
Workaround:
None.
|
CSCdt19936
|
Symptoms:
Port stuck in building vc
Conditions:
Power off/on or reset node
Workaround:
Issue dnpnport portID then uppnport portID command
|
CSCdt22626
|
Symptoms:
CAC is set for ABR for 2%. Have 2 connections big PCR CBR connection and ABR connection. If CBR is routed first, then ABR con is not able to route.
Conditions:
ABR connection is not routed due to no bandwidth although pnni has enough bandwidth
Workaround:
dncon on the CBR connection rrtcon on ABR upcon on the CBR connection
|
CSCdt23284
|
Symptoms:
Dax connections go into failed state.
Conditions:
When upgraded from 2.1(0.15) to 2.1(0.30).
Workaround:
Down one of the pnni port and up again.
|
CSCdt27655
|
Symptoms:
The Cumulative RM fixed round trip time parameter (octet 9) is not included in the ABR setup parameter.
Conditions:
When initiating an SPVC ABR call, the cumulative RM FRTT octet is not included in the ABR setup parameter.
Workaround:
None.
|
CSCdt31293
|
Symptoms:
Able to add 2 master to the same slave endpoint for dax connections
Also, this will lead to dspcons mess-up
Conditions:
add slave endpoint
add master endpoint to slave endpoint NSAP address
add another master endpoint (with different vpi vci) to the same slave endpoint NSAP address and vpi vci
Workaround:
None.
|
CSCdt34888
|
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 disabled).
|
CSCdt37734
|
Symptoms:
Fail to configure SPVC prefix.
Conditions:
SPVC prefix can be configured only if there is no connection in the node. Unfortunately, there are six dangling legs in CM for three dax connections.
Workaround:
None
Status:
Unreproducible
|
CSCdt37525
|
Symptoms:
cli command dnpnport/uppnport of NNI port timeout. pnRedman was busy sending to standby while the standby is in failed status showing in dspcds. syncRam shouldn't allow application (pnRedman) to send to standby when standby is in failed status.
Conditions:
p2spvc4.8.PXM.a > dspver
Image Type Shelf Type Card Type Version Built On ---------- ---------- ---------- ------------ ------------ Runtime MGX PXM45 2.1(50.43)A Feb 1 2001, 03:54:17 Boot MGX PXM45 2.1(50.43)A -
The MGX(p2spvc4) node has a 100k SPVC routed connections.
Workaround:
None.
|
CSCdt38260
|
Symptoms:
pnport went into vc failure state
Conditions:
setrev was executed on AXSM
Workaround:
None.
|
CSCdt38632
|
Symptoms:
Syntax for the command routeNetAdd failed
Conditions:
At the cli prompt type the command
Workaround:
None.
|
CSCdt41956
|
Symptoms:
SAR frame transmit failed and ssiFrameXmt failed error messages are recorded in event log.
Conditions:
Switchcc executed every 8 minutes.
Workaround:
None.
|
CSCdt43448
|
Symptoms:
from dsppnports, there are failed three spvc connections at both orion node (svcpop2) and MGX node(p2spvc4).
Conditions:
Both Orion node svcpop2 and MGX node p2spvc4 have redundancy cards and multiple pnni interfaces. About 99K spvc connections are configured and routed on the node. Upgraded the FW to 1.1(50.44)A and system went to reset. After reset system, the spvc connections start to reroute. Once finished rerouting, there are still three connections failed. Chi and Qian were looking into this problem and collecting necessary informations. (02/12/2001)
Workaround:
None.
|
CSCdt44343
|
Symptoms:
Event log files are not ordered in chronological order
Conditions:
on a redundant node, as a card comes up in standby mode. The file number sequence is off.
Workaround:
None.
|
CSCdt45643
|
Symptoms:
Route Op Start/Stop messages are dropped incorrectly.
Conditions:
None
Workaround:
None.
|
CSCdt47978
|
Symptoms:
dbgcon command is available at cli level. Enabling it globally can increase load on the CPU. The current fix prints a warning message.
Conditions:
Not applicable
Workaround:
None.
|
CSCdt50122
|
Symptoms:
Node-name missing at higher levels when dsppnni-node is done.
Conditions:
Execute the dsppnni-node command.
Workaround:
None.
|
CSCdt59596
|
Symptoms:
Trap 60078 (cwCoreCardSwitch) was sent with cwTrapSlotNumber and cwTrapIndex in reversed order so old active slot number would be wrong.
Conditions:
The trap is sent after a PXM switchover.
Workaround:
None.
|
CSCdt66184
|
Symptoms:
addcon, dspcons, dspcon, delcon, cnfcon are only available at the
CISCO_GP access level.
Conditions:
Commands are available on AXSMS.
Workaround:
You must log in as cisco to access these commands.
|
CSCdt75586
|
Symptoms:
Control VC stays in attempt states. QE SAR shows discards/errors on the GLCN.
Conditions:
We suspect that QE VC queue is not purged when the connection is deleted. It causes the cell memory leak in QE. Pretty soon the cell memory will reaches the threshold so the incoming cell will get discarded.
Workaround:
Switchover to standby.
|
CSCdt75394
|
Symptoms:
Alarms do not sync up during CWM cold start.
Conditions:
1. CWM cold start.
2. too many alarms in switch.
Workaround:
None.
|
CSCdt78822
|
Symptoms:
Memory is never freed.
Conditions:
Failure cases of dspconstats command.
Workaround:
None.
|
CSCdu00481
|
Symptoms:
ANYUSER can delcon/cnfcon.
Conditions:
ANYUSER level is just for checking status (dsp commands). But I found a user at ANYUSER level can do both delcon and cnfcon.
Workaround:
Unknown.
|
S3 BUGS
|
|
CSCdp43597
|
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.
|
CSCdp93160
|
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.
|
CSCdr40795
|
Symptoms:
No command available for clearing connection statistics.
Conditions:
Clearing connection statistics.
Workaround:
None
|
CSCds10778
|
Symptoms:
Standby PXM gets reset by the 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.
|
CSCds12952
|
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.
|
CSCds15154
|
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, the port may go to Building VC.
Workaround:
Down the port and up the port should bring the port to UP again.
|
CSCds55940
|
Symptoms:
Card alarm is generated when core redundancy is lost.
Conditions:
When core redundancy is disabled using cnfndparms.
Workaround:
None
|
CSCds62761
|
Symptoms:
SPVC are allowed to be added on failed PNNI interface.
Conditions:
When you run the addcon command on a failed PNNI interface.
Workaround:
Do not add an SPVC on a failed PNNI interface.
|
CSCds69318
|
Symptoms:
dspcds command output shows alarms.
Conditions:
When you execute the dspcds command on standby PXM card.
Workaround:
Ignore alarms displayed on the standby PXM card.
|
CSCds82118
|
Symptoms:
Control chars in file names' are printed as is during listing of the files.
Conditions:
Accidental creation of file(s) with control characters in its (their) name(s).
Workaround:
None.
|
CSCds87891
|
Symptoms:
addcon screen help is not correct for the VCI range.
Conditions:
When addcon is issued.
Workaround:
None.
|
CSCds91053
|
Symptoms:
Observed following message on screen... call vsim_free_pdata.
Conditions:
When BXM is reset during lot of connection rerouting/derouting.
Workaround:
None.
|
CSCdt04611
|
Symptoms:
Copychan command used to build 1000 connections at a time appears to be causing the ethernet interface to hang.
Conditions:
Ethernet chip appears to freeze. User loses connectivity to the switch.
Workaround:
Possibly a PXM switchover may resolve the ethernet connectivity issue.
|
CSCdt12510
|
Symptoms:
Intuitive error message appears when a connection is added on an existing endpoint.
Conditions:
When connection is added on an existing end point.
Workaround:
Do not add a connection on an existing end point.
|
CSCdt33174
|
Symptoms:
After formatting the PXM hard disk, the sysVersionSet command returns an error about not being able to open C:/SHMDB/forced_version
Conditions:
2.0.12 code was used.
Workaround:
Before issuing the sysVersionSet command, create a /SHMDB directory and FTP the four files from a working node's /SHMDB directory on to the node.
|
CSCdt15090
|
Symptoms:
SES APS line reverts when it is configured for non-revertive mode.
Conditions:
When an APS line is set for bi-direction and non-revertive mode.
Workaround:
No work around.
|
CSCdt79361
|
Symptoms:
BPX clock source was not visible to SES.
Conditions:
When SES was attached to BPX.
Workaround:
Do not include the following commands in the list of PXM1 CLI commands:
•cnfclksrc
•delclksrc
•dspclksrcs
|
CSCdt95688
|
Symptoms:
cnfsig returns syntax error.
Conditions:
Interface in provisioning state does not accept some values for t310.
Workaround:
Bring the port operationally up and then issue cnfsig with desired t310 values.
|
Problems Fixed in Release 1.0.12
Table 9 Problems Fixed in 1.0.12
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdt11833
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
Symptoms:
lower E3 bank spvp's in error after power cycle
Conditions:
shelf power cycle off/on
Workaround:
None
|
S3 BUGS
|
|
CSCds68731
|
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
|
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 10 Problems Fixed in 1.0.11
Bug ID
|
Description
|
S1 BUGS
|
|
CSCds64807
|
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
|
Symptoms:
System reload due to pnCccb crash
Conditions:
dspconstats
Workaround:
None
|
CSCds84187
|
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
|
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.
Conditions:
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
|
Symptoms:
After a power cycle to the shelf.
Conditions:
Standby PXM1 card is stuck in Init state
Workaround:
Reset the standby PXM1 card
|
CSCds01154
|
Symptoms:
Sometimes some connections are in discontinuity state
Conditions:
Multiple PXM switchovers
Workaround:
Wait for resync to be over
|
CSCds04661
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
Symptoms:
Some ports with ILMI on will be stuck in autocfg state.
Conditions:
Power cycle the ses and bpx.
WorkAround:
Bring the port down & up administratively and the port will be up.
|
CSCds57013
|
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
|
Symptoms:
dspcons does not have an option for a bit failure connections
Conditions:
dspcons
Workaround:
None
|
CSCds60816
|
Symptoms:
After resetsys, previous Standby card becomes Active
Conditions:
After executing the resetsys command
Workaround:
None
|
CSCds61996
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
Symptoms:
Programming the new Novram fails.
Condition:
The new Novram(AT93C66) required a different programming sequence.
Workaround:
None.
|
CSCds08804
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
Symptoms:
No defect will be exposed to user.
Workaround:
None
|
CSCds65459
|
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
|
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 11 Problems Fixed in Release 1.0.10
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdr76366
|
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
|
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
|
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
|
Symptoms:
The node will perform system reload.
Conditions:
When delete partition on BPX for BXM ports.
Workaround:
None.
|
CSCds06087
|
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
|
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
|
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
|
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
|
|
CSCdu22689
|
Symptoms:
When the addshelf command was administered, a communication failure error message appeared, and the user could not add the shelf.
Conditions:
The node name was the same for both the BPX and the SES.
Workaround:
The SES node name must be different from the node name of the attached BPX.
|
CSCdr47657
|
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
|
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
|
Symptoms:
Calls will not get routed through the nodes in the network.
Conditions:
Some calls will not get rerouted problem.
Workaround:
None.
|
CSCdr62399
|
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
|
Symptoms:
redCoveringSlot field in the PXM redundancy MIB is not 0, when the primary slot is Active.
Conditions:
When the primary slot is Active, PXM redundancy MIB does not give the correct.
redCoveringSlot.
Workaround:
None.
|
CSCdr68627
|
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
|
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
|
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
|
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
|
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
|
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.
|
CSCdr79020
|
Symptoms:
Subnetmask field is modified when modifying the Netmask attribute.
Conditions:
After using ipifconfig to configure the IP and Netmask, the user entered dspipif to view it. The subnetmask field was modified instead of the Netmask attribute.
Workaround:
Do not use NET_MASK unless you want to build a complicated SNMP network by using subnet.
|
CSCdr82247
|
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 12 Problems Fixed in Release 1.0.01
Bug ID
|
Description
|
S1 BUGS
|
|
CSCdr28772
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
Symptoms:
Runtime image corrupted when FTPing; PXM pair has some boot IPaddr.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr47937
|
Symptoms:
CWM shows connection as OK after upload.
Conditions:
After doing an upload.
Workaround:
Query for chan state.
|
CSCdr47997
|
Symptoms:
Task tDbgOutTsk is suspended after down and up PNNI link many time.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48012
|
Symptoms:
System switchover after cannot access shell mode for a while.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48230
|
Symptoms:
Trunk port goes into building VC when cnfrsrc is done.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48427
|
Symptoms:
PNNI trunk in ILMI Query after burning FW.
Conditions:
Unknown.
Workaround:
None.
|
CSCdr48563
|
Symptoms:
Ports in Provisioning state with active calls.
Conditions:
Congestion caused by faulty feeder trunk. This is a very infrequent.
Workaround:
None.
|
CSCdr48832
|
Symptoms:
PNNI database took too long to update after down/up link (SLT).
Conditions:
Unknown
Workaround:
None.
|
Additional Deliverables
SNMP MIB
The SES controller MIB is being provided with the delivery of Release 1.0.00 of the SES controller software on CCO. The MIB is in standard ASN.1 format and is included in the same directory where the SES controller software is located within CCO. The SNMP SES controller MIB file can be compiled with most standards-based MIB compilers.
Refer to Appendix E, SNMP Management Information Base, in the Cisco SES PNNI Controller Software Configuration Guide, Release 1.0.01 for a description of the MIBs supported by the SES controller.
Default Values
There have been no changes.
BXM Firmware MFM Release Notes
About the Firmware MFM
BXM Firmware version M.F.M. 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.M.
Table 13 Front Cards
Model Num
|
Description
|
FW model
|
HW Rev
|
FW Rev
|
BXM-155-4
|
4 port OC3 Line Module (Front Card)
|
F
|
B
|
MFMMFM
|
BXM-155-8
|
8 port OC3 Line Module (Front Card)
|
F
|
B
|
MFM
|
BXM-622
|
1 port OC12 Line Module (Front Card)
|
F
|
D
|
MFM
|
BXM-622-2
|
2 port OC12 Line Module (Front Card)
|
F
|
D
|
MFM
|
BXM-T3-8
|
8 port T3 Line Module (Front Card)
|
F
|
B
|
MFM
|
BXM-T3-12
|
12 port T3 Line Module (Front Card)
|
F
|
B
|
MFM
|
BXM-E3-8
|
8 port E3 Line Module (Front Card)
|
F
|
B
|
MFM
|
BXM-E3-12
|
12 port E3 Line Module (Front Card)
|
F
|
B
|
MFM
|
BXM-155-8DX
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-155-8D
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-155-4DX
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-155-4D
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-622-2DX
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-622-2D
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-622-DX
|
1 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-T3-12EX
|
12 port T3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-T3-12E
|
12 port T3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-T3-8E
|
8 port T3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-E3-12EX
|
12 port E3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-E3-12E
|
12 port E3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-E3-8E
|
8 port E3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-155-4
|
4 port OC3 Line Module (Front Card)
|
F
|
C
|
MFM
|
BXM-155-8
|
8 port OC3 Line Module (Front Card)
|
F
|
C
|
MFM
|
BXM-622
|
1 port OC12 Line Module (Front Card)
|
F
|
E
|
MFM
|
BXM-622-2
|
2 port OC12 Line Module (Front Card)
|
F
|
E
|
MFM
|
BXM-155-8DX
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-155-8D
|
8 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-155-4DX
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-155-4D
|
4 port OC3 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-622-2DX
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-622-2D
|
2 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFM
|
BXM-622-DX
|
1 port OC12 Line Module (Front Card)
|
F
|
A0
|
MFM
|
Table 14 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
|
SMFMR-155-4
|
4 port single-mode fiber long-reach back card
|
A
|
na
|
SMFMR-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
|
SMFMR-622
|
1 port long-reach OC12 back card
|
A
|
na
|
SMFMR-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 MFM
Bug fix only.
New Features supported in BXM Firmware MFK
LCN cac with policing 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. Burn firmware should not be interrupted. Card resets in the middle of burn firmware will result in the BXM being maintained in the core state (Identified by blinking yellow LED), or failed state (Identified by a solid red led). In this case the dspcds screen will report the card as FAILED. This state can be recovered by reburning the firmware into the card.
4. Protection Switching based on BER on BXM may not comply to standards. The GR-253 & ITU-T G.783 requires that switching be completed within 60 msec from the time the error starts. BXM is unable to detect BER threshold crossing until the next poll, which occurs every 250 msec. Thus, switching time may be up to 250 msec under certain circumstances.
5. In APS 1+1 default configuration, both backcard LEDs show green when primary card is active and selection is from PROT line. When primary card is active and it is selecting from PROT, PROT backcard should be green, since it is carrying traffic. WORK backcard should also be green since that is the physical path for the primary (and active) card to pass traffic. So backcard LED green means the backcard is directly or indirectly carrying traffic and pulling the backcard will cause traffic disruption. (CSCdm53430)
6. In APS 1+1 default configuration and a manual W->P is on and a switchyred is issued, a manual W->P event is logged. By default, on switchyred the new active card comes up in "clear" state. But in this case since there is a manual W->P on, the APS line switches to PROT and the switching is logged. (CSCdm53404)
7. In APS 1+1 default configuration if the selected line is PROT and last user request is clear and a switchyred is issued, line switches to WORK. If the last user request is "clear", full automatic APS switching is in effect with the working line being active by default. When there is no last user switch request to switch to any particular line, the working line will become active. (CSCdm53420)
8. When APS Annex B is added to local end which has the Secondary card active, the APS trunk goes into Comm Failure for few seconds and then clears. If Secondary card is active, then do a switchyred to make Primary card active and then add APS Annex B. (CSCdm46359).
9. 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.
10. 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 following upgrade procedures:
–Upgrading from firmware revision MEA or higher
–Upgrading from firmware revision lower than MEA
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.
Known Anomalies
The following is the list of known anomalies for the BXM firmware.
Table 15 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 feeder is provisioned without AR feeder 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 16 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 17 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:
reproducible
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 18 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. Issue either the "rsh <slot> cdcfg netwotk dis" command before the upgrading, or issue the "rsh <slot> cdcfg netwotk ena" command 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 re-synchronize 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 19 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 20 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 at BCC in addition to existing dnpnport at 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 21 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 22 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 in AIS 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 23 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:
None.
|
The following bugs are fixed in MFB.
Table 24 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 the FCES feature is enabled on the BXM, the 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 and 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 documentation to explain 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 25 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:
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:
Enter 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 26 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 sequence W->P, P->W and then W->P, then cause LOS on WORK line and put the cable back, APS switches to working line.
Workaround:
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:
None.
|
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:
None.
|
CSCdm78335
|
Symptom:
dspvsistatus rarely shows the VSI programming status as Done
Conditions:
Primary and secondary port has two different VPI range.
Workaround:
None.
|
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:
None.
|
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:
None.
|
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 0-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 27 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 28 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 29 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 entering the switchyred command, 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 firmware 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
Related Documentation
The following Cisco publications contain additional information related to the operation of this product and associated equipment in a Cisco WAN switching network.
Table 1 SES PNNI Controller Release 1.1 Documentation
Title
|
Description
|
Cisco SES PNNI Controller Software Configuration Guide, Release 1.1
DOC-7813539=
|
Describes how to configure, operate, and maintain the SES PNNI Controller.
|
Cisco SES PNNI Controller Software Command Reference, Release 1.1
DOC-7813541=
|
Provides a description of the commands used to configure and operate the SES PNNI Controller.
|
Cisco MGX and SES PNNI Network Planning Guide
DOC-7813543=
|
Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
|
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following URL:
http://www.cisco.com
Translated documentation is available at the following URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
•Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace:
http://www.cisco.com/cgi-bin/order/order_root.pl
•Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:
http://www.cisco.com/go/subscription
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to
•Streamline business processes and improve productivity
•Resolve technical issues with online support
•Download and test software packages
•Order Cisco learning materials and merchandise
•Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:
http://www.cisco.com
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.
Inquiries to Cisco TAC are categorized according to the urgency of the issue:
•Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.
•Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
•Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
•Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:
http://www.cisco.com/tac
All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:
http://www.cisco.com/register/
If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:
http://www.cisco.com/tac/caseopen
If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.
This document is to be used in conjunction with the documents listed in the "" section.
AccessPath, AtmDirector, Browse with Me, CCIP, CCSI, CD-PAC, CiscoLink, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That's Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, PIX, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0108R)Copyright © 2001, Cisco Systems, Inc.
All rights reserved.
Feedback
