2.0.01 Release Notes for MGX 8850 Software

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

Phased Release Strategy

This is a first release of PXM45 and AXSM. Future releases are planned to add new feature contents.

Software Release 2.0.01 and Related Hardware

AXSM Cards

The AXSM is a double height ATM service module that is compatible with release 2.0 and later PXM45 based versions of the MGX. The AXSM uses the serial line traces on MGX chassis to access the 45Gbp crosspoint fabric of the PXM45 and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.

The AXSM provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM on the IGX, and AUSM of the release 1 MGX8850. Other Cisco ATM platforms, and other ATM manufacturers equipment have proven to be compatible.

Line Interfaces for the AXSM Cards

ATM Layer Information

Network Management Features

The AXSM offers a complete ATM feature set and allows the MGX8850 to scale to the core of service provider networks from the T3/E3 edge to the OC48c core. Full line rate is achieved through the use of the serial line traces on the MGX8850 platform. The entirely standards based design and connection protocols enables the installation into any existing network, as well as building new ATM infrastructures.

PXM 45 Cards

The PXM-45 is a 45Gbps processor switch module. The architecture of the PXM-45 contains the CellBus fabric that is used in the current PXM-1, but adds the functionality of a 45Gbps cross point switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX8850. The PXM-45 provides a Stratum3 central clocking circuit conforming to GR-1244 and G.813 specifications. This is an improvement over the Stratum4 based PXM-1 design.

Reliability, Availability and Serviceablity (RAS) Features

The PXM-45 is designed to be fully redundant, there are two dedicated slots in the 8850 (dual height slots 7 and 8) that will house the PXM-45. Highlight of the RAS features are listed below:

•

Switchover from active to standby is designed to result in no cell loss with the exception of cells that are physically on the fabric at the time of the swap.

•

In-band arbitration/grant mechanism ensures that service module failure does not stop traffic flow

•

Hardware design to ensure that if one or both hard disk fails, the cards will still pass traffic with no interruption, although provisioning could be suspended.

•

MTBF Goal is calculated using a 99.9999% availability model which assumes two PXMs in a system. This was calculated at greater than 100,000 hours.

PNNI

The PXM-45 will support PNNI software. There are two other components that make the complete card set these are:

•

Two RJ45 RS232 Data Termination Equipment (DTE) ports that can be Y cabled. Pinouts are as follows:

Pin	Signal	Direction	Description
1	RTS	OUTPUT	Request to Send
2	DTR	OUTPUT	Data Terminal Ready
3	TX	OUTPUT	Transmit Data
4	SG		Signal Ground
5	SG		Signal Ground
6	RX	Input	Receive Data
7	DSR	Input	Data Set Ready
8	CTS	Input	Clear to Send

•

Two DB9 T1/E1 BITS input, with converted cables that can be Y cabled. The followingconnections are supported:

•

One DB15 Alarm interface. Contacts are normally open. This interface can be Y cabled.

PNNI

Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and will scale to very large networks.

PNNI includes two categories of protocols. PNNI defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI topology and routing are based on the well-known link-state routing technique.

PNNI also defines a second protocol for signaling, that is, message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI 4.0 signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure. Whereas the UNI signaling protocol distinguishes between the user and network sides of a connection, PNNI is a symmetrical protocol.

PNNI provides dynamic ATM routing with QoS support as defined by the ATM Forum. PNNI uses link-state and source state route technology, supports aggregation for private ATM addresses and links between switches, and has the ability to scale the network and its performance by means of configuring PNNI peer groups and hierarchical levels. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology.

•

Enhanced CAC with per service class policy parameter (See separate feature description)

PNNI networks are highly resilient due to their ability to quickly reroute connections around failed network elements, and to update routes and network topology based upon availability of network resources. Connections will generally route quickly using pre-computed routing tables, but in the case of congestion or during a network failure, on-demand routes will be calculated for connections.

Special Installation/Upgrade Requirements

General

SCT Files

Upgrade Procedure

Loading the runtime images from 2.0.00 to 2.0.01

Due to bug CSCdr50312 (see section Known Anomalies) graceful upgrade will not work with this image.

Former active card should now be the standby card. When it is in standby status, upgrade its boot code.

Features Not Supported

Committed (but not delivered in this release)

Connection density: 50K connection per node is not supported.(25K connections per node are supported with Limitation listed below).

Obsoleted

Notes & Cautions

The following CLI commands were changed since publication of user documentation. Reason for the change is to make these commands consistent with other products.

Some of the available bandwidth is used by signaling (PNNI rcc, SSCOP and ILMI).

The database stores the backplane serial number and backcard serial numbers. Therefore if cards are moved from one node to other, console will display "SHM Alert !! Alert!!" . The first time a PXM is brought up in a shelf, a default database is created. The backplane, hard disk, and the UI backcard serial numbers are recorded as part of this database. A PXM nativity check is run when the PXM is coming up. This check will produce an SHM alert failure message if some of the serial numbers do not match. The serial numbers will not match if the card has been previously installed in another shelf. The mismatched serial numbers will trigger the following message:

Documented	Implemented	Purpose
addchan	addcon	Add SPVC endpoit
cnfchan	cnfcon	Change parameters of SPVC
delchan	delcon	Delete SPVC endpoint
dspchans	dspcons	Display all SPVCs in the node
dspchan	dspcon	Display a specific SPVC

Step 1

Enter shmFailDisplay. The display table will show that BRAM is not native.

Step 2

Enter shmFailRecoveryHelp. This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is shmRecoverIgRblDisk.

Run the last shellconn command to get the failure resaon, typically the BRAM Non Native message.

•

For redundant PXM systems, if you see this on the standby card, execute the sysClrallcnf command on the standby card.

It is possible to add ports at cell rate fractionally higher than maximum line rate. This may cause cell drop.

Limitations

Support for 25,000 connections per node with limit of 25,000 connections per NNI. Also note following bugs under "known anomolies" section :

Cannot change card SCT without deletion of all connections, partitions and ports

To replace one type of AXSM card with other type, it is required to delete all connections, partitions , ports and down lines. In case of AXSM card failure, same type of AXSM card must be istalled in that slot.

If port(s) and trunk(s) are configured on same AXSM card and port level failure occurss, it will cause SPVC deroutes.

Connection statistics at CLI and Bucket level is not available in AXSM-1-2488 cards. However, connection debug statistics are available in all types of cards.

For PXM45, clock synchronization in E1 sync mode is not supported (T1 and E1 in data mode is supported).

OC48 BC intermittently fails to detect the optical input after power recycle. If this happens, theback Card should be reseeded.

Release 2.0.01 System Content

Switch Software and Boot Codes

Hardware Products

Known Anomalies

The following is the list of known anomalies in this Switch Software delivery. Included with each is a brief discussion of the problem. A more in depth discussion is available in the release note enclosure of the problem record in Bug Navigator.

Model	800 Part Number	Revision
PXM45	800-06147-05	A0
PXM-UI-S3	800-05787-01	A0
PXM-HD	800-05052-03	A0
AXSM-1-2488	800-05795-04	A0
SMFSR-1-2488-FC	800-05490-05	A0
SMFXLR-1-2488-FC	800-05793-05	A0
SMFLR-1-2488-FC	800-06635-04	A0
AXSM-16-155	800-05776-05	A0
AXSM-4-622	800-05774-07	A0
AXSM-16-T3/E3	800-05778-07	A0
SMFIR-2-622	800-05383-01	A1
SMFLR-2-622	800-05385-01	A1
SMB-8-T3-BC	800-05029-02	A0
SMB-8-E3-BC	800-04093-02	A0
MMF-8-155	800-04819-01	A1
SMFIR-8-155	800-05342-01	B0
SMFLR-8-155	800-05343-01	A1


Bug ID	Description
S1 Bugs
CSCdr15133	Symptom: Many [vsierr] messages and [egress ConnID delete failure] messages are reported by the card hosting EP2_UNI_PORT_ON_TRK. Condition: (1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2). (2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1. (3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2. (4) There are 20K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. ( 5) Another UNI port (EP2_UNI_PORT_ON_TRK) is present in NODE_EP2 using the same AXSM card which also provides the lines as trunks between NODE_VIA and NODE_EP2. (6) There are 5K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORT_ON_TRK. (7) All these 25K (=20K+5K) SPVCs are routed through one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other trunk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed. (8) A [uppnport] is executed to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA. (9) A [dnpnport] is executed to TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA. This forces ALL 25K SPVCs to be rerouted to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA. Workaround: One of the following: (1) Move the 5K SPVCs from EP2_UNI_PORT_ON_TRK to EP2_UNI_PORTS. (2) Reduce the number of SPVCs from 25K to 10K. (3) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
CSCdr15197	Symptom: Some applications were holding a large number of unreleased buffers Condition: On a node with 10K SPVC and 1K SVC, after a number of switchcc, it was found that a application, pnsscop was holding many buffers (leaking). Workaround: None
CSCdr15911	Symptom: Changing the backcard may sometimes cuase the front card to reset and loss service. It may occasionally difficult to bring up the AXSM. Conditions: This problem happens occasionally when someone reseats the backcard several times, the front card is reset. It is also observed that during power on/off testing, sometime the PhyTask got suspended. Workaround: Try not to reseat the backcard too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.
CSCdr19636	Symptom: When there is mismatch between the dsplns alarm status and dspalms output. Condition: On a T3 card, if one side of the line is configured as adm mode and another as plcp mode, then the lines go into alarm. dsplns shows the lines in critical alarm, but dspalms or dspalm -ds3 on one of the lines says clear. Workaround: On the line that has plcp enabled use dspalm -plcp bay.line to see the alarm. The problem has now been fixed in such a way that even dspalm -ds3 bay.line on a plcp line will show its plcp alarm status.
CSCdr20887	Symptom: After the trunk card comes back from reset, vsierr 0x5017 messages and [egress ConnID add failure] messages are observed. Condition: (1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2). (2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1. (3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2. (4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other turnk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed. (5) A [uppnport] is executed to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA. (6) Reset this trunk card (hosting TRK_A & TRK_B) while in [down in progress] state. Workaround: One of the following: (1) Do not reset trunk card while rerouting takes place. (2) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
CSCdr22185	Symptom: VsiErr message with a string explaining the error such as "Interslave timeout" and others get displayed; these messages are indications of a recoverable condition and are not meant to be displayed. Conditions: These messages can show up when the system is under stress, such as on system rebuild, and VsiErr due to real errors are meant to be displayed, but instead warning VsiErrs are displayed Workaround: None
CSCdr22569	Symptom: ABR connections fail. Condition: There are parallel links at via node(s) to the next node on the routing path (DTL) of an ABR connection. Workaround: Don't configure parallel links at via nodes
CSCdr23168	Symptom: Resetting the AXSM UNI card in the edge node while the PNNI is establishing connections on it might intermitantly cause the tVsiSlave task to crash on the AXSM UNI when it eventually comes up. Conditions: (1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2). (2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1. (3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2. (4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks. (5) Reset NODE_EP1. (6) While SPVCs are being established (about 15K), reset the AXSM UNI card. (7) After the AXSM has come up, a lot of VsiErrs are observed, and then the tVsiSlave task crashed. Workaround: (1) Do not reset the UNI AXSM while the PNNI is rebuilding the connections.
CSCdr34387	Symptom: A few SPVCs are not seen after resetsys. Not all SPVCs on any one interface have been lost. Condition: Happens when a node is fully loaded to 50K connection capacity. WorkAround: Avoid connection addition during heavy connection re-routing, link status changes. After the problem has occurred - SPVCs can be re-added.
CScdr35241	Symptom: After reseting the AXSM (UNI) card in endnode, and performed pxm45 switchover while the port is still in down in progress, once the AXSM card is up, and all uni ports are in "up" state, vsi error 0x502a (connection reserve failure) are observed. Conditions: (1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2). (2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1. (3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2. (4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks. (5) Reset the UNI card in NODE_EP1. (6) While the port is in "down in progress" state, perform pxm45 swithover. (7) VsiErr 0x5017 are observed once the UNI AXSM card is up and all UNI ports are in "up" state. Workaround: One of the following: (1) Do not perform pxm45 swithover while any of the UNI port is in "down in progress" state. (2) If the failure has already occured, rectify this problem by resetting the UNI card.
CSCdr36772	Symptom: Bucket statistics file name has incorrect file name. Conditions: Suppose the file is created at 5:30 it will have a time of 5:15. The interval is 15 to 30 min. This means that the beginning time is used instead ofthe ending time. WorkAround: None.
CSCdr36954	Symptom: VC Failure due to insufficient LCNs used up by the user conns. The port stays in VC failure forever. Conditions: When more SPVCs are provisioned than the available LCNs, the port could go into VC failure upon few resets on the controller or the Slaves. This happens because of failure conditions to establish connections and if user connections could be established before the control VC connections. Workaround: Never provision more than the available LCNs.
CSCdr37025	Symptom: Some of the provisioning command operation does not get reflected on standby and disk. Condition: When there are many spvcs are getting added/deleted/modified within ver short period of time and also at the same time many ports status is oscilatting between up and down in that case this may happen. Work Around: When port status is oscilating, do not add/mpdify/delete spvcs on it.
CSCdr37302	Symptom: Unable to ping/telnet to the node intermittenly. Conditions: This problem occurs in a redundant PXM node. When ping the node from a workstation, the ifShow command shows that the receiving packet counts is inrementing while the send packet counts remains the same. Workaround: Reconfigure the interface with the same IP address again using command
CSCdr38809	Symptom: After restoring the configuration using restoreallcnf command, and controller card switchover happend, the some of the SPVC end points may be missing and/or the attributes of some of the VCs may be changed. Condition: When restoreallcnf is performed, the configuration on the disk is overwritten by the restored configuration on the Active controller card and the configuration needs to be cleared on the Standby controller card before it could synchronize the configuration with that on the Active controller card. This clearing of configuration on the Standby controller card is not done as a part of restoreallcnf. This causes the problem. Workaround: You need to clear the configuration using clrallcnf before restoring the configuration. You should make sure that the Standby controller card is in operational state when configuration is cleared. If the Standby controller card is not in operatinal state when clrallcnf was performed on the node, you should clear the configuration on the Standby controller card when the card is in the boot state using sysClrallcnf command.
CSCdr39120	Symptom: Reset of AXSM cards and switchover will cause SPVC to reroute. Condition: When ILMI is turned on the AXSM, when reset the Peer ILMI module will trigger a Loss of Connectivity and all the calls on the interface will be derouted. Workaround: If Using Orion 1.0.x or P-II 2.0.x, disabling the Securelink procedures will not allow the calls to be derouted (cnfilmiproto command can be used to turn off Secure link on a port basis). If not using the above, there is no workaround as secure link is enabled on NNI/UNI links. pxm1Cli> cnfilmiproto <portid> -securelink no - turns off the securelink on the NNI trunks. By default its turned on for all the interfaces.
CSCdr40126	Symptom: If there are more than 31K connections on a single AXSM in a VIA node, the connections on the AXSM are not deleted when PNNI deroute the connection. Conditions: (1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2). (2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1. (3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2. (4) There are 31K+ SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks. (5) Down either of the trunk connecting either NODE_EP1 or NODE_EP2 to the NODE_VIA to cause connections deroute. After the deroute completes, it was observed that the connections in the NODE_VIA are not deleted, and no error were observed. Workaround: (1) Restrict the number of connections on the NODE_VIA to less than 31K. This can be done by configuring the partitions for NNI trunks on the NODE_VIA to support less than 31k connections (combined).
CSCdr40620	Symptom: NO SPVCS. After PXM rebuild some interfaces might disappear. WITH SPVCS Every time PXM card (both cards in case of redundancy) is rebooted, Node cannot come up. pnRedman may be in exception. Condition: If any image built between Apr 21, 2000 & Apr 29, 2000 had been used in a node, then there is a possiblity for data base corruption, which will lead to this problem. Workaround: No workaround.
CSCdr43257	Symptom: Some of connections are not routed. Route trace shows that no route found because no enough bandwidth. Since the network is very complecated (113 nodes + 300 links), it is very difficult to issolate the problem. It may or may not be a bug. It need to be investigated with enhanced trace utility. Conditions: Large network: (113 nodes + 300 links) Workaround: Increase bandwidth (cell rate, LCN, links) on critical path.
CSCdr43665	Symptom: The call does not routing with VPI/VCI assignment error. Condition: When you have big number of calls (around 16K) in one interfaces and switch-over. Workaround: Do not do switch-over when call is in progress and # of calls is around 16K.
CSCdr45695	Symptom: Could not run "dspln", dspports, etc. Could not walk mib tables. Conditions: The "dsplog" CLI output might contain following message: 01-00127 05/12/2000-11:14:26 MIBS-4-SEMTAKE_FAILED E:06412 snmpSA 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe. tSmCmdTskcl: doMibTbls(): Can't get resrc semaphore.: Err from snmpMibSemTake 01-00104 05/12/2000-09:21:54 MIBS-4-SEMTAKE_FAILED E:06409 tSmCmdTskc 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe. Work around: The Card which has this problem(dsplog -sl <x> has the above message) will have to be reset.
CSCdr46104	Symptom: Exception in pnCcb task causing the active processor to reset. Condition: Observed on derouting and rerouting SPVCs over an IISP link. Workaround: None.
CSCdr47947	Symptom: After reseting the AXSM (UNI) card in endnode, and performed pxm45 switchover while the port is still in down in progress, once the AXSM card is up, and all uni ports are in "up" state, vsi error 0x502a (connection reserve failure) are observed. Conditions: (1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2). (2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1. (3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2. (4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks. (5) Reset the UNI card in NODE_EP1. (6) While the port is in "down in progress" state, perform pxm45 swithover. (7) VsiErr 0x5017 are observed once the UNI AXSM card is up and all UNI ports are in "up" state. Workaround: One of the following: (1) Do not perform pxm45 swithover while any of the UNI port is in "down in progress" state. (2) If the failure has already occured, rectify this problem by resetting the UNI card.
CSCdr50312	Symptom: Standby card will be reset and come back in the higher revision ( 2.0(1) ) The card will then transition to the failed state. Conditions: Upgrading gracefully ( through the loadrev command ) on the PXM with redundancy available ( 2 PXMs in the node ) between release 2.0(0) and 2.0(1) Workaround: Do a non-graceful upgrade by using the setrev command This will cause the PXMs to be reset and come back in the higher revision setrev 7 2.0(1)
CSCdr19861	Symptom: Lot of VsiErr messages appear on the console. Conditions: (1) In a two node PNNI network with 2 NNI trunks, one with OC48 and other with OC-12 link. (2) Add connections beyond OC-12 capacity into the OC-48 trunk. (3) Reset the Node, if the OC-48 trunk comes up in the down state, or if the OC-48 is downed, the connections get re-routed to the OC-12 trunk. (4) If the bandwidth capacity of the exceeds the OC-12 trunk, AXSM will reject the connections commit request beyond the interface capacity. (5) PNNI tries to PACK in as many connections as possible into the OC-12 trunk. Some of the connection ADD requests are rejected by CAC. Workaround: (1) Use trunks of the same link capacity.
CSCdr25037	Symptom: Many [vsierr] messages and [egress ConnID add failure] messages are reported by the trunk card on NODE_EP1 while the rebooted UNI card does NOT have error messages. Conditions: In a three-node network with two nodes (NODE_EP1 & NODE_EP2) connected directly as well as via a third node (NODE_VIA), approximately 5000 SPVCs are added between NODE_EP1 and NODE_EP2. All of these AXSM cards operate in stand-alone (e.g., non-redundant) mode. The UNI card in NODE_EP1 is rebooted (by resetcd from PXM45 or ESC-CTRL-X). Immediately after the PXM45 console reports the insertion of the UNI-AXSM, a [switchcc] command is issued. Workaround: One of the following: (1) Do not [switchcc] at all. (2) Do not [switchcc] until the rebooted UNI-card is burning the flash (by observing a few cycles of [burning xxxxx verify ... ok] messages) (3) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
CSCdr26669	Symptom: This problem rarely happens. link presents with 2WayInside state, but no route through that link found. Conditions: Parallel PNNI links between adjacent nodes. Workaround: Down then up the link.
CSCdr27033	Symptom: Clock source does not revert back to primary bits clock when revertive mode enabled. This can also appear in the form that clock is not switched to a valid clock source that should have a good clock signal. What is really the case is that the clock source has been previously declared as unuseable/unlockable by the clock source manager. This clock source will not be chosen again until after clock source reconfiguration. Condition: The clock source manager is the traffic cop for maintaining the correct/best clock source and managing the state of all clock sources. To make sure that the current clock source is valid, frequency and phase error tests are continuously run on the clock source. Should there ever be a sample that shows invalid frequency or phase error, the clock source is placed into "out of lock" state and a more intensive test is done on the clock source. If this intensive test shows enough failure, the clock source is declared unlockable. To determine if a clock source has been labelled as unuseable, there are two methods: 1. From shellconn issue command nclkm_status. Look for the MUXA/MUXB "programmed as" lines of the display. If the source is programmed as "TOP SRM", it has been labelled as unuseable. 2. From shellconn issue command dspclockinfo. If clock source is configured but programmed to NULL, then it is labelled as unuseable. (NOTE: This display is in the process of change to be more clear about this special clock source state.) Workaround: Reconfigure the clock source, even if it is to the same exact configuration to clear the unlockable state. Use cnfclksrc command.
CSCdr27718	Symptom: The SSCOP, PNNI protocol states would not be in Established state, two_way inside respectively. The protocol PDUs will be discarded at SAR level. Conditions: When an UNI/NNI interface is configured on the Line card. Workaround: If the problem persists for sometime, bring the interface administratively down and then administratively UP.
CSCdr28767	Symptom: The SSCOP, PNNI protocol states would not be in Established state, two_way inside respectively. The protocol PDUs will be discarded at SAR level. Conditions: When an UNI/NNI interface is configured on the Line card. Workaround: If the problem persists for sometime, bring the interface administratively down and then administratively UP
CSCdr28772	Symptom: Some pnni ports with ILMI on go down temporarily and come up. The calls are derouted and rerouted back. Condition: This happens on a large network which has 50k spvc endporints. The node has at least 14 trunks spread accross 6 BXM cards. Pull out one of the cards and re-insert the card. Workaround: This is temporary glitch on few nni ports. This happens intermitently. There is no work around yet.
CSCdr29013	Symptom: Much lower via node reroute rate when attemping to reroute SPVCs at a higher call rate than nodal setup msg congestion threshold value. Condition: When massive SPVCs are being rerouted because of resetting some nodes in the network or when trying to setup SVC connections at a very high call rate. Workaround: Try not to exceed call setup rate of 100calls/sec for SVCs or SPVC reroute at this stage. Additional Information: Root cause of the problem has already been identified; with the fix, call setup acceptance rate is going to be stablized around the nodal setup msg congestion threshold, not going to drop dramatically when call attempting rate goes higher.
CSCdr31492	Symptom: Some of the connections remain in fail state. Condition: Execute dnpnport on an NNI interface, it goes into down in progress state. Before the interface goes into the down state reset the AXSM having some endpoints that go through the NNI which is in down in progress. (Assuming the AXSM doesnot conatin that NNI interface). Workaround: This problem is not yet solvet it has no known work around.
CSCdr34225	Symptom: Cell drops are noticed on OC3 with default line rate. Conditions: The line rate specified for OC3 is 353208 cells/sec. But, infact it is 353207.55 cells/sec. So cell drops are noticed if traffic is pumped in at 353208 cells/sec. Workaround: Use following rates( cells/sec )as max line rate for: Max rate for OC3: 353207 Max rate for OC12: TBD Max rate for T3 and E3: TBD Max rate for oc48:
CSCdr34707	Symptom: Calls will not go through. Condition: The address PTSE is present in the database but the address is not present in the network reachable address table. WorkAround: None.
CSCdr34851	Symptom: After addpart with incorrect parameters, the partition gets added on AXSM, but dsppnports on PXM45 either doesn't show the port, or it shows the IF status as provisioning. After delpart, dsppnports shows the IF status up for the port on the PXM45, although dspparts on the AXSM doesn't show the partition anymore. There is no error message displayed. Conditions: Two conditions seen in our lab that caused this problem: - clock configured on the line associated with the partition, delpart doesn't fail, but partition removed from the database, but PNNI doesn't get informed of partition delete - tried to add partition on a vnni port with incorrect vpi range, partition added to the database, but PNNI doesn't get informed of the partition add Workaround: Workaround after the conditions are seen is to do resetsys on PXM45.
CSCdr36903	Symptom: ILMI fails to transition to a steady state and PNNI ports may not come up. As a calls might fail to route or use another available heathy trunk. Conditions: PXM switchover with ILMI enabled. If the ILMI protocol across the peer have not reached a steady state this problem has been noticed intermittently. Workaround: dnpnport and uppnport the affected port(s) after the switchover is complete.
CSCdr39329	Symptom: Few connections will be in fail state at one end point(either master end or slave end) Conditions: This happens when a large number of connections are established and then some line cards are reset. Workaround: None Additional Information: If the problem persists, attempt reroute for the failed connections from CLI
CSCdr39684	Symptom: Cannot display link selection configured on PNNI port. Conditions: ILMI (auto-config) is enabled on the port. Workaround: disable ILMI (auto-config) on PNNI port.
CSCdr39892	Symptom: The symptoms of this problem is that all traffic that is coming into the axsm card is being discarded. Specifically, ingress traffic does not go into the switch planes and since the queues in the QE48 gets full, the incoming traffic reaches the maximum cell threshold and all cells are discarded. Conditions: This problem may occur if the axsm card experiences multiple (more than 32) switch plane errors. Switch plane errors such as lost of sync, code violation, crc error, disparity error. Since switch plane error may occur during pxm45 switch cc's, this problem may also occur during pxm45 switch cc's. Workaround: Reset the axsm card that is not passing traffic.
CSCdr40167	Symptom: User see sometimes SPVC fail to route spvc connection on AXSM card resets Condition: Repeated AXSM card resets on the POPEYE2 node OR repeated BXM card resets on BPX node Workaround: none
CSCdr40333	Symptom: User did not have the granularity to find out why the clock when bad. Condition: A clock can go bad due to excessive jitter, high frequency, etc. Workaround: User would have to go to the clock source and verify functionality with the source equipment to find out the reason.
CSCdr40484	Symptom: User did not have the granularity to find out why the clock when bad. Condition: A clock can go bad due to excessive jitter, high frequency, etc. Workaround: User would have to go to the clock source and verify functionality with the source equipment to find out the reason.
CSCdr40821	Symptom: Some SPVC conns are in AIS-FAIL in standby Conditions: a. resedcd (PXM or BXM) b. dnpnport/uppnport (PNNI trunk) c. rebooting via nodes Workaround: switchcc the PXM.
CSCdr41012	Symptom: Ports go to Down in Progress after Reset/Downing the AXSM. This is due to failure to resync the connections. Conditions: When large number of connections are to be resynced after a line card recovery, the control connections (signalling and routing) fails to be reinserted. Workaround: None.
CSCdr41170	Symptom: After changing T3 line framing mode from ADM to PLCP, continuous vsi error messages are reported on ASXM. Conditions: Existing connections have used up all bandwidth corresponding to ADM framing mode (104268 cps). Workaround: When T3 framing mode is changed, check if the new line type cell rate is less than the SG rate sum of existing SG belonging to the line. If so, reject the command.
CSCdr41708	Symptom: After the switchover, the new active Pxm still shows that the above inserted backcard is still missing. This will eventually cause an extra switchover when a healthier standby Pxm is ready. Conditions: If inserting a backcard into the standby Pxm's slot resulted in making the standby Pxm the healthier card, the standby Pxm will be made that active Pxm. Workaround: If backcards on both Pxms are missing/bad, always replace/insert the backcard on the active Pxm first. This will not trigger the above switchover and bug.
CSCdr42075	Symptom: port(s) in "vc failure" Conditions: Have svc calls, with active and standby pxm. Pull the active pxm and reset card, causing switchover. Workaround: None.
CSCdr43945	Symptom: One can exceed the peak cell rate upto line rate thereby starving all resources to other connections. This is due to the fact that OAM and RM cells do not get policed. Conditions: Add a connection and pump non-user-data cells e.g OAM/RM cells using a tester or CPE. Workaround: For policing complience test use User data cells only.
CSCdr44255	Symptom: Svc call on uni port getting released. Conditions: Make a svc call on uni(3.0/3.1) port using a tester. Pullout and put back the cable between the node and tester within 10sec(T309). Woekaround: This problem occurs alternately. There is no work around yet.
CSCdr44537	Symptom: The connection does not pass the data traffic. Condition: The UBR SPVC provisioned with PCR=0 and resync happened. Workaround: Do not provision pcr=0. Reactivate the connection using dncon/upcon command.
CSCdr44566	Symptom: Dax connections are in FAIL state Condition: Did a resetsys on the PXM Workaround: Check the endpoint interface, do a dnpnport and uppnport on those interfaces, the connection should be in ok state
CSCdr45063	Symptom: The address or address prefix associated with a PNNI node at a lowest level peer group, if not summarized by any of the default or configured summary address, may sometimes be failed to be advertised arocss the peer group boundary even when its advertising scope is wide enough. Conditions: Assuming a hierarchical PNNI network originally works fine with an address A that associated with a node N at the lowest level, and A is seen as advertised across the peer group boundary just fine. Reboot the node N and A may be missing across the peer group boundary, when the identifier of the address PTSE for A differs from the one before the reboot. Workaround: The root of the problem has been found and a fix has been put in and verified as a correct resolution. In this fix, the PTSE ID is now stored in the local reachable address Trie of a LGN, along with the node index of the node at the child peer group. As such, the identification of a given entry in the local reachable address Trie includes both the node index of the node and the PTSE ID at the child peer group. Note this handling is the same as already existed for network reachable address Trie.
CSCdr45896	Symptom: 1. The problem is not observable, but the problem can be identified/observed when the traffic parameters are verified by doind "dalConnParamsShow" after de-routing the connections from one trunk to another on a different card Conditions: 1. 2 Node PNNI network 2. 2 AXSM trunks on 2 different cards 3. De-Route connections from one trunk to another trunk in another card Workaround: Don't de-route/re-route conns between trunks across trunks on different cards. Use multiple trunks if needed on the same card.
CSCdr45962	Symptom: Some SPVC conns are in AIS-FAIL in active PXM after switchover Conditions: After multiple switchover of PXM Workaround: issue following command on shellconn of newly active PXM. For axample, pxm1> conProEnableConnTrap conProEnableConnTrap
CSCdr46262	Symptom: When switchover occurs, all the master / slave endpoints are attempted to route / half commit, and it will hit congestion, which will not recover dspnodalcongflags will show connpendingflg set to TRUE. Condition: 1000s of non routed master / slave SPVCs are configured on a port which is operationally down. & switchover occurs. Workaround: Manual Switchover : Do not try switchover Automatic Switchover : None
CSCdr46945	Symptom: The PNNI main task is looping when calling pnni_delete_db_ptse() for a horizontal link. Conditions: The PNNI main task loops infinitively in the function pnni_delete_db_ptse() when the PTSE deleted is a horizontal link. Workarounds: None
CSCdr47590	Symptom: After Switchover Standby(newly active) doesn't have the same number of SPVCs as Active had before. Condition: When we have failure on AXSM or some port which has many thousands SPVC. WorkAround: None
CSCdr47777	Symptom: After rebooting AXSM or BXM card, the OC3 sonet alarm are reported on both AXSM and BXM. Conditions: When connecting OC3 trunk between AXSM and BXM, if the AXSM or BXM card is reset, OC3 sonet alarms are reported on both BXM and AXSM. AXSM reports red alarms while BXM reports yellow alarm. Workaround: Physically pull out the Tx cable from BXM and reinsert it.
CSCdr48075	Symptom: CWM has difficulty understanding the contents of a SNMP trap when retrieved from the RTM MIB. Conditions: The robust Trap Manager Mechanism support from an MGX8850 is not properly working. An additional internal data structure is being prepended to the SNMP Trap PDU. Workaround: There is no known workaround.
CSCdr50497	Symptom: dspsct command does not display proper information. Conditions: dspsct to display content of an SCT file in PXM Disk. Workaround: If the SCT is already applied to an active port/card, use dspcdsct or dspportsct command to display the contents of the sct. For the SCT files not applied to any port or card, there is no workaround available on MGX platform. Use CWM to display contents of such SCTs.
S2 Bugs
CSCdm87251	Symptom: When multiple applications are sending IPC message with urgent option, the sequence of these urgent messages are not maintained by the receiving task. However, the sequence of urgent messages from the same sending task will be maintained. Condition: When multiple applications are sending IPC message with urgent option, the sequence of these urgent messages are not maintained. Workaround: don't use this option until the feature is supported. Currently no applications are using this 'urgent' option. Note: If a sending task does not have to maintain sequence of urgent messages with other task(s), i.e., sequence only needs to be maintained on a per-source task basis, then this urgent option can still be used. Only if multiple sending tasks are sending one stream of urgent messages which need to retain the order when they arrive at the receiver task, then it may create a race condition until this feature is supported. Workaround: None
CSCdr06568	Symptom: Trap number 60061 not received by CWM when AXSM T3/E3 self test fails. Condition: This trap is not supported at this time. Workaround: None
CSCdr07794	Symptom: The "task NwClockMgr is suspended" is seen on the PXM console. Clocking services are not available when the NwClockMgr is suspended. Condition: Resetting the PXM or reseating the UI backcard can trigger the network clock manager to suspend. Workaround: Reseating the UI card, follow by resetting the PXM card may resolve this problem.
CSCdr19400	Symptom: VSIM on the edge-node stops communicating with the slave when the via node is reset. Condition: It is found that VSIM stops communicating with its slave when the via node is reset or ILMI downed. It is found that VSIM has exhausted all the IPC buffers and there are no more IPC buffers to use. It has manifested in the timer handling functions not working (not being invoked) and thus VSIM is sitting idle without taking any actions. VSIM keeps all the messages Queued up in it's databases and no actions are being taken. Workaround: Reset the node.
CSCdr19527	Symptom: OC3 UNI port down in progress after multiple dnport/upport and switchcc Condition: The two-node was configured with 10K SPVC conns. 1. resetcd each AXSM card in order. 2. Sleep about 1000 seconds 3. dnport 1/upport 1 on OC3 cards ten times for two nodes. 4. switchcc on one node (B1b) 5. repeat step 1 again. Workaround: dnport 1/ upport 1 again, if this doesn't work then reboot PXM
CSCdr19861	Symptom: VsiErr Messages appear on the console. Condition: (1) In a two node PNNI network with 2 NNI trunks, one with OC48 and other with OC-12 link. (2) Add connections beyond OC-12 capacity into the OC-48 trunk. (3) Reset the Node, if the OC-48 trunk comes up in the down state, or if the OC-48 is downed, the connections get re-routed to the OC-12 trunk. (4) If the bandwidth capacity of the exceeds the OC-12 trunk, AXSM will reject the connections commit request beyond the interface capacity. (5) PNNI tries to PACK in as many connections as possible into the OC-12 trunk. Some of the connection ADD requests are rejected by CAC. Workaround: Use trunks of the same link capacity.
CSCdr19985	Symptom: Sometimes some of ports (with ILMI on) going to ILMI query status and ILMI state becomes Undefined state. Condition: 1. Remove the active PXM45 card, switchover takes place. 2. Reinsert the PXM45 card back. 3. Display the ports. Workaround: Down the port and then up the port.
CSCdr21366	Symptom: VPC route optimization does not work. Condition: If the Route Optimization vci range configured using cnfrteopt is set to 0..0 to apply route optimisation to only VPC conns, the path connections will not be optimized. Workaround: Set a VCI range larger than VPI range.
CSCdr23821	Symptom: Memory allocated by snmpSsiMalloc() is not freed intermittently. Condition: 1. ILMI session is configured for the partition 2. ILMI session is active 3. On AXSM CLI execute the dnport command followed by upport on the logical port where ILMI session is running Workaround: Avoid dnport upport on the port where ILMI session is active.
CSCdr24083	Symptom: Once the primary clock comes back, the switch should not move to primary clock source. User sees the switch moving to primary clock. Condition: When the primary configured clock source is external BITS clock and is configured as non-revertive, if this clock goes bad, the switch automatically selects secondary clock source. Workaround: None
CSCdr24332	Symptom: The node is not using the configured clock. Condition: When the user configures a clock source on the node, the node tries to lock to the configured clock source. Once the clock is locked, it monitors the locked clock source. For some unknown reason, the switch is unable to maintain the lock to the configured clock source for a long period of time. When this happens, the node switches to default clock on the PXM card. Workaround: None
CSCdr24874	Symptom: Set maxbw to 0 for nrtvbr returns error Switch rsp ret failure Condition: Using the command cnfpnportcac to specify maxbw (maximum bandwidth in percentage) returns an error for the CLI command. For an nRT VBR, it is treating the same way as CBR connection and the modification to maxbw to 0 is returned as an error. Workaround: The control VCs need to be disabled before setting maxbw to zero. This can be done by disabling SSCOP/PNNI/ILMI.
CSCdr25037	Symptom: Many [VSIERR] messages and [egress ConnID add failure] messages are reported by the trunk card on NODE_EP1 while the rebooted UNI card does NOT have error messages. Condition: In a three-node network with two nodes (NODE_EP1 & NODE_EP2) connected directly as well as via a third node (NODE_VIA), approximately 5000 SPVCs are added between NODE_EP1 and NODE_EP2. All of these AXSM cards operate in stand-alone (e.g., non-redundant) mode. The UNI card in NODE_EP1 is rebooted (by resetcd from PXM45 or ESC-CTRL-X). Immediately after the PXM45 console reports the insertion of the UNI-AXSM, a [switchcc] command is issued. Workaround: One of the following: (1) Do not [switchcc] until the rebooted UNI-card is burning the flash (by observing a few cycles of [burning xxxxx verify ... ok] messages) (2) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
CSCdr25085	Symptom: Some ports on the AXSM card stay in "down in progress" state after being reset. Condition: Reset AXSM card with resetcd command, seeing msg "slot <axsm slot#> present" on the active pxm45 card and immediately do a switchcc on PXM45. This is an intermittent problem. Workaround: A resetsys will bring back all the ports and get SPVCs rerouted.
CSCdr25293	Symptom: If the clock source to which the switch is locked fails, hardware will not do automatic switchover to the next clock source. This results in bad clock for some period. Software does recognize the clock is bad and does a switchover to other configured clock source or local internal oscillator. Condition: May occur after configuring either the primary or secondary clock source. Workaround: None
CSCdr27033	Symptom: Clock source does not revert back to primary bits clock when revertive mode enabled. This can also appear in the form that clock is not switched to a valid clock source that should have a good clock signal. What is really the case is that the clock source has been previously declared as unusable/unlockable by the clock source manager. This clock source will not be chosen again until after clock source reconfiguration. Condition: The clock source manager is the traffic cop for maintaining the correct/best clock source and managing the state of all clock sources. To make sure that the current clock source is valid, frequency and phase error tests are continuously run on the clock source. Should there ever be a sample that shows invalid frequency or phase error, the clock source is placed into "out of lock" state and a more intensive test is done on the clock source. If this intensive test shows enough failure, the clock source is declared unlockable. To determine if a clock source has been labelled as unusable, there are two methods: 1. From shellconn issue command nclkm_status. Look for the MUXA/MUXB "programmed as" lines of the display. If the source is programmed as "TOP SRM", it has been labelled as unusable. 2. From shellconn issue command dspclockinfo. If clock source is configured but programmed to NULL, then it is labelled as unusable. (NOTE: This display is in the process of change to be more clear about this special clock source state.) Workaround: Reconfigure the clock source, even if it is to the same exact configuration to clear the unlockable state. Use cnfclksrc command.

Problems Fixed in Release 2.0.01


Bug ID	Description
S1 Bugs
CSCdr16509	Symptom: The pnCcb task crashes. Condition: Set max crankback value on one SPVC interface of connection to a value lower than that on any outgoing trunk. Create network conditions whereby the connection does not re-route. Workaround: Do not set asymmetric crankback values for interfaces involved in a connection re-route.
CSCdr18493	Symptom: new SVC/SPVC calls are not able to establish; dspintfcongflag <interface> displays action flags "dropsetupflg, dropestabflg, pacevsiresyncflg" as TRUE, but all detection flags as FALSE. Condition: When trunk card were reset, replaced or taken out and back in with large number of connections on that trunk card. But the occurrence of this problem is very rare. Workaround: None
CSCdr18895	Symptom: pnCCb task crash Condition: The node is fully populated with the interfaces and a switchcc was done. CLI command dsppnports is executed. Workaround: None
CSCdr19468	Symptom: PNNI link is in twoWayInside state. PNNI neighbor is in EXCHANGE state. Condition: This problem only occurs after executing the switchcc command on the PXM45 card. Workaround: Issue another switchcc command.
CSCdr19624	Symptom: CWM may still have slave endpoint but dspspvcs/dspcons on PXM will not have the slave endpoint. Condition: If snmp does del master con then do del slave.Then del slave will be NAK for DAX case. Workaround: None
CSCdr21477	Symptom: System reboots after exception Condition: After switchover, sometimes the system reboots. Workaround: None
CSCdr22523	Symptom: Unable to change AW on PNNI interface. Condition: If a interface is configured as UNI or IISP and auto-config is enabled this interface could become PNNI interface due to auto-config. Then, you wont be able to modify the AW. Workaround: Don't configure the interface to PNNI
CSCdr22884	Symptom: Occurrence of unexpected system reload Condition: To reset trunk card of remote node while interface are in "down in progress" state. Workaround: To reboot the node that the unexpected system reload occurred.
CSCdr23188	Symptom: The problem is an unexpected system reload Condition: Under rare conditions, in which the via node of some connections, the problem may occur, when there is a trunk card reset, link reset. Workaround: None
CSCdr23471	Symptom: pnRedMan task on Standby PXM crashes. Condition: Race condition between CALL Programming Update and Call Release update to standby. Normally, Call programming update should reach the standby before Call release update. Can occur during SPVC re-routes. Workaround: Reboot the standby.
CSCdr24210	Symptom: qe0Task or qe1Task (the scheduler task) may be suspended. Condition: When a QE1210 HW bug causes stale cells in qe extraction cell buffers, it may cause the qe0 or qe1 scheduler task to be suspended. Workaround: None
CSCdr26057	Symptom: pnCCb exception after several dnpnport/uppnport Condition: This only happens when you have both SVP and SVC connections and calling from lower node ID to higher node ID. Workaround: Only call from higher node ID to the lower Node ID.
S2 Bugs
CSCdp64862	Symptom: AXSM cards have TLB load exception while PXM resetting Condition: A software exception is generated on an AXSM card when the AXSM card experiences shortage of memory and attempts to log errors. This software exception occurs as a result of attempting to free memory that is already released. This problem does not affect the functionality of the AXSM card on which this software exception is generated. Workaround: None
CSCdr05166	Symptom: VSI Master Transactions may be returned two times. Condition: Unknown Workaround: None
CSCdr12738	Symptom: tSarDisp task becomes suspended. Condition: If you have the MGX 8850 node running for few days, the <CmdArg>tSarDisp<NoCmdArg> task gets suspended on the PXM45 card. Workaround: Reload the affected PXM45 card.
CSCdr14812	Symptom: Inconsistency in dsppnport and dsppnportsig commands Condition: If the IF-type is happen to be negotiated (operational) value and negotiated (operational) IF-type value is different from provisioned IF-type value, then these two commands show different values of IF-type. Workaround: None
CSCdr16284	Symptom: Different tasks use 46% CPU after trying to set up 10 SPVC calls. Condition: The SPVC connections which are failed to route will stay in busy recommitting single commits (SPVC end only) makes CPU on PXM45 busy at 30 to 46% for any number of failed SPVC connections on a node. Workaround: None
CSCdr16577	Symptom: String_too_long error message from DBSYNC. Condition: If you transfer a file onto an MGX 8850 node or copy a file or rename a file on the MGX 8850, the event specified in the problem description is logged. Additional Information: It is not an error and you may ignore this event.
CSCdr16978	Symptom: conntrace fails when trace connection with call-ref greater than 8388607 Condition: CallRef greater than 8388607 Workaround: None
CSCdr17387	Symptom: The memory owned by pnRedman task might increase when SyncRam communication breaks on the active card Condition: If there is a SyncRam Db Reset during call journalling it could result in memory leakage. This can happen only when there is redundant PXM cards. Workaround: None
CSCdr17915	Symptom: ILMI state shows EnableNotUp while ILMI is actually up. Condition: 1. PXM45 switchover while ILMI state is not UpAndNormal 2. AXSM restarts when ILMI is enabled Workaround: "dnpnport" then "uppnport". The protocol between PNNI controller and AXSM ILMI has been modified that while ILMI is enabled and running on AXSM, if PNNI controller sends the enable command again, AXSM ILMI will sends all the traps to PNNI controller as if it were cold started.
CSCdr18792	Symptom: Congestion on the node where SPVC connections are terminated Condition: Resetting cards will cause this problem intermittently with large amount of SPVC connections. Workaround: None
CSCdr18824	Symptom: Port goes into VC failure after AXSM reset. Condition: Sometimes control VCs (SSCOP/PNNI) can not be setup due to some temporary failure. Workaround: None
CSCdr19859	Symptom: If ssiIpcNameShow is issued on AXSM, the AXSM card would hang. Condition: This is due to a image linking issue where one IPC module should NOT be included in AXSM image. Workaround: Don't execute the command.
CSCdr20269	Symptom: Cannot set daylight-savings-time time zones using the cnftmzn CLI command. Condition: None Workaround: Timezone must be left as non-daylight savings time. Time can be set to the correct hour, though, using cnftime.
CSCdr20606	Symptom: A heavily loaded Cisco MGX 8850 may incorrectly deny access to a valid user. Condition: This condition occurs only during periods of heavy load; user validation returns to the correct behavior when the load lightens. Workaround: Reboot the system.
CSCdr20662	Symptom: Error message will show up in the pxm45 log. The message is logged by the HwMonitor task in the ssiStringCopy function. The error message says the string is too long. Condition: Every time the AXSM card is reset and goes through initialization. Workaround: No workaround. This error will not cause any operational problems.
CSCdr20819	Symptom: VsiErrs may be visible on log or PXM console. These are harmless errors reporting internal mismatch state. Condition: While a call gets rerouted due to trunk failure or a delchan is performed to delete a configured SPVC. Workaround: None
CSCdr21431	Symptom: Unexpected system congestion. Condition: Controller goes into congestion mode when an remote node reboot Workaround: To reboot the node that unexpected system reload occurred.
CSCdr21592	Symptom: Error "Cannot allocate more than 100 interfaces per node" is displayed in dsplog. Condition: Addition of the PNNI controller fails if more than 95 interfaces are provisioned on the PXM before the controller is added. Workaround: Add the PNNI controller before provisioning other interfaces.
CSCdr21593	Symptom: Error logs from CSTAT and StatsTask when bringing up AXSM2 cards Condition: During reboot of AXSM2 card the message is logged in the PXM. Workaround: None
CSCdr21713	Symptom: Stats file does not have all the connections configured for stats Condition: AXSM1 cards with stats collection enabled on the connection using cnfchan <ifno> <vpi> <vci> -stat <enable/disable>. Workaround: None
CSCdr22099	Symptom: User cannot add connections. User cannot delete the partition either. Condition: After a partition has been provisioned, it is possible for user to replace the AXSM card with another that has less hardware capacity. In such cases, the partition cannot be re-added properly by Resource Manager since there is not enough resource anymore. Workaround: Allow deletion of a partition as long as no connection is added to the partition, even if the partition does not exist in Resource Manager's database.
CSCdr22501	Symptom: "Cannot Allocate Memory" errors may be found in the output of the dsplog command. Condition: These messages will be associated with physical slots containing AXSM cards. This will not become a problem unless there have been a large number of PXM45 switchovers and switchcc commands. Workaround: If the problem does occur, reset the AXSM card.
CSCdr22605	Symptom: The Memory Block Error: invalid next block prev ptr value error is observed in the system log. Condition: When a card goes to the Active State, the dsplog output will display SSI-4-MEMBLKERROR E:00094 trapClTask 0x8015bcf0 Memory Block Error: invalid next block prev ptr value 0x0 block 0x868f1b50 in ssiFree. Workaround: None. No impact to the system.
CSCdr22928:	Symptom: Insert a second PXM into a node, and the PXM card does not become standby ready. Running the dspcds command from the active PXM shows the newly inserted PXM is in boot or init state. Condition: The cause for this problem is the BRAM on newly inserted PXM is bad. It may have a bad checksum or contain some invalid data. Workaround: At the shellconn prompt on the newly inserted card issue a sysClrallcnf command.
CSCdr23321	Symptom: Memory leak occurs when VSIM hits congestions while doing dnport/upport. Condition: When VSIM tries to send notification to the IFM about the congestion, VSIM is not freeing up the memory it has allocated for sending the message. This buffer remains unfreed and causes memory leak. Workaround: None
CSCdr23384	Symptom: The ADM (never changed) line critical alarm does go away, but the line reverted to ADM mode remains in critical alarm state. The now-ADM line still thinks it has PLCP alarm which of course is not applicable because the line is now in ADM mode. Condition: Two T3 lines are connected, both configured as ADM mode. When on eT3 line is changed from ADM to PLCP mode while the other remains in ADM mode, alarms occurs on both lines. The PCLP line gets "critical" alarm state due to loss of PLCP framing, while the ADM line gets "critical" alarm state due to LOCD. This is the correct outcome. The PLCP line is then reverted back to ADM mode. The critical alarm state of both lines should go away. Workaround: Clear PCLP-related alarms when line is changed from PLCP to ADM mode.
CSCdr23932	Symptom: No Envmon SNMP traps are issued from the newly active PXM45 Condition: The problem only occurs after executing the switchcc command on the PXM45 card. Workaround: Issue another switchcc command.
CSCdr23973	Symptom: dspclksrcs does not reflect the exact status of clock. Condition: Primary and secondary clocks are configured on a node to supply a single clock to the backplane. After the configured clock on a node is lost, dspclksrcs shows the clock is bad. Once the clock becomes Ok, dspclksrcs does not reflect the exact status of clock. Workaround: Execute nclkm_status from the PXM45 shell. This will give the actual status of the configured clock.
CSCdr24242	Symptom: pnCcb Exception Condition: With SPVC master end-points configured, the system may crash when booting up. Workaround: None. Very intermittent
CSCdr24286	Symptom: The port is stuck in auto config. Condition: A port is in auto cfg state and the card is reset port back up Workaround: None
CSCdr24442	Symptom: This is a configuration problem. If an interface is designated to a UNI, it should be connected to a CPE. If the interface is connected to a peer node, then enabling, ILMI on the interface will convert the interface to be a PNNI link Condition: 1. Have UNI interfaces with ILMI disabled on the interfaces. Add SPVCs on the interfaces. 2. Attach the interface to a peer node with ILMI disabled. 3. Enable ILMI on the line cards on both these nodes. 4. Enable autoconfiguration on the controllers. (By default autoconfig is enabled). 5. The interfaces will go down and come back up again. SPVC will not go down as only a UNI interface went down. SPVC will be conditioned. 6. ILMI autoconfiguration with make the interface as NNI. All the SPVC will be taken out of conditioning. As all the management plane (ILMI) actions are ignored for the SPVC, we might find SPVCs being terminated on a NNI interface. We should be very careful when enabling ILMI on the interfaces on which SPVC has been provisioned. ILMI works on device types and if the peer device type is same, the protocol running on the interface will be PNNI. Workaround: Do not connect 2 BPX/ MGX ports with ILMI enable and provision SPVCs. Since the device types for BPX/MGX are node, they will turn into PNNI interfaces with ILMI being turned on. If there is a need to use the interfaces as UNI, please do not enable ILMI on these interfaces and connect it to BPX/MGXs.
CSCdr24761	Symptom: VsiErrs may be visible on log or PXM console. These are harmless errors reporting internal mismatch state. Condition: While a delchan is performed to delete a configured SPVC. Workaround: None
CSCdr25260	Symptom: Error message reported by the AXSM application. Condition: The error message occurs during AXSM bring up. There is no impact to the system Workaround: None
CSCdr25296	Symptom: Connection fails - no route found. Condition: If redundant addresses/prefixes are configured in PNNI network, a connection may fail if one of the address advertising node is unreachable. Workaround: Don't provision redundant addresses/prefixes

Obtaining Service and Support

For service and support for a product purchased from a reseller, contact the reseller. Resellers offer a wide variety of Cisco service and support programs, which are described in the section "Service and Support" in the information packet that shipped with your chassis.

Note If you purchased your product from a reseller, you can access Cisco Connection On-line (CCO) as a guest. CCO is Cisco Systems' primary, real-time support channel. Your reseller offers programs that include direct access to CCO's services.

Cisco Connection On-line

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

•

Modem: From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.

Additional Support Information

GSE-WAN Trials Engineer will field calls between the hours 8:00a.m. PST and 5:00p.m. PST.

All calls placed outside this window will be supported directly by Development Engineering.

A temporary contract will be provided for opening a CARE case on all issues called in.

If escalation to Developmment Engineering is necessary then a DDTS bug will be opened and linked to the CARE Case.

CRC will be provided escalation information in the event calls are received into the TAC call center.

Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.

Table Of Contents

2.0.01 Version Software Release Notes for Cisco WAN MGX 8850 Software

About These Release Notes

About the 2.0.01 Release

Phased Release Strategy

Software Release 2.0.01 and Related Hardware

AXSM Cards

Line Interfaces for the AXSM Cards

ATM Layer Information

Network Management Features

PXM 45 Cards

Reliability, Availability and Serviceablity (RAS) Features

PNNI

PNNI

Special Installation/Upgrade Requirements

General

SCT Files

Upgrade Procedure

Loading the runtime images from 2.0.00 to 2.0.01

Features Not Supported

Committed (but not delivered in this release)

Obsoleted

Notes & Cautions

Limitations

Release 2.0.01 System Content

Switch Software and Boot Codes

Hardware Products

Known Anomalies

Problems Fixed in Release 2.0.01

Obtaining Service and Support

Cisco Connection On-line

Additional Support Information