Guest

Cisco BPX 8600 Series Switches

1.0.15 Version Software Release Notes, Cisco SES PNNI Controller

  • Viewing Options

  • PDF (974.2 KB)
  • Feedback
1.0.15 Version Software Release Notes Cisco SES Controller Software

Table Of Contents

1.0.15 Version Software Release Notes
Cisco SES Controller Software

About These Release Notes

About the 1.0.15 Release

Software Release 1.0.15

Service Expansion Shelf (SES) PNNI and SVC Controller

Clarifications

Upgrade from SES 1.0.12, 1.0.13, or 1.0.14 to SES 1.0.15

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.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.15 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.15 Release

The 1.0 software release supports the Cisco WAN switching products: BPX 8600 series with SES controller.

Software Release 1.0.15

Service Expansion Shelf (SES) PNNI and SVC Controller

Release 1.0.15 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, or 1.0.14 to SES 1.0.15

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 to 1.0.15. Boot upgrade can be graceful or non-graceful, depending on the type of card to be upgraded and the configuration of the node.


Note Since SES 1.0.13, 1.0.14 and 1.0.15 are using the same Boot image,(1.0.13, check software compatibility matrix), there is no need to upgarde Boot image if it is upgarded from 1.0.13 or 1.0.14. Please skip the backup boot upgarde procedure and upgarde the run time image. If SES is upgraded from 1.0.12 to 1.0.15, then it requires upgrade the Boot image before the Runtime Image. Please use the boot image from the 1.0.13 Release.


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.013.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.

ses1.1.PXM.a> cc 2

Step 5 From shellConn on the standby card, follow this procedure:

a. Type sh to go to the shellConn.

ses1.2.PXM.s> sh

b. issue sysBackupBoot command.

PXM1> sysBackupBoot

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.

pxm1bkup>sysPxmRemove

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.

pxm1bkup>cd "C:/FW"

Step 8 Enter the ls command to verify that the boot firmware file is there.

pxm1bkup>ls

Step 9 Enter the sysFlashBootBurn boot firmware file name command

pxm1bkup>sysFlashBootBurn"pxm1_001.000.013.000_bt.fw"

a. Enter Y for Yes.

b. When the pxm1bkup> prompt returns, issue the reboot command.

Flash Download completed...
value = 0 = 0x0
pxm1bkup> reboot

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.

ses1.1.PXM.a> switchcc 

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.

pxm1>sysBackupBoot

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.

pxm1bkup>cd "C:/FW"

Step 6 Enter ls command to verify the boot firmware file is there

pxm1bkup>ls

Step 7 Enter sysFlashBootBurn boot firmware file name command.

pxm1bkup>sysFlashBootBurn"pxm1_001.000.013.000_bt.fw"

Proceed as follows:

a. Enter Y for Yes

b. At the pxm1bkup> prompt, enter the reboot command.

pxm1bkup> reboot

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.

ses1.1.PXM.a> dspcd 1

Upgrade the SES PNNI Runtime Image

This section provides instructions for upgrading the Runtime Images from 1.0.12/1.0.13/1.014 to 1.0.15.

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.15 is pxm1_001.000.015.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(15.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(15.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(15.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(15.0)

Step 7 The the dspcd command to verify successful upgrade.

ses1.1.PXM.a>dspcd 1
ses1.1.PXM.a>dspcd 2

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(15.0)

Note No cards will reset.


b. Reply Yes to the proceed question.

c. Enter the dspcd command in the following example:

ses1.1.PXM.a>dspcd 1

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(15.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(15.0)

Step 5 Execute commitrev to commit the new version of Runtime Image of controller card

a. commitrev <slot> <image version>

commitrev 1 1.0(15.0)

b. dspcd 1

ses1.1.PXM.a>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.13 Backup boot, pxm1_001.000.013.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.15 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.14 is compatible with MFM BXM (See Table 1 for more information.)


Notes & Cautions

Limitations

Release 1.0.15 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


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.15

Table  5 PXM Software Bugs 

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  6 PXM Software Bugs 

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  7 PXM Software Bugs 

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:

dsptask 1 2

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  8 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  9 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  10 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  11 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  12 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  13 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  14 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  15 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  16 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  17 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  18 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  19 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  20 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  21 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  22 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  23 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  24 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  25 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  26 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  27 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  28 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.

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.