Cisco MGX 8800 Series Switches

Table Of Contents

Release Notes for Cisco MGX 8850 (PXM1E/PXM45) and MGX 8830, Software Release 3.0.25

Contents

About Release 3.0.25

Locating Software Updates

Frame Discard Feature

About Release 3.0.23

About Release 3.0.20

SPVC Connection Statistics

AXSM-E OAM Enhancements

CLI Configurable Access

Controller Card Mastership Sanity Verification

Serial Bus Path Fault Isolation

Cell Bus Path Fault Isolation and Recovery

Enhancements for Release 3.0.20

About Release 3.0.10

MGX-RPM-XF-512 Card

Hardware Features

Software Features

AXSM-E Double Density

PXM1E-16-T1E1 with PNNI-IMA Trunking

AXSM-32-T1E1-E with PNNI-IMA Trunking

PXM-UI-S3/B Back Card

MCC-16-E1

RBBN-16-T1E1

PXM1E Online Diagnostics

FRSM-12-T3E3 Online Diagnostics

MGX-SRME

MGX-VISM-PR-8T1/8E1

Alarm Filtering

Enhancements in Release 3.0.10

About Release 3.0.00

High Density Frame Relay FRSM-12-T3E3 Card

PXM1E Platform Card in the new MGX 8850 (PXM1E) and MGX 8830 Switches

About the New MGX 8830 Switch

About the New MGX 8850 (PXM1E) Switch

ITU APS on AXSM/B and AXSM-E for PXM45

MGX-RPM-XF-512 Card

Hardware Features

Software Features

DSL Access Support — Single-ended SPVC Configuration

250K Connections

Path and Connection Trace

Network Clock Distribution Protocol (NCDP)

Simple Network Time Protocol (SNTP)

Priority Routing

Per Connection Overbooking

Preferred Routing

Clear Service Module Configuration (clrsmcnf)

Disk Sync Verify

AXSM and AXSM-E Virtual UNI

Persistent Topology

SCT File Management and User-Configurable Names

Detection of Non-native Controller Front Card and HDD Card

VISM-PR Card

Enhancements in Release 3.0.00

Service Class Template File Information for Release 3.0.25

Service Class Template File Information for Release 3.0.23

Service Class Template File Information for Release 3.0.20

Service Class Template File Information for Release 3.0.10

Service Class Template (SCT) File Information for Release 3.0.00

New Commands for Release 3.0.25

New Commands for Release 3.0.20

System Requirements

Software/Firmware Compatibility Matrix

MGX and RPM Software Version Compatibility Matrix

Additional Notes

Hardware Supported

APS Connectors

MGX 8850 (PXM45) Product IDs and Card Types

MGX 8850 (PXM1E) Product IDs and Card Types

MGX 8830 Product IDs and Card Types

Limitations, Restrictions, and Notes

Release 3.0.25 Limitations

Release 3.0.23 Limitations

Bandwidth Limitations with IMA Ports

Release 3.0.20 Limitations

AXSM-E OAM

CLI Configurable Access

Controller Card Mastership Sanity Verification

Serial Bus Path Fault Isolation

Cell Bus Path Fault Isolation and Recovery

FRSM-12-T3E3 Card

Release 3.0.10 Limitations

AXSM-32-T1E1-E Card

PXM1E-16-T1E1 Card

PXM1E Cards

PXM1E Online Diagnostics

MGX-SRME Card

FRSM-12-T3E3 Card

FRSM-12-T3E3 Online Diagnostics

AXSM-E Double Density

AXSM Cards

PNNI Limitation

SCT Files

Persistent Topology

Reroute Call Performance Changes

Clocking Limitations

Additional Limitations

Release 3.0.00 Limitations

Policing Accuracy for PXM1E

Maximum Threshold Accuracy for PXM45 and PXM1E

PXM1E-based Switches

Reserved VCIs

FRSM-12-T3E3 Card

Disk Space Maintenance

Non-native Controller Front Card and HDD Card

clrsmcnf Command

APS

Path and Connection Trace

SNTP

Priority Routing

SPVC Interop

Preferred Route

Persistent Topology

NCDP

Manual Clocking

AXSM Cards

Bulk Status Enquiry

VISM Limitations

RPM-PR and RPM-XF Limitations

Restrictions for Release 3.0.25

Restrictions for Release 3.0.23

Restrictions for Release 3.0.20

Restrictions for Release 3.0.10

AXSM-32-T1E1-E Card

PXM1E-16-T1E1 Card

Restrictions for Release 3.0.00

AXSM Model B Restrictions

Formatting Disks

Saving Configurations

Other Limitations and Restrictions

Clearing the Configuration on Redundant PXM45 and PXM1E Cards

Limitations and Restrictions for 2.1.x

General Limitations, Restrictions, and Notes

Limitations for rteopt via Parallel Links

Important Notes

APS Management Information

Preparing for Intercard APS

Managing Intercard APS Lines

Troubleshooting APS Lines

Installing and Upgrading to Release 3.0.25

Important Upgrade Notes

Frame Discard

AXSM/B Cards Running APS

AXSM Cards in Op B Mode and APS Lines

NNI Ports

Manual Clocking

Upgrade Precautions from 2.0.x

Installation and Upgrade Procedures

Caveats for Release 3.0.25

MGX 8830 and MGX 8850 (PXM45/PXM1E) Open Caveats in Release 3.0.25

Status of MGX 8830 and MGX 8850 (PXM45/PXM1E) Caveats Found in Previous Releases

MGX 8830 and MGX 8850 (PXM45/PXM1E) Resolved Caveats in Release 3.0.25

Caveats for Release 3.0.23

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.23

Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.23

Caveats for Release 3.0.20

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.20

Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.20

Caveats for Release 3.0.10

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.10

Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.10

Caveats for Release 3.0.00

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.00

Anomalies Resolved in Release 3.0.00

Known Route Processor Module or MPLS Caveats

MGX-RPM-XF-512 Caveats

Acronyms

Documentation

Changes to this Document

Related Documentation

Cisco WAN Manager Release 11

Cisco MGX 8850 (PXM45) Multiservice Switch Release 3

Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3

Cisco MGX 8950 Multiservice Switch Release 3

SES PNNI Controller Release 3

Cisco MGX 8830 Multiservice Switch Release 3

Cisco WAN Switching Software Release 9.3

Cisco MGX 8850 (PXM1) Edge Concentrator Switch Release 1

Cisco MGX 8250 Edge Concentrator Switch Release 1

Cisco MGX 8230 Edge Concentrator Switch Release 1

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

How to Find Multiservice Switch Customer Documents Online

If the Part Number is Known

If the Part Number is Not Known

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Cisco TAC Web Site

Cisco TAC Escalation Center

Release Notes for Cisco MGX 8850 (PXM1E/PXM45) and MGX 8830, Software Release 3.0.25

---

Contents

About Release 3.0.25

Release 3.0.25 is a software maintenance release for the MGX 8830 PNNI routing switch and for the MGX 8850 switch.

Locating Software Updates

For the MGX 8830 and the MGX 8850, software updates are located at Cisco Connection Online (CCO) at the following location:

http://www.cisco.com/kobayashi/sw-center/wan/wan-planner.shtml

Frame Discard Feature

New developments have occurred in the CLI for the Frame Discard feature in connection provisioning. Starting with releases 3.0.23 and 4.0.10, two types of frame discard became available. For a detailed explanation, see the addcon or cnfcon description in either the Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 Command Reference (Release 3 or 4) or the Cisco ATM Services (AXSM) Software Configuration Guide and Command Reference for MGX Switches (Release 3 or 4). Also see the Note in the Installation and Upgrade section of these release notes.

About Release 3.0.23

Release 3.0.23 is a software maintenance release for the MGX 8830 PNNI routing switch and for the MGX 8850 (PXM45) and MGX 8850 (PXM1E) switches.

About Release 3.0.20

Release 3.0.20 contains these new features:

•SPVC Connection Statistics

•AXSM-E OAM Enhancements

•CLI Configurable Access

•Controller Card Mastership Sanity Verification Enhancement

•Serial Bus Path Fault Isolation Enhancement

•Cell Bus Path Fault Isolation and Recovery Enhancement

SPVC Connection Statistics

SPVC connection statistics display the statistics generated for the originator node, and for an MPG node, it displays the statistics for the border nodes. It will show the number of SPVC connections that are successfully routed, number of connections that are failed, and the number of crankbacks initiated and received.

AXSM-E OAM Enhancements

The AXSM-E OAM enhancements consist of two changes. The first change modified the driver for the AXSM-E card to successfully pass high volume of OAM cells. The second change enhanced the OAM task to better share the node resources with the other cards in the node.

This feature is available only for the MGX 8850 switch with the PXM45 controller.

CLI Configurable Access

A new command, cnfcli, has been created to allow administrators to customize the CLI command access levels. An ASCII file with the command names and the corresponding new command access levels is created by an administrator. This file is FTP'ed to the node. This file contains commands for the whole node, irrespective of the card types (one file per system). Then cnfcli is invoked to parse and install the new command access levels.

Controller Card Mastership Sanity Verification

This feature provides checks to validate the hardware mastership states on the active and standby PXM cards. The scope of this enhancement in this release is to detect invalid mastership states, send a trap, and log more information. This feature does not provide any new auto-corrective action when a mastership problem is detected.

Serial Bus Path Fault Isolation

The MGX 8850 currently uses the serial bus for its data path transport. The switching ASICs and Humvee chips on the PXM and Switch Module cards are designed to detect data integrity and chip errors.

When an error is detected on the switching fabric path by either the Service Module cards, or the Switching Fabric card (e.g., PXM45, or XM60) and if the error count exceeds its error threshold, the error is reported to the PXM, and the PXM will take one or more of the following corrective actions:

•shutdown the humvee/switch fabric link that is reporting errors

•switch to a standby switching module

•switch to a standby PXM module

•reset the active switch module (SM)

Table 1 summarizes the enhancements made in this firmware release in isolation and recovery procedures:

Table 1 Enhancements to Isolation and Recovery Procedures 

Failure Detection	Isolation	Recovery
Humvee Errors on SM	Isolate local Humvee errors before reporting failure to the PXM. Speed up detection/isolation of Humvee SFRAME errors to be less than 10msec versus the current (2+ seconds).	Follow current recovery procedure when such an error is detected. 1) Shutdown the link that reported the errors 2) If all links going toward an SM card fails, move the SM slot to degraded mode, and if redundancy is available on that SM, switch the standby SM to be active. 3) If all links reported error on a card, leave the last failed link up.
Humvee Errors Reported on the PXM	Isolate local Humvee errors before reporting failure to the PXM. Speed up detection/isolation of Humvee SFRAME errors to be less than 10msec versus the current (2+ seconds).	Follow current recovery procedure when such an error is detected. 1) Shutdown the link that reported the errors 2) If all Humvee links on the PXM report errors, raise a non-fatal error against the PXM. If PXM redundancy is available, switch to the standby PXM card.
Switch Fabric errors	Isolate local Switching Fabric errors before reporting failure to the PXM. Speed up detection/isolation of Switching Fabric SFRAME errors to be less than 10msec versus the current (2+ seconds).	Follow current recovery procedure when such an error is detected. 1) Shutdown the link that reported the errors 2) If all links going toward an SM card fails, move the SM slot to degraded mode, and if redundancy is available on that SM, switch the standby SM to be active. 3) If all links reported error on a card, leave the last failed link up. (new)

This feature is available only for the MGX 8850 switch with the PXM45 controller.

Cell Bus Path Fault Isolation and Recovery

The service modules and the controller cards use the Cell Bus for almost all the inter-card communication. One aspect of inter-card communication involves the active controller card periodically polling the service modules to detect service module failures. So, any failure to use the Cell Bus results in major failure in the system. In Release 3.0.20, the firmware has been enhanced to offer better procedures for detection, isolation and limited recovery from the failure of the hardware components that are specific to using the Cell Bus path.

The Cell Bus Path fault is isolated to the PXM if its polling of all Service Modules and the standby controller card in the node fails. Once the fault is isolated to the active PXM, the Active PXM is reset to initiate a switchover and recover from the failure.

Enhancements for Release 3.0.20

The product enhancement requests (PERs) in Table 2 were introduced in Release 3.0.20.

Table 2 List of Product Enhancement Requests in MGX Release 3.0.20 

Enhancement Number	Purpose
2834	A dsphotstandby command which, when entered on the AXSM, would check for the readiness of the standby AXSM. This would ensure that a switchover to the standby AXSM would be safe.
7419	Two new CLI commands, dspportrtcnt and clrportrtcnt, are being added as a way to display the real-time statistics in both ingress and egress directions and to clear these statistics, respectively.

About Release 3.0.10

Release 3.0.10 contains these new features:

•MGX-RPM-XF-512 Card

•AXSM-E Double Density

•PXM1E-16-T1E1 with PNNI-IMA Trunking

•AXSM-32-T1E1-E with PNNI-IMA Trunking

•PXM1E Online Diagnostics

•FRSM12 Online Diagnostics

•MGX-SRME

•MGX-VISM-PR-8T1/8E1

•Alarm Filtering

MGX-RPM-XF-512 Card

MGX-RPM-XF-512 is the next generation RPM card based on Cisco Patented Parallel Express forwarding (PXF) technology. Service Provider customers can use MGX-RPM-XF-512 to IP enable their FR/ATM infrastructure to provide high touch services like IP VPNs using MPLS with line rate quality of service (QoS). The MGX-RPM-XF-512 Gigabit Ethernet module can play a key role in service provider networks providing Metro Ethernet services in conjunction with Cisco ONS 15454.

This feature is available with this release for the MGX 8950 switch.

Hardware Features

The MGX-RPM-XF-512 card has the following hardware features:

•Full height serial line based router module.

•Dual OC-24 ATM SAR.

•1-port Gigabit Ethernet back card support per MGX-RPM-XF-512 front card.

•1-port OC-12 POS back card support per MGX-RPM-XF-512 front card.

•One MGX-RPM-XF-512 front card can only support either the Gigabit Ethernet (GE) or Packet over SONET (POS) back card but not both at the same time in the initial release.

•High-speed back card is supported in the upper half of the shelf.

•Console back card with two FE ports for management traffic is supported only in the lower half of the chassis.

Software Features

The MGX-RPM-XF-512 card has the following software features:

•Edge LSR functions.

•Label Switch Controller.

•1:N Redundancy.

---

Note Only RPMs of the same card type are supported in a redundancy group.

---

•MPLS Class of Service. (Low Latency queueing, Diffserv support, WFQ/CBWFQ, Modular QoS CLI)

•Frame-based MPLS and cell-based MPLS support.

•PNNI SPVC/SPVP connection management.

•ATM COS such as VBR-nrt, VBR-rt, and UBR.

•Full IP Routing suite - RIPv2/OSPF/ISIS/BGP.

•Support for IP multicast.

•PPP services. PPPoA

•VLAN-802.1Q support with 802.1Q to MPLS VPN mapping.

AXSM-E Double Density

This feature doubles the number of ports previously available with each AXSM-E Service Module. Each AXSM-E Service Module supports up to two back cards. Previous to Release 3.0.10, only one was supported. The actual bandwidth supported by each card remains constant at 622 Mbps, but the additional ports allow better scaling of service provider networks using ABR with VS/VD support and per-connection traffic shaping.

This feature is available for the MGX 8850 switch with the PXM45 controller.

PXM1E-16-T1E1 with PNNI-IMA Trunking

PXM1E-16-T1E1 is a new PXM1E front card with support for two back cards RBBN-16-T1E1 and MCC-16-E1. PXM1E will provide up to 16 T1 or E1 ports with IMA Versions 1.0 and 1.1 support for PNNI trunking.

---

Note UNI support for the interfaces will be provided in a future software release.

---

T1 or E1 links (but not a mix) can be grouped to form IMA groups of links 1 to 16 in a single group. Both RBBN-16-T1E1 and the MCC-16-E1 back cards support 1:1 redundancy on PXM1E-16-T1E1. The maximum number of connections supported in a shelf with PXM1E-16-T1E1 as the processor card is 13,500 connections.

The PXM1E-16-T1E1 card is supported in the MGX 8830 switch and the MGX 8850 switch with the PXM1E controller.

AXSM-32-T1E1-E with PNNI-IMA Trunking

The AXSM-32-T1E1-E card is a double-height service module used on the PXM-45 based MGX 8850 platform. In this release, the AXSM-32-T1E1-E supports ATM cell transfer over a total of 32 T1/E1 interfaces. Up to two back cards of the same type (RBBN-16-T1E1 or MCC-16-E1) are supported with 16 T1/E1 interfaces per backcard. The AXSM-32-T1E1-E card supports a maximum of 32,096 connections. It supports enhanced traffic management capabilities with per-VC/VP traffic shaping and ABR with VS/VD along with multilevel statistics.

In this release, IMA Versions 1.0 and 1.1 are supported (PNNI trunking only).

---

Note UNI IMA will be available in a subsequent software release.

---

This feature is available for the MGX 8850 switch with the PXM45 controller.

PXM-UI-S3/B Back Card

The PXM-UI-S3/B back card provides four serial ports and two Ethernet ports and Stratum-3 clock functionality for the PXM1E front cards.

The PXM-U1-S3/B card is supported in the MGX 8830 and the MGX 8850 switches.

MCC-16-E1

The MCC-16-E1 back card has sixteen E1 miniature coaxial connectors.

The MCC-16-E1 card is supported in the MGX 8830 and the MGX 8850 switches.

RBBN-16-T1E1

The RBBN-16-T1E1 back card has a "ribbon" type connector that supports sixteen T1 or E1 ports.

The RBBN-16-T1E1 card is supported in the MGX 8830 and the MGX 8850 switches.

PXM1E Online Diagnostics

The feature provides the capability to configure a hardware-oriented test to check the health of the PXM cards—both active and standby. The test can be run in the active, standby, or both modes at the same time. The test is nonintrusive and runs with minimum overhead. The capability is provided as an option. The failure of online diagnostics in the active PXM1E card results in a switchover to the standby PXM1E card. The failure of the online diagnostics in the standby PXM1E card results in declaring the standby PXM1E card as failed. The feature is available for all the different PXM1E cards:

•4OC3/STM1

•8 T3/E3

•16 T1/E1

•T3E3/155

Table 3 describes the PXM1E online diagnostics feature support levels for devices within the PXM1E cards:

Table 3 PXM1E Devices and Online Diagnostic Feature Support 

Device	Supported by Online Diagnostics?
Atlas 0	Yes
Atlas 1	No
QE 0	No
QE 1	Yes
CBC 0	No
CBC 1	No
Disk	No
R7k CPU/Nile4o	No
ATMizer SAR	No
UMCC FPGA	No
DMA Controller	No
ELMER FPGA	No
BRAM	No
UIS3 FPGA	No
SUNI Framer	No
QJET Framer	No

This feature is available for the MGX 8830 and MGX 8850 (PXM1E) switches.

FRSM-12-T3E3 Online Diagnostics

This feature provides the capability to configure a hardware-oriented test to check the health of the FRSM-12-T3E3 card—both active and standby. The test can be run in active, standby, or both modes at the same time. The test is nonintrusive and runs with minimum overhead. The capability is provided as an option. The failure of online diagnostics in the active FRSM-12-T3E3 card results in a switchover to the standby FRSM-12-T3E3 card. The failure of the online diagnostics in the standby FRSM-12-T3E3 card results in declaring the standby FRSM-12-T3E3 card as failed. The failure of the standalone FRSM-12-T3E3 card results in the card being placed in the failed state but the card will not be reset.

This feature is available for the MGX 8850 switch with the PXM45 controller.

MGX-SRME

This feature provides channelization and redundancy support for MGX-VISM-PR in a MGX 8850 (PXM45) chassis. The MGX-SRME card can take one OC-3 or one STM-1 as ingress, channelize the signal to a T1 or an E1 and distribute to an MGX-VISM-PR 8T1 or an MGX-VISM-PR 8E1 card via a distribution bus inside the MGX 8850 (PXM45) chassis. For redundancy, a MGX-VISM-PR card can be configured as a standby card, so if one active MGX-VISM-PR card fails, MGX-SRME reroutes the traffic to the standby card. MGX-SRME also provides automatic protection switching (APS) capabilities on the ingress line. If one line fails, the other line takes over. APS protocols include GR-253, ITU-T Annex A and Annex B.

The MGX-SRME card is supported in the MGX 8830 and the MGX 8850 switches.

MGX-VISM-PR-8T1/8E1

This feature provides support for the MGX-VISM-PR-8T1/8E1 card on the MGX 8830 platform, and provides the capability for voice applications in this switch.

The MGX-VISM-PR-8T1E1 card is supported in the MGX 8830 switch.

Alarm Filtering

The Alarm Filtering feature works in conjunction with Cisco WAN Manager (CWM) 11.0.10 to display a filtered integrated shelf alarm. The filtered integrated shelf alarm ignores all lines, ports, connections and feeder alarms reported by a given node. When the CWM GUI displays a group of nodes in group mode, the group's integrated alarm is the aggregation of all filtered alarms reported by the nodes in the group, and all trunk/line alarms reported by these nodes.

Enhancements in Release 3.0.10

The product enhancement requests (PERs) in Table 2 were introduced in Release 3.0.10.

Table 4 List of Product Enhancement Requests in MGX Release 3.0.10 

Enhancement Number	Purpose
2291	The persistent topology feature provides CWM with a persistent view of the network, regardless of the current operational status of the nodes in the network. Topology information (IP address, node ID, feeder port ID, etc.) is stored in the persistent topology database for each node in the network. If a node is disconnected from the network due to some error scenario (the link went down, the node rebooted, etc.), CWM would still be able to retrieve information about this node from the persistent topology database. Starting with this release, the persistent topology database contains information on the routing and feeder nodes in the network.
5055	CLI commands provided to display VC/CoS thresholds in the AXSM-E QE. This feature is available for the MGX 8850 switch with the PXM45 controller.
5068	dspport on AXSM-E card and dsppnport on PXM card should display the same number of SVCs. This feature is available for the MGX 8850 switch with the PXM45 controller.
5267	Better clock resolution provided for tstdelay on AXSM-E cards. This feature is available for the MGX 8850 switch with the PXM45 controller.

About Release 3.0.00

Release 3.0.00 contains these new features:

•High Density Frame Relay FRSM-12-T3E3 card

•PXM1E Platform card in the new MGX 8850 (PXM1E) and MGX 8830 switches

•ITU APS and Annex B on AXSM/B and AXSM-E for PXM45

•MGX-RPM-XF-512 Card

•DSL Access Support — Single-ended SPVC configuration

•250K Connections

•Path and Connection Trace

•Network Control Distribution Protocol

•Simple Network Time Protocol

•Priority Routing

•Per Connection Overbooking

•Preferred Routing

•Clear Service Module Configuration (clrsmcnf)

•Disk Sync Verify

•AXSM and AXSM-E Virtual UNI

•Persistent Topology

•SCT File Management and User Configurable Names

•Detection of Non-native Controller Front Card and HDD Card

•VISM-PR Card

High Density Frame Relay FRSM-12-T3E3 Card

The High Density Frame Relay FRSM-12-T3E3 card is a double-height, serial line based, high-speed frame relay module for the MGX 8850 (PXM45) system capable of supporting 12 ports of DS3 unchannelized frame interfaces. The FRSM-12-T3E3 is built upon the existing AXSM-E architecture, and it can accept small packets and sustain 622Mbps of ATM throughput (with frame to ATM conversion). The FRSM-12-T3E3 in conjunction with the MGX-RPM-XF-512 card, can be used to provide MPLS service with frame access. Some of the features supported in the FRSM-12-T3E3 are:

•Interfaces: Frame Relay UNI/NNI, Frame Forwarding

•# of connections: 4K/port, 16K/card

•FRF.5, FRF.8.1 interworking

•LMI, enhanced-LMI, FRF.1.2

•Ingress per-VC queuing, Frame-based policing

•Standard ABR with VS/VD

•1:1 hot-standby card redundancy and Y-cable redundancy

Benefits

The explosion in Internet usage and bandwidth demanding applications is fueling the growth for higher access speeds. The frame services market is growing rapidly for increased access speeds, fractional T3 and T3, beyond the traditional subrate T1 and T1 speeds. Some of the applications for the FRSM-12-T3E3 are:

•Frame-based IP services

•DS3 Frame Relay Service

The FRSM-12-T3E3 card is supported on the MGX 8850 switch with the PXM45 controller. (This card is not supported on PXM1E-based switches, that is, MGX 8850 (PXM1E) and MGX 8830.

PXM1E Platform Card in the new MGX 8850 (PXM1E) and MGX 8830 Switches

The new PXM1E-based switches include:

•MGX 8850 (PXM1E)

•MGX 8830

These switches are low end, cost effective multi-service switches based on the current MGX architecture with integrated uplinks on the processor card. The switch will provide a mix of broadband and narrowband services in addition to PNNI routing and signaling. It combines Narrow Band Service Module (NBSM) support, onboard network interface, and PNNI capability into a cost-effective single board switch. The PXM1E switches have these features:

•FRSM 8T1/8E1, HS2B

•VISM-PR (on MGX 8850 (PXM1E); not on MGX 8830)

•AUSM 8T1/E1

•CESM-8T1/B, CESM-8E1

•SRM-E and SRM-3T3/C

•Support for RPM-PR controller

•New combination back card for the PXM1E-T3E3-155

•2 back cards per front card - one PXM-UI-S3 card, one network interface card

•Planned connection limit - one of the following:

•27K (both terminating and via connections)

•16K DAX connections

•combination of DAX and through with limit of 13.5K to 27K connections

•Support for 1:1 redundancy

•Automatic Protection Switching (APS) both ITU-T and GR-253, 1:1 and 1+1 support

The PXM1E has PNNI/ATM routing that supports the ATM Forum standard PNNI routing/signaling. It can be a peer to the PXM45 based switches in the single peer group and participate in the multi-peer groups. It supports different types of connections - SVC, SVP, S-PVC, and S-PVP. UNI 3.X/4.0 signaling and ILMI are used to setup SVCs. PXM1E will support 16K local switching connections.

About the New MGX 8830 Switch

The Cisco MGX 8830 is an attractively priced 1.2 Gbps switch for sites with power and size constraints. It allows our customers to extend their geographic reach to more remote locations that need the high availability and features of the MGX 8850 in a smaller footprint.

The MGX 8830 supports interface modules for Frame Relay, ATM, Circuit Emulation, IP and Packet Voice.

New with the Cisco MGX 8830 is the industry's first ATM Modular optics, enabling service providers to mix and match single-mode, multi-mode and intermediate reach fiber on Broadband ports. Service providers can also add the broadband ports as needed, minimizing CAPEX.

About the New MGX 8850 (PXM1E) Switch

The Cisco MGX 8850 Multiservice Switch -- with the new PXM1E processor card -- is a low end, cost-effective multiservice switch based on the current MGX architecture with integrated network interfaces on the processor card. Like the MGX 8830, the switch will provide a mix of broadband and narrowband services in addition to PNNI routing. It scales from DS0 to OC-3/STM1.

The PXM1E-4-155, PXM1E-8-T3E3, and the PXM1E-T3E3-155 cards are supported in the MGX 8830 switch and the MGX 8850 switch with the PXM1E controller.

ITU APS on AXSM/B and AXSM-E for PXM45

APS provides redundancy on SONET/SDH equipment to protect against line failure or fiber cut. APS permits the network to react to failed optical lines and/or optical interfaces by switching to an alternate line. This release supports the international standards ITU-T G.783 Annex A and B APS on AXSM/B and AXSM-E optical modules. APS 1+1 intercard redundancy requires use of an APS connector (MGX-APS-CON) to connect adjacent back cards.

The complete list of architecture mode supported by software is:

•1+1 GR253

•1:1 GR253

•1+1 G.783 Annex A

•1:1 G.783 Annex A

•1+1 G.783 Annex B

ITU-T APS on AXSM/B is supported on the MGX 8850 (PXM45) and the MGX 8950 switches. ITU-T APS on AXSM-E is supported on MGX 8850 switch with the PXM45 controller.

Benefits

For a line failure, the detection and signaling of the failure occurs within 10 ms and the switchover occurs within 50 ms. For a card failure, the recovery will occur in less than 250msec. Using APS is a faster way to recover than can be achieved with Y-cable redundancy or ATM layer rerouting.

MGX-RPM-XF-512 Card

MGX-RPM-XF-512 is the next generation RPM card based on Cisco Patented Parallel Express forwarding (PXF) technology. Service Provider customers can use MGX-RPM-XF-512 to IP enable their FR/ATM infrastructure to provide high touch services like IP VPN's using MPLS with line rate QOS. The MGX-RPM-XF-512 GigE module can play a key role in service provider networks providing Metro Ethernet services in conjunction with Cisco ONS 15454.

Hardware Features

The MGX-RPM-XF-512 card has the following hardware features:

•Full height Serial Line based Router module.

•Dual OC24 ATM SAR.

•1-port GigE backcard support per MGX-RPM-XF-512 front card.

•1-port OC12 POS backcard support per MGX-RPM-XF-512 front card.

•One MGX-RPM-XF-512 front card can only support either the GE or POS backcard but not both at the same time in the initial release.

•High speed backcard is supported in the upper half of the shelf.

•Console backcard with 2 FE ports for management traffic is supported only in the lower half of the chassis.

Software Features

The MGX-RPM-XF-512 card has the following software features:

•Edge LSR functions.

•Label Switch Controller.

•1:N Redundancy. Note: Only RPM's of the same card type are supported in a redundancy group.

•MPLS Class of Service. (Low Latency queueing, Diffserv support, WFQ/CBWFQ, Modular QOS CLI)

•Frame based MPLS and Cell based MPLS support.

•PNNI SPVC/SPVP connection Management.

•ATM COS such as VBR-nrt, VBR-rt, and UBR.

•Full IP Routing suite - RIPv2/OSPF/ISIS/BGP

•Support for IP Multicast.

•PPP services. PPPoA

•VLAN-802.1Q support with 802.1Q to MPLS VPN mapping.

The MGX-RPM-XF-512 card is supported on the MGX 8850 switch with the PXM45 controller.

DSL Access Support — Single-ended SPVC Configuration

The feature enables configuration of both the endpoints of the SPVCs at the master end of the connection. With the feature, the connection needs be provisioned using the double ended provisioning model. The slave end of the connection is activated when the connection is established by the master end. This feature provides the ability to provision single-ended SPVC connections that originate on the DSLAM.

The Single-ended SPVC Configuration feature is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.

Benefits

This feature enables improved interoperability with other vendor equipment and management stations.

250K Connections

The 250K Conns feature improves the scalability of the existing PXM45 node from the current 100K connections to 250K connections. This feature is supported only on the version B of the PXM 45 card with 256M of memory. On a single node, there can be a maximum of 250K SPVC/SPVP and SVC/SVP connections, where a maximum of 100k connections are persistent, and the other 150K connections are non-persistent. However, a node will support 250k persistent connections if it is not managed by CWM.

The number of persistent connections are limited by the number of connections supported by CWM, which is currently 100K.

The 250K Connections feature is supported on the MGX 8850 and MGX 8950 switches with PXM 45 version B cards.

Benefits

Customers can provision more connections on each switch.

Path and Connection Trace

The Path and Connection Trace feature allows the user to determine the path taken by a connection. The Path Trace feature is used for new connections in the process of being established. The Connection Trace feature is used to collect information on existing connections that have already been established. The Path and Connection Trace feature supported in the previous releases is based on the pre-standard version of the ATM Forum specification. In the current release the Path and Connection Trace feature will conform to ATM Forum standard PNNI Addendum for Path and Connection Trace, Version 1.0 af-cs-0141.000.

The Path and Conn Trace feature is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830 and MGX 8850 (PXM1E) switches.

Benefits

Standards based feature enables interoperability with other vendor equipment.

Network Clock Distribution Protocol (NCDP)

Network Clock Distribution Protocol (NCDP) is the means by which an accurate clock source is chosen by a node and is distributed to the rest of the nodes within a network for the purpose of ensuring synchronized network operation. NCDP based clocking provides resiliency of clock sources in a network which is vital for delay-sensitive traffic like video and voice traffic and allows the network to proactively switch clock sources rather than waiting for the quality of the active clock source to degrade.

NCDP is disabled by default. The only configuration required to enable the clock distribution is to enable it, then add the clock source references. NCDP can be turned off on a nodal basis or an interface basis. NCDP supports clock distribution to 200 nodes in the network. If the network is larger than 200 nodes, it should have multiple clocking domains with separate clock sources.

NCDP is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.

Benefits

The implementation of NCDP based clock distribution on the MGX 8800 enables service providers to deploy large scale networks with integrated clocking suitable for delay sensitive data transfer.

Simple Network Time Protocol (SNTP)

Simple Network Time Protocol (SNTP) based time of day synchronization enables MGX 8800 nodes to have network time synchronization. Accurate time of day service is provided by synchronizing to Universal Time Coordinated (UTC) time. The standard based approach allows the switch to synchronize to any SNTP/NTP time server. This provides accurate time for statistics and alarms generated on the switch and enables accurate synchronization of such events between switches. The BPX uses a similar protocol for time distribution, but with the addition of SES, the BPX can also be synchronized using SNTP. In a network of BPX 86xx and MGX 88xx switches, time must be set on the BPX in order to be distributed consistently throughout the network.

SNTP is supported on the MGX 8850 PXM45, MGX 8950, MGX 8830 and MGX 8850 (PXM1E) switches.

Benefits

The SNTP Server functionality allows MGX 88xx and BPX 86xx switches to act as SNTP servers for the network.

Priority Routing

Priority based routing allows customers to specify the priority of connections. The priority allows high priority connections to be established before low priority connections. During failures, the high priority connections are also released before low priority connections. This action enables rerouting and reestablishment of high priority connections earlier than low priority connections.

This feature is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.

Benefits

The customer can offer prioritized services based on connection priority.

Per Connection Overbooking

The Per Connection Overbooking feature for SPVCs provides improved control of network utilization for multiple tiers of service on a network supporting various trunk capacities. The percentage utilization factor is used for Connection Admission Control for the connection. The actual bandwidth used for Connection Admission Control for the connection is based on the PCR/SCR configured for the connection and the percentage utilization factor configured for the connection, combined with the percent utilization configured for interfaces in the selected path.

Overbooking means that less bandwidth is reserved for a connection, however it can use more bandwidth. The feature will enable overbooking to be performed on a connection basis.

Per Conn Overbooking is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.

Benefits

This feature enables service providers to provide differentiated overbooking on a per connection basis rather than only on a uniform basis allowed by interface overbooking.

Preferred Routing

Preferred routing of connections provides the network operator a means of bypassing the PNNI route selection, and configuring a specific path through the network by which a connection will follow. Preferred routes can be configured as either Preferred or Directed routes. A Preferred route is a route which will follow the configured path if available, but will revert to a PNNI-selected route if the preferred route is not available. A Directed route is a route which will follow only the configured path; if the configured path is not available, the connection will remain unrouted.

In this first implementation of Preferred routes, a set of preferred routes is configured and assigned reference numbers, referred to as route sets. As connections are configured, they can be assigned to a particular route set. Each route set can currently contain one preferred (or directed) route.

Preferred routes can currently be specified only across a single PNNI peer group.

Since the preferred route is placed in the PNNI DTL by the source node, preferred routes are interoperable with any standard PNNI implementation.

Preferred routing is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.

Benefits

The customer can control the selection of routes based on criteria other than those allowed in the route selection algorithms offered by PNNI.

Clear Service Module Configuration (clrsmcnf)

The clrsmcnf feature clears the configuration for a particular service module slot without affecting the configuration of other slots. This feature clears the configuration from both memory and disk (persistent). The clrsmcnf command will be a blocking command and the service module will be unavailable for provisioning during the entire duration of the command.

The clrsmcnf feature is supported on the following modules.

•MGX 8850 (PXM45): AXSM, AXSM/B, AXSM-E, RPM-PR, MGX-RPM-XF-512

•MGX 8830 and MGX 8850 (PXM1E): FRSM, AUSM, CESM, VISM, RPM-PR

Benefits

The clrsmcnf feature does not impact or clear the configuration of the entire shelf (clrallcnf), it only clears the configuration for a particular slot thereby limiting the impact.

Disk Sync Verify

This feature provides a verification utility to check the synchronization of the disk "data" between the active PXM and standby PXM hard disks in the D:/DB2 directory. This disk synchronization verification utility provides a method of checking the "data" between the active PXM and standby PXM hard disks when invoked through CLI. This new CLI command, dskdbverify, invokes the task of verifying the "data" between the active PXM and standby PXM hard disks. This CLI command can be invoked both on the active PXM and standby PXM.

AXSM and AXSM-E Virtual UNI

A new port type called Virtual UNI (VUNI) is defined in addition to the already defined port types - UNI, NNI, VNNI (Virtual Trunk). This feature benefits both the MPLS and PNNI control plane.

Virtual UNI is supported on the MGX 8850 (PXM45) and MGX 8950 switches with the AXSM, AXSM/B, and the AXSM-E line cards.

Benefits

Customers can provision multiple Virtual ports each with a VP range on one physical line and thus allow transport of PNNI SPVPs. This feature removes the restrictions in previous releases with Virtual Trunks (VNNI) wherein only one VP could be defined so only SPVC could be transported across those VNNI interfaces. With Virtual Port an MGX, that is not configured with MPLS control plane (LSC) but is expected to transport PNNI and MPLS traffic to a neighboring switch configured with both MPLS and PNNI, can utilize this feature by defining a combination of VUNI (0-255 VP range) or VNNI (0-4095 range) or a VNNI (one VP only) on a single Physical ATM port thus allowing trunking as well as terminating traffic on a single physical port.

Virtual port allows the flexibility of defining separate Service Class Templates per logical Virtual port. This allows customers to engineer different behaviors of traffic on different logical ports on the same physical line.

Persistent Topology

The Persistent Topology feature enables CWM to maintain a persistent topology information of the entire network. One or more nodes will be designated as gateway nodes. Whenever CWM needs info about the network, it will query gateway nodes to collect necessary information. Gateway nodes are defined to be nodes from which CWM can query for information on the nodes contained within a peer group. A node needs to be configured to be a gateway node in every peer group through CLI or CWM before it can be used as one.

This feature will deliver the following functionality:

Cumulative collection of node info for topology database. Node info will contain nodeId, nodeName, lanIP, atmIP, sysObjId.

•Allow manual configuring (i.e. enabling and disabling) a gateway node through CLI.

•Allowing manual deletion of a node info from the topology database.

•Support redundancy of the cumulative topology database.

Benefits

This feature is useful to monitor the entire network as information of all the nodes irrespective of their state will be available to the CWM. It enables service providers who deploy large scale networks to keep track of the all the nodes in the network.

SCT File Management and User-Configurable Names

This features implements version control for the SCT files such that the SCT files can have a major version, which would keep track of the parameters being added/deprecated, and a minor version to address limitations. A SCT management MIB was created to keep CWM and the switch in sync with respect to the MIBs. The SCT MIB contains a version parameter, and can be used to convey the minor and major versions of the SCT file. When the SCT file is modified by the user, the user can save the file as a new file or as a different version of the SCT file.

Detection of Non-native Controller Front Card and HDD Card

With this feature the runtime firmware detects when a controller front card or HDD card from another shelf/node is inserted into a node in the standby controller card slot. When the firmware detects a non-native PXM1E front (that has hard disk) or HDD back card is inserted into a node in the standby controller card slot, all the contents, except the contents in the C:FW, C:SCT, F:SCT and the image files and auto configuration files in the E:RPM, on the hard disk in the standby controller card slot will be deleted and the event log files will be backed up.

In other words, when a non-native hard disk is detected in the standby controller slot, the following files and directories will be preserved, event log files are backed up and everything else, including event log files, will be deleted on the non-native hard disk:

•C:FW

•C:SCT

•F:SCT

•all files except auto configuration files in E:RPM directory

As a result of this feature, the hard disk on the standby controller slot no longer needs to be manually cleaned up when it is moved from another shelf/node.

VISM-PR Card

Table 5 describes the configuration requirements for VISM and VISM-PR in combination with the MGX 8000 Series switches and supported processor modules. Refer to the "Release Notes for Cisco Voice Interworking Service Module Release 3.0(0)" for details about VISM modules.

Table 5 VISM/VISM-PR and MGX 8000 Series Switch Support 

VISM Module	MGX 8230 with PXM1	MGX 8250 with PXM1	MGX 8850 with PXM1	MGX 8850 with PXM1E	MGX 8850 with PXM45
MGX-VISM-8T1	Yes	Yes	Yes	No	No
MGX-VISM-8E1	Yes	Yes	Yes	No	No
MGX-VISM-PR-8T1	Yes	Yes	Yes	Yes	Yes
MGX-VISM-PR-8E1	Yes	Yes	Yes	Yes	Yes

Enhancements in Release 3.0.00

The product enhancement requests (PERs) in Table 2 were introduced in Release 3.0.00.

Table 6 List of Product Enhancement Requests in MGX Release 3.0.00 

Enhancement Number	Purpose
124	This feature provides a verification utility to check the synchronization of the disk data between the active PXM and the standby PXM hard disks in the D:/DB2 directory. This utility provides a method of checking the "data" between the active PXM and the standby PXM hard disks when invoked through the CLI.
1087	Since the MGX 8850 with PXM45 is used as a core switch and that switch does not have a time of day/date distribution, the switch needs to provide support for Network Time protocol (NTP - RFC 1305). Accurate time of day is needed by customer operations to correlate events on multiple switches as well as network management and with customers.
1473	AXSMs, when APS is configured, is bridging the SONET line instead of just section and path as specified in ANSI T1.105.
1557	This extension of VNNI functionality - by permitting the assignment of VPI range instead of a single VPI would benefit lots many customers. Currently, we have following possible config on an AXSM line: - A NNI port, over which you could run PNNI and assign the full 0 -4095 VPI address range. - A UNI port, you have a VPI range 0-255 for terminating connections. - Multiple VNNI ports. Initial definition requires specifying a VPI assignment for the port. You cannot terminate connection on an NNI port. Neither can you route PVP through a VNNI interface. These restrictions have the potential of affecting our customer's business decisions. Implementing this PER will eliminate the above listed constraints on an AXSM port.
1609	The community read string on 8850 was changed to something other than public to close a potential security hole/violation.
1663	This feature is included support ITU-T O.151 based segment OAM loopback test feature.
1092	The conntrace command currently is not synchronous and the prompt is sometimes returned prior to the trace output. The request is to have conntrace command provide a timeout per hop and also to provide an output that shows when the command failed due to a time out. The timer per hop can be up to 5 seconds. Also, the results of the command should be placed at the end of the command display. In addition, a field showing the Terminating InterfaceID should also be provided before the field showing the Terminating Interface VPI.
2182	The Cisco MGX 8850/8950 did not offer a way to configure a preferred route for any connection. Instead the PNNI routing engine configures the route across the network based on configurable routing policies. This feature is available on other Cisco PAR platforms (BPX/IGX) and is used frequently by customers. Customers require the ability to configure a preferred route per connection (VC and VP), and the ability to configure a direct preferred route whereby if the preferred fails the connection is not re routed.
2193	This features implements version control for the SCT files such that the SCT files can have a major version, which would keep track of the parameters being added/deprecated, and a minor version to keep track of modifications to parameters. A SCT management MIB was created to keep CWM and the switch in sync with respect to the SCT files in a node. It also helps CWM in getting the operational status of a SCT file.
2291	The persistent topology feature enables CWM to maintain a persistent topology information of the entire network.
2500	User configurable names for specific SCTs can be entered using CWM and is stored in the switch's database.
2509	A connection summary alarm trap is sent whenever several connections enter into alarm on a service module. The connection summary alarm trap (60306) has been replaced with a newer trap (60311) which contains additional information such as the number of VPCs and VCCs in failure.
2834	This PER tracks PER 20000123 A dsphotstandby command which, when entered on the AXSM, would check for the readiness of the standby AXSM. This would ensure that a switchover to the standby AXSM would be safe.

Service Class Template File Information for Release 3.0.25

There are no new SCT files for Release 3.0.25.

Service Class Template File Information for Release 3.0.23

There are no new SCT files for Release 3.0.23.

Service Class Template File Information for Release 3.0.20

There are no new SCT files for Release 3.0.20.

---

Note SCTs 54 and 55 are for IMA applications. SCTs 52 and 53 are for non-IMA applications. See AXSM Command Ref, addimaport, "Setting the Correct Port SCT" for details (http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/axsm/axcmds.htm).

---

Service Class Template File Information for Release 3.0.10

This section contains service class template (SCT) file information for Release 3.0.10.

AXSM-E

The following are the new AXSM-E SCT files introduced for this release:

•SCT 52—Policing enabled on PNNI, disabled on MPLS, for ATM T1/E1 application, maximum VC/CoSB cell threshold setting is the same between SCT 52 and 53.

•SCT 53—Policing disabled on PNNI and MPLS, for ATM T1/E1 application, maximum VC/CoSB cell threshold setting is the same between SCT 52 and 53.

•SCT 54—Policing enabled on PNNI, disabled on MPLS, IMA group with 1 to 4 links, maximum VC/CoSB cell threshold setting is the same between SCT 54 and 55.

•SCT 55—Policing disabled on PNNI and MPLS, IMA group with 1 to 4 links, maximum VC/CoSB cell threshold setting is the same between SCT 54 and 55.

•SCT6—Policing disabled, used for trunks.

The following are checksums for the new AXSM-E SCT file:

•AXSME_SCT.PORT.52.V1—Check sum = 0x199550ec = 429215980

•AXSME_SCT.PORT.53.V1—Check sum = 0xf6d53485 = 4141167749

•AXSME_SCT.CARD.52.V1—Check sum = 0xde496f2 = 233084658

•AXSME_SCT.PORT.54.V1—Check sum = 0x2a96b5b9 = 714519993

•AXSME_SCT.PORT.55.V1—Check sum = 0x5403c5ac = 1409533356

•AXSME_SCT.PORT.6.V1—Check sum = 0xb69ce935 = 3063736629

FRSM12

The following is the new FRSM12 SCT file introduced for this release:

•SCT 7—Enable WFQ for all ATM service types as the default.

The following are checksums for the new FRSM12 SCT file:

•FRSM12_SCT.CARD.7.V1—Check sum = 0x587dd247 = 1484640839

•FRSM12_SCT.PORT.7.V1—Check sum = 0x58d9a42a = 1490658346

PXM1E

The following are the new PXM1E SCT files introduced for this release:

•SCT 52—Policing enabled.

•SCT 53—Policing disabled.

•SCT 54—Policing enabled.

•SCT 55—Policing disabled.

•SCT6—Policing disabled, used for trunks.

The following are checksums for the new PXM1E SCT files:

•PXM1E_SCT.PORT.52.V1—Check sum = 0x199550ec = 429215980

•PXM1E_SCT.PORT.53.V1—Check sum = 0xf6d53485 = 4141167749

•PXM1E_SCT.PORT.54.V1—Check sum = 0x2a96b5b9 = 714519993

•PXM1E_SCT.PORT.55.V1—Check sum = 0x5403c5ac = 1409533356

•PXM1E_SCT.PORT.6.V1—Check sum = 0xb69ce935 = 3063736629

Service Class Template (SCT) File Information for Release 3.0.00

This section contains SCT file information for Release 3.0.00.

PXM1E

The Service Class Template (SCT) bundle in Release 3.0.00 includes updates:

•PXM1E_SCT.PORT.5

•PXM1E_SCT.PORT.6

The default SCTs provided with Release 3.0.00 are as follows:

•SCT 5 - policing enabled. In general, this is for use on UNI ports.

•SCT 6 - policing disabled. In general, this is for use on NNI ports.

PXM1E_SCT.PORT.5.V1:Check sum is = 0x18a4fdad= 413466029

PXM1E_SCT.PORT.6.V1:Check sum is = 0x2cb30eb7= 749932215

PXM1E does not support CARD SCT. See CSCdx55759 for details.

ABR VSVD parameters are not supported due to hardware limitation.

The above PXM1E SCT files apply to MGX 8850 and MGX 8830.

The Service Class Template (SCT) bundle in Release 3.0.00 includes updates:

•AXSME_SCT.CARD.5

•AXSME_SCT.PORT.5

•AXSME_SCT.PORT.6

AXSM and AXSM/B

•SCT 2 - policing enabled, PNNI

•SCT 3 - policing disabled, PNNI

•SCT 4 - policing enabled, MPLS and PNNI

•SCT 5 - policing disabled, MPLS and PNNI

The check sum for the SCT files are as follows

•AXSM_SCT.PORT.2.V1:Check sum is = 0x78ccfb22= 2026699554

•AXSM_SCT.PORT.3.V1:Check sum is = 0x987919a7= 2558073255

•AXSM_SCT.PORT.4.V1:Check sum is = 0x775bfaa2= 2002516642

•AXSM_SCT.PORT.5.V1:Check sum is = 0xe84c696a= 3897321834

•AXSM_SCT.CARD.2.V1:Check sum is = 0x78ccfb22= 2026699554

•AXSM_SCT.CARD.3.V1:Check sum is = 0x987919a7= 2558073255

•AXSM_SCT.CARD.4.V1:Check sum is = 0x775bfaa2= 2002516642

•AXSM_SCT.CARD.5.V1:Check sum is = 0xe84c696a= 3897321834

A user can do dspsctchksum <filename> to confirm that the checksum of the Cisco-released SCT file and the file on the node match.

AXSM-E

These are the new AXSM-E SCT files:

•SCT 52 - policing enabled, PNNI

•SCT 53 - policing disabled, PNNI

The following are checksums for the new AXSM-E SCT file:

•AXSME_SCT.PORT.52.V1:Check sum is = 0x5bf9af20= 1543089952

•AXSME_SCT.PORT.53.V1:Check sum is = 0x7007c02a= 1879556138

•AXSME_SCT.CARD.52.V1:Check sum is = 0x5bf9af20= 1543089952

FRSM-12-T3E3

The SCT file for FRSM-12-T3E3 has the following changes:

•ATM CAC is not supported.

•UPC cannot be configured using SCT

•WFQ and ABR is not supported in the port SCT

•Cosb min rate and excess priority cannot be configured in the port SCT

•Frame_Discard mode is always set and user should not change it

•SCT 4 - PNNI

The checksum is:

•FRSM12_SCT.PORT.4 checksum = 0x28539d36

• FRSM12_SCT.CARD.4 checksum = 0x28539d36

New Commands for Release 3.0.25

There are no new or changed commands for Release 3.0.25.

New Commands for Release 3.0.20

The following commands are new:

•clrimadelay

•clrnodalconstats

•clrportconstats

•clrportrtcnt

•cnfchanstdabr

•cnfcli

•cnfportconstats

•dspadjlnalm

•dspadjlnalmcnt

•dspcdhealth

•dsphotstandby

•dspnodalconstats

•dspportrtcnt

•dsptech

•forcecdnative

•smclrscrn

Please refer to the following manuals for details about commands:

•The MGX 8830, MGX 8850 (PXM1E and PXM45), and MGX 8950 Command Reference, Release 3, available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/cmdref/index.htm

•The AXSM Software Configuration Guide and Command References for MGX 8850 (PXM45) and MGX 8950, Release 3, available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/axsm/index.htm

System Requirements

This section describes software compatible with this release, and lists the hardware supported in this release.

Software/Firmware Compatibility Matrix

Table 7 lists Cisco WAN or Cisco IOS products that are certified with Release 3.0.25.

Table 7 MGX 3.0.25 Compatibility Matrix 

Product	N	N-1	N-2
CWM	11.0.10P4	N/A	N/A
MGX 8230, 8250, and MGX 8850 (1.x only)	1.2.13	1.2.02	1.1.34
MGX 8850, PXM45	3.0.25	3.0.23	2.1.81
MGX 8850, PXM1E	3.0.25	3.0.23	—
MGX 8830	3.0.25	3.0.23	—
MGX 8950	3.0.23	—	—
BPX/IGX	9.3.45	9.3.36	—
BXM FW	MFV	MFU	—
UXM FW	ACJ	ABU	—
MGX 8220	5.0.19	—	—
SES	3.0.25	1.1.75	—
MGX-RPM-PR-256/512	12.2(15)T	12.2(11)T2	—
MGX-RPM-XF-512	12.2(15)T	—	—
VISM	3.1.2/3.1.1	—	—

MGX and RPM Software Version Compatibility Matrix

Table 8 lists the software that is compatible for use in a switch running Release 3.0.25 software.

Table 8 MGX and RPM Software Version Compatibility Matrix 

Board Pair	Boot Software	Minimum Boot Code Version	Runtime Software	Latest Firmware Version	Minimum Firmware Version
PXM45	pxm45_003.000.025.200_bt.fw	3.0.25	pxm45_003.000.025.200_mgx.fw	3.0.25	3.0.25
PXM45/B
PXM1E-4-155	pxm1e_003.000.025.200_bt.fw	3.0.25	pxm1e_003.000.025.200_mgx.fw (MGX 8850 chassis only)	3.0.25	3.0.25
PXM1E-8-T3E3
PXM1E-16-T1E1
PXM1E-COMBO See note below.
PXM1E-4-155	pxm1e_003.000.025.200_bt.fw	3.0.25	pxm1e_003.000.025.200_m30.fw (MGX 8830 chassis only)	3.0.25	3.0.25
PXM1E-8-T3E3
PXM1E-16-T1E
PXM1E-COMBO See note below.
AXSM-1-2488	axsm_003.000.025.200_bt.fw	3.0.25	axsm_003.000.025.200.fw	3.0.25	3.0.25
AXSM-16-155
AXSM-4-622
AXSM-16-T3/E3
AXSM-1-2488/B
AXSM-16-155/B
AXSM-4-622/B
AXSM-16-T3E3/B
AXSM-16-T3E3-E	axsme_003.000.025.200_bt.fw	3.0.25	axsme_003.000.025.200.fw	3.0.25	3.0.25
AXSM-8-155-E
AXSM-16-T3E3-E
AXSM-32-T1E1-E
FRSM-12-T3E3	frsm12_003.000.025.200_bt.fw	3.0.25	frsm12_003.000.025.200.fw	3.0.25	3.0.25
MGX-VISM-PR-8T1	vism_8t1e1_VI8_BT_3.1.01.fw	3.1.01	vism_8t1e1_003.051.002.000.fw (CALEA version) vism_8t1e1_003.001.002.000.fw (non-CALEA version)	3.51.02 (CALEA),3.01.02 (non-CALEA)	3.51.02 (CALEA),3.01.02 (non-CALEA)
MGX-VISM-PR-8E1
MGX-SRME	—	—	—	—	—
AX-CESM-8E1	cesm_8t1e1_CE8_BT_1.0.02.fw	1.0.02	cesm_8t1e1_020.000.005.200.fw	20.0.5	20.0.5
AX-CESM-8T1
MGX-CESM-8T1/B
MGX-AUSM-8T1/B	ausm_8t1e1_AU8_BT_1.0.02.fw	1.0.02	ausm_8t1e1_020.000.005.200.fw	20.0.5	20.0.5
MGX-AUSM-8E1/B
AX-FRSM-8E1	frsm_8t1e1_FR8_BT_1.0.02.fw	1.0.02	frsm_8t1e1_020.000.005.200.fw	20.0.5	20.0.5
AX-FRSM-8E1-C
AX-FRSM-8T1
AX-FRSM-8T1-C
MGX-FRSM-HS2/B	frsm_vhs_VHS_BT_1.0.05.fw	1.0.04	frsm_vhs_020.000.005.200.fw	20.0.5	20.0.5
MGX-RPM-PR-256	rpm-boot-mz.122-15.T	12.2(15)T	rpm-js-mz.122-15.T	12.2(15)T	12.2(11)T2
MGX-RPM-PR-512
MGX-RPM-XF-512	rpmxf-boot-mz.122-15.T	12.2(15)T	rpmxf-js-mz.122-15.T	12.2(15)T	12.2(15)T

---

Note The PXM1E-COMBO card is also known as the PXM1E-T3E3-155 card.

---

Additional Notes

The SNMP MIB release for 3.0.25 is mgxmibs3020.tar.

Table 9 shows the various types of APS protocols that are supported on the AXSM/A and AXSM/B cards, and the MGX release that provides the support.

Table 9 APS Protocol Support 

Op Mode (APS Protocol)	Card Types
	AXSM/A	AXSM/B
Op_A mode (GR253)	Release 2.1.x and higher	Release 2.1.x and higher
Op_B mode (GR253, ITU-T Annex A/B)	—	Release 3.0.00 and higher

Hardware Supported

This section lists Product IDs, 800 part numbers, and revision levels for MGX 8950 cards. It also lists MGX 8950 front and back card types, and whether APS connectors are supported.

This section lists:

•MGX 8850 (PXM45) Product IDs, 800 part numbers, and revision levels

•MGX 8850 (PXM1E) Product IDs, 800 part numbers, and revision levels

•MGX 8830 Product IDs, 800 part numbers, and revision levels

Front and back card types, and whether APS connectors are supported for

•MGX 8850 (PXM45)

•MGX 8850 (PXM1E)

•MGX 8830

APS Connectors

Table 10 lists MGX 8850 (PXM45) APS connectors.

Table 10 MGX 8850 (PXM45) APS Connectors

Hardware	MGX-8850-APS-CON (800-20640-01)	MGX-APS-CON (800-05307-01)
AXSM-16-155	Yes	Yes
AXSM-16-155/B	Yes	Yes
AXSM-4-622	Yes	Yes
AXSM-4-622/B	Yes	Yes
AXSM-1-2488	Yes	Yes
AXSM-1-2488/B	Yes	Yes
AXSM-8-155-E	Yes	Yes
AXSM-2-622-E	Yes	Yes
MGX-SRME	Yes	No

Table 11 lists MGX 8850 (PXM1E) APS connectors.

Table 11 MGX 8850 (PXM1E) APS Connectors 

Hardware	MGX-8850-APS-CON (800-20640-01)	MGX-APS-CON (800-05307-01)
PXM1E-4-155	Yes	Yes
PXM1E-COMBO (See note below)	Yes	Yes
MGX-SRME	Yes	No

Table 12 lists MGX 8830 APS connectors.

Table 12 MGX 8830 APS Connectors

Hardware	MGX-8830-APS-CON (800-05308-02)
PXM1E-4-155	Yes
PXM1E-COMBO (See note below)	Yes
MGX-SRME	No

---

Note The PXM1E-COMBO card is also known as the PXM1E-T3E3-155 card.

---

---

Note The MGX-SRME card does not need the APS-CON connector for APS.

---

MGX 8850 (PXM45) Product IDs and Card Types

Table 13 lists Product IDs, 800 part numbers, and revision levels for the MGX 8850 (PXM45).

Table 13 Card Numbers and Revisions Supported in Release 3.0.25 for MGX 8850 (PXM45)
 

Product ID	800 Part Number	Minimum Revision
PXM-UI-S3	800-05787-02	-A0
PXM-HD	800-05052-03	-A0
PXM45	800-06147-07	-B0
PXM45/B	800-09266-04	-A0
AXSM-1-2488	800-05795-05	-A0
AXSM-1-2488/B	800-07983-02	-A0
AXSM-2-622-E	800-18521-02	-A0
AXSM-4-622	800-05774-09	-B0
AXSM-4-622/B	800-07910-05	-A0
AXSM-8-155-E	800-18520-02	-A0
AXSM-16-155	800-05776-06	-A0
AXSM-16-155/B	800-07909-05	-A0
AXSM-16-T3E3	800-05778-08	-A0
AXSM-16-T3E3/B	800-07911-05	-A0
AXSM-16-T3E3-E	800-18519-02	-A0
AXSM-32-T1E1-E	800-22229-01	-A0
SMFLR-1-2488	800-06635-04	-A0
SMFSR-1-2488	800-05490-05	-A0
SMFXLR-1-2488	800-05793-05	-A0
SMFLR-1-2488/B	800-08847-01	-A0
SMFSR-1-2488/B	800-07255-01	-A0
SMFXLR-1-2488/B	800-08849-01	-A0
SMFIR-1-622/C	800-07410-02	-A0
SMFLR-1-622/C	800-07411-02	-A0
SMFIR-2-622	800-05383-01	-A1
SMFLR-2-622	800-05385-01	-A1
SMFIR-2-622/B	800-07412-02	-B0
SMFLR-2-622/B	800-07413-02	-B0
MMF-4-155/C	800-07408-02	-A0
SMFIR-4-155/C	800-07108-02	-A0
SMFLR-4-155/C	800-07409-02	-A0
SMB-4-155	800-07425-02	-A0
MMF-8-155-MT	800-04819-01	-A1
SMFIR-8-155-LC	800-05342-01	-B0
SMFLR-8-155-LC	800-05343-01	-C0
MMF-8-155-MT/B	800-07120-02	-A0
SMFIR-8-155-LC/B	800-07864-02	-B0
SMFLR-8-155-LC/B	800-07865-02	-B0
SMB-8-E3	800-04093-02	-A0
SMB-8-T3	800-05029-02	-A0
MCC-16-E1	800-19853-02	-A0
RBBN-16-T1E1	800-21805-03	-A0
FRSM-12-T3E3	800-18731-02	-A0
SMB-6-T3E3	800-08799-01	-A0
MGX-VISM-PR-8E1	800-07991-02	-A0
MGX-VISM-PR-8T1	800-07990-02	-A0
AX-RJ48-8T1	800-02286-01	-A0
AX-R-RJ48-8T11	800-02288-01	-A0
AX-RJ48-8E1	800-02408-01	-A0
AX-R-RJ48-8E11	800-02409-01	-A0
AX-SMB-8E1	800-02287-01	-A0
AX-R-SMB-8E11	800-02410-01	-A0
MGX-SRME	800-14224-02	-A0
MGX-SMFIR-1-155	800-14460-02	-A0
MGX-STM1-EL-1	800-14479-02	-A0
MGX-RPM-PR-256	800-07178-02	-A0
MGX-RPM-PR-512	800-07656-02	-A0
MGX-RPM-XF-512	800-09307-06	-A0
MGX-MMF-FE	800-03202-02	-A0
MGX-RJ45-4E/B	800-12134-01	-A0
MGX-RJ45-FE	800-02735-02	-A0
MGX-XF-UI	800-09492-01	-A0
MGX-1GE	800-18420-03	-A0
MGX-1OC12POS-IR	800-08359-05	-A0
MGX-GE-LHLX	30-1299-01	-A0
MGX-GE-SX	30-1301-01	-A0
MGX-GE-ZX	10-1439-01	-A0
MGX-APS-CON2	800-05307-01	-A0
MGX-8850-APS-CON1	800-20640-01	-A0

1 R means that this is a redundant card. 2 Either connector works for the AXSM cards in the MGX 8850 (PXM45).

Table 14 lists MGX 8850 (PXM45) front and back card types and whether APS connectors are supported.

Table 14 MGX 8850 (PXM45) Front and Back Card Types and Supported APS Connectors
 

Front Card Type	Back Card Types	Supports APS Connector (MGX APS-CON or MGX-8850-APS-CON)
PXM45	PXM-HD	—
	PXM-UI-S3	—
PXM45/B	PXM-HD	—
	PXM-UI-S3	—
AXSM-1-2488	SMFSR-1-2488	Yes
	SMFLR-1-2488	Yes
	SMFXLR-1-2488	Yes
AXSM-1-2488/B	SMFSR-1-2488/B	Yes
	SMFLR-1-2488/B	Yes
	SMFXLR-1-2488/B	Yes
AXSM-2-622-E	SMFIR-1-622/C	Yes
	SMFLR-1-622/C	Yes
AXSM-4-622	SMFIR-2-622	Yes
	SMFLR-2-622	Yes
AXSM-4-622/B	SMFIR-2-622/B	Yes
	SMFLR-2-622/B	Yes
AXSM-8-155-E	SMB-4-155	Yes
	MMF-4-155/C	Yes
	SMFIR-4-155/C	Yes
	SMFLR-4-155/C	Yes
AXSM-16-155	MMF-8-155-MT	Yes
	SMFIR-8-155-LC	Yes
	SMFLR-8-155-LC	Yes
AXSM-16-155/B	SMB-4-155	Yes
	MMF-8-155-MT/B	Yes
	SMFIR-8-155-LC/B	Yes
	SMFLR-8-155-LC/B	Yes
AXSM-16-T3E3, AXSM-16-T3E3/B AXSM-16-T3E3-E	SMB-8-T3	—
	SMB-8-E3	—
AXSM-32-T1E1-E	MCC-16-E1	—
	RBBN-16-T1E1	—
FRSM-12-T3E3	SMB-6-T3E3	—
MGX-VISM-PR-8T1	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
MGX-VISM-PR-8E1	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
MGX-SRME	MGX-SMFIR-1-155	Yes
	MGX-STM1-EL-1	Yes
MGX-RPM-PR-256 MGX-RPM-PR-512	MGX-MMF-FE	—
	MGX-RJ45-4E/B	—
	MGX-RJ45-FE	—
MGX-RPM-XF-512	MGX-XF-UI	—
	MGX-1GE	—
	MGX-1OC12POS-IR	—
	MGX-GE-LHLX1	—
	MGX-GE-SX1	—
	MGX-GE-ZX1	—

1 Small form factor pluggable optical transceivers for MGX-1GE back card.

MGX 8850 (PXM1E) Product IDs and Card Types

Table 15 contains Product IDs, 800 part numbers, and revision levels for the MGX 8850 (PXM1E).

Table 15 Card Numbers and Revisions Supported in Release 3.0.25 for MGX 8850 (PXM1E)
 

Product ID	800 P/N	Minimum Revision
PXM1E-4-155	800-18588-03	-A0
PXM1E-8-T3E3	800-18590-03	-A0
PXM1E-16-T1E1	800-18658-04	-A0
PXM1E-COMBO (See note below)	800-18604-03	-A0
MMF-4-155/C	800-07408-02	-A0
SMFIR-4-155/C	800-07108-02	-A0
SMFLR-4-155/C	800-07409-02	-A0
PXM-UI-S3/B	800-21557-01	-A0
SMB-8-T3	800-05029-02	-A0
SMB-8-E3	800-04093-02	-A0
MGX-T3E3-155	800-18698-02	-A0
MMF-1-155-SFP1	10-1308-01	-A0
SMFLR-1-155-SFP1	10-1280-01	-A0
SMFIR-1-155-SFP	10-1283-01	-A0
MCC-16-E1	800-19853-02	-A0
RBBN-16-T1E1	800-21805-03	-A0
MGX-VISM-PR-8T1	800-07990-02	-A0
MGX-VISM-PR-8E1	800-07991-02	-A0
MGX-SRME	800-14224-02	-A0
MGX-SMFIR-1-155	800-14460-02	-A0
MGX-STM1-EL-1	800-14479-02	-A0
MGX-RPM-PR-256	800-07178-02	-A0
MGX-RPM-PR-512	800-07656-02	-A0
MGX-MMF-FE	800-03202-02	-A0
MGX-RJ45-4E/B	800-12134-01	-A0
MGX-RJ45-FE	800-02735-02	-A0
MGX-AUSM-8T1/B	800-04809-01	-A0
MGX-AUSM-8E1/B	800-04810-01	-A0
AX-CESM-8E1	800-02751-02	-A0
AX-CESM-8T1	800-02750-02	-A0
MGX-CESM-8T1/B	800-08613-02	-A0
AX-FRSM-8T1	800-02437-04	-A0
AX-FRSM-8E1	800-02438-04	-A0
AX-FRSM-8T1-C	800-02461-04	-A0
AX-FRSM-8E1-C	800-02462-04	-A0
MGX-FRSM-HS2/B	800-17066-01	-A0
AX-SMB-8E1	800-02287-01	-A0
AX-R-SMB-8E12	800-02410-01	-A0
AX-RJ48-8E1	800-02408-01	-A0
AX-R-RJ48-8E12	800-02409-01	-A0
AX-RJ48-8T1	800-02286-01	-A0
AX-R-RJ48-8T12	800-02288-01	-A0
MGX-12IN1-8S	800-18302-01	-A0
SCSI2-2HSSI/B3	800-05463-02	-A0
	800-05501-01	-A0
MGX-8850-APS-CON	800-20640-01	-A0
MGX-APS-CON	800-05307-01	-A0

1 These cards are required only if you need modular optics with the PXM1E-COMBO back card. 2 R means that this is a redundant card. 3 The SCSI2-2HSSI/B card has two different 800 part numbers, and both part numbers are valid.

Table 16 lists MGX 8850 (PXM1E) front and back card types and whether APS connectors are supported.

Table 16 MGX 8850 (PXM1E) Front and Back Card Types and Supported APS Connectors
 

Front Card Type	Back Card Types	Needs APS-CON?
PXM1E-4-155	MMF-4-155/C	Yes
	SMFIR-4-155/C	Yes
	SMFLR-4-155/C	Yes
	PXM-UI-S3/B	—
PXM1E-8-T3E3	SMB-8-T3	—
	SMB-8-E3	—
	PXM-UI-S3/B	—
PXM1E-16-T1E1	PXM-UI-S3/B	—
	MCC-16-E1	—
	RBBN-16-T1E1	—
PXM1E-COMBO (See note below.)	MGX-T3E3-155	—
	MMF-1-155-SFP21	—
	SMFLR-1-155-SFP1	—
	SMFIR-1-155-SFP1	—
	PXM-UI-S3/B	—
MGX-VISM-PR-8T1	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
MGX-VISM-PR-8E1	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
MGX-SRME	MGX-SMFIR-1-155	Yes
	MGX-STM1-EL-1	Yes
MGX-RPM-PR-256 MGX-RPM-PR-512	MGX-MMF-FE	—
	MGX-RJ45-4E/B	—
	MGX-RJ45-FE	—
MGX-AUSM-8T1/B	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
MGX-AUSM-8E1/B	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
AX-CESM-8E1	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
MGX-CESM-8T1/B	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
AX-FRSM-8T1	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
AX-FRSM-8E1	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
AX-FRSM-8T1-C	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
AX-FRSM-8E1-C	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
MGX-FRSM-HS2/B	SCSI2-2HSSI/B	—
	MGX-12IN1-8S	—

1 Small form factor pluggable optical transceivers for PXM1E-COMBO back card.

---

Note The PXM1E-COMBO card is also known as the PXM1E-T3E3-155 card.

---

MGX 8830 Product IDs and Card Types

Table 17 lists Product IDs, 800 part numbers, and revision levels for the MGX 8830.

Table 17 Card Numbers and Revisions Supported in Release 3.0.25 for MGX 8830 

Product ID	800 P/N	Minimum Revision
PXM1E-4-155	800-18588-03	-A0
PXM1E-8-T3E3	rta800-18590-03	-A0
PXM1E-16-T1E1	800-18658-04	-A0
PXM1E-COMBO (See note below)	800-18604-03	-A0
MMF-4-155/C	800-07408-02	-A0
SMFIR-4-155/C	800-07108-02	-A0
SMFLR-4-155/C	800-07409-02	-A0
PXM-UI-S3/B	800-21557-01	-A0
SMB-8-T3	800-05029-02	-A0
SMB-8-E3	800-04093-02	-A0
MGX-T3E3-155	800-18698-02	-A0
MMF-1-155-SFP1	10-1308-01	-A0
SMFLR-1-155-SFP1	10-1280-01	-A0
SMFIR-1-155-SFP	10-1283-01	-A0
MCC-16-E1	800-19853-02	-A0
RBBN-16-T1E1	800-21805-03	-A0
MGX-SRME	800-14224-02	-A0
MGX-SMFIR-1-155	800-14460-02	-A0
MGX-STM1-EL-1	800-14479-02	-A0
MGX-RPM-PR-256	800-07178-02	-A0
MGX-RPM-PR-512	800-07656-02	-A0
MGX-MMF-FE	800-03202-02	-A0
MGX-RJ45-4E/B	800-12134-01	-A0
MGX-RJ45-FE	800-02735-02	-A0
MGX-AUSM-8T1/B	800-04809-01	-A0
MGX-AUSM-8E1/B	800-04810-01	-A0
AX-CESM-8E1	800-02751-02	-A0
AX-CESM-8T1	800-02750-02	-A0
MGX-CESM-8T1/B	800-08613-02	-A0
AX-FRSM-8T1	800-02437-04	-A0
AX-FRSM-8E1	800-02438-04	-A0
AX-FRSM-8T1-C	800-02461-04	-A0
AX-FRSM-8E1-C	800-02462-04	-A0
AX-SMB-8E1	800-02287-01	-A0
AX-R-SMB-8E12	800-02410-01	-A0
AX-RJ48-8E1	800-02408-01	-A0
AX-R-RJ48-8E1	800-02409-01	-A0
AX-RJ48-8T1	800-02286-01	-A0
AX-R-RJ48-8T1	800-02288-01	-A0
MGX-12IN1-8S	800-18302-01	-A0
MGX-FRSM-HS2/B	800-17066-01	-A0
SCSI2-2HSSI/B3	800-05463-02	-A0
	800-05501-01	-A0
MGX-VISM-PR-8E1	800-07991-02	-A0
MGX-VISM-PR-8T1	800-07990-02	-A0

1 These cards are required only if you need modular optics with the PXM1E-COMBO back card. 2 R means this is a redundant card. 3 The SCSI2-2HSSI/B card has two different 800 part numbers, and both part numbers are valid.

---

Note The PXM1E-COMBO card is also known as the PXM1E-T3E3-155 card.

---

Table 18 lists MGX 8830 front and back card types and whether APS connectors are supported.

Table 18 MGX 8830 Front and Back Card Types and Supported APS Connectors
 

Front Card Type	Back Card Types	Needs APS-CON?
PXM1E-4-155	MMF-4-155/C	Yes
	SMFIR-4-155/C	Yes
	SMFLR-4-155/C	Yes
	PXM-UI-S3/B	—
PXM1E-8-T3E3	SMB-8-T3	—
	SMB-8-E3	—
	PXM-UI-S3/B	—
PXM1E-COMBO (See note below.)	MGX-T3E3-155	No
	MMF-1-155-SFP1	—
	SMFLR-1-155-SFP1	—
	SMFIR-1-155-SFP1	—
	PXM-UI-S3/B	—
PXM1E-16-T1E1	MCC-16-E1	—
	RBBN-16-T1E1	—
	PXM-UI-S3/B	—
MGX-SRME	MGX-SMFIR-1-155	Yes
	MGX-STM1-EL-1	Yes
MGX-RPM-PR-256 MGX-RPM-PR-512	MGX-MMF-FE	—
	MGX-RJ45-4E/B	—
	MGX-RJ45-FE	—
MGX-AUSM-8T1/B	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
MGX-AUSM-8E1/B	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
AX-CESM-8E1	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
AX-CESM-8T1	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
MGX-CESM-8T1/B	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
AX-FRSM-8E1	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
AX-FRSM-8T1-C	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
AX-FRSM-8E1-C	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—
MGX-FRSM-HS2/B	SCSI2-2HSSI/B	—
	MGX-12IN1-8S	—
MGX-VISM-PR-8T1	AX-RJ48-8T1	—
	AX-R-RJ48-8T1	—
MGX-VISM-PR-8E1	AX-SMB-8E1	—
	AX-R-SMB-8E1	—
	AX-RJ48-8E1	—
	AX-R-RJ48-8E1	—

1 Small form factor pluggable optical transceivers for the PXM1E-COMBO back card.

---

Note The PXM1E-COMBO card is also known as the PXM1E-T3E3-155 card.

---

Limitations, Restrictions, and Notes

This section includes information about limitations, restrictions, and notes pertaining to Release 3.0.25.

Release 3.0.25 Limitations

•No new limitations for Release 3.0.25.

Release 3.0.23 Limitations

Bandwidth Limitations with IMA Ports

In previous 3.0.x Releases, for IMA NNI ports, when there is a change in the available IMA bandwidth (for example when one T1/E1 line in the IMA group goes down), PNNI does not learn nor advertise the change in bandwidth. As a consequence, SVC and SPVC connections are accepted when there is not enough bandwidth. Also, if the bandwidth has gone down even below the sum of the connections that have already been committed, no action is being taken. The result is that we loose data traffic on all the connections.

To rectify the above stated problem, starting with Release 3.0.23, the Service Module will inform the controller of the bandwidth reduction and we will be releasing the required number of connections such that the current usage is equal to or lesser than the new physical bandwidth. There is no guarantee that the same connections will be released at both sides of the trunk. To ensure this we will have to initiate the release from only one side of the trunk.

For the different types of trunks (PNNI, IISP and AINI) the following conditions will be used to decide whether the local node has to initiate the release of the connections:

•IISP: This side of the link is configured as the network_side.

•PNNI: The local node has a higher nodeId than the node at the other end of the trunk.

•AINI: vpivcialloc option has been enabled for this side of the trunk.

The following commands can be of used to identify the problem:

•dspimagrp - Specifies the Avail Cell Rate (c/s) in the IMA Groups.

•dsppnportrsr - Specifies the Available BW used in the PNNI port.

•dsppnni-idb - Specifies the Available Bandwidth (AvCR) advertised by PNNI.

•dsppnni-ptse -detail true - Specifies the PNNI database, including the Horiz Links and their respective AvCR.

The solution to initiate the release of connections from the node with the higher node ID for a NNI link might not always work. Consider the following scenario:

1) One end of the IMA trunk is configured with a higher maximum cell rate than the other end. The end of the trunk configured with the higher maximum cell rate is hosted on a node with a higher node ID and the other end with the lower maximum cell rate is on a node with a lower node ID.

2) This trunk has connections routed, which have used up till the maximum cell rate on the end with the lower maximum cell rate.

3) Now if there is a IMA link loss in the IMA group, it will result in the maximum cell rate going down at both the ends. On the node with the higher node ID if this new maximum cell rate is still greater than what is used, this node will not initiate the release of the required number of connections. As a result of this data traffic will be lost on all the connections.

The latter limitation applies to IISP and AINI trunks as well:

1) If the side of the IISP link configured as the "network_side" has a higher maximum cell rate.

2) If the side of the AINI link configured as the "vpi/vci-allocator" has a higher maximum cell rate. (refer to Caveat CSCea14630)

Release 3.0.20 Limitations

AXSM-E OAM

•If the connection is in the ingress (remote) loopback mode, then the connection can receive OAM loopback cells up to the line rate (as long as the policing policy permits).

•If the connection is not in the loopback mode and is operating in the normal mode, then the AXSM-E card can receive up to 8K OAM loopback cells per second. Any excessive OAM loopback cell will dropped. This limitation applies for all the connections.

For example, if there is only one connection, then that connection can receive 8K loopback cells per second. If there are 9K connections on an AXSM-E card and one OAM loopback cell per second is being pumped through on each connection, then there can only be up to 8K connections to receive loopback cells at any given second, and the additional 1K connections would not receive for that second.

The limitation is 8K OAM loopback cells is per card and not per connection. Also, only OAM loopback cells pumped from the line on the ingress side of an endpoint can be handled. OAM loopback cells from the egress side are not handled because OAM loopback cells from the egress side can only be initiated by the CLI.

CLI Configurable Access

•Not all CLI commands are allowed to be changed and a command cannot be changed to CISCO_GP group access level.

•Only the switch software is allowed to generate the binary file. This file has an authentication signature which has to be validated before the file can be used. Any manual changes to the file would make the file void.

•If the binary file becomes corrupted, then the command access levels revert back to the default values during the card bring-up. To recover, repeat the installation process or retain a copy of the binary file and do cnfcli accesslevel install on that service module.

•Currently, command names are verified, but an invalid command name may be parsed and be added to the binary file. However, this invalid name would be ignored later.

•If replication to standby failed, the installation process failed.

•cnfcli accesslevel default restores all command access levels to default for the service module that this command is executed on. It does not remove the binary file and this change is not persistent. If it is executed on the active card of a redundancy pair, the standby card is not affected. When the card is reset and the binary file exists, it will configure from the binary file when it is brought up.

Controller Card Mastership Sanity Verification

•Because the solution provided in this release can only detect and log invalid mastership state transitions, an outage may still occur.

Serial Bus Path Fault Isolation

•The Serial Bus Fault Isolation feature only addresses isolating errors on the local cards. However, when a common error occurs on the switching fabric card, this solution does not address this. As a result, if there is a problem on the PXM card or the XM60, the fault is going to be reported against all cards that detected the symptoms of this problem.

Cell Bus Path Fault Isolation and Recovery

•The isolation procedures can isolate the Cell Bus path involving the QE SAR that is used for polling the Serial Bus based Service Modules (e.g., AXSM, AXSM/B, AXSM-E,) and all the communication with the standby controller card and the Cell Bus Based Service Modules (e.g., FRSM, CESM). These procedures can't isolate the Cell Bus path failures involving ATMizer SAR that is used for the inter-card communication except polling, between the active controller card and the Serial Bus based Service Modules (e.g., AXSM, AXSM/B, AXSM-E).

•The isolation procedures isolate the Cell Bus path failures to the active controller card only. This means, it is determined whether the active controller card has the fault for the inter-card communication over the Cell Bus from the active controller card to the Service Modules and the standby controller card or not. It does not isolate the fault if the active controller card fails to communicate with some cards and successfully communicates with the rest on the Cell Bus.

•There should be at least 2 cards (2 Service Modules or 1 Service Module and 1 standby PXM) for the isolation procedures to be able to isolate the Cell Bus path failures to the active controller card.

•Only the failures detected by periodic polling triggers the isolation procedures. Failures reported from other sources in the system against a Service Module or the standby controller card due to the Cell Bus path failures don't initiate the isolation procedures, and which results in resetting that card against which the failure is reported, even while the active controller card is in the process of isolating the Cell Bus path failures triggered by the polling failures.

•There is no separate trap/alarm generated against the active controller card Cell Bus path when the fault is isolated to the active controller card. Only the event logs will be available that can be used during the manual investigation triggered by the card reset and/or switchover traps.

•If there is no controller card redundancy available, isolating the Cell Bus path failure to active controller card results in outage as the active controller card will be reset.

FRSM-12-T3E3 Card

•Because of the hardware limitation of the current FPGA Egress Frame Engine in the Frame Relay Service Inter-Working mode, the egress aggregate cell rate should not go over the DS3 rate (104,268).

For example, assume that there is an SPVC connection with a maximum CIR (44,210,000) provisioned between a port on a FRSM-12-T3E3 card and a port on a AXSM card in a same node. On the FRSM-12-T3E3 side the connection is configured as in mode chanType = 3 (frSIWtranslate:Frame Relay Service Inter-Working, translation).

If the AAL5 PDU traffic pumped into the connection of the AXSM port (for example from an AdTech tester) is coming in at a rate higher than DS3, the Egress Frame Engine may not be able to handle this high rate and the encapsulation translation error may occur.

•The default DE to CLP and CLP to DE mapping in the CLI command addcon, which are "mapCLP" and "mapDE", are taken from the SCT 0 file instead of the SCT files associated with the port. This happens for the following FR channel types:NIW, NIW replace, SIW transparent, and SIW translation. To make the mapping consistent with the default values in the SCT file, you need to use SNMP MIB chanDEtoCLPmap, chanCLPtoDEmap or CLI options -demap, -clpmap to set the values. (Refer to caveat CSCdz47385.)

•When issuing the CLI command cnfpart -lcn <#lcns>, the wrong error code is returned when the configure resource partition command cnfpart is issued when the number of logical connections is greater than the available logical connections on the card. The error code from the cnfpart command should be:

ERR:Cannot allocate requested LCNs for partition

But the following error message is displayed:

ERR:Cannot modify LCN range due to configured connections

(Refer to caveat CSCdz47806.)

•If you disable LMI on a port, then enable/configure it again, the LMI counters are not re-initialized. The previous LMI counts and errors will be added to the new ones. A simple workaround is to clear the counters on the port. (Refer to caveat CSCdz30469.)

Release 3.0.10 Limitations

AXSM-32-T1E1-E Card

•Only 10 SVC calls per second is guaranteed.

•FDL support for loopback code detection is not supported.

•Far-end line performance counters are supported only for the E1 interface. They are not supported for the T1 interface.

•HMM support is not available for IMA-32 and the Framer devices.

•IMA link alarms, LIF and LODS integration times are not configurable.

•An IMA group configured for Version 1.1 does not fall back to Version 1.0 if the far-end IMA group is configured with Version 1.0.

•Auto-restart (persistent Rx IMA ID) feature is not supported.

•When there is a switchover, it can take up to 3.5 seconds for the IMA groups to recover. Data is lost until the groups recover.

•Support for UNI and virtual trunking on IMA groups is not available. But UNI and virtual trunking on non-IMA T1/E1 ATM lines is available.

•Support for UNI IMA is not available.

•IMA group cannot have links from the upper and lower bays together.

•ITC clocking mode on IMA is not supported.

•Transmission delay of more than 500 ms on the T1/E1 IMA links is not supported.

•GTSM (Group Traffic State Machine) up and down integration times should be configured to values of 0 (zero) only.

•There is a 5-ms fluctuation on IMA delay tolerance.

•While the IMA group accumulated delay is being removed with clrimadelay, the following apply:

–Any changes to this IMA group configuration at NE are blocked.

–Any changes in the FE IMA links in this group can cause the NE IMA group to restart.

•The VC and COSB thresholds are updated as and when the links are added or deleted from the IMA groups. The thresholds for the connections added when there are N links in the group can differ from the connections added when there are (N+1) links in the IMA group.

•Round trip propagation delay of more than 1 second on IMA links is not supported.

•The CLI clrimadelay or the corresponding SNMP set operation is issued to remove accumulated delay from an IMA group. While delay is being removed, the following CLIs must not be executed. They will return error if issued. The corresponding SNMP set operations will also be rejected:

–delimagrp

–cnfatmimagrp

–cnfimagrp

–upimagrp

–dnimagrp

–rstrtimagrp

–addimalnk

–clrimadelay

–startimalnktst

–cnfimalnktst

–stopimalnktst

–delimalnk

•Any of the following operations can extend the delay removal completion by 9 seconds.

–IMA link deletion at *FE*

–IMA group restart at *FE*

–IMA link transition into Unusable state at *FE*

–IMA link entrance into LIF failure at *NE*

Then the group will be restarted and it may take another 3 seconds to become operational. The group will be restarted even if the delay process completes sooner and any of the operations listed above occurs.

•GTSM (Group Traffic State Machine) UP and DOWN integration times should be configured to a value of 0 for all IMA groups. Any positive value, especially the UP time, will delay the operational state of any port(s), configured on the IMA group, from becoming active. This can cause more than desired traffic loss during a card switchover.

•BERT is supported only on the T1 interfaces. It is not supported on the E1 interfaces.

•Sub-slot and port identifiers do not correspond to the exact physical attribute for IMA and channelized interfaces as they used to in the old unchannelized interfaces. Refer to the DDTS issue CSCdy08500 for more information. The following apply to the AXSM-32-T1E1-E card in Release 3.0.10:

–If the logical port on the SM is deleted, the corresponding pnport on the controller, that is, PXM45, should be deleted.

–The port number in the pnport (shelf.slot:subslot.port:subport) could be a random number. The user should not interpret this number as line or IMA group number.

PXM1E-16-T1E1 Card

•Only 10 SVC calls per second is guaranteed.

•FDL support for loopback code detection is not supported.

•Far-end line performance counters are supported only for the E1 interface. They are not supported for the T1 interface.

•HMM support is not available for IMA-32 and the Framer devices.

•IMA link alarms, LIF and LODS integration times are not configurable.

•An IMA group configured for Version 1.1 does not fall back to Version 1.0 if the far-end IMA group is configured with Version 1.0.

•Auto-restart (persistent Rx IMA ID) feature is not supported.

•When there is a switchover, it can take up to 3.5 seconds for the IMA groups to recover. Data is lost until the groups recover.

•Support for UNI IMA, virtual trunking on IMA groups, and T1/E1 ATM lines are not available.

•Support for UNI is not available.

•ITC clocking mode on IMA is not supported.

•Transmission delay of more than 500 ms on the T1/E1 IMA links is not supported.

•GTSM (Group Traffic State Machine) up and down integration times should be configured to a value of 0 (zero) only.

•There is a 5-ms fluctuation on IMA delay tolerance.

•While the IMA group accumulated delay is being removed with the clrimadelay command, the following apply:

–Any changes to this IMA group configuration at NE are blocked.

–Any changes in the FE IMA links in this group can cause the NE IMA group to restart.

•The VC and COSB thresholds are updated as and when the links are added/deleted from the IMA groups. The thresholds for the connections added when there are N links in the group can differ from connections added when there are (N+1) links in the IMA group.

•Round trip propagation delay of more than 1 second on IMA links is not supported.

•The CLI clrimadelay or the corresponding SNMP set operation is issued to remove accumulated delay from an IMA group. While delay is being removed, the following CLIs must not be executed. They will return error if issued. The corresponding SNMP set operations will also be rejected:

–delimagrp

–cnfatmimagrp

–cnfimagrp

–upimagrp

–dnimagrp

–rstrtimagrp

–addimalnk

–clrimadelay

–startimalnktst

–cnfimalnktst

–stopimalnktst

–delimalnk

•Any of the following operations can extend the delay removal completion by 9 seconds.

–IMA link deletion at *FE*

–IMA group restart at *FE*

–IMA link transition into Unusable state at *FE*

–IMA link entrance into LIF failure at *NE*

Then the group will be restarted and it may take another 3 seconds to become operational. The group will be restarted even if delay process completes sooner and any of the operations listed above occurs.

•GTSM (Group Traffic State Machine) UP and DOWN integration times should be configured to a value of 0 for all IMA groups. Any positive value, especially the UP time, will delay the operational state of any port(s), configured on the IMA group, from becoming active. This can cause more than desired traffic loss during a card switchover.

•BERT is supported only on the T1 interfaces. It is not supported on the E1 interfaces.

PXM1E Cards

•The maximum number of connections on the PXM1E cards (except for the PXM1E-16-T1E1 card) is 27K, and the maximum number of ports on these cards (except for the PXM1E-16-T1E1 card) is 4K.

•The dspapsbkplane command does not work for the PXM1E-4-155 card.

•An LOS condition on an APS line will not be reported by the dspalms command if both the following are true:

–The PXM1E card has SONET lines, and

–Either the APS line with the LOS condition is the Protection line for intracard APS, or the APS line with the LOS condition is the adjacent back card line for intercard APS. For example, if line 1 on slot 7 is the Working line and line 1 on slot 8 is the Protection line, then an LOS on line 1 in slot 8 will not be reported when dspalms is issued on slot 7, assuming slot 7 has the Active front card. The dspadjlnalm command will also not report LOS in this situation.

All other conditions (LOF, OOF, etc.) are reported correctly (refer to caveat CSCdy30310).

•For uplink ports on all PXM1E cards, the standby controller card is not able to derive clock signals from the standby uplink port (daughter card) due to a hardware limitation. No data signals can be received on the standby card and clock signals cannot be recovered. On switchovers, the uplink clock sources will be requalified (refer to caveat CSCdy68971).

•When a back card is inserted or removed, verify that the back card is accessible by reading a register on the back card. If the front card is not able to read the register, the back card will be put into the mismatch state. If the problem happens on the active card and if the standby card is available, card will be switched over. Otherwise the back card is put into mismatch state. If the problem also happens on the standby card, the backcard will be put into mismatch state. A message will be put into dsplog to show that the back card is not considered to be in a healthy state. This message should be ignored when it is logged when the card is in the Init (I) state. Only messages logged in either the Active (A) or Standby (S) states are valid.

When intercard APS is configured, the active front card takes control of the standby back card. The standby front card will not be able to determine the local back card health because it does not have control of its own back card. When intercard APS is configured for the PXM1E-COMBO (also known as PXM1E-T3E3-155) card, and if all the SONET lines on the standby card displays an alarm, the shellcon function dspAdjBcHealth(0) should be used to determine the alternate back card's health. This back card health detection is available only for the PXM1E-COMBO card (refer to caveat CSCdy39859).

PXM1E Online Diagnostics

•Online diagnostics uses VPI=32 and VCI=31 for a connection setup. No other connection (data or control) should use this VPI/VCI pair. Using this VPI/VCI pair may result in the failure of the online diagnostics (if enabled) and the card will subsequently be placed in the failed state.

MGX-SRME Card

•MGX-SRME APS provisioning will be blocked on all unsupported PXM45 cards and a proper warning message displayed.

•This feature provides the capability to guard against fiber cut and line failures. It minimizes the traffic loss by switching to the protection line when it detects a problem on the working line.

•This feature relies on the interrupt line coming from the MGX-SRME card to the PXM45/B. PXM45/B boards have an interrupt line to MGX-SRME card. MGX-SRME APS will work only on PXM45/B having 800-level part number equal or greater than 800-09266-03.

FRSM-12-T3E3 Card

•On an FRSM-VHS, all connections on a port with LMI enabled will have those connection statuses initialized to okay. If the connection is actually in LMI abit alarm, then the connection alarm will be updated to the correct state (LMI abit alarm) via asynchronous updates or the periodic full state update. On a resetcd on an FRSM-12-T3E3 card, all connections on a port with LMI enabled will have those connection statuses initialized to LMI abit alarm. If the connection is actually okay, then the connection alarm will be updated to the correct state (okay) via asynchronous updates or the periodic full state update. In either case, the connection alarm will be updated to the correct, current state. For the FRSM-VHS card, it starts in the okay state, and for FRSM-12-T3E3 card, it starts in the LMI abit alarm state (refer to caveat CSCdy28727).

•For the cnfchanstdabr command, because of a hardware limitation, the NRM (number of cells per forward RM) range is now 4 to 256 (refer to caveat CSCdy05769).

FRSM-12-T3E3 Online Diagnostics

•Online diagnostics can only detect problems; it does not have the capability to isolate problems.

AXSM-E Double Density

•With the AXSM-E double density feature, the total bandwidth supported by each Service Module without blocking is 622 Mbps.

AXSM Cards

•Do not enable offline diagnostics on AXSM cards in the APS 1+1 Op A mode. A possible loss of signal will occur when offline diagnostics are run on the AXSM cards in this configuration (refer to caveat CSCdy62950).

•For AXSM OC-3 cards running in the Op B mode, a remote card switchover can occur by doing setrev on a local node. This problem occurs when more than twelve lines are configured for APS and the setrev command is issued. The mode of the AXSM card can be found by issuing the dspcd command. The card switchover on the remote node is happening because of flooding of several interrupts occurring on all the lines. The cause of the interrupt was the reset of both the cards on local node (refer to caveat CSCdy09027).

•APS is supported on AXSM-1-2488/B after upgrading the card to Release 3.0.00 and up, and enabling the card to operate in the Op B mode.

•The dspapsln/dspapslns/dspalms/dspalm commands on a standby AXSM card do not show the results consistent with an active card. When the cards are operating in the Op B mode (which can be found by issuing the dspcd command on an AXSM card), the standby card does not perform the alarm integration and APS is also not enabled on the standby card. All the defects or failures and statistics are dynamic events which are not sent to the standby card—the standby card is unable to show the correct faults as shown by the active card. These commands are not blocked on the standby card as these are useful for debugging purposes (refer to caveat CSCdx63098).

•When there is an APS line between an AXSM card in the Op A mode and an AXSM card in the Op B mode, the working and protected lines can go into the SD (signal degraded) mode if the cards are set up for 1:1 intracard APS and SD is set to -7 upward. The problem is seen because of the behavior of the AXSM card in the Op A mode, and the problem exists only between an AXSM card in the Op B mode and an AXSM card in the Op A mode; it does not exist if both AXSM cards are in the Op B mode or in the Op A mode.

•Whenever a switch is made on the AXSM card in the Op A mode, it does the bridging to the other line on which a switch is going to happen. In this duration, the AXSM card in the Op B mode notices the change in the BER count and although the BER count is very small, it is sufficient to declare Signal Degraded (SD) because of having the SD threshold set at -7 (refer to caveat CSCdy31269).

•A standby AXSM card cannot sync up with an active AXSM card after loadrev to Release 3.0.10 if the redundant AXSM card has NNI ports and 40k connections configured, and both cards the 2.0(15.2) image. In the 2.0.x release, the LCN could be 0 but in later releases the ATLAS LCN 0 has been taken out from the pool. So for the cards with 4 ATLASs, the problem will be seen for the following LCNs while upgrading to Release 3.0.10 (refer to caveat CSCdy36202):

–0

–32 * 1024 = 32768

–64 * 1024 = 65536

–96 * 1024 = 98304

•When running in the APS Op B mode on an AXSM/B card, EM database corruption messages may be reported on line interfaces. If this situation occurs, use the following shellcon command to refresh the alarm structure (refer to caveat CSCdy24461):

–emRefreshLineState <1-based bay number> <1-based line number>

PNNI Limitation

There is a limitation in the ATM Forum PNNI specification on how the crankbacks are handled by the entry border nodes. If the entry border of a peer group cannot route a call to the destination node and if the cause of blocking was within the peer group, then the entry cranks back to the next higher level (page 246, point b.1.2 in the ATMF PNNI specification). This higher level crankback is translated to a blocked node of the logical group node and so the source node processing this crankback would treat the whole peer group to be blocked. If this entry border node crankback happens on the destination peer group or if it happens on the transit peer group that is the only route to reach the destination node, then the calls will not get routed.

SCT Files

•With the changes for CSCdw80282, you must FTP the SCT files for all the service modules back to the PXM45/PXM1E controller cards after a clrallcnf command is issued. These files are removed because they are considered to be nodal configuration files and are deleted from the C:/SCT and the F:/SCT directories.

•With the changes for CSCdw80303, the SCT files for all the service modules are saved. The valid SCT files in C:/SCT and F:/SCT and their subdirectories are saved in a zip file along with the other configuration information. When the configuration is restored, the saved SCT files will be copied into the C:/SCT and the F:/SCT directories, and will overwrite any files in those directories.

•Users should not use AXSM SCT files with an SCT ID greater than 255. If a value greater than 255 is used, CWM will not be able to syncup those SCT files.

Persistent Topology

•If the node ID is changed on a remote node, then the new node ID value is automatically saved into the entry corresponding to that remote node on the gateway node. There is no longer a need to manually delete the old node ID value from the gateway node. Note that this behavior is different from Release 3.0.00.

However, if a remote node is downed, the gateway node is reset, the node ID of the remote node is changed, and the remote node is connected to the network again, the gateway node will store the new node ID as a new entry instead of overwriting the old entry with the new node ID. In this situation, the procedure for node ID change stated in the Release Notes for 3.0.00 should be used.

Reroute Call Performance Changes

For better call performance on PXM45/B cards, the following commands need to be issued after the upgrading to Release 3.0.10:

1. cnfnodalcongth -connpendlo 750 -connpendhi 1000

2. cnfnodal congth -setuphi 1000

Then perform the following commands at both ends of the NNI links:

3. confintcongth <physical port> -setuphi 500

4. cnfpnctlvc <physical port> sscop -scr 3000

---

Note These parameters are recommended only for the PXM45/B cards and not for the PXM45A or the PXM1E cards.

---

Clocking Limitations

•The clock sources will be requalified when auto-revertive mode is changed using the cnfclksrc command.

•The dspclksrcs command may display status as configuring on the new Active controller card just after a switchover even though the clock sources are configured and latched to one of the clock sources. However, this inconsistency in the display is transient and the display is corrected after few seconds.

•The standby controller card doesn't monitor the uplink clock sources. As a result, the standby controller card doesn't generate alarm if an uplink clock source becomes unlockable. The information showed by the dspstbyclksrcs command may be incorrect for the uplink clock sources on the standby controller card.

•There is no action initiated either on the Active controller card or on the Standby controller card if none of the configured clock sources is good, the time period for the hold-over mode has expired (more then 24 hours since neither primary nor secondary clock source became unlockable) and the local oscillator used for free running is not functional. However, alarms are raised and events are logged under these conditions.

•Once the secondary clock source becomes the active clock source when the primary clock source became unlockable, the primary clock source is not monitored or qualified. As a result, it is not reverted to primary clock source when the primary clock source becomes stable even though auto-revertive mode is enabled. The workaround to get the primary clock source get monitored and relatched is to reconfigure the primary clock source. This will force the primary clock source to be requalified and relatched.

•The controller card attempts to reprogram a clock source on the Service Module(s) if the clock source is configured to be taken from a port on a Service Module when one of the following occurs:

–A Narrow Band Service Module switchover and a clock source is configured to be taken from a port on that Service Module

–A Broadband Service Module switchover

–A port on any Broadband Service Module is administratively upped

–An active Broadband Service Module rebuild is completed

–A Narrowband Service Module has rebuilt and a clock source is configured to be taken from a port on that Service Module. If the controller card fails to reprogram the clock source on the Service Module under the above circumstances, the network clocking hardware on the controller card is deprogrammed to not take the clock source from that Service Module. Under these circumstances, the clock source needs to be reconfigured to reattempt to program the clock source on the Service Module.

Additional Limitations

•Starting with Release 3.0.10, when a hardware card is newly supported in a release, the core clear command should be invoked once because of a CLI limitation. On executing the core command, the display shows the current core as 2 or 3, and the core clear command needs to be executed (refer to caveat CSCdz31938).

•For the MGX 8950, at least two XM60s are needed. One of the XM60s has to be on top, and has to be in slot 9 or 10.

•Currently, an error message is displayed when the primary card is in the standby state and the secondary card is in the active state for 1:1 redundancy. The issue is a design limitation, and the error message "Primary card is not Active" is displayed (refer to caveat CSCdy41074).

•During a burnboot command execution on an AUSM, CESM, or FRSM card, the switchredcd or switchcc commands are not blocked. Both switchover scenarios can cause the burnboot activity to terminate abnormally, which will most likely result in a damaged card.

•There will be resource (LCN, VPI/VCI) leaks on UNI ports if SPVC connections are derouted while a UNI port is down due to card removal or dnport (see caveat CSCdx57063).

•The switchcc command results in requalification of the primary or secondary clock sources if on the newly active card the primary or secondary clock sources were not qualified before switchcc. On the active card, the non-active clock source is requalified upon executing the switchcc, resetcd, or dnport commands (refer to caveat CSCdx30282).

•The default setupHi value for PXM45A has been reduced from 180 to 120. This is the number of SETUPs that the node will admit in a second, before it starts to drop the incoming SETUPs. The default thresholds for the following controller cards remain the same:

Release 3.0.00 Limitations

Policing Accuracy for PXM1E

•There is a limitation regarding the policing accuracy for the PXM1E. The policing rate is defined as 50000000/PCR. If the PCR is comparable to the OC12 line rate (1412830), the policing rate parameter is a relative small number (50000000/1412830 = ~35.38996). Because integer division is performed, the decimal values are truncated. As a result, the policing parameter cannot be calculated accurately. Moreover, the policing rate parameter is stored in an exponent (5-bits) and mantissa (9-bits) format, so this format cannot represent a small number very accurately. Combining the above two factors, a 100% accurate policing parameter cannot be configured.

To ensure that users get the rate that they have specified, the software configures policing at the next larger rate which the hardware can support. For example, if we program a connection with PCR = 1400000, the software programs the actual policing rate to be 1428571. For a worst case scenario, if the user configures a VBR2 connection with a PCR of 1400010 and the ingress user traffic is 1428570, there will not be any policing because the ATLAS would do policing at rate 1428571 only.

Refer to caveats CSCdw72256, CSCdw72459, CSCdw72971, CSCdw73652, CSCdw67564 for more information.

Maximum Threshold Accuracy for PXM45 and PXM1E

•There is a limitation regarding the maximum threshold accuracy for the PXM45 and PXM1E. The Qbin threshold and VI rate are stored in the form of exponent and mantissa, and some accuracy is lost in expressing the real rate. In testing the thresholds, the lack of accuracy is compounded with both of the Qbin and VI rate (draining rate) and therefore we cannot calculate a exact 100% correct discard rate.

To ensure that the user gets the rate that they have specified, the software configures Qbin depth at the next larger rate which the hardware can support. As a result, ICG and RSD are truncated. In this example, we have the following scenario:

Refer to caveats CSCdw89558, CSCdw85738, CSCdw89101, or CSCdw89123 for more information.

PXM1E-based Switches

•MPLS controller is not supported on PXM1E cards.

•PXM1E clock source is supported by VISM, CESM, and AUSM narrow band service module cards. The VISM card can provide two clock sources, primary or secondary. CESM and AUSM can provide only one source, either primary or secondary.

•Only SPVCs and SPVPs are supported on narrow band service modules. SVCs are not supported on NBSM.

•No bandwidth CACing support on the narrow band service modules, except for the MGX-RPM-PR-256/512 which is checked against the OC-3 card rate. Bandwidth CACing is supported on PXM1E uplink port.

•The maximum bandwidth to be distributed among narrow band service modules is ~OC10 while traffic on the network interfaces can achieve true OC12 line rate.

•Traffic should be balanced between the cell bus controllers to achieve the OC-10 rate. The traffic should be distributed equally at a rate of about OC-5 on the two cell bus controllers. The cell bus controllers cannot load share to achieve OC-10 with one Cell Bus set at an OC-6 rate, and another cell bus set at an OC-4 rate. Anything above OC-6 will be dropped. However, if only one cell bus controller is used and the other cell bus controller is not used, then it can achieve OC-10. On an 8850, the CBCs are split between the left and right side of the chassis: CBC0 supports slots 1 to 6 and 17 to 22, and CBC1 supports slots 9 to 14 and 25 to 30. On an MGX 8830, CBC0 supports slots 3, 5, 10, and 12, and CBC1 supports slots 4, 6, 11, and 13.

•The PXM1E with a UI-S3 card will drop up to 70 percent of outgoing Ethernet packets to specific switches. Use an approved Cisco hub/switch. This only applies to packets sent on the UI-S3 Ethernet interface. Known incompatible hubs are HP8000ProCurve and Netgear FS108.

---

Caution For narrowband service modules cards, whenever T1 or T3 cards are replaced with E1 or E3 cards, or vice versa, the clrsmcnf command for that slot must be used.

---

Reserved VCIs

•The following are the reserved VCIs that the customer cannot provision:

–vpi=0, vci=5 is used for SSCOP for UNI signaling ports (UNI, none ports do not need signaling). If it is a virtual terminal or EVUNI, then the minimum vpi and the VCI=5 are used for SSCOP.

–vpi=0, vci=18 is used for PNNI RCC (if the port is not NNI, or Virtual NNI, then you do not need this).

–vpi=0, vci=16 is used for ILMI if ILMI is enabled. Similarly, for virtual terminal or EVUNI, it is minimum vpi and vci=16.

–If MPLS is configured it is vci=33 in the similar fashion as above.

–If NCDP is configured it is minimum VPI and vci=34 for NCDP clocking.

FRSM-12-T3E3 Card

•The FRSM-12-T3E3 card does not have the capability of supporting E3 signals.

•CLLM will not be supported: The FRSM-12-T3E3 card can support connection level congestion through ATM EFCI. It also supports FR-ATM interworking of ECN and EFCI. Frame level congestion only happens in the rare case of full line rate sub 15-byte frames; therefore, the hardware will only support Port Level Congestion Management in the Frame Relay domain.

•BERT: Not supported.

•Sub-rate DS3: Not supported.

•The following are port and connection limitations pertaining to the new FRSM-12-T3E3 card:

–4 bytes header length with Stratcom LMI is not supported.

–LMI on Frame Forwarding port is not supported.

–If LMI is configured, port header length cannot be changed.

–Single ended connections can only originate from FRSM12. Single-ended connections terminating on FRSM12 are not supported.

–Single-ended SPVC can only originate from FRSM12-T3E3. Termination on SPVC of single-ended SPVC is not supported.

–chanType cannot be modified.

–If Port header length is 2 bytes, the maximum DLCI number is 1023.

•If Port header length is 2 bytes, the restricted DLCIs are 0, 1007, and 1023.

•If Port header length is 4 bytes, the restricted DLCIs are 0 and 8257535.

•To add Frame Forward connection, the port should be of type Frame Forward.

•For Frame Forward port, the maximum connections is 1.

•For Frame Relay port, the maximum connections is 4000.

•The maximum number of frame relay connections is 16K.

•If the connection is in loopback, it cannot be modified.

•CIR can only be 0 for uBR connections.

•If CIR == 0, BC should also be zero, BE, and zeroCirConEir should be nonzero.

•If CIR != 0, BC should be nonzero.

•If chanType is Frame Forward, chanFECNconfig should be setEFCIzero, chanCLPtoDEmap should be ignoreCLP, chanDEtoCLPmap should not be mapCLP.

•If chanType is NIW or NIWReplacem chanFECNconfig should be setEFCIzero, chanCLPtoDEmap should not be setDEzero or setDEone.

•If chanType is frSIW_transparent or frSIW_translate, chanCLPtoDEmap should not be ignoreCLP.

•Maximum connections depending on LMI type:

–Annex A/D LMI, 2-byte header, FRF 1.2 not enabled: 898 conns

–Annex A/D LMI, 2-byte header, FRF 1.2 enabled: 1000 conns (port max)

–Annex A/D LMI, 4-byte header, FRF 1.2 not enabled: 640 conns

–Annex A/D LMI, 4-byte header, FRF 1.2 enabled: 4000 conns (port max)

–Strata LMI, 2-byte header, FRF 1.2 not enabled: 560 conns

–Strata LMI, 2-byte header, FRF 1.2 enabled: 1000 conns (port max)

Disk Space Maintenance

•As the firmware does not audit the disk space usage and remove unused files, the disk space in C: and E: drives should be manually monitored. Any unused saved configuration files, core files and firmware files, and the configuration files of the MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards should be promptly deleted manually. Following this procedure allows you to avoid shortage of disk space to successfully store event logs, configuration upload files in the C: drive and the configuration of MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards in the E: drive.

Non-native Controller Front Card and HDD Card

•When a nonnative PXM1E or HDD back card is inserted in the standby controller slot, the firmware does not clean up the drives which have free disk space below 30 percent. When the standby controller card comes up, it needs to be verified whether the contents have been cleaned up.

•When a nonnative PXM1E or HDD back card is inserted in the standby controller slot, the firmware does not clean up the non-auto configuration files in the E:RPM directory. These non-auto configuration files in the E:RPM directory have to be manually cleaned up after the standby controller card becomes ready.

•Due to the checks for nonnative cards, when the controller front or HDD cards are swapped in the same node, the controller card that attempts to come up as active may get reset twice.

•When a nonnative HDD card is inserted into the standby controller slot, verify that after the card becomes ready in the standby controller slot, its hard disk contents are deleted and synchronized the relevant files from the Active card.

clrsmcnf Command

•For the clear service module configuration feature, if there is a controller card switchover before the clear service module configuration operation is complete, the clrsmcnf command needs to be reissued to ensure that the configuration is completely cleared to avoid any incomplete cleanup.

•For the clear service module configuration feature, using the clrsmcnf command may result in discrepancy in the PNNI configuration. For example, some connections may be in the mismatch state.

•If the clrsmcnf command is given with the option to clear the software version for the slot as well, then the card will go into the failed state after the operation is complete.

•While using the clrsmcnf command, the card in the specified slot is not usable until the operation has successfully completed.

•The clrsmcnf command will not work for redundant service modules.

•The clrsmcnf command will not work if an upgrade is in progress.

•If MGX-RPM-PR-256/512 or MGX-RPM-XF-512 is configured as an LSC (Label Switch Controller), execution of clrsmcnf command on those LSC slots will be rejected, as designed.

•The clrsmcnf command does not work if the controller exists for the slot.

APS

•For AXSM-B APS, the back card of the active card must be present for APS to function.

•The new commands dspadjlnalm and dspadjlnalmcnt are now supported on AXSMB.

•Port LED lights on AXSM-E front cards indicate the receive status of physical line connected to it only when the card is in active state. For a standby AXSM-E card, the LEDs always remain green whether the lines are in LOS irrespective of which lines are active (refer to caveat CSCdv68576).

Path and Connection Trace

•Path trace is not supported on the control port.

•Path trace will not have the accurate information when there is a crankback on the connect path.

•Path and connection trace feature in Release 3.0.00 and higher is not compatible with the path and connection trace available with previous releases.

SNTP

•The CWM MIB is not supported in Release 3.0.00 and higher.

Priority Routing

•Prioritized reroute of SPVCs is not guaranteed, if the SPVCs originate on a signaling port. We might see SPVCs getting routed out-of-order. In-order routing of SPVCs is guaranteed on non-signaling ports.

•The MGX-RPM-PR-256/512 does not support configuration of routing priority. All RPM mastered SPVCs will be assigned a routing priority of 8 by the PXM.

•The addcon command on VISM does not have support for specifying the routing priority. All the SPVCs added from VISM are assigned a priority of 8. The routing priority can be changed using the cnfpncon command.

•Changing the routing priority for DAX connections will not change the priority of the associated pn-cons (SVCs). This is because the SPVCs will not be derouted and rerouted if just the endpoint parameters are changed, and routing priority is an endpoint parameter. Also, because DAX connections are never derouted, even when the UNI port goes down and the rrtcon command is not supported for DAX connections, the routing priority change will never get reflected. The only way for this to get reflected is to use the dncon and upcon commands. Because DAX connections are never derouted, the effect of this limitation is voided.

•Priority routing operates in a best effort manner. This is because of the following reasons:

–Two in-order RELEASEs can still arrive out-of-order at the Master node, if they take two different paths.

–Under congestion scenarios we can expect RELEASEs to be transmitted out-of-order. This is because we do not want to hold up the release of other calls if we are not able to send RELEASEs on one of the interfaces, as it is congested. The calls that we are unable to release could be higher priority calls.

•Lower priority SPVCs can be routed ahead of higher priority SPVCs. This can happen if we have attempted several times to route higher priority SPVCs, but failed. To prevent starvation of lower priority SPVCs, we will start to route lower priority SPVCs and we will get to the higher priority SPVCs at a later point in time.

SPVC Interop

•NNI SPVC Addendum Version 1.0 is not supported.

•PNNI 1.0 Addendum (Soft PVC MIB) is not supported.

•Terminating single-ended SPVCs on AUSMs, CESMs, or FRSMs is not supported.

•Origination of single-ended spvcs (with -slavepersflag) from AUSMs, FRSMs, CESMs, VISMs and RPMs is not supported.

•CC (Continuity Check) is not be available at the slave end of a single-ended SPVC.

•Reporting AIS detection to CWM is not be available at the slave end of a single-ended SPVC.

•The tstdelay command is not be available at the slave end of a single-ended SPVC on a switch.

•The slave end of a single-ended SPVC is not be visible to CWM.

•If single-ended SPVCs are originated from switches, they can only be configured via CLI and not from CWM in the current release.

•Single-end provisioning will not be supported for DAX connections, because no value addition is seen for interoperability.

•SPVC statistics are not available for the slave endpoint of a single-ended SPVC because this endpoint is non-persistent.

•When the persistent slave endpoint of an existing SPVC connection is deleted and the master endpoint is allowed to remain, the connection may get established as a single-ended spvc connection. In this case, CWM will show the connection as Incomplete.

•Override of SVC connections on a VPI due to an incoming SPVP request for that VPI is not supported. The following override options are alone supported:

–spvcoverridesvc

–spvcoverridesvp

–spvpoverridesvp.

Preferred Route

•Upgrading a preferred routing configured connection from any Release 3.0.x will be non-graceful. In a future release, the configuration of the preferred route identifier information for each connection will be supported on the Service Module cards instead of on the PXM controller. During the upgrade, the preferred route identifier information for each connection will be lost and the preferred route identifier needs to be reprovisioned on the Service Module cards. Also, the preferred route table at the PXM controller will be lost. Connections that have already been routed with preferred routing will remain, and there will be no alarms for these connections.

•The preferred routes can be specified only within a PNNI single peer group meaning all the nodes in the preferred route lie within the same peer group.

•All the nodes in the network should be running Release 3.0.00 software to use the preferred route feature.

•All the links specified in the preferred route should be PNNI links.

•If a node in the PNNI network changes its PNNI node ID, the old entry in the persistent topology database in all the nodes in the network need to be deleted. If any of the preferred routes in any nodes in the network contains the changed node as one of the hops, the preferred route(s) must be modified using the new table index (in the persistent topology database) allocated for the changed node.

•If a node in the PNNI network is deleted via configuration commands from the persistent topology database, if any of the preferred routes configured at that node (where the delete command is executed) contains the deleted node as one of the hops, the preferred route(s) must be deleted/modified manually.

•If a node in the PNNI network is removed via physical decommissioning, and if any nodes in the network had some preferred routes that contain the removed node as one of the hops, the preferred route(s) must be deleted/modified manually.

•Due to differences in physical port numbering, non-Cisco nodes can only be the terminating nodes in a preferred route.

•When a connection is routed on a route other than its preferred route and if the preferred route becomes available, the connection would not be automatically derouted to route back to its preferred route. The user has to deroute/reroute by using configuration commands (optrte, rrtcon, dncon/upcon etc.).

•The preferred route configuration is available using only the CLI at the PXM controller. The configuration of the preferred route will be available with the CWM proxy service agent in a future CWM release.

Persistent Topology

•In a mixed network of pre-Release 3.0.00 and 3.0.00 or later nodes, only the node name and the node ID will be shown for a pre-Release 3.0.00 node in the topology database. This is because the feature is not present in pre-Release 3.0.00 nodes.

•If a peer group is made up of physical nodes with pre-Release 3.0.00 release logical nodes, then the information for the logical node will be stored in the topology database, because there is no way to distinguish between physical nodes and pre-Release 3.0.00 release logical nodes. Logical nodes with Release 3.0.00 or later will not be stored in the topology database.

•To delete a node information entry from the topology database, first remove the node itself from the network, either by disconnecting the cables, or downing all the links between that node and the network. Wait for an hour. Then, delete that node from the topology database. This is done because, even if a node is removed from the topology database of all nodes in the peer group, its PTSEs will still be stored in the other nodes until they are flushed from those nodes. This would happen within an hour's time, but it is configurable as a PNNI timer value. If the node is deleted from the topology database within that hour's time, and the node does switchcc/reboot, then it is possible that the node info for that deleted node will be added back into the topology database.

•When the node ID of a node is changed, the old node ID is added back into the topology database as a new node entry. In addition, the old node ID will still be stored in the topology database of all the other nodes in the peer group. In order to delete this entry, wait for an hour so that the PTSEs with the old node ID is flushed from the topology database of all the nodes in the peer group, and then delete the information of the old node ID from the topology database.

•It is possible that the gateway nodes are not in synchronicity in a peer group, and this could happen in many situations. For example, a gateway node is added in a peer group, then a node is deleted from the peer group, and another gateway node is configured, then the information for the deleted node would not be in the second gateway node. Another example is that a node is deleted from one gateway node, but not in another gateway node.

•When you delete a node from the peer group, the node information must be deleted from all the nodes in that PG, even the non-gateway-node nodes. Otherwise, the node information for that deleted node will still be in the non-gateway-node nodes. This could cause inconsistencies later if this node is configured to be a gateway node.

NCDP

•FRSM:NO clock sources supported on FRSM. So if the root clock is chosen to be a port on FRSM it will be a bad clock source and we will compute a new root clock source. Ideally, no clock source should be configured on FRSM.

•If a clock source goes bad, there is no way to find out if it has become good. If the user wants NCDP to consider that clock source again, the user needs to re-add the clock source.

•Suppose a root clock source is configured on NBSM which is in redundant configuration. If a switchover of the NBSM is done there might be loss of clocking for some time.

•Currently there is no way for the user to know what is the secondary (second best) clock source in NCDP mode. This might create problems for the user who is trying to delete/modify the partition on the line carrying the secondary best clock source.

•Revertive option is not provided in NCDP.

Manual Clocking

•AUSM can support only one clock. If a second clock is configured on the same AUSM card AUSM will send a NACK. When the second clock is sent a NACK, no warning or message is given by the CLI. The NAK can only be found out by looking through the logs. The second clock configured on the AUSM will not be reflected in the clocking database.

•If the line carrying the primary or the secondary clock source goes in alarm and a switchcc command is used on the switch, the clock configuration for the line in alarm is removed. The clock configuration will also be removed if any card is rebooted when the clocking line is in alarm. This only applies to AXSM and VISMs.

•FRSM: NO clock sources supported on FRSM. If a clock source is configured on FRSM it will not be reflected in our database.

•When the resetcd command is used on a service module, the primary and secondary (if configured) clock sources are recommitted even though the primary or secondary clock source is not a port on the service module that was reset. Recommitted means that the primary and secondary clock source will get requalified and the node will temporarily latch onto the internal oscillator, After the clock is requalified, the node will lock onto the primary clock source once again.

•The clock will not revert if the clock switched due to frequency drift.

AXSM Cards

•If ER stamping is used, the rate interval does not provide sufficient accuracy to be completely effective. As a result, when an AXSM card is supporting a PNNI link which is congested with mixed CBR/ABR traffic, cells will be dropped. This condition only occurs when ER stamping is enabled and CI is disabled on an AXSM PNNI link, along with CBR/ABR traffic running so as cause congestion on the link.

•It is recommended that the CI/EFCI mechanism be used for rate feedback rather than the ER stamping mechanism, especially if CBR/ABR traffic is expected (refer to caveat CSCdw63829).

Bulk Status Enquiry

•Release 3.0.00 and up have a limitation in using the "Bulk Status Enquiry" signaling message with a node running Release 2.1. Bulk Status Enquiry is a proprietary signaling message used to check whether connections across peer nodes are intact. It is triggered automatically upon PXM switchover as well as in other scenarios like SSCOP link establishment. Though Bulk Status Enquiry will not work with Release 2.1 when the peer node is running release 3.0.00 and up, there is an automatic fall back mechanism to standards specific "Normal Status Enquiry" procedure in case the bulk procedure fails. Hence, there should be no loss of functionality as a result of this limitation (refer to caveat CSCea75590).

VISM Limitations

For details on VISM limitations, refer to the Release Notes for Cisco Voice Interworking Service Module Release 3.1(0). These release notes are available online at the following location:

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm

The release notes are identified by switch name and release number (for example, MGX 8850 (PXM45), Release 3.0.10.

RPM-PR and RPM-XF Limitations

Starting with Release 3.0.00, Route Processor Module (RPM) cards have their own release notes. For details on the MGX-RPM-PR-256/512 cards, refer to the Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for MGX Release 1.2.11 and MGX Release 3.0.10 or the Release Notes for Cisco MGX Route Processor Module (MGX-RPM-XF-512) for MGX 8850 (PXM45) Release 3.0.10. These release notes are available online at the following location:

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm

The release notes are identified by switch name (for example, MGX 8850 (PXM45), Release 3, Route Processor Module, Release Notes.

Restrictions for Release 3.0.25

No restrictions have been identified.

Restrictions for Release 3.0.23

No restrictions have been identified.

Restrictions for Release 3.0.20

No restrictions have been identified.

Restrictions for Release 3.0.10

No restrictions have been identified.

AXSM-32-T1E1-E Card

•Maximum number of user connections is 32096.

•Maximum number of links in an IMA group is 16.

•PNNI requires that SCR be equal to 453 cells per second and PCR be equal to 969 cells per second for the control connection.

•SSCOP requires that SCR be equal to 126 cells per second and PCR be equal to 2000 cells/second.

PXM1E-16-T1E1 Card

•Maximum number of connections is 13500.

•Maximum number of links in an IMA group is 16.

•PNNI requires that SCR be equal to 453 cells per second and PCR be equal to 969 cells per second for the control connection.

•SSCOP requires that SCR be equal to 126 cells per second and PCR be equal to 2000 cells per second.

Restrictions for Release 3.0.00

AXSM Model B Restrictions

The enableaxsmbaps command is a PXM CLI command required to turn on additional APS features on AXSM/B cards in Releases 3.0.x and up. By issuing this command, the card operating mode becomes AXSM Op B. This command is required only while upgrading configured cards with Release 3.0.x images. If the AXSM/B cards do not have any configuration and are upgraded with Release 3.0.x, then the card operating mode would be made as AXSM Op B and it is not required to issued the enableaxsmbaps command.

The command has the following syntax:

enableaxsmbaps <primary | secondary slot>

The enableaxsmbaps command should be given after the completion of upgrading to Release 3.0.x. The following requirements are needed to change the card operating mode to AXSM Op B:

•For redundant cards, both the cards should be AXSM/B cards and the image on both cards should be Release 3.0.x and up.

•For non-redundant cards, the card should be an AXSM/B and the image should be Release 3.0.x and up.

Formatting Disks

•The hard disks should not be formatted with the Release 3.0.00 backup boot or runtime firmware. The Release 3.0.00 firmware initializes the disks with DOS File System Version 2.0 where as the earlier 2.x releases use DOS File System Version 1.0. As a result, if the hard disks are formatted with Release 3.0.00 firmware, those disks will become unusable in nodes running Release 2.x firmware. Because Release 3.0.00 firmware is backward compatible, it can use hard disks with DOS File System Version 1.0.

Saving Configurations

•The C disk drive should not be used for saving multiple older configurations, images, and core dumps. The disk space on this drive is needed to save event logs and configurations, and the logs and configurations will not be correctly saved if there is inadequate disk space.

Other Limitations and Restrictions

•PXM disk sync verification will not work if an upgrade is in progress.

•The maximum number of connections supported in Release 3.0.00 is 250K connections with the PXM45/B controller cards.

•Load sharing will not be enabled automatically if upgrading from a lower revision that has load sharing disabled.

•Path and connection trace are not supported between different peer groups.

•On AXSM cards, when configuring virtual interfaces (i.e. VUNI, VNNI, EVUNI, EVNNI), the physical interface must be of all one ATM header type, either UNI or NNI. Keep in mind that the signaling that is applied to a virtual port is independent of the actual virtual port ATM header. The only limit will be that the VPI value must be within the UNI ATM header limitations (0-255).

Clearing the Configuration on Redundant PXM45 and PXM1E Cards

•Due to checks to prevent an inserted card from affecting the system, an additional step may be required when inserting two nonnative PXM45 (or PXM1E) cards in a shelf. Insert the first PXM45, use the clrallcnf command, and allow this to become active before inserting the second PXM45 (or PXM1E).

•After using the clrallcnf command, you must clean up old SCT files (refer to caveat CSCdw80282).

Limitations and Restrictions for 2.1.x

This section is extracted from the MGX 2.1.79 release notes. It describes the following issues for Releases 2.1.60 through 2.1.80:

•General limitations, restrictions, and notes

•APS management information and open issues

•Clearing the configuration on redundant PXM45/B cards

General Limitations, Restrictions, and Notes

The following limitations and restrictions apply to this release.

---

Note For the MGX 8950, references to "AXSM" refer to the AXSM/B cards.

---

•The 8 port MMF back cards for the AXSM and AXSM/B front cards do not support Y-cable redundancy.

•Presently, the PXM CLI allows for provisioning of a PNNI controller (controller id 2) on any slot in the chassis, but for this release, such provisioning should be restricted to slot 7 only.

•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in this release with the PXM45 card is 99, and for PXM45/B cards it is 192. Of the 192 PNNI interfaces, up to 100 interfaces can be signaling ports. The other 92 interfaces should be non-signaling ports, such as non self-supporting ports.

•AXSM-1-2488 and AXSM-1-2488/B cards do not have a policing function enabled.

•The front card hardware (motherboard/daughterboard) for each card type can support up to two back cards. But in Release 2.1.80, only one AXSM-E back card (that is, half the port capacity available in hardware) is supported by software. The full port capacity will be supported with a future software release. No hardware changes will be required.

•In Multiple Peer Group (MPG) mode, when one switches over to the standby on a PGL node with three levels, it can take several minutes on the standby card for this PGL to come up and the SVC based RCC to setup. This is normal behavior, because PNNI does not support hot redundancy. For a switchover, the entire PNNI database must be rebuilt. (It is like a reboot for PNNI, even though the active calls are not affected.)

•Trace information captured in the error logs of non-PXM slots (seen with the dsperr -sl <slotnum> command) will not translate addresses in the trace to correct symbolic names. Such files with trace data need to be moved off the system using FTP and forwarded to TAC and engineering.

•Support for three controllers only (one for PNNI and two for LSC). Controller ID 2 is reserved for a PNNI controller; IDs 3 to 20 are available for LSC controllers.

•Partition ID 1 is reserved for PNNI.

•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in this release with PXM45 cards is 99 and PXM45/B cards is 192.

•If an active AXSM card is stuck in the active INIT state, the standby PXM will not go to the standby ready state until the active AXSM goes to a steady state. The steady states are: active ready, failed, mismatch, empty, empty reserved, and standby ready. With redundancy configured, if a standby AXSM card is stuck in a standby init state, with an active AXSM already in a active ready state, the standby PXM will go to the standby ready state without delay. If both AXSMs in the redundancy pair are not in a steady state, then the standby PXM will not go to the standby ready state until one or both of the two AXSM cards are in the active ready state.

•If the destination address is reachable for both an IISP and a PNNI link from the same node, ABR connections will not route. The current routing algorithm will always choose IISP links over PNNI links because it is local. Because IISP does not support ABR connections, the connection setup will fail.

•In this release, a Service Class Template (SCT) can be changed with connections present. However, if the change affects services in use, the connections will be rerouted.

•When CWM is used to manage the network, the IP address 10.0.x.x cannot be used as the LAN address (lnPci) for the switch.

•Caveat CSCdx29956 information—the release note enclosure contains these fields:

–Symptom: Cellbus clock configuration defaults after a power cycle.

–Condition: Set one of the cell bus clock speeds to 42 MHz and power cycle the node.

–Workaround: Re-configure cell bus clock after a node rebuild.

•If there are MGX-RPM-PR-256/512 card(s) in the node, after clrallcnf, the standby controller card takes longer to come up. The more MGX-RPM-PR-256/512 cards in the node, the longer the standby controller takes to come up. This also happens when the standby controller card is coming up, and MGX-RPM-PR-256/512 cards are inserted into slots that were not previously used for MGX-RPM-PR-256/512 cards.

Limitations for rteopt via Parallel Links

This section lists limitations for rteopt via parallel link. Use Figure 1 as you work through the scenarios in this section.

Figure 1 Configuration Example for rteopt via Parallel Link

The configuration for Figure 1 and the scenarios in this section are as follows:

•Link 1 has forward and backward admin weight set to 500 (via cnfpnni-intf).

•Link 2 has forward and backward admin weight set to 1000.

•Link 3 has forward and backward admin weight set to 2000.

•SPVC connection is routed from Node A to Node C (Master endpoint is at Node A) via link 1 and link 2.

Scenario 1: Link 2 is down (for example, by using the dnpnport command), connections are rerouted right away but Node A has not had that information updated in the routing tables yet.

SPVC on Node A will have routing cost = 2*500 + 2*1000 = 3000, but since link 2 is down, Node B will choose link 3. The routing cost on Node A SPVC is still 3000 as it did the calculation during the route search.

If link 2 is up, if you use a rteopt command on Node A to obtain the new route, and the new path selected has a cost of 3000.

Because SPVC has 3000, it does not reroute through link 2.

Scenario 2: Instead of link 2 being down, if there is a crankback on link 2, the same result stated above occurs.

Scenario 3 (for CBR and VBR): Link selection is set as maxavcr, maxcr, or random on Node B (by using the cnfpnni -selection command) If link 2 has less bandwidth than link 3, and the link selection criteria at Node B is set to maxavcr, Node A will still put the cost as 3000 with least aw calculation, but Node B will choose link 3 (even though it is costlier) because it has more bandwidth.

Scenario 4 (for ABR and UBR): Link selection does not apply to ABR and UBR (by using the cnfpnni -selection command). This is exactly the same as Scenario 3 because ABR and UBR follow load balancing on parallel links instead of choosing the minaw link.

Scenario 5 (for all types of service categories): After call setup, if the admin weight is increased on the link on which the call is routed, the routing cost calculated during the call setup will not get changed. So if a rteopt is done after increasing admin weights on the existing links on the connection path, the connections will not get optimized to take the newer path.

Workaround

If you use the dnpnport command on link 2 (connections will be routed via link 3), after using the uppnport command on link 2, then use the cnfpnni-intf command to change the existing administrative weight on link 2 to a lesser value, for example, 800 (from 1000).

When the optrte command is used at Node A, routing cost will be = 2*500 + 800(fwd) + 1000 (bwd) = 2800 for the new route of link 2.

Because all SPVC connections have 3000 as the routing cost, connections will be rerouted on link 2.

Important Notes

This section provides general notes that apply to this release, and covers some procedures that are not yet in the manuals.

•You must use the SCT files released with Version 2.1.80 (number 2 and 3, which were included in Version 2.0.13 are similar to number 2 and 3 for 2.1.80) for the Control VC feature. If you are using the MPLS feature, then you will need to change to SCT 4 or 5, which were released with Version 2.1.00.

•By default, 2000 cps and 543 cps will be reserved for SSCOP and PNNI Signalling VC respectively, even when you disable SSCOP and PNNI. These values are configurable by the cnfpnctlvc command.

•Do not execute the delcontroller command when connections/ports still exist. The impact of executing delcontroller with connections is that the connections cannot be recovered until the controller is re-added using addcontroller and the AXSM cards or the entire node has to be reset (otherwise ports remain in the provisioning state). There is now a warning to the user of the impact of the command when there are existing connections/ports.

•Analysis of the code has identified a situation which has a low probability of occurring and in fact has not been encountered in any test scenarios to date. This caution and associated workaround is provided as a precautionary measure. When the link bandwidth for SPVC connections is reaching full capacity, making minimal bandwidth available for new SPVC connections, a condition can be encountered where the initial software check believes there is sufficient bandwidth for the new SPVC connection. However, the final software confirmation for available bandwidth may be rejected because there is no bandwidth available. If this problem occurs, the system will recover when the PNNI updates are refreshed. (This will happen at the default time of 30 minutes.) The user can recover from this problem by making the Administrative weight of that link very high to avoid that link from being used.

•When the switch cannot automatically resolve nativity check conflicts, you can force a configuration rebuild from a specific hard disk by establishing a console port session through the corresponding PXM-UI-S3 card and issuing the shmRecoverIgRbldDisk command. This command ignores the nativity check and configures the entire switch according to the configuration on the hard disk.

•PNNI default minimum VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes (for example, MPLS and NCDP). For users who would like to add MPLS controller in future releases of MGX 8850, it is highly recommend to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be established automatically on 0/32. Minimum VPI is not negotiated by ILMI, so the user should set this parameter the same on both nodes.

APS Management Information

The following tips apply to the use of the dspapsbkplane command and the APS connector, which is sometimes called a backplane. The APS connector must be installed to enable intercard APS.

The APS dspapsln, dspapslns, switchapsln, and dspapsbkplane commands were modified in release 2.1.70.

---

Note The dspadjlnalm and dspadjlnalmcnt commands are new to Release 3.0.00. The dspadjlnalmcnt command is supported on AXSM-E and AXSM/B.

---

The APS dspadjlnalm command was new to release 2.1.70. Refer to the Release Notes for MGX 8850 Command Reference for Release 2.1 at the following location for further details about the commands mentioned in these release notes:

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r21/index.htm

---

Note The issues in this section are seen only in Operational mode 1+1, bidirectional, Rev/non-Rev. If at least one side is configured as 1+1 unidirectional, these problems do not occur.

---

The following are some open issues in this release:

•Reset of active AXSM/A or AXSM/B, removal of active AXSM/A or AXSM/B, or AXSM/A or AXSM/B card switchover may cause the lines behind that card to be in an LOS status for 20ms to 30ms. If these lines were active at the time, some additional APS switch will occur; and the corresponding lines at the far-end will be in SF alarms before the standby AXSM card comes up. The momentary loss of signal is due to the hardware limitation; no other workaround is available. (Refer to caveat CSCdu41763—P-comment and CSCdv01058—Eng-Note for more details.)

•For AXSM/A hardware only: If multiple active lines are removed at the same time, one line may not switch over.

–To recover, either perform a lockout of Protection line and Clear from the far end or perform delete APS for the line, then add the APS line back.

Preparing for Intercard APS

The following components are required for intercard APS:

•Two front cards.

•Two back cards for every bay hosting APS lines. All lines on cards used for intercard APS must operate in APS pairs or use Y cables.

•An APS connector installed between the two back cards for every bay hosting APS lines.

Use the dspapsbkplane command on both the standby and active card to verify that the APS connector is plugged in properly. The following example shows the results displayed by the dspapsbkplane command when the APS connector is in place:

M8xx0_NY.1.AXSM.a > dspapsbkplane

Line-ID   Primary Card Signal Status       Secondary Card Signal Status

                    Slot #1                             Slot #2        

  1.1               PRESENT                             PRESENT

  1.2               PRESENT                             ABSENT 

  2.1               PRESENT                             ABSENT 

  2.2               PRESENT                             ABSENT 

Remote Front Card : PRESENT 

Top Back Card     : ENGAGED 

Bottom Back Card  : ENGAGED 

The following example shows the results displayed by the dspapsbkplane command when the APS connector is not place:

M8xx0_LA.1.AXSM.a > dspapsbkplane

Line-ID   Primary Card Signal Status       Secondary Card Signal Status

                    Slot #1                             Slot #2        

  1.1               PRESENT                             ABSENT

  1.2               ABSENT                              ABSENT 

  2.1               PRESENT                             ABSENT 

  2.2               ABSENT                              ABSENT 

Remote Front Card : ABSENT 

Top Back Card     : ENGAGED 

Bottom Back Card  : NOT-ENGAGED 

---

Note The dspapsbkplane command should be used only when the standby card is in the Ready state. When the standby card is booting or fails, intercard APS cannot work properly and this command displays NOT ENGAGED.

---

If the dspapsbkplane command displays the APS Line Pair does not exist message, suspect that the APS is not configured on a line.

If the dspapsbkplane command shows different values for each of the two cards, suspect that the APS connector is seated properly on one card but not on the other.

The APS connector status is the same for all lines in a single bay because the APS connector interconnects two back cards within the same bay. You need to enter the dspapsbkplane command only once to display the APS connector status for both upper and lower bays.

Enter the dspapslns command to verify APS configuration. If the working and protection lines show OK, both lines are receiving signals from the remote note.

Managing Intercard APS Lines

In AXSM and AXSM/B intercard APS, either front card can be active, and can be connected to either APS line through the APS connector joining the two back cards. The following process describes how intercard APS communication works:

1. The signal leaves the front card at the remote end of the line. (See Figure 2 and Figure 3.)

2. The signal passes through the APS connector and both back card transmit ports at the remote end of the line. (See Figure 2 and Figure 3.)

3. The signal travels through both communication lines to the receive ports on both back cards at the local end. (See Figure 2 and Figure 3.)

4. The active front card processes the signal that is received on the active line. (See Figure 2 and Figure 3.)

5. The standby card monitors only the status of the standby line. (See Figure 2 and Figure 3.)

6. If necessary, the signal passes through the APS connector to the front card. (See Figure 3.)

---

Note For AXSM, the front card monitors only one of the receive lines. For AXSM/B, the front card monitors both the receive lines.

---

Figure 2 shows an example of how this process operates in a standard APS configuration, where the primary card monitors the working line and the secondary card monitors the protection line.

Figure 2 Standard APS Configuration

Figure 3 shows an example of how the APS communication process operates in a crossed APS configuration, where the secondary card monitors the working line that is attached to the primary card, and the primary card monitors the protection line that is connected to the secondary card.

Figure 3 Crossed APS Configuration

Line failures are always detected at the receive end of the line. This is where a switchover occurs when a failure is detected. Two different types of switchovers can occur, depending on whether the APS was configured as unidirectional or bidirectional in the cnfapsln command:

•When a failure occurs on a line configured for unidirectional switching, the switch changes lines at the receive end only. A switchover is not necessary at the transmit end because the transmitting back cards send signals on both lines in the 1 +1 APS configuration.

•When a failure occurs on a line configured for bidirectional switching, a switchover occurs at both ends of the line.

If the status of the standby line is good, a switchover from the failed active line to the standby is automatic.

Enter the cnfapsln command to enable an automatic switchover back to the working line after it recovers from a failure, as shown in the following example:

M8xx0_LA.1.AXSM.a > cnfapsln -w 1.1.1 -rv 2

Table 19 describes the configurable parameters for the cnfapsln command.

Table 19 The cnfapsln Command Parameters 

Parameter	Description
-w <working line>	Slot number, bay number, and line number of the active line to configure, in the format: slot.bay.line Example: -w 1.1.1
-sf <signal fault ber>	A number between 3 and 5 indicating the Signal Fault Bit Error Rate (BER), in powers of 10: •3 = 10-3 •4 = 10-4 •5 = 10-5 Example: -sf 3
-sd <SignalDegradeBER>	A power if 10 in the range 5 to 9 that indicates the Signal Degrade Bit Error Rate (BER): •5 = 10-5 •6 = 10-6 •7 = 10-7 •8 = 10-8 •9 = 10-9 Example: -sd 5
-wtr <Wait To Restore>	The number of minutes to wait after the failed working line has recovered, before switching back to the working line. The range is 5 to 12. Example: -wtr 5
-dr <direction>	Determines whether the line is unidirectional or bidirectional. •1 = Unidirectional. The line switch occurs at the receive end of the line. •2 = Bidirectional. The line switch occurs at both ends of the line. Note This optional parameter is not shown in the above example because you do not need to set it for a revertive line. Example: -dr 2
-rv <revertive>	Determines whether the line is revertive or non-revertive. •1 = Non-revertive. You must manually switch back to a recovered working line. •2 = Revertive. APS automatically switches back to a recovered working line after the number of minutes set in the -wtr parameter. Example: -rv 1

If you want to manually switch from one line to another, enter the switchapsln <bay> <line> <switchOption> <service switch> command, as shown in the following example:

M8xx0_LA.1.AXSM.a > switchapsln 1 1 6

Manual line switch from protection to working succeeded on line 1.1.1

Table 20 describes the configurable parameters for the cnfapsln command.

Table 20 The switchapsln Command Parameters 

Parameter	Description
bay	The working bay number to switch.
line	The working line number to switch.
switchOption	The method of performing the switchover. •1 = Clear previous user switchover requests. Return to working line only if the mode is revertive. •2 = Lockout of protection. Prevents specified APS pair from being switched over to the protection line. If the protection line is already active, the switchover is made back to the working line. •3 = Forced working to protection line switchover. If the working line is active, the switchover is made to the protection line unless the protection line is locked out or in the SF condition, or if a forced switchover is already in effect. •4 = Forced protection to working line switchover. If the protection line is active, the switch is made to the working line unless a request of equal or higher priority is in effect. This option has the same priority as option 3 (forced working to protection line switchover). Therefore, if a forced working to protection line switchover is in effect, it must be cleared before this option (forced protection to working line switchover) can succeed. •5 = Manual switchover from working to protection line unless a request of equal or higher priority is in effect. •6 = Manual switchover from protection to working line. This option is only available in the 1+1 APS architecture.
service switch	This is an optional parameter. When set to 1, this field causes all APS lines to switch to their protected lines.

Enter the dspapslns command to verify that the active line switched over from the protection line to the working line, as shown in the following example:

M8xx0_LA.1.AXSM.a > dspapslns

Working Prot.  Conf  Oper    Active  WLine PLine WTR   Revt Conf Oper LastUser

Index   Index  Arch  Arch    Line    State State (min)      Dir  Dir  SwitchReq

------- -----  ----  -----   ------  ----- ----- ----- ---- ---- ---- ----------

  1.1.1  2.1.1 1+1    1+1    working    OK    OK     5  Yes   bi   bi ManualP->W

Troubleshooting APS Lines

This section describes the port light behavior changed in Release 3.0.00 as follows:

•Port lights on AXSM /B front cards indicate the receive status of APS lines.

•The active front card always displays the status of the active line.

•The standby card always displays the status of the inactive line. If only one APS line fails, the line failure LED is always displayed on the standby front card.

•Port lights on AXSMB front cards indicate the receive status of the physical line connected to it. For example, when APS is configured for working line as 5.1.3 and protection line as 6.1.3, regardless of which card is active, the port LED on card 5 will show the receive status of 5.1.3 and card 6 will show the receive status of 6.1.3.

---

Note The remainder of this section is the same as for Release 2.1.80 unless otherwise noted as updated for Release 3.0.10.

---

---

Caution When the active front card and the active line are in different slots and the inactive line has failed, it is easy to incorrectly identify the failed line as the line in the standby slot. To avoid disrupting traffic through the active line, verify which physical line is at fault before disconnecting the suspect line.

---

If the active line fails and the standby line is not available, the switch reports a critical alarm.

If the active line fails and the standby line takes over, the former standby line becomes the new active line, and the switch reports a major alarm.

If an AXSM/A front card fails, APS communication between the redundant front cards fails. This can result in one of the following situations:

•If both APS lines were working before the failure, an APS line failure causes a switchover to the protection line.

•If either APS line failed prior to a front card failure, a failure on the active line does not cause a switchover to the other line. Because the standby front card failed, it cannot monitor the standby line and report when the line has recovered. This means that the active card cannot use the standby line until the standby front card is replaced and the line problem corrected.

Use the following procedure to troubleshoot APS lines:

---

Step 1 Enter the dsplns command to determine if the line in alarm is an APS line. The dsplns  command shows which lines are enabled for APS:

M8xx0_LA.1.AXSM.a > dsplns

                                           Medium Medium 

  Sonet  Line     Line     Line    Frame   Line   Line     Alarm   APS 

  Line  State     Type     Lpbk   Scramble Coding Type     State   Enabled

  ----- ----- ------------ ------ -------- ------ -------  -----   -------- 

   1.1     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Enable

   1.2     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Disable

   2.1     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Disable

   2.2     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Disable

If the line in alarm is an APS line, and has always functioned properly as an APS line, proceed to Step 2.

If the line in alarm has never functioned properly as an APS line, verify that the following are true:

•Redundant front and back cards are in the appropriate bays and are installed at both ends of the line.

•Cable is properly connected to both ends of the line.

•Enter the dspapsbkplane command to verify that the APS connector is installed properly at both ends of the line.

Step 2 Enter the dspapslns command at both ends of the communication line to determine whether one or both lines in an APS pair are bad. Use Table 21 to help you determine which APS line is not functioning properly.

---

Note Table 21 is updated for Release 3.0.00.

---

Table 21 Troubleshooting APS Line Problems Using the dspaps Command 

Active Line	Working Line	Protection Line	Working Line LED	Protection Line LED	Description
Working	OK	OK	Green	Green	Active card is receiving a signal on working and protection lines. This does not guarantee that transmit lines are functioning properly. You must view the status on a remote switch.
Protection	SF	OK	Green for AXSM/A Red for AXSM/A Green for AXSM/B	Red	Active card is receiving a signal on the protection line. No signal is received on the working line.
Working	OK	SF	Green	Red	Active card is receiving a signal on the working line. No signal is received on the protection line.
Working	SF	SF	Red	Red	Active card is not receiving a signal from either line. The working line was the last line to work.
Protection	SF	SF	Red	Red	Active card is not receiving a signal from either line. The protection line was the last line to work.
Working	UNAVAIL	UNAVAIL	—	—	The card set is not complete. One or more cards have failed or been removed. See Table 22 to troubleshoot card errors.

If one or both lines appear to be bad, determine whether the working or protection line is in alarm. Troubleshoot and correct the standby line first. Replace the components along the signal path until the problem is resolved.

•If the dspapslns command at either end of the line indicates a front or back card problem, resolve that problem first. (See Table 22 to troubleshoot card problems).

•If the dspapslns command shows a signal failure on the standby line, replace that line.

•If the standby line is still down, replace the cards along the signal path.

Table 22 Troubleshooting Card Problems 

APS Line Failure	Possible Cause
All lines in upper and lower bays	Suspect a bad or removed front card. If both front cards are good, both back cards may be bad.
All lines in upper bay only. Lower bay APS lines OK.	Suspect bad upper bay back card.
All lines in lower bay only. Upper bay APS lines OK.	Suspect bad lower bay back card.

---

Installing and Upgrading to Release 3.0.25

For upgrades, the term graceful means the process does not interrupt switch traffic or change the switch configuration.

The MGX 8850 (PXM45) switch can be gracefully upgraded to Release 3.0.25 from Release 2.0.15, 2.0.16, 2.1.81 and 3.0.23. If upgrading from a release lower than 2.0.15, then the node must be upgraded first to 2.0.15, then to 3.0.25.

The MGX 8850 (PXM1E) and MGX 8830 switch can be gracefully upgraded to Release 3.0.25 from Release 3.0.23.

---

Note MGX Release 3.0.25 was not tested for the MGX 8950 switch.

---

---

Note Starting with Release 3.0.10, CLI commands and shellconn commands can be used to burn the boot images.

---

Important Upgrade Notes

---

Note If there are already two database versions on the disk, there may not be enough space for a new database to be created. Please read the Release-note enclosure for CSCdz29983. This Release-note enclosure is described in the "MGX 8830 and MGX 8850 (PXM45/PXM1E) Open Caveats in Release 3.0.25" section.

---

Frame Discard

---

Note An important caveat exists for virtual path connections (VPCs) that were added with frame discard enabled before version 3.0.23 or 4.0.10. The switch lets you enable frame discard on a VPC, even though hardware does not support it. If a VPC with frame discard enabled already existed on the node when you upgrade to release 3.0.23, 4.0.10, or later, you cannot subsequently modify the VPC unless you delete it, then re-add it with frame discard disabled. To avoid the need to delete a VPC, disable frame discard on any such VPCs before you upgrade to MGX releases 3.0.23, 4.0.10, or later.

---

The order of software releases was as follows:

•MGX 4.0.00 April 2003

•MGX 3.0.23 May 2003

•MGX 4.0.10 August 2003

•MGX 4.0.11 October 2003

•MGX 4.0.12 October 2003

•MGX 3.0.25 December 2003

AXSM/B Cards Running APS

•On upgrading to 3.0.10 and higher, the cnfxbarmgmt command has to be issued in the following cases to enable the loadsharing and auto shutdown when it is not enabled by default during the upgrade:

–A non-graceful upgrade from 2.0.x to 3.0.10 and higher.

–Upgrading from 2.1.76 or later when load sharing or auto shutdown is manually disabled.

AXSM Cards in Op B Mode and APS Lines

•If the firmware is being upgraded using loadrev/runrev to Release 3.0.10 and higher from Release 3.0.00, the APS lines must be deleted prior to the upgrade if all of the following conditions are met (refer to caveat CSCdy09317).

–APS is operating in the Operating Mode B. This can be verified from the output of the dspcd command on the AXSM card.

–APS lines have been added and none of the APS lines are configured with ITU-T protocol (that is, Annex-B protocol).

•When upgrading from 2.1.80 to 3.0.10 and higher, check that the working and protection lines are free of any line failures prior to issuing the enableaxsmbaps command. Otherwise, the ports can go down. If this problem is encountered, take out the receive part of the line that doesn't have the alarm and re-insert it (refer to caveat CSCdz50925).

NNI Ports

•Signaling must be configured on NNI ports prior to upgrading to Release 3.0.00 and higher. Otherwise, for an NNI port with no signaling and ILMI enabled, after upgrading to Release 3.0.00 and higher, the PNNI link will go down.

Manual Clocking

•Manual clocking may latch twice when upgrading the PXM45 controller cards from Release 2.1.x to Release 3.0.00 and higher.

Upgrade Precautions from 2.0.x

•For 1+1 APS and while the standby card is resetting during the upgrade process, the far end APS status is invalid and dspapsln will show the line is in mismatch or SF state (the NNI link will stay up). Once the standby card comes up, alarm will be clear. This means that APS protection is lost during the standby card reset.

•The ILMI default value for Release 2.0.15 is 0 for UNI and NNI ports, but Release 3.0.10 and higher uses the minVPI defined in the partition.

Installation and Upgrade Procedures

The procedures to upgrade to Release 3.0.25 appear in "Appendix A, Downloading and Installing Software Upgrades" in:

•Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3 (DOC-7814577=)

•Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3 (DOC-7814248=)

---

Note For MGX-RPM-XF-512 upgrade information, refer to the Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3.

---

You can access manuals (see the "Obtaining Documentation" section) or download them from the main Multiservice Switch Documentation site as follows:

---

Step 1 Go to http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm.

Step 2 Click on the link that matches your product name or configuration, for example:

•MGX 8850 (PXM45)

•MGX 8850 (PXM1E)

•MGX 8830

Step 3 Click on Release 3.

Step 4 Click on the Software Configuration Guide or RPM Installation manual.

---

Caveats for Release 3.0.25

This section provides information about caveats associated with Release 3.0.25 software.

Severity level 1, 2, and 3 caveats are organized in this section as follows:

•MGX 8830 and MGX 8850 (PXM45/PXM1E) Open Caveats in Release 3.0.25

•Status of MGX 8830 and MGX 8850 (PXM45/PXM1E) Caveats Found in Previous Releases

•MGX 8830 and MGX 8850 (PXM45/PXM1E) Resolved Caveats in Release 3.0.25

MGX 8830 and MGX 8850 (PXM45/PXM1E) Open Caveats in Release 3.0.25

Table 28 lists the Severity 1 open caveats for the MGX 8830 and MGX 8850 (PXM45/PXM1E) Release 3.0.25 software.

---

Note The open caveats listed in this section are accurate as of December 1, 2003.

---

Table 23 Severity 1 Open Caveats for MGX Release 3.0.25 Software 

DDTS Issue	Description
CSCdz12195	Symptom: AXSME-8-OC3 card fails to perform switchcdred the first time. Condition: The problem seem to happen with the test automation script used in manufacturing. Workaround: The same command issued the 2nd time seem to work O.K. Hardware: AXSME
CSCdz29064	Symptom: Watchdog causes the controller card (PXM) or Service Module (AXSM/AXSME/FRSM12) to rebuild. Condition: The Task Monitor erroneously detects a task is hung while attempting to delete another task when it is actually waiting on a message queue to receive messages. Workaround: None. Hardware: PXM45/B
CSCea18042	Symptoms: PXM crashes. Conditions: Send more data on the connection than the configured PCR. Workaround: Do not allow to send more data than configured PCR. Hardware: PXM45

Table 29 lists the Severity 2 open caveats for the MGX 8830 and MGX 8850 (PXM45/PXM1E) Release 3.0.25software.

---

Note

Table 24 Severity 2 Open Caveats for MGX 3.0.25 Software 

DDTS Issue	Description
CSCdy59180	Symptom: Once it was observed that 4 SPVC failed to route. This failure was due to slave state of the connections were in wrong state. Conditions: When large number (250k) of SPVC rerouted Workaround: None Hardware: PXM45/B
CSCdy60873	Symptom: After resetting the MGX-RPM-XF-512 card, it went into the failed state. Conditions: It happens mostly under the following conditions. a) When the ssi chunk pool free pattern was set. Run ipcMblkShow to see whether this pattern is set or not. Workaround: Reset the ssiChunk Pool Free pattern set (if it is enabled already). Do "ssiChunkPoolsFillFreePatternSet 0" to reset this option. Hardware: PXM45B
CSCdy65143	Symptom: Executing a dspcon on the PXM45/B with an invalid VCI is displaying a connection with a different VCI and other invalid attributes. Conditions: Executing dspcon with an invalid VCI to display the connection. Workaround: Unknown. Hardware: PXM45/B
CSCdy71636	Symptom: The customer sees traffic stop in one direction spontaneously Conditions: It happens spontaneously on an FRSM 8T1E1 card on a MGX1 shelf. MGX1 shelf is a feeder to an MGX 2 shelf. Workaround: Using CWM reconfigure the CIR of the connection. Or delete and re add the PVC Hardware: FRSM-8T1E1
CSCdy77053	Symptom: There is no AXSME port ingress counter. This is creating a problem when using the AXSME double density feature. Conditions: dspportcnt does not provide ingress counters. Workaround: None. Hardware: AXSME
CSCdy80912	Symptom:PXM45 card got reset 2+ times Conditions: In this order, reset the AXSM cards, the standby PXM45 card, then the active PXM45 card. Workaround: Unknown. Hardware: PXM45/B
CSCdy81906	Symptom: Cards in slots 1 and 2 rebooted and then failed. Conditions: After a burnboot on the PXM45 in slot 8, and switchcc was executed on the shelf. Workaround: None. Hardware: PXM45/B
CSCdz29610	Symptom: IMA link is stuck in LODS alarm. Conditions: Both 1 & 2 need to be met. 1. When only the Rx of IMA link at one end is disconnected and re-connected. 2. The link whose Rx is disconnected is cross-connected at the other end. Workaround: 1. Delete the link and add it back. OR 2. Restart the group using CLI restartimagrp. Hardware: PXM1E-IMA
CSCdz31938	Symptom: Current core shows 2 or 3 instead of valid values 0 or 1. condition: Seems to only happen in version 3.0.11.0 On CLI, on executing 'core', the display shows current core as 2 or 3. Workaround: On the CLI, execute command 'core clear'. This will take care of the problem for good. Hardware: PXM1E
CSCdz43030	Symptom: IMA link added to a group displays the following Rx & Tx states and does not become active even if it is connected to the FE link and there are no line alarms. X,Y,A and Z are any valid numbers. dspimalnks =========== Link Grp Rel Ne Ne NeRx Tx Rx Num Num Dly Tx Rx Fail Lid Lid (ms) State State Status ------------------------------------------------------------------------------ 1.X 1.Y 0 Not in Group Not in Group No Failure Z A Conditions: Current state: The group has non-zero links in LIF failure that are not connected to FE. Action that leads to the above problem: The group is restarted using CLI restartimagrp or corresponding SNMP command. After the restart, any link addition will result in the state mentioned above. Workaround: 1. Connect all links to FE and make sure there are no physical line alarms on any of the links and that the FE group is sending valid ICP cells on all the links. All the links will then transition to active by themselves. OR 2. Delete all links from the group and add them back. In this case, the links that are connected to FE will become active. Hardware: AXSME-IMA
CSCdz46545	Symptom: Clock source stuck in wideband-locking Conditions: 1) After changing the distribution mode from manual to ncdp. 2) Revertive option enabled in the manual mode. Workaround: Configure the clock source to non-revertive in manual mode before changing the clock mode to ncdp. Hardware: PXM1E
CSCdz47471	Symptom: Power reset on node causes the primary SM to go into mismatch after runrev is issued (1:n redundancy) Condition: During one of the upgrade failure recovery scenarios on a service module (SM), a node power reset is performed after runrev command is issued for slot-17 (the redundant card is in slot-29). After power is restored, the primary card comes up in mismatch state. Observe some error messages as well. Workaround: unknown Hardware: PXM1E
CSCdz69770	Symptom: The error message is not printed on the display. Condition: At the time this problem was seen, no particular commands were issued. Workaround: None. Hardware:PXM1E
CSCea11335	Symptom: PXM in Active-F state. Conditions: System had a single PXM and a series of consecutive AXSM switchredcd commands resulted in an exception during snmp request. Workaround: None. Hardware: PXM45B
CSCea29664	Symptom: Customer reports that on one MGX 8850 switch, an AXSM-16-155 card in a particular slot is automatically removed from the shelf and then comes back in service. No manual or CLI intervention. The card is restored after about 2 minutes. This can happen a few times a day with periods of nearly a month with no problems. Card replacement already performed. Conditions: Normal operation for the switch. Workaround: None. Hardware: AXSM-16-155
CSCea64790	Symptom: AXSM in Yred 1:1 configuration has a strange behavior: standby card fails and goes into the Init/Boot/Empty status, traffic on the active card is affected, a reset on the failed card affects the active card too. The active card is not accessible via CC command, reply: "Err: redirection timed out" Conditions: System running code 3.0.20; Yred configuration on AXSM 1:1. Workaround: Resetting via CLI on the "ACTIVE" card, it will restore both the cards but some ghost connections may appear in "mismatch" status. Need to delete the connections manually. A display of those connections will display the following message: "ERR: Connection does not exist on controller". Hardware: AXSM
CSCea78828	Symptom: Both PXM45B failed after loadrev latest test image, and the log reports fatal error on slot8. Conditions: When slot 8 was active, do loadrev. Workaround: Pull out slot 7. Hardware: PXM45B
CSCec83347	Symptoms:MGX45 node populated with AXSME running ver 3.0.(20.100) reset due to watchdog timeout, and dumped a core. Concern: Need to investigate the root cause for the card to reset Workaround:None required, as standby takes over Hardware: AXSME
CSCin17591	Symptom: The administrative state of the subinterface is not getting populated in config upload for RPM-PR. Conditions: Create a new subinterface on a RPM-PR card with an PXM1E controller card. Then do a cold start of CWM which does a configuration upload from the switch. After this data is uploaded to the CWM database, it was realized that subinterface administrative status is missing. Workaround: Check the subinterface administrative status via the CLI. Hardware: PXM1E

The open caveats listed in this section are accurate as of December 1, 2003.

---

Table 30 lists the Severity 3 open caveats for the MGX 883 and MGX 8850 (PXM45/PXM1E) Release 3.0.25 software.

---

Note The open caveats listed in this section are accurate as of December 1, 2003.

---

Table 25 Severity 3 Open Caveats for MGX Release 3.0.25 Software 

DDTS Issue	Description
CSCdu27030	Symptom: OAM CC Activation Cell correlation tag is incorrectly modified. Conditions: User notes that an F4-Seg Active-CC OAM cell with a correlation tag of 0x6A is returned to the sending device with a correlation tag of 0x00. Workaround: None. Hardware: AXSM
CSCdv69400	Symptom: addchanloop on AXSME doesn't have option 2. Local loop in loopback. Condition: When addchanloop on AXSME. Workaround: Not known. Hardware: AXSME
CSCdx62800	Symptoms: MGX45 CLI Reference Manual needs to be updated. Conditions: 4 new commands missing out of the manual. Workaround: None. Hardware: PXM45B
CSCdx82847	Symptom: Line status LED's on standby PXM1E always show green. Conditions: The line status LED on a standby PXM1E is always green even if the line is in LOS. This is inconsistent with other LEDs on the PXM1E. e.g. the ALARMs LEDs on the standby PXM1E remain OFF. We think that the line status LED should either reflect same as the active PXM1E or they remain OFF as of the alarm LED. Workaround: None. Hardware: PXM1E
CSCdx85715	Symptom: CLI needed to display config and connection type of svc based RCC. Conditions: Command equivalent to dsppnctlvc. Workaround: None. Hardware: PXM45B
CSCdy23797	Symptom: pntrace commands not completely documented. Conditions: MGX CLI Manual vs. the troubleshooting guide. Workaround: None. Hardware: PXM45B
CSCdy36692	Symptom: Need warning messages for cnfport Conditions: Warning messages are needed to inform the user that cnfport is going to be changed. Workaround: None. Hardware: PXM1E
CSCdy37182	Symptom: dspcd shows lower back card empty for a full height back card. Conditions: None. Workaround: None. Not service impacting, only a display issue. Hardware: all
CSCdy41895	Symptoms: 'dspportsct vcThr' should match with the one shows on 'dspportsct qeVcThr' But the VSI_Signal values shown from SCT does not match to the actual HW value. Conditions: dspportsct vcThr & dspportsct qeVcThr. Workaround: This is a display problem. The VSI_Signal VC Threshold values being display from the dspportsct or dspcdsct command is incorrect. Basically the AXSME software ignores the VC Threshold values being specified in SCT. Instead, the AXSME software would program a lower pre-defined threshold values for the VSI Signal channels. So the values in the HW are correct. Please ignore the VSI_signal values from the SCT. The lower pre-defined is needed because we want to limit our traffic flow on the VSI signaling channels prevent flooding the PXM45. If the PXM45 is flooded, then there will be some unpredictable and unreliable behaviors on PXM45. We are going to fix the display problem. Hardware: AXSME
CSCdy47415	Symptom: delred shows incorrect error message. Conditions: delred command issued. Workaround: No workaround needed. Just ignore the message and use dspred to verify the delred result. Hardware: PXM1E
CSCdy49757	Symptom: AUSM channel, port and SAR counters do not correctly count RM cells received from CPE. Conditions: The AUSM channel, port and SAR counters do not correctly handle RM cells when they are generated by the CPE (test-set). When RM cells are received by the AUSM card the baseline behavior is that they should be discarded by the UNI port. Indeed that is what is noted to happen for AUSM on PXM1E. The command dspconload" shows that no traffic is received from the AUSM when a stream of RM cells at 480 cps is generated by the test-set. Workaround: None. Hardware: AUSM-8T1E1
CSCdy59294	Symptom: AUSM/PXM1E transmits invalid PTI=7 cells into network but cannot pass traffic out of far-end AUSM port. Condition: An abr1 PVC was provisioned between two AUSM-IMA ports: [Test Set A] <---> node1 to node2 <---> [Test Set B] Test set A generated 480 CPS of ATM cells with the PTI field set to 7 (invalid). The payload consisted of 48 byte 6A pattern. The channel, port and SAR counters on node1 indicate that traffic is being sent into the network. On the PXM1E card on node1 the "dspconload" command indicates that all the PTI=7 traffic is sent out the trunk interface. In fact there seems to be RM cell overhead in both directions. The "dspconload" command on node1 indicates that all PTI=7 traffic is being received on the trunk interface. However on the AUSM port on node2 the chan, port and SAR counters all remain at zero. It is very strange that the AUSM card handles PTI=7 cells differently on the Ingress and Egress directions. At one time the PVC was able to transmit PTI=7 cells end to end but it has only been observed to happen once. Workaround: None. Hardware: AUSM-8T1E1
CSCdy73100	Symptom: Misspelled word in the syntax of the cnfpnni-node output. Conditions: When viewing the output, the word does is spelled deso. Workaround: None. Hardware: PXM45/B
CSCdy81038	Symptom: You can addred then switchredcd, with a bad gigE backcard or while the gige is in an uninitialized state. Condition: *Sep 30 19:46:45.475: %GE-3-INTERNAL: GE internal error, HW init failed. Backcard may need to be reseated -Traceback= 401CA3A8 401CA604 401CCA1C 40407350 403C4AFC 402EDAB4 402EDC9C 403A1 1D0 403A11BC *Sep 30 19:46:45.483: %GE-3-INITFAIL: GE initialization failed, GigabitEthernet1 /0 -Traceback= 401CA474 401CA604 401CCA1C 40407350 403C4AFC 402EDAB4 402EDC9C 403A1 1D0 403A11BC. Workaround: Enhancement request. Currently the backcard must be reseated, replaced, and or removed. Hardware: RPM-XF
CSCdy82452	Symptom: QE48 fault not detected in standby state. Conditions: User executed QE48 VC Table and QDB Memory Bank Fault Insertion test cases. Workaround: None. Hardware: AXSM1
CSCdy82836	Symptom: Standby AXSM-E card did not reset and error was not recorded in event log. Condition: Humvee ILT CAM data bit 8 tied to GND fault insertion test case was executed. Workaround: Unknown Hardware: AXSME
CSCdy82849	Symptom: When fault inserted on active or standby card, reset/switchover did not take place for 3 min. Condition:SWB10-Hold Atmizer in reset fault insertion test case was executed. Workaround: Unknown. Hardware: AXSME
CSCdy82872	Symptom: Card fault not reported in event log. Conditions: Hold Port 1 secondary Tetra in reset fault insertion test case was executed on standby AXSM-E. Workaround: Unknown. Hardware: AXSME
CSCdy86511	Symptom: The AXSM reset due to a software error. See logs below. The error information is corrupted. Condition: This is a customer node running 2.1(80). The card has been replaced and is being sent back for failure analysis. Workaround: Unknown. Hardware: AXSME
CSCdz04750	Symptom: The FRSM8 card does not correctly process incoming frames with incorrect CRC-16. condition: The FRSM8 card does not correctly process incoming Frames with incorrect Frame Check Sum sequence. The port should discard these "corrupt" frames under the port counter "RcvFramesDiscCRCError:". Instead the frames get sent into the network. Workaround: Unknown. Hardware: PXM1E
CSCdz18393	Symptom: xcnfln command does not have v.35 option included in the display. Condition: xcnfln command has the option for x21 and hssi. But it does not have the option for v35. We can configure the line using the x21 option for v.35. But it would be clear if that option also included in the xcnfln. Workaround: Unknown. Hardware: PXM1E
CSCdz25041	Symptom: No hssi option in the xcnfln command. Condition: 1. No hssi option in the xcnfln command 2. Adding the line loopback on the line which has loopback enabled gives wrong error message Error occurred during the SNMP SET operation !! Probable Reason: "Cannot change loopback" SNMP Error Code: 76 Set failed due to illegal parameter(s) Syntax: addlnloop "line_num" line number -- 1-2 for HSSI, 1-8 for V.35/X.21. It should say the line loopback is already enabled. --------------------------------------------------- 3. When we try to add the loopback with xcnfln command on the line with already enabled loopback it gives the wrong error message. Error occurred during the SNMP SET operation !! Probable Reason: "Cannot change loopback" SNMP Error Code: 76. Set failed due to illegal parameter(s). It should take it or it should say the loopback is already enabled. Workaround: Unknown. Hardware: PXM1E
CSCdz29332	Symptom: Unknown Error Code message returned on cli. Condition: When the dsppnni-timer command is executed with the incorrect node index. Workaround: None. Hardware: PXM45/B
CSCdz29983	Symptom: Standby card might not come up after the loadrev. Condition: Node's disk space is not enough for the new database to be created if there are already two database versions in the disk. Workaround: Remove old database before the upgrade. To remove, first check if there is more than the current database - Save the current configuration: CLI "saveallcnf" - If more than the current database version has been created, then remove other or older databases following these steps:: 1. From the Active PXM slot, dspversion to know the current FW version. 2. From the Active PXM slot, cd D:/DB2/LS1 3. ls to see if there is any extra DB Version beside the current expected version DB. Delete the extra DB Version. 4. Go to shellconn and still in the "D:/DB2/LS1" directory path. a. Delete the extra database: pxm1> "deltree VER00X_YYY_ZZZ" b. Repeat steps 1 to 4 to check and remove any extra database(s) on the Standby PXM also.
CSCdz34835	Symptom: cnfln -e3 <bay.line> -len <length> did not work. Conditions: All conditions. Workaround: None. Hardware: PXM1E
CSCdz40676	Symptom: cnfpnportsig command results in false warning when a value for vpi=0 is assigned. Condition: cnfpnportsig 7:2.6:26 -vpi 1. WARNING: Signaling VPI is outside of the port VPI range. Syntax: cnfpnportsig <portid>. Workaround: Unknown. Hardware: PXM1E
CSCdz40700	Symptom: dsplog for FRSMHS2/B does not show the line deleted in the message". Condition: ON FRSM-HSSI Module, line is deleted by using the delln command. But it is not showing in the dsplog that the line is deleted as it shows for other SM modules. Workaround: Unknown. Hardware: PXM1E
CSCdz40737	Symptom: dspcnfdiag is not updated after cnfdiagall command for SRM slot. Conditions: The display is not updated after "cnfdiagall" for slot 15,16,31 & 32 (SRM). After a new node was installed we issued the "cnfdiagall enable disable" command. The display does not update the status for SRM slots. Workaround: None. Hardware: PXM1E
CSCdz46078	Symptom: dspalms does not have hssi option. Condition: dspalms does not have the " hssi " option as the line type. However, it does work, if you use x21 option. Workaround: Unknown. Hardware: PXM1E
CSCdz53209	Symptom: FRSM-2T3 cards came up without boot image. Condition: New FRSM-2T3 cards were inserted in slot-13 and slot-14. Initially they came in "boot" state. At this time setrev was executed for slot-13 and 14. After setrev both cards came up as active without boot image. Workaround: Unknown. Hardware: PXM1E
CSCdz67977	Symptom: General error logs for humvee devices for the error state change. Conditions: If Elt mismatch errors or other errors happen, this could happen if there are some pnports and the communication between the active PXM and AXSMs fail. Workaround: None. Hardware: AXSM
CSCea08833	Symptom: AXIS appears as the shelf name causing a display error on MGX PXM1E. Conditions: When the customer performs a switchredcd or a resetcd on the FRSM2T3. Workaround: None. Hardware: PXM1E
CSCea24010	Symptom: During PXM45/B upgrade from 2.1(80.0) to 3.0.(20.100). OAM error messages were seen in the log. This was seen on two nodes in the customer's network. Example: 13A00416 02/16/2003-04:47:04 OAM-5-LOG tOamLb OamLpbkHandler OAM error: OamLpbkHandler: 164: 4099: 65280 11111 - 3 dropped. Conditions: Upgrade from 2.1(80.0) to 3.0(20.100). Workaround: None. Hardware: PXM45B
CSCea25980	Symptom: During a segment test for a VC,found that the "addlocalloop" type 1 and/or 2 doesn't work with the scenario below in case a ping is used as test: router1 ----- MGX1 ---- ATM CLOUD ---- MGX2 --- MUX ---- router2 Ping from router 1 were successful only if traffic from remote end was interrupted. Conditions: Always reproducible if egress side is sending some kind of traffic. Observed on AXSM running 2.0.17 FW. Workaround: Need to put down the egress interface or avoid in some way traffic from egress side to pass toward the cpe from where the ping is performed. Hardware: AXSM1
CSCea31637	Symptom: Loopback OAM got dropped at wire rate on AXSME, it will happen on the FRSM12, too. Condition: SPVC provisioned btw FRSM12 and AXSM/AXSME, pump-in loopback OAM to the port of AXSM/AXSME which has connections with FRSM12 at DS3 rate. The OAM cell will get dropped. Workaround: This happens only in special cases. No workaround for the DS3 rate lpbk OAM drop. Hardware: FRSM12
CSCea38347	Symptom: When cnfdiagall is done enabling online diag for all slots, it also enables for SRM-3T3 which does not support online diag? Conditions: During upgrade, if all online diagnostics are disabled, then after the upgrade, when all online diagnostics are enabled, only the diagnostics for PXM-1E are enabled whereas the diagnostics for SMs remain disabled. However if the online diagnostics are NOT disabled prior to upgrade then after the upgrade the display still shows online diagnostics are enabled for PXM-1E as well as the SMs. Workaround: None
CSCea41517	Symptom: Device errors detected on the Humvee ASIC by the Hardware Monitoring Module (HMM) are logged silently without a corresponding alarm or trap. Conditions: There should be errors on the Humvee ASIC (such as Transceiver Errors, QE Interface Errors etc.). Workaround: None.
CSCea42088	Symptom: Can not modify the remote ICR value. Conditions: ABR XPVC connection between axsm-e & bxm. Workaround: None. Hardware: AXSME
CSCea59289	Symptom: Command "addchanloop" doesn't work when used on VPs with a value greater than 255. The loop should be put on the egress side and must cross an NNI link. Below a diagram that explain the conditions for observe the problem: router1-----AXSM-MGX1-AXSM ----PNNI LINK---- AXSM-MGX2-AXSM----router2 Loop on MGX2 face to router1, NNI link in the middle. Conditions: This has been observed in a network running 3.0(20) AXSM1. Workaround: None. Hardware: AXSM1
CSCeb12259	Symptoms: Hard disk goes to busy state and needs a power up to get out of the busy state Conditions: Not known Workaround: None. Hardware: PXM1E
CSCeb55991	Symtoms: In the log we see it switch from one clock source to another for no apparent reason in the log. Conditions: MGX PXM45B 3.0.20.100 Workaround: None Hardware: PXM45B
CSCeb72485	Symptom: The CESM port will get stuck in RcvAIS due to an alarm loop. Conditions: This should be specific to a hard loopback or to equipment that transmits back exactly the same T1 state as received (without interpretation). With a test set or any equipment on one end of a CESM connection and a loopback on the remote end when there is an ATM PVC failure, there is an alarm loop which prevents the circuit from coming up even after the ATM PVC is restored. Workaround: Once in this state, to recover the line alarm must be cleared. This can be accomplished by plugging in a good T1 or by resetting the CESM. Hardware: CESM-8T1E1
CSCec45442	Symptom: After a switchcc or any PXM switchover, a second outage is seen about 10 seconds after the switchover. The second outage may last anywhere from 8 to 120 seconds. Conditions: This has only been observed with specific ATM encryption equipment also inline. Extensive testing has been done with the encryption equipment removed and this problem is not present in those scenarios. Workaround: None Hardware: PXM1E
CSCuk38319	Symptom: VC-12 REI is seen on the tester connected to SRME. Conditions: Links added to VISM-PR-8E1. Workaround: None. Hardware: PXM45/B

Status of MGX 8830 and MGX 8850 (PXM45/PXM1E) Caveats Found in Previous Releases

Table 31 lists the status of the known caveats from previous releases.

Table 26 Status of Known Caveats from Previous Releases 

DDTS Issue	Severity	Description
CSCdz24242	Severity 1	Fixed in Release 3.0.23
CSCeb12284	Severity 1	The bug was closed since it was due to a faulty hardware device.
CSCdy53476	Severity 2	This bug was closed when it could not be reproduced.
CSCdz78585	Severity 2	This bug was closed since it is not applicable any more to the hardware.
CSCdx45116	Severity 3	This bug was closed due to a hardware limitation.
CSCdy78398	Severity 3	This bug was closed due to a design limitation.
CSCdy82219	Severity 3	The bug was closed due to a design limitation.
CSCdy82452	Severity 3	Duplicate of CSCeb48125, which was fixed in Release 3.0.20.
CSCdy82780	Severity 3	Fixed in Release 3.0.23.
CSCdz08738	Severity 3	This bug was closed since it could not be reproduced.
CSCdz40737	Severity 3	Duplicate of CSCea38347
CSCdz67977	Severity 3	Duplicate of CSCea41517
CSCea27448	Severity 3	Duplicated of CSCdz88612, which was fixed in Release 3.0.23.
CSCea32002	Severity 3	This bug was closed since it could not be reproduced.
CSCea64210	Severity 3	This bug was closed since the software was working as designed.
CSCea75060	Severity 3	This bug was closed since it could not be reproduced.
CSCea85655	Severity 3	This bug was closed since it could not be reproduced.
CSCea92433	Severity 3	Duplicate of CSCea75060, which was closed since it could not be reproduced.
CSCeb03870	Severity 3	Fixed in Release 3.0.23.

MGX 8830 and MGX 8850 (PXM45/PXM1E) Resolved Caveats in Release 3.0.25

Table 32 lists the resolved caveats for the MGX 8830 and MGX 8850 (PXM45/PXM1E) software Release 3.0.25.

---

Note All bug fixes from Release 3.0.23 as of December 1, 2003 are also fixed in Release 3.0.25.

The resolved bugs listed in this section are accurate as of December 1, 2003.

---

Table 27 Resolved Caveats for MGX Release 3.0.25 Software 

CSCdz47532	1e:DT PXM1e 4-oc3 BC in mismatch state
CSCea15756	PXM switched from slot 8 to slot 7 due to non-fatal major er
CSCeb18630	ncdp_db gets updated during loadrev state and blocks runrev
CSCeb33695	Fix the ssiClkTickGet timer wraparound leading to file creat
CSCeb37912	AIS status is not getting updated on the VUNI port
CSCeb59779	Trap 60051 not generated for RPM_PR
CSCeb60706	PXM45/B reset due to non fatal major error core dump availab
CSCec49356	tVsiSlave on AXSM crashes on multiple nodes around the same
CSCec63239	VxWork timer wrapped around
CSCec66037	UBR.2 policing needs to tag all cells

Caveats for Release 3.0.23

This section provides information about caveats associated with Release 3.0.23 software.

Severity level 1, 2, and 3 caveats are organized in this section as follows:

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.23

•Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.23

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.23

Table 28 lists the Severity 1 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.23 software.

---

Note The open caveats listed in this section are accurate as of May 17, 2003.

---

Table 28 Severity 1 Open Caveats for MGX Release 3.0.23 Software 

DDTS Issue	Description
CSCdz12195	Symptom: AXSME-8-OC3 card fails to perform switchcdred the first time. Condition: The problem seem to happen with the test automation script used in manufacturing. Workaround: The same command issued the 2nd time seem to work O.K. Hardware: AXSME
CSCdz24242	Symptom: PnCcb got suspended due to leakage using up all chunks in some ipc pools. Conditions: Running the following scripts. 1. resetcd all NBSMs at 800 sec interval in a infinite loop. 2. up/dn ILMI on each PNNI link at 60 sec interval was done on 7 links in an infinite loop. Workaround: Unknown. Hardware:PXM1E
CSCdz29064	Symptom: Watchdog causes the controller card (PXM) or Service Module (AXSM/AXSME/FRSM12) to rebuild. Condition: The Task Monitor erroneously detects a task is hung while attempting to delete another task when it is actually waiting on a message queue to receive messages. Workaround: None. Hardware: PXM45/B
CSCea18042	Symptoms: PXM crashes. Conditions: Send more data on the connection than the configured PCR. Workaround: Do not allow to send more data than configured PCR. Hardware: PXM45
CSCeb12284	Symptoms: Node reset. Conditions: After burnboot, and upgrading from 3.0.20 to 3.0.23. Workaround: Unknown. Hardware: PXM45

Table 29 lists the Severity 2 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.23software.

Table 29 Severity 2 Open Caveats for MGX 3.0.23 Software 

DDTS Issue	Description
CSCdy53476	Symptom: All service modules and standby PXM in the node reset/boot continuously. Complete communication failure between the active PXM and all other slots. Conditions: Unknown. Workaround: None, other than a node rebuild. Hardware: PXM45/B
CSCdy59180	Symptom: Once it was observed that 4 SPVC failed to route. This failure was due to slave state of the connections were in wrong state. Conditions: When large number (250k) of SPVC rerouted Workaround: None Hardware: PXM45/B
CSCdy60873	Symptom: After resetting the MGX-RPM-XF-512 card, it went into the failed state. Conditions: It happens mostly under the following conditions. a) When the ssi chunk pool free pattern was set. Run ipcMblkShow to see whether this pattern is set or not. Workaround: Reset the ssiChunk Pool Free pattern set (if it is enabled already). Do "ssiChunkPoolsFillFreePatternSet 0" to reset this option. Hardware: PXM45B
CSCdy65143	Symptom: Executing a dspcon on the PXM45/B with an invalid VCI is displaying a connection with a different VCI and other invalid attributes. Conditions: Executing dspcon with an invalid VCI to display the connection. Workaround: Unknown. Hardware: PXM45/B
CSCdy71636	Symptom: The customer sees traffic stop in one direction spontaneously Conditions: It happens spontaneously on an FRSM 8T1E1 card on a MGX1 shelf. MGX1 shelf is a feeder to an MGX 2 shelf. Workaround: Using CWM reconfigure the CIR of the connection. Or delete and re add the PVC Hardware: FRSM-8T1E1
CSCdy77053	Symptom: There is no AXSME port ingress counter. This is creating a problem when using the AXSME double density feature. Conditions: dspportcnt does not provide ingress counters. Workaround: None. Hardware: AXSME
CSCdy80912	Symptom:PXM45 card got reset 2+ times Conditions: In this order, reset the AXSM cards, the standby PXM45 card, then the active PXM45 card. Workaround: Unknown. Hardware: PXM45/B
CSCdy81906	Symptom: Cards in slots 1 and 2 rebooted and then failed. Conditions: After a burnboot on the PXM45 in slot 8, and switchcc was executed on the shelf. Workaround: None. Hardware: PXM45/B
CSCdz29610	Symptom: IMA link is stuck in LODS alarm. Conditions: Both 1 & 2 need to be met. 1. When only the Rx of IMA link at one end is disconnected and re-connected. 2. The link whose Rx is disconnected is cross-connected at the other end. Workaround: 1. Delete the link and add it back. OR 2. Restart the group using CLI restartimagrp. Hardware: PXM1E-IMA
CSCdz31938	Symptom: Current core shows 2 or 3 instead of valid values 0 or 1. condition: Seems to only happen in version 3.0.11.0 On CLI, on executing 'core', the display shows current core as 2 or 3. Workaround: On the CLI, execute command 'core clear'. This will take care of the problem for good. Hardware: PXM1E
CSCdz43030	Symptom: IMA link added to a group displays the following Rx & Tx states and does not become active even if it is connected to the FE link and there are no line alarms. X,Y,A and Z are any valid numbers. dspimalnks =========== Link Grp Rel Ne Ne NeRx Tx Rx Num Num Dly Tx Rx Fail Lid Lid (ms) State State Status ------------------------------------------------------------------------------ 1.X 1.Y 0 Not in Group Not in Group No Failure Z A Conditions: Current state: The group has non-zero links in LIF failure that are not connected to FE. Action that leads to the above problem: The group is restarted using CLI restartimagrp or corresponding SNMP command. After the restart, any link addition will result in the state mentioned above. Workaround: 1. Connect all links to FE and make sure there are no physical line alarms on any of the links and that the FE group is sending valid ICP cells on all the links. All the links will then transition to active by themselves. OR 2. Delete all links from the group and add them back. In this case, the links that are connected to FE will become active. Hardware: AXSME-IMA
CSCdz46545	Symptom: Clock source stuck in wideband-locking Conditions: 1) After changing the distribution mode from manual to ncdp. 2) Revertive option enabled in the manual mode. Workaround: Configure the clock source to non-revertive in manual mode before changing the clock mode to ncdp. Hardware: PXM1E
CSCdz47471	Symptom: Power reset on node causes the primary SM to go into mismatch after runrev is issued (1:n redundancy) Condition: During one of the upgrade failure recovery scenarios on a service module (SM), a node power reset is performed after runrev command is issued for slot-17 (the redundant card is in slot-29). After power is restored, the primary card comes up in mismatch state. Observe some error messages as well. Workaround: unknown Hardware: PXM1E
CSCdz69770	Symptom: The error message is not printed on the display. Condition: At the time this problem was seen, no particular commands were issued. Workaround: None. Hardware:PXM1E
CSCdz78585	Symptom: PXM1E in failed state. Conditions: Observed PXM-1E in slot-7 in Failed state with all port LEDs on the front panel glowing amber and are static. The status LED is red and blinking. The node was upgraded to new release on Friday and the node was last seen in OK state on 01/11/2003 15:00GMT. Today's capture taken 01/13/2003 14:00 GMT shows PXM-1E in slot-7 in Failed state. Workaround: None. Hardware: PXM1E
CSCea11335	Symptom: PXM in Active-F state. Conditions: System had a single PXM and a series of consecutive AXSM switchredcd commands resulted in an exception during snmp request. Workaround: None. Hardware: PXM45B
CSCea29664	Symptom: Customer reports that on one MGX 8850 switch, an AXSM-16-155 card in a particular slot is automatically removed from the shelf and then comes back in service. No manual or CLI intervention. The card is restored after about 2 minutes. This can happen a few times a day with periods of nearly a month with no problems. Card replacement already performed. Conditions: Normal operation for the switch. Workaround: None. Hardware: AXSM-16-155
CSCea64790	Symptom: AXSM in Yred 1:1 configuration has a strange behavior: standby card fails and goes into the Init/Boot/Empty status, traffic on the active card is affected, a reset on the failed card affects the active card too. The active card is not accessible via CC command, reply: "Err: redirection timed out" Conditions: System running code 3.0.20; Yred configuration on AXSM 1:1. Workaround: Resetting via CLI on the "ACTIVE" card, it will restore both the cards but some ghost connections may appear in "mismatch" status. Need to delete the connections manually. A display of those connections will display the following message: "ERR: Connection does not exist on controller". Hardware: AXSM
CSCea78828	Symptom: Both PXM45B failed after loadrev latest test image, and the log reports fatal error on slot8. Conditions: When slot 8 was active, do loadrev. Workaround: Pull out slot 7. Hardware: PXM45B
CSCin17591	Symptom: The administrative state of the subinterface is not getting populated in config upload for RPM-PR. Conditions: Create a new subinterface on a RPM-PR card with an PXM1E controller card. Then do a cold start of CWM which does a configuration upload from the switch. After this data is uploaded to the CWM database, it was realized that subinterface administrative status is missing. Workaround: Check the subinterface administrative status via the CLI. Hardware: PXM1E

Table 30 lists the Severity 3 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.23 software.

---

Note The open caveats listed in this section are accurate as of May 17, 2003.

---

Table 30 Severity 3 Open Caveats for MGX Release 3.0.23 Software 

DDTS Issue	Description
CSCdu27030	Symptom: OAM CC Activation Cell correlation tag is incorrectly modified. Conditions: User notes that an F4-Seg Active-CC OAM cell with a correlation tag of 0x6A is returned to the sending device with a correlation tag of 0x00. Workaround: None. Hardware: AXSM
CSCdv69400	Symptom: addchanloop on AXSME doesn't have option 2. Local loop in loopback. Condition: When addchanloop on AXSME. Workaround: Not known. Hardware: AXSME
CSCdx45116	Symptom: Some of the connections are in alarm after stopbert testing Condition: cnfbert, startbert then stopbert Workaround: dncon/upcon or dnport/upport can recover the connection from the alarm status. Hardware: AXSME-IMA
CSCdx62800	Symptoms: MGX45 CLI Reference Manual needs to be updated. Conditions: 4 new commands missing out of the manual. Workaround: None. Hardware: PXM45B
CSCdx82847	Symptom: Line status LED's on standby PXM1E always show green. Conditions: The line status LED on a standby PXM1E is always green even if the line is in LOS. This is inconsistent with other LEDs on the PXM1E. e.g. the ALARMs LEDs on the standby PXM1E remain OFF. We think that the line status LED should either reflect same as the active PXM1E or they remain OFF as of the alarm LED. Workaround: None. Hardware: PXM1E
CSCdx85715	Symptom: CLI needed to display config and connection type of svc based RCC. Conditions: Command equivalent to dsppnctlvc. Workaround: None. Hardware: PXM45B
CSCdy23797	Symptom: pntrace commands not completely documented. Conditions: MGX CLI Manual vs. the troubleshooting guide. Workaround: None. Hardware: PXM45B
CSCdy36692	Symptom: Need warning messages for cnfport Conditions: Warning messages are needed to inform the user that cnfport is going to be changed. Workaround: None. Hardware: PXM1E
CSCdy37182	Symptom: dspcd shows lower back card empty for a full height back card. Conditions: None. Workaround: None. Not service impacting, only a display issue. Hardware: all
CSCdy41895	Symptoms: 'dspportsct vcThr' should match with the one shows on 'dspportsct qeVcThr' But the VSI_Signal values shown from SCT does not match to the actual HW value. Conditions: dspportsct vcThr & dspportsct qeVcThr. Workaround: This is a display problem. The VSI_Signal VC Threshold values being display from the dspportsct or dspcdsct command is incorrect. Basically the AXSME software ignores the VC Threshold values being specified in SCT. Instead, the AXSME software would program a lower pre-defined threshold values for the VSI Signal channels. So the values in the HW are correct. Please ignore the VSI_signal values from the SCT. The lower pre-defined is needed because we want to limit our traffic flow on the VSI signaling channels prevent flooding the PXM45. If the PXM45 is flooded, then there will be some unpredictable and unreliable behaviors on PXM45. We are going to fix the display problem. Hardware: AXSME
CSCdy47415	Symptom: delred shows incorrect error message. Conditions: delred command issued. Workaround: No workaround needed. Just ignore the message and use dspred to verify the delred result. Hardware: PXM1E
CSCdy49757	Symptom: AUSM channel, port and SAR counters do not correctly count RM cells received from CPE. Conditions: The AUSM channel, port and SAR counters do not correctly handle RM cells when they are generated by the CPE (test-set). When RM cells are received by the AUSM card the baseline behavior is that they should be discarded by the UNI port. Indeed that is what is noted to happen for AUSM on PXM1E. The command dspconload" shows that no traffic is received from the AUSM when a stream of RM cells at 480 cps is generated by the test-set. Workaround: None. Hardware: AUSM-8T1E1
CSCdy59294	Symptom: AUSM/PXM1E transmits invalid PTI=7 cells into network but cannot pass traffic out of far-end AUSM port. Condition: An abr1 PVC was provisioned between two AUSM-IMA ports: [Test Set A] <---> node1 to node2 <---> [Test Set B] Test set A generated 480 CPS of ATM cells with the PTI field set to 7 (invalid). The payload consisted of 48 byte 6A pattern. The channel, port and SAR counters on node1 indicate that traffic is being sent into the network. On the PXM1E card on node1 the "dspconload" command indicates that all the PTI=7 traffic is sent out the trunk interface. In fact there seems to be RM cell overhead in both directions. The "dspconload" command on node1 indicates that all PTI=7 traffic is being received on the trunk interface. However on the AUSM port on node2 the chan, port and SAR counters all remain at zero. It is very strange that the AUSM card handles PTI=7 cells differently on the Ingress and Egress directions. At one time the PVC was able to transmit PTI=7 cells end to end but it has only been observed to happen once. Workaround: None. Hardware: AUSM-8T1E1
CSCdy73100	Symptom: Misspelled word in the syntax of the cnfpnni-node output. Conditions: When viewing the output, the word does is spelled deso. Workaround: None. Hardware: PXM45/B
CSCdy78398	Symptom: SAR errors not detected by SCM for 3 minutes. Conditions: Tests consisting of SAR single bit errors were executed on active and standby AXSM cards. Workaround: None. Hardware: AXSMB-OC3
CSCdy81038	Symptom: You can addred then switchredcd, with a bad gigE backcard or while the gige is in an uninitialized state. Condition: *Sep 30 19:46:45.475: %GE-3-INTERNAL: GE internal error, HW init failed. Backcard may need to be reseated -Traceback= 401CA3A8 401CA604 401CCA1C 40407350 403C4AFC 402EDAB4 402EDC9C 403A1 1D0 403A11BC *Sep 30 19:46:45.483: %GE-3-INITFAIL: GE initialization failed, GigabitEthernet1 /0 -Traceback= 401CA474 401CA604 401CCA1C 40407350 403C4AFC 402EDAB4 402EDC9C 403A1 1D0 403A11BC. Workaround: Enhancement request. Currently the backcard must be reseated, replaced, and or removed. Hardware: RPM-XF
CSCdy82219	Symptom: PNNI ports go into provisioning mode and spvcs fail when fault on active card or card switchover allowed to standby card with fault. Conditions: Utopic 2 Bus CBC to ATMIZER bit tx/rx errors inserted on active or standby cards. Workaround: None. Hardware: AXSMB-OC3
CSCdy82452	Symptom: QE48 fault not detected in standby state. Conditions: User executed QE48 VC Table and QDB Memory Bank Fault Insertion test cases. Workaround: None. Hardware: AXSM1
CSCdy82780	Symptom: Faulty card did not reset and come up as failed. Condition: Customer executed QE48 Tx UTOPIA3 to Humvee parity error fault insertion test case. Workaround: Unknown. Hardware: AXSM1
CSCdy82836	Symptom: Standby AXSM-E card did not reset and error was not recorded in event log. Condition: Humvee ILT CAM data bit 8 tied to GND fault insertion test case was executed. Workaround: Unknown Hardware: AXSME
CSCdy82849	Symptom: When fault inserted on active or standby card, reset/switchover did not take place for 3 min. Condition:SWB10-Hold Atmizer in reset fault insertion test case was executed. Workaround: Unknown. Hardware: AXSME
CSCdy82872	Symptom: Card fault not reported in event log. Conditions: Hold Port 1 secondary Tetra in reset fault insertion test case was executed on standby AXSM-E. Workaround: Unknown. Hardware: AXSME
CSCdy86511	Symptom: The AXSM reset due to a software error. See logs below. The error information is corrupted. Condition: This is a customer node running 2.1(80). The card has been replaced and is being sent back for failure analysis. Workaround: Unknown. Hardware: AXSME
CSCdz04750	Symptom: The FRSM8 card does not correctly process incoming frames with incorrect CRC-16. condition: The FRSM8 card does not correctly process incoming Frames with incorrect Frame Check Sum sequence. The port should discard these "corrupt" frames under the port counter "RcvFramesDiscCRCError:". Instead the frames get sent into the network. Workaround: Unknown. Hardware: PXM1E
CSCdz08738	Symptom: After node rebuild PXM1E went into mismatch with LowerBackcRd. Condition: slot-7 was active and slot-8 was standby. A power off/on was done on the node. After the rebuild slot-7 was coming up as active and slot-8 was coming up as standby. When slot-7 became active it is observed that it is in mismatch with LowerBackCard. When slot-8 became standby there was a switchover so that slot-8 became active and slot-7 got reset and came back up as standby. Workaround: Unknown Hardware: PXM1E
CSCdz18393	Symptom: xcnfln command does not have v.35 option included in the display. Condition: xcnfln command has the option for x21 and hssi. But it does not have the option for v35. We can configure the line using the x21 option for v.35. But it would be clear if that option also included in the xcnfln. Workaround: Unknown. Hardware: PXM1E
CSCdz29983	Symptom: Standby card might not come up after the loadrev. Condition: SES node's disk space is not enough for the new database to be created if there are already two dbVersions in the disk. Workaround: Remove old database before the upgrade. To remove, first check if there is more than the current database - Save the current configuration: CLI "saveallcnf" - If more than the current DB Version has been created, then take action to remove other/old database following these steps: 0- From the Active PXM slot, "dspversion" to know the current FW version. 1- From the Active PXM slot, "cd D:/DB2/LS1" 2- "ls" to see if there is any extra DB Version beside the current expected version DB. The extra DB Version should be deleted. 3- go to shellconn and still in "D:/DB2/LS1" directory path. 4- Delete the extra database: pxm1> "deltree VER00X_YYY_ZZZ" 5- Do steps from 1 to 4 to check and remove any extra database on the Standby PXM1 also.
CSCdz25041	Symptom: No hssi option in the xcnfln command. Condition: 1. No hssi option in the xcnfln command 2. Adding the line loopback on the line which has loopback enabled gives wrong error message Error occurred during the SNMP SET operation !! Probable Reason: "Cannot change loopback" SNMP Error Code: 76 Set failed due to illegal parameter(s) Syntax: addlnloop "line_num" line number -- 1-2 for HSSI, 1-8 for V.35/X.21. It should say the line loopback is already enabled. --------------------------------------------------- 3. When we try to add the loopback with xcnfln command on the line with already enabled loopback it gives the wrong error message. Error occurred during the SNMP SET operation !! Probable Reason: "Cannot change loopback" SNMP Error Code: 76. Set failed due to illegal parameter(s). It should take it or it should say the loopback is already enabled. Workaround: Unknown. Hardware: PXM1E
CSCdz29332	Symptom: Unknown Error Code message returned on cli. Condition: When the dsppnni-timer command is executed with the incorrect node index. Workaround: None. Hardware: PXM45/B
CSCdz34835	Symptom: cnfln -e3 <bay.line> -len <length> did not work. Conditions: All conditions. Workaround: None. Hardware: PXM1E
CSCdz40676	Symptom: cnfpnportsig command results in false warning when a value for vpi=0 is assigned. Condition: cnfpnportsig 7:2.6:26 -vpi 1. WARNING: Signaling VPI is outside of the port VPI range. Syntax: cnfpnportsig <portid>. Workaround: Unknown. Hardware: PXM1E
CSCdz40700	Symptom: dsplog for FRSMHS2/B does not show the line deleted in the message". Condition: ON FRSM-HSSI Module, line is deleted by using the delln command. But it is not showing in the dsplog that the line is deleted as it shows for other SM modules. Workaround: Unknown. Hardware: PXM1E
CSCdz40737	Symptom: dspcnfdiag is not updated after cnfdiagall command for SRM slot. Conditions: The display is not updated after "cnfdiagall" for slot 15,16,31 & 32 (SRM). After a new node was installed we issued the "cnfdiagall enable disable" command. The display does not update the status for SRM slots. Workaround: None. Hardware: PXM1E
CSCdz46078	Symptom: dspalms does not have hssi option. Condition: dspalms does not have the " hssi " option as the line type. However, it does work, if you use x21 option. Workaround: Unknown. Hardware: PXM1E
CSCdz53209	Symptom: FRSM-2T3 cards came up without boot image. Condition: New FRSM-2T3 cards were inserted in slot-13 and slot-14. Initially they came in "boot" state. At this time setrev was executed for slot-13 and 14. After setrev both cards came up as active without boot image. Workaround: Unknown. Hardware: PXM1E
CSCdz67977	Symptom: General error logs for humvee devices for the error state change. Conditions: If Elt mismatch errors or other errors happen, this could happen if there are some pnports and the communication between the active PXM and AXSMs fail. Workaround: None. Hardware: AXSM
CSCea08833	Symptom: AXIS appears as the shelf name causing a display error on MGX PXM1E. Conditions: When the customer performs a switchredcd or a resetcd on the FRSM2T3. Workaround: None. Hardware: PXM1E
CSCea24010	Symptom: During PXM45/B upgrade from 2.1(80.0) to 3.0.(20.100). OAM error messages were seen in the log. This was seen on two nodes in the customer's network. Example: 13A00416 02/16/2003-04:47:04 OAM-5-LOG tOamLb OamLpbkHandler OAM error: OamLpbkHandler: 164: 4099: 65280 11111 - 3 dropped. Conditions: Upgrade from 2.1(80.0) to 3.0(20.100). Workaround: None. Hardware: PXM45B
CSCea25980	Symptom: During a segment test for a VC,found that the "addlocalloop" type 1 and/or 2 doesn't work with the scenario below in case a ping is used as test: router1 ----- MGX1 ---- ATM CLOUD ---- MGX2 --- MUX ---- router2 Ping from router 1 were successful only if traffic from remote end was interrupted. Conditions: Always reproducible if egress side is sending some kind of traffic. Observed on AXSM running 2.0.17 FW. Workaround: Need to put down the egress interface or avoid in some way traffic from egress side to pass toward the cpe from where the ping is performed. Hardware: AXSM1
CSCea27448	Symptom: DAX Connection "ok" on PXM and "mismatch" on AXSM. Conditions: Issue dncon followed by upcon for DAX connection with a NAK from AXSM. Workaround: None. Hardware: PXM45
CSCea31637	Symptom: Loopback OAM got dropped at wire rate on AXSME, it will happen on the FRSM12, too. Condition: SPVC provisioned btw FRSM12 and AXSM/AXSME, pump-in loopback OAM to the port of AXSM/AXSME which has connections with FRSM12 at DS3 rate. The OAM cell will get dropped. Workaround: This happens only in special cases. No workaround for the DS3 rate lpbk OAM drop. Hardware: FRSM12
CSCea32002	Symptom: After runrev, both the PXM1E cards got reset. Conditions: Issue runrev during card upgrade. Workaround: None Hardware: PXM1E
CSCea42088	Symptom: Can not modify the remote ICR value. Conditions: ABR XPVC connection between axsm-e & bxm. Workaround: None. Hardware: AXSME
CSCea59289	Symptom: Command "addchanloop" doesn't work when used on VPs with a value greater than 255. The loop should be put on the egress side and must cross an NNI link. Below a diagram that explain the conditions for observe the problem: router1-----AXSM-MGX1-AXSM ----PNNI LINK---- AXSM-MGX2-AXSM----router2 Loop on MGX2 face to router1, NNI link in the middle. Conditions: This has been observed in a network running 3.0(20) AXSM1. Workaround: None. Hardware: AXSM1
CSCea64210	Symptom: Need better explanation for some of the counters shown in dspchancnt. Conditions: Some counters are zero for certain types of connections. Workaround: None. Hardware: PXM1E
CSCea75060	Symptom: Failure in ipc buffer assign and free: 07A05639 04/09/2003-02:03:12 FIPC-4-MBLKFREEFAIL ISR ssi_ipc_buffer_free Failed to free mblk 7566238, errno 0 07A05638 04/09/2003-02:03:12 FIPC-4-MBLKASSIGNFAIL ISR ssiIpcMessageAssign Message assignment failed: MBLK 7566238 07A05637 04/09/2003-02:03:12 SSI-4-CHNK_XNOT_USED ISR ssiMemChunkAssignpool=[IPC:Mblks] ptr=0x7566238 flags=0x0 cnt=0 own=0x0(ISR) caller=0x3be98c/0xffffffff Conditions: When the ISR is trying to free a buffer that currently not used. Workaround: None. Hardware: PXM45
CSCea85655	Symptom: Standby PXM continuously reboots. Conditions: Do restoreallcnf on the node. Workaround: Remove the "C:/.clrdsk" file, if it is present. Hardware: PXM45B
CSCea92433	Symptom: IPC memory buffer indicates that "nb free fl" is 11 Condition: On slot-7 "ipcMblkSHow" shows 10 for "nb free fl".nodea is running the latest release Workaround: Unknown Hardware: PXM1E
CSCeb03870	Symptom: ENET LED Stay LIT after unplugging ethernet cable or unplugging back card on PXM45. Condition: ENET LED Stay LIT even when no activity on ethernet. Workaround: None. Hardware: PXM45
CSCeb12259	Symptoms: Hard disk goes to busy state and needs a power up to get out of the busy state Conditions: Not known Workaround: None. Hardware: PXM1E
CSCuk38319	Symptom: VC-12 REI is seen on the tester connected to SRME. Conditions: Links added to VISM-PR-8E1. Workaround: None. Hardware: PXM45/B

Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

Table 31 lists the status of the known caveats from previous releases.

Table 31 Status of Known Caveats from Previous Releases 

DDTS Issue	Severity	Description
CSCdz03178	Severity 1	The bug was closed when it could not be reproduced.
CSCdz43804	Severity 1	The bug was closed because an incorrect configuration was used.
CSCdv53825	Severity 2	This bug was closed when it could not be reproduced.
CSCdv85607	Severity 2	This bug was closed when it could not be reproduced.
CSCdw91580	Severity 2	This bug is a hardware-related bug and will be fixed in a future MGX release.
CSCdx55987	Severity 2	Duplicate of CSCdz21027, which is an Severity 6 bug.
CSCdy36815	Severity 2	The bug was closed since this was a design limitation.
CSCdy37445	Severity 2	The bug was closed when it could not be reproduced.
CSCdy51734	Severity 2	Duplicate of CSCdy53476, which is open.
CSCdy87875	Severity 2	The bug was closed because it was caused by a broken pin on the card.
CSCdz01404	Severity 2	The bug was closed when it could not be reproduced.
CSCdz09831	Severity 2	The bug was closed when it could not be reproduced.
CSCdz18745	Severity 2	The bug was found to be against the MGX 1.2.20
CSCdz20300	Severity 2	Fixed in Release 3.0.20
CSCdz28878	Severity 2	The bug was closed since this was decided to be an enhancement to the design.
CSCdz29058	Severity 2	The bug was closed since there was a hardware problem that was fixed when the disk drive was replaced.
CSCdz32753	Severity 2	Duplicate of CSCdz47788, which was duped to CSCdx95657, which was discovered to not be a customer-affecting issue.
CSCdz36502	Severity 2	The bug was closed when it could not be reproduced.
CSCdz37753	Severity 2	Duplicate of CSCea27807, which was fixed in Release 3.0.23.
CSCdz38471	Severity 2	The bug was closed when it could not be reproduced.
CSCdz40649	Severity 2	Fixed in Release 20.0.3.0.
CSCdz41807	Severity 2	The bug was closed when it could not be reproduced.
CSCdz44136	Severity 2	The bug was closed when the requested information was delivered to the customer.
CSCdz44886	Severity 2	The bug was closed when the unnecessary commands were removed.
CSCdz47408	Severity 2	The bug was closed because it was a design limitation.
CSCin15276	Severity 2	The bug will be fixed in a future MGX release.
CSCdt30145	Severity 3	The bug was closed when it could not be reproduced.
CSCdu26141	Severity 3	The bug was closed and was decided to not be a customer affecting bug.
CSCdu29780	Severity 3	The bug closed because the behavior is correct.
CSCdy10480	Severity 3	The bug was closed since SCT file 0 does not exist.
CSCdy16930	Severity 3	Fixed in Release 3.0.10
CSCdy46972	Severity 3	The bug was closed since it could not be reproduced.
CSCdy46993	Severity 3	Duplicate of CSCdz25071, which was fixed in Release 3.0.20.
CSCdy54607	Severity 3	Duplicate of CSCdy55759, which was fixed in Release 3.0.20.
CSCdy62765	Severity 3	The bug was closed because it was a design limitation.
CSCdy64715	Severity 3	Duplicate of CSCdy59933, which was closed because the behaviour is correct.
CSCdy71223	Severity 3	The bug was closed because an incorrect configuration was used.
CSCdy79293	Severity 3	The bug was closed when it could not be reproduced.
CSCdz35839	Severity 3	The bug was closed since the customer could not provide information to further debug the problem.
CSCdz40720	Severity 3	The bug closed because the behavior is correct.
CSCdz40750	Severity 3	Duplicate of CSCdy47415, which is open.
CSCdz40766	Severity 3	The bug closed because the behavior is correct.
CSCdz45973	Severity 3	The bug was closed due to a design implementation problem that got fixed.
CSCdy59923	Severity 4	The bug closed because the behavior is correct.
CSCdy59933	Severity 4	The bug closed because the behavior is correct.
CSCdz27670	Severity 5	The bug was reduced in severity from Severity 2 to Severity 6.
CSCdy61622	Severity 5	The bug was reduced in severity from Severity 2 to Severity 6.
CSCdv50574	Severity 6	The bug was decreased in severity from Severity 3 to Severity 6.
CSCdy07693	Severity 6	This bug was reduced from a Severity 2 to a Severity 6 bug.
CSCdy51843	Severity 6	The bug was reduced in severity from Severity 2 to Severity 6.
CSCdy51865	Severity 6	The bug was reduced in severity from Severity 2 to Severity 6.
CSCdy52131	Severity 6	The bug was reduced in severity from Severity 2 to Severity 6.

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.23

Table 32 lists the resolved caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 software Release 3.0.23.

---

Note All bug fixes from Release 3.0.20 as of May 20, 2003 are also fixed in Release 3.0.23.

The resolved bugs listed in this section are accurate as of May 20, 2003.

---

Table 32 Resolved Caveats for MGX Release 3.0.23 Software 

CSCdy09657	dspdiagstatus does not display the state and role of SMs
CSCdy14462	PXM45 hangs when new boot image is being burnt in the card.
CSCdy29552	AXSM should generate CON stats file whether or not conns exi
CSCdy23934	FRSM12: IFE should not check DE/FECN bit in FF mode
CSCdy36971	FRSM12: IFE send Empty Frame to IWS
CSCdy40482	CTC messages flooding the logs during standby reset
CSCdy42620	CLI command delcons needs special privilege usage parameter
CSCdy56026	dspcon on MGX did not show rcv AIS from BPX
CSCdy60837	UPG:after loadrev from 2.1.80 to 3.0.10, detects DB-CONV-ERR
CSCdy69719	A2SAR failures not handled in Active PXM45B
CSCdy74714	cntl c during dumpconfig command caused runaway task
CSCdy82780	HFIT:QE48 tx UTOPIA 3 to HUMVEE parity error
CSCdz12182	FRSM12: OAM Traffic Should Have Higher Priority than Data
CSCdz24242	1e DT: pnCcb suspended after accessing null pointer, PXM1e crashed.
CSCdz26894	PXM45C:WatchDog Timeout Error on FRSM12 card
CSCdz30469	FRSM12:LMI counters not reset on addport
CSCdz32479	1e DT:online diag cannot add conn for test
CSCdz33267	Conn endpt sends AIS into network even tho port side clears
CSCdz33358	dspcon shows switch side tx:AIS when it should be normal
CSCdz35906	Nativity shmRecoverRbldDisk does not recover the correct sw
CSCdz36598	PXM1e:many SPVCs stuck in E-AISRDI alrm after resetcd/switch
CSCdz39307	AXSME port and channel stats do not match with SCM
CSCdz39715	Clock source stuck in wideband-locking
CSCdz40409	Can set ABR ICR greater than PCR or less than MCR on DAX SPV
CSCdz41032	Setrev is not working to go back to a previous version
CSCdz45007	AXSME-16T3E3 failed when redundancy is added.
CSCdz46475	Node reset after switchcc
CSCdz46762	SSCOP stuck in reset state. no cons can be routed over the l
CSCdz47960	DB Lost on AXSM-OC12 after burnboot
CSCdz48221	100+% utilization causes pnport failure
CSCdz48915	NCCI Pass along bit not set for PNNI interface
CSCdz49346	PXM/AXSM reset after AXSM burnboot and switchredcd
CSCdz50925	AXSM port goes down after upgrade/enableaxsmbaps command
CSCdz53181	cannot cc to frsm-hssi card on pxm1e
CSCdz53904	1e:DT SM_ALARM*.CF files created on FW directory continuous
CSCdz55603	FIPC-4-MBLKFREEFAIL messages seen in the dsplog of MGX
CSCdz56349	clralmcnt is not clearing the alarms when slot 8 is active
CSCdz59023	FRSM12:PM7324 S/UNI Atlas port fail not clr when delport w/
CSCdz59045	FRSM12:conn alarm states do not correctly reflect hw states
CSCdz62529	switchcc after first burnboot on PXM1E changed card cnf from
CSCdz64884	dsppnports shows port in enablenotup state
CSCdz65507	Unable to perform tstconseg when another tstdelay is in prog
CSCdz65633	FRSM12:CC fails when ports are cnfg as frame forwarding
CSCdz66066	after executing resetcd on active PXM1e the stdby went to ac
CSCdz66570	Cannot configure addsct on new node in network
CSCdz66766	SHM:cell dropping on SPVCs cross cards when standby PXM45 r
CSCdz67639	Connections re-routed and 3 OC-3 ports went into LOS.
CSCdz67970	CORE_CARD_SWITCH message dropped on switchcc
CSCdz70241	Traffic stops after del APS & delred on OC12
CSCdz70330	AIS from MGX1 FRSM8E1 not correctly handled on MGX2 AXSM
CSCdz71007	dsppnni-node-list doesn't display all the mgx45 nodes as per
CSCdz72868	Connections reroute upon switchover, mismatch in dsp outputs
CSCdz75190	AXSME dspcons does not show egressAIS channel alarm on maste
CSCdz75974	UPGRD:resetcd while card in Loadrev-Done-U logged VSIS error
CSCdz76956	mainproc suspended, ACTIVE PXM45 Failed and STBY stuck in IN
CSCdz76963	All SMs on PXM1E node reset after resetcd 8 (active) was don
CSCdz77246	1e:DT 1:1 and intra card 1+1 aps:traffic fully stops after
CSCdz80175	AXSM SPVCs in Mismatch State after PXM45/A to PXM45/B Swap
CSCdz80242	PVCs re-routed and ilmi state was enable not up.
CSCdz81021	dspcons does not show egressAIS channel alarm on master end
CSCdz81325	P2MP connections not released on 3.0.20 node
CSCdz81893	VC Merge feature disabled on AXSM-E only, works fine on AXSM
CSCdz82197	Bug in vxWorks routing code causes processor crash
CSCdz82288	NBSM stats on PXM1E fails, no files getting collected.
CSCdz82752	UPGRD:VCM error when control VC creating fail
CSCdz83243	reseating of the back card on FRSM-HSSi show user connection
CSCdz84282	frsm cards came up in mismatch state
CSCdz84750	PXM45 to AXSME commit failure on spvc
CSCdz85056	Failed hard PXM45 switch over
CSCdz85291	UPGR:Loadrev to upgrade from 2.1 to 4.0 get COMEPPARMINVAL
CSCdz85324	clock became unknown when trying to configure a different cl
CSCdz86284	Online diag error caused the PXM card to go into Unknown Sta
CSCdz87147	SVC/SPVC not route over PNNI VNNI (VT) intf using different
CSCdz88612	Handling of Resync Commit Failures
CSCea00962	optimizing IMA group transmission delay ~1.8ms
CSCea01679	Active card rebuilds when update fails after upgrades
CSCea07519	Tracking CSCdz67639 checkin against AXSM/B
CSCea07531	Tracking checkin against AXSME;Conns. reroute after local sw
CSCea08932	PXM45 to FRSM12 commit failure on spvc
CSCea10729	No AIS seen when FC is pulled out of sec active FRSM-2T3
CSCea11560	Cards in slot 16 reported in Mismatch state by PXM on a 8950
CSCea12486	number of SVCs is greater than max conns
CSCea12947	AXSME_8OC3 causing OAM managed pvcs to fail
CSCea13534	Can Not set asymmetric ICRs on DACS ABR SPVCs
CSCea13996	UPGRD:at loadrev, stdby pxm reports SFP mismatch
CSCea14186	Resetsys on PGL caused permanent failure of election process
CSCea14630	IMA bandwidth change not reflected in PNNI
CSCea16961	1e:HARD cnfpart has incorrect check with imax < imin
CSCea17055	AXSM:Intf cnfg policy fail.
CSCea18523	Software does not store line stats in the stats files
CSCea20034	AXSM:clralmcnt does not clear DS3 alarm counters
CSCea21717	AXSM with policing enabled, expectation is that gcra1 is ena
CSCea22748	Conn commit failure because of bw params going -ve.
CSCea24042	tVsiSync task suspend in active AXSM
CSCea24098	1e HARD:SHMA-4_API_SEND_ERR on active PXM1E after switchcc/
CSCea26024	REG4:AXSM-T3E3 in Mismatch after upgrade
CSCea27807	BRAM corruption on PXM45B after power cycle and during runti
CSCea28800	1e HARD:UPLDBRAMERR upon switchred from pri to sec during l
CSCea29511	When VPC is failing, VNNI port not in alarm
CSCea29533	switch error for snmpget on pnni trunk
CSCea38838	SNMP GET on the cwmChanPercentUtil returns different value t
CSCea44266	REG4:Unknown reserved st. of Combo back card causes APS fai
CSCea44296	Delcon does not delete the channel loop on AXSME card.
CSCea44784	Delpart causes a AXSM failure
CSCea47481	after swithover data stopped on a pvc between two nodes
CSCea53817	PNNI Bypass advertisement is random instead of descending or
CSCea55999	dspload shows service category corruption for partitions
CSCea57987	REG4:VBR con failed with x-commit during upgrade
CSCea64177	PXM1E ABR doesn't support dual leaky buckets
CSCea64785	AXSM Conn. database corrupted after disk corruption
CSCea66438	Bert is enabled on the FRSM8T1 line even though no bert runn
CSCea66971	Log floods with VSI_4-RMBWCACError
CSCea72069	Ports went to building vc after reinsertion of AXSM cards
CSCea77528	SRME standby does not initialize properly
CSCea79983	UPGRD:SysDiag reports error upon enabling online diag on sr
CSCea80038	UPGRD:tRed reports srme card failure upon stdby pxm reset
CSCea80481	ASXM does not con info while pxm is having connection in fai
CSCea81899	LSNT:error writing file.error 0x38801c for RPM
CSCea85629	LMI protocol should exchange logical slot/port info
CSCeb13967	PXM45 reset due to Tlb Load Exception
CSCin32419	Unable to start Line/Port bert on NBSM (frsm-8e1) -8850R2.
CSCin42958	addred CLI is returning error

Caveats for Release 3.0.20

This section provides information about caveats associated with Release 3.0.20 software.

Severity level 1, 2, and 3 caveats are organized in this section as follows:

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.20

•Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.20

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.20

Table 33 lists the Severity 1 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.20 software.

Table 33 Severity 1 Open Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 3.0.20 Software 

DDTS Issue	Description
CSCdy81906	Symptom: Cards in slots 1 and 2 rebooted and then failed. Conditions: After a burnboot on the PXM45 in slot 8, and switchcc was executed on the shelf. Workaround: None. Hardware: PXM45/B
CSCdz03178	Symptom: On a PXM1E node, several service module cards went into the failed state. Conditions: On a PXM1E node, it is observed that some service modules are in the Failed state. This happened after several switchcc's. Workaround: Unknown. Hardware: PXM1E
CSCdz12195	Symptom: AXSME-8-OC3 card fails to perform switchcdred the first time. Condition: The problem seem to happen with the test automation script used in manufacturing. Workaround: The same command issued the 2nd time seem to work O.K. Hardware: AXSME
CSCdz29064	Symptom: Watchdog causes the controller card (PXM) or Service Module (AXSM/AXSME/FRSM12) to rebuild. Condition: The Task Monitor erroneously detects a task is hung while attempting to delete another task when it is actually waiting on a message queue to receive messages. Workaround: None. Hardware: PXM45/B
CSCdz43804	Symptom: IP Ethernet for MGX 8950 and SES are not accessible. Condition: Power outage. Workaround: Unknown. Hardware: PXM45

Table 34 lists the Severity 2 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.20 software.

Table 34 Severity 2 Open Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 3.0.20 Software 

DDTS Issue	Description
CSCdv53825	Symptoms: sframetick lock config is lost. Conditions: When a switchcc is executed on the shelf. Workaround: None. Hardware: PXM45
CSCdv85607	Symptom: Core dump occurred for standby AXSMEOC3 card though no activities. Conditions: AXSMEOC3 with standby card. Workaround: Unknown. Hardware: AXSME
CSCdw91580	Symptom: SRME APS switchover time > 250ms when either SRME front card or back card is removed. Conditions: When SRME is engaged in APS and either SRME front card or back card is removed. Workaround: Before removing the SRME card, check that the SRME card is in the standby state instead of the active state. Hardware: PXM1E
CSCdx45116	Symptom: Some of the connections are in alarm after stopbert testing Condition: cnfbert, startbert then stopbert Workaround: dncon/upcon or dnport/upport can recover the connection from the alarm status. Hardware: AXSME-IMA
CSCdx55987	Symptom: All the external xtags are down at the RPM. Attempts to cc to the AXSM card in slot 5 (containing xtag interfaces) failed a couple of times. The control plane is passing traffic one way. Conditions: PXM in slot 8 standby in empty reserve state. Customer noted slow response at cli of AXSM prior to being unable to access slot 5 (axsm). The PXM logged P1 sar errors messages. The PXM also had a coredump triggered by cache errors. Workaround: Not known at this time. Contact TAC to capture data while node is in this state. Hardware: axsm1b_oc12
CSCdy07693	Symptom: Other ILMI sessions dropped. Condition: When large (~10K) SNMP PDUs are pumped into one ILMI connection from ADTECH. Workaround: Stop PDU flood. Hardware: PXM1E
CSCdy14462	Symptom: PXM45/B gets stuck during a boot download. Conditions: A new boot image was being downloaded. Workaround: resetcd from active pxm or reseat the card Hardware: PXM45
CSCdy23934	Symptom: "dspchancnt" reports non zero Rcv Frames DE/FECN/BECN for connection in frame forwarding mode. Condition: SPVC provisioned btw AXSM and FRSM12, the connection in FF mode on the FRSM12 side. pump in AAL5 traffic via the AXSM, "dspchancnt" will display "Rcv Frames DE/FECN/BECN" incrementing. Workaround: Ignore these counters. Hardware: frsm12
CSCdy36815	Symptom: FRSM floods dsplog on PXM1E. Conditions: Anytime an LCN gets out of alarm. Workaround: Unknown. Hardware: FRSM-8T1E1
CSCdy36971	Symptom: LMI failed when all ports passing DS3 rate traffic on over 1000 conns. Condition: 42Mbps traffic pumped in to 1450 conns, snaked on 11 ports. Workaround: Limit the rate. Hardware: frsm12
CSCdy37445	Symptom: IPC memLeaks were observed. In ipc buffer id 0x10002 the owner task "0x200bf" called: - CpiToAppCreateMsg+0xac - ssiIpcBufferCopy+0x6c. In ipc buffer id 0x10005 the owner task "0x200bf" called: - CpiToAppCreateMsg+0xac - ssiIpcBufferCopy+0x6c. Condition: On a PXM1E node that has been idle for more than 6+ hours. Workaround: None Hardware: PXM1E
CSCdy51734	Symptom: Standby PXM went to Empty state as seen in dspcds or dspcd. Conditions: None. Workaround: Issue resetcd on the standby PXM. Hardware: PXM45/B
CSCdy51843	Symptom: CBC clocking affected on active and standby PXM1E does not switch over to standby Condition: Fault was inserted on standby card 8 and it is never detected by the active card. upon forced switch over, the standby did not take over and all the SM's were reset and never came back up. If you insert a card with CBC clocking affected in the standby slot, it is not detected. In this situation we may have a faulty standby card just sitting in the node. Workaround: Unknown. Hardware: PXM1E
CSCdy51865	Symptom: FI: ATMizer SAR SDRAM data bus corruption & ATMizerII SAR chip disable on active - does not switch over to standby. Condition: FI: ATMizer SAR SDRAM data bus corruption & ATMizerII SAR chip disable on active - does not switch over to standby. Both cards in ready state. When fault inserted on active it does not switch over to standby. All pnni links go down, connections in fail state. Data traffic stops. Standby card resets after some time. Workaround: Unknown. Hardware: PXM1E
CSCdy52131	Symptom: For fault Insertion, reset/failure on PXM1E is reported incorrectly in error log and reset type & error is not logged. Condition: When we insert the QE0 reset (test 4a) fault. The log does not show reset type and error reason. The fault insertion card is in slot 8. When we insert reset QE1 (test 4b) fault on PXM1E. The failure and reset reason is not reported in the log correctly. The fault insertion card is in slot 8. Workaround: Unknown. Hardware: PXM1E
CSCdy53476	Symptom: All service modules and standby PXM in the node reset/boot continuously. Complete communication failure between the active PXM and all other slots. Conditions: Unknown. Workaround: None, other than a node rebuild. Hardware: PXM45/B
CSCdy59180	Symptom: Once it was observed that 4 SPVC failed to route. This failure was due to slave state of the connections were in wrong state. Conditions: When large number (250k) of SPVC rerouted Workaround: None Hardware: PXM45/B
CSCdy60873	Symptom: After resetting the MGX-RPM-XF-512 card, it went into the failed state. Conditions: It happens mostly under the following conditions. a) When the ssi chunk pool free pattern was set. (from shellconn, ssiChunkPoolsFillFreePatternSet 1 will enable this). Run ipcMblkShow to see whether this pattern is set or not. Workaround: Reset the ssiChunk Pool Free pattern set (if it is enabled already). Do "ssiChunkPoolsFillFreePatternSet 0" to reset this option. Hardware: PXM45/B
CSCdy61622	Symptom: 1) All AXSM/ASM-E cards without redundancy go to Active-F state 2) All AXSM/AXSM-E cards with redundancy switched over The AXSM-E cards will switch back and forth between the redundant pair. Condition: If the Active PXM tries to reset the standby PXM and the reset does not go through and it is put to FAILED state. Workaround: Remove the standby PXM which has been put to failed state. Hardware: PXM45/B
CSCdy65143	Symptom: Executing a dspcon on the PXM45/B with an invalid VCI is displaying a connection with a different VCI and other invalid attributes. Conditions: Executing dspcon with an invalid VCI to display the connection. Workaround: Unknown. Hardware: PXM45/B
CSCdy69719	Symptom: ATMizer failure not handled in active PXM45/B Condition: When Dip switch for fault insertion is turned on spl active HFIT PXM45/B board Workaround: The fault is detected by standby PXM45/B. On active card, there is no workaround. Hardware: PXM45/B
CSCdy71636	Symptom: The customer sees traffic stop in one direction spontaneously Conditions: It happens spontaneously on an FRSM 8T1E1 card on a MGX1 shelf. MGX1 shelf is a feeder to an MGX 2 shelf. Workaround: Using CWM reconfigure the CIR of the connection. Or delete and re add the PVC Hardware: FRSM-8T1E1
CSCdy74714	Symptom: Runaway task logged in dsplog after cntl c was issued. Condition: The cntl c was issued to halt the dumpconfig command which was part of a script that was running on the shelf. Workaround: none Hardware: PXM45/B
CSCdy77053	Symptom: There is no AXSME port ingress counter. This is creating a problem when using the AXSME double density feature. Conditions: dspportcnt does not provide ingress counters. Workaround: None. Hardware: AXSME
CSCdy80912	Symptom:PXM45 card got reset 2+ times Conditions: In this order, reset the AXSM cards, the standby PXM45 card, then the active PXM45 card. Workaround: Unknown. Hardware: PXM45/B
CSCdy87875	Symptom: A major environmental alarm being reported on a shelf with a PXM45. Condition: 0 RPM reading for both upper and lower fan trays. Workaround: Unknown. Hardware: PXM45/B
CSCdz01404	Symptom: Standby PXM45/B experienced software error, produced a core dump, and reset. One of the task is trying to release a connection on standby pxm, and it is accessing a invalid pointer stored in its connection data. Conditions: During connection deroute/re-route. Workaround: Reset standby card to recover. Hardware: PXM45/B
CSCdz09831	Symptoms: The MGX 8850 lost IP connectivity. Customer can not telnet to the MGX 8850 IP address. Conditions: Not known. Workaround: Pulled out AXSM slot 9 to force to redundant AXSM slot 10. IP connectivity restored after switch over. Hardware: AXSM1
CSCdz12182	Symptom: CC failure on UBR VCs when CBR VC of the same port carries full DS3 traffic. Condition: Traffic in the CBR VC contains many small frames. Workaround: Unknown. Hardware: frsm12
CSCdz18745	Symptom: FRSM-HS2/B is not coming out of mismatch state when we pull out and put back the FRSM-V35 back card. Condition: Slot 12 is configured with FRSMH2/B with FRSM-V32/X21 back card. The card is active state. The customer pulled out the back card on the slot 12, then the card went into mismatch state which is a normal behavior. But when the back card is put back, the front card is not resetting and it is not coming as active state. It is stuck in Mismatch state/empty state though the back card is actually present. Workaround: Resetcd to rest the card to make it active again. Hardware: PXM1E
CSCdz20300	Symptom: NAM task memLeak detected. Conditions: While checking for memLeaks in the node. Workaround: Unknown. Hardware: PXM1E
CSCdz27670	Symptom: dspcd does not show display 800 number nor CLIE number. Conditions: dspcd does not show 800 number nor CLIE number. Customer needs this command to verify correct cards in slots. Workaround: Unknown. Hardware: PXM1E
CSCdz28878	Symptom: PXM45 slot #8 failed with Max Card Resets reached. Condition: May be due to issue with the HD ejectors Workaround: Unknown. Hardware: PXM45/B
CSCdz29058	Symptom: PXM1E slot 7 is in failed / card type is showing unknown. Condition: PXM1E slot 7 is in failed / card type is showing unknown. Customer is uncertain as to what cause this issue to happen. To clear problem, removed slot7 and put back in and problem cleared. Workaround: Unknown. Hardware: PXM1E
CSCdz29610	Symptom: Ima link is stuck in LODS alarm. Conditions: Both 1 & 2 need to be met. 1. When only the Rx of IMA link at one end is disconnected and re-connected. 2. The link whose Rx is disconnected is cross-connected at the other end. Workaround: 1. Delete the link and add it back. OR 2. Restart the group using CLI restartimagrp. Hardware: PXM1E-IMA
CSCdz31938	Symptom: current core shows 2 or 3 instead of valid values 0 or 1. condition: Seems to only happen in version 3.0.11.0 On CLI, on executing 'core', the display shows current core as 2 or 3. Workaround: On the CLI, execute command 'core clear'. This will take care of the problem for good. Hardware: PXM1E
CSCdz32753	Symptom: Online diagnostics fails on a node. Conditions: MGX 8850 PXM45/B Workaround: Unknown. Hardware: PXM45/B
CSCdz35906	Symptom: PXM45 comes up as Failed with UNKNOWN node name. Conditions: The above symptom is seen only on a node with single PXM45. In a node, with an Active PXM45, the above symptom is not seen under any of the following conditions for the standby slot (unless the Active PXM45 is removed or has a permanent failure). 1. Disk backcard running 3.0.x.x image and front card comes from a node running 2.0 or 2.1.x. 2. Disk backcard running 2.1.x version and the front card comes from a node running 3.0.x.x. 3. Front card running 3.0.x.x image and Disk backcard comes from a node running 2.0 or 2.1.x. 4. Front card running 2.1.x version and the Disk backcard comes from a node running 3.0.x.x. Workaround: The following is the workaround to bring up the node with a non-native Front card or Disk backcard (drop to shellconn before executing these commands). (Specify the failed PXM45 slot number (7 or 8) in step-3 below): 1. copy "C:/version", "C:/SHMDB/forced_version" 2. a=0 3. shmPslotSwRevGet (<failed_PXM_slot#>, &a) 4. shmBramUpdateEnable 5. gShmShmDbRevisionSet(&a) 6. shmRecoverIgRbldDisk. Hardware: PXM45/B
CSCdz36502	Symptom: After switchcc, new active PXM1E now in active-F state and several narrowband service module cards in failed state. Conditions: After switchcc, new active PXM1E now in active-F state and several narrowband service module cards in failed state. Slot 7 has a suspected bad disk so that card was removed after the switchcc was completed. New active card in slot 8 now is in active-f state and several SM's in the failed state. Customer believes that after switchcc and the removal of slot 7 card that the node was in a good state. They believe a short time later this node ended up in a failed state. Workaround: Unknown. Hardware: PXM1E
CSCdz37753	Symptom: PXM45 was reset and came up in mismatch. Conditions: Due to power glitch which occurred in the lab network. Workaround: Unknown. Hardware: PXM45/B
CSCdz38471	Symptom: Cannot provision on RPM-PR after upgrades. Conditions: Solution Test Network. Workaround: clrsmcnf <RPM-PR slot #> Hardware: PXM45
CSCdz40649	Symptom: FRSM-HS2/B card with FRSM-HSSI back card resets when you down the connection. Conditions: FRSM-HS2/B card with FRSM HSSI card resets when the PVC on a PXM1E node is downed. FRSM-HS2/B with FRSM-HSSI back cards are in slots 3 and 4, and are configured as 1:1 redundancy. When the PVC is downed using the dncon command, the FRSM-HS/B card resets. Workaround: Unknown. Hardware: PXM1E
CSCdz41807	Symptom: All service modules show Failed/Empty, Standby PXM shows Boot/Empty Resvd Active PXM shows Active-F/Active. All connections showed Failed. Conditions: MGX 8850 PXM45 running 2.1.80 Workaround: Unknown. Hardware:
CSCdz43030	Symptom: IMA link added to a group displays the following Rx & Tx states and does not become active even if it is connected to the FE link and there are no line alarms. X,Y,A and Z are any valid numbers. dspimalnks =========== Link Grp Rel Ne Ne NeRx Tx Rx Num Num Dly Tx Rx Fail Lid Lid (ms) State State Status ------------------------------------------------------------------------------ 1.X 1.Y 0 Not in Group Not in Group No Failure Z A Conditions: Current state: The group has non-zero links in LIF failure that are not connected to FE. Action that leads to the above problem: The group is restarted using CLI restartimagrp or corresponding SNMP command. After the restart, any link addition will result in the state mentioned above. Workaround: 1. Connect all links to FE and make sure there are no physical line alarms on any of the links and that the FE group is sending valid ICP cells on all the links. All the links will then transition to active by themselves. OR 2. Delete all links from the group and add them back. In this case, the links that are connected to FE will become active. Hardware: AXSME-IMA
CSCdz44136	Symptom: EPD not working properly, On PXM1E Cells are dropped at cell bus level when backpressure is sent to PXM1e Condition: EPD not working properly, On PXM1E Cells are dropped at cell bus level when backpressure is sent to PXM1e when AUSM card is completely congested. It appears that the oscillation may occur when traffic is around 8T1. Workaround: Unknown. Hardware: PXM1E
CSCdz44886	Symptom: To get an Ethernet access to the PXM, deleted the route and got the load exception and after executing the routAdd PXM45 got hung. Condition: PXM45 got hung after routeDelete and routeAdd Workaround: Unknown. Hardware: PXM45
CSCdz45973	Symptom: A customer node stops responding to login attempts. The active PXM45/B was in slot 7, and the standby PXM45/B was in slot 8. Conditions: The slot 7 card did not respond to console port and LAN connectivity. The active card would not respond to ICP ping from the standby PXM. No terminating connections on this node. All other via connections have been rerouted. Hence no customer traffic outage. Workaround: Remove active PXM45/B card. Reseat standby PXM45/B card, causing node to rebuild and standby to become active. Hardware: PXM45/B
CSCdz46545	Symptom: Clock source stuck in wideband-locking Conditions: 1) After changing the distribution mode from manual to ncdp. 2) Revertive option enabled in the manual mode. Workaround: Configure the clock source to non-revertive in manual mode before changing the clock mode to ncdp. Hardware: PXM1E
CSCdz46762	Symptom: SSCOP stuck in reset state on both sides of an NNI link. Conditions: The node should have few NCDP enabled ports. Enable the NCDP using cnfncdp -distributionMode 1 if it is not enabled perform a switchcc. The problem may not appear always. Workaround: Proactive: After enabling NCDP do a resetcd on the standby. This will clear any problem that could appear on the standby and any switchcc later will not cause any problems. Hardware: PXM1E
CSCdz47408	Symptom: On AXSME connection with vbr-nrt pvc and with WFQ enabled, can't reach PCR. Conditions: MGX 2.1.80 and an interim 3.0.20 release. Workaround: Unknown. Hardware: AXSME
CSCdz47471	Symptom: Power reset on node causes the primary SM to go into mismatch after runrev is issued (1:n redundancy) Condition: During one of the upgrade failure recovery scenarios on a service module (SM), a node power reset is performed after runrev command is issued for slot-17 (the redundant card is in slot-29). After power is restored, the primary card comes up in mismatch state. Observe some error messages as well. Workaround: unknown Hardware: PXM1E
CSCdz47960	Symptom: DB lost on AXSM-OC12 after burnboot 3.0.20 Conditions: MGX with 2.1.80 burnboot 3.0.20 Workaround: Unknown Hardware: AXSM1
CSCin15276	Symptom: Database is getting wrongly populated for targer_line_frm in line distribution table. Conditions: Add SRM links. Workaround: Unknown. Hardware: PXM1E
CSCin17591	Symptom: The administrative state of the subinterface is not getting populated in config upload for RPM-PR. Conditions: Create a new subinterface on a RPM-PR card with an PXM1E controller card. Then do a cold start of CWM which does a configuration upload from the switch. After this data is uploaded to the CWM database, it was realized that subinterface administrative status is missing. Workaround: Check the subinterface administrative status via the CLI. Hardware: PXM1E

Table 35 lists the Severity 3 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.20 software.

Table 35 Severity 3 Open Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 3.0.20 Software 

DDTs Issue	Description
CSCdt30145	Symptom: Loss of activity and clock switching to priority 1 messages observed in event log. Condition: AXSM-OC48 cards in system were being reseated. Workaround: Unknown. Hardware: PXM45
CSCdu26141	Symptom: SHM-4_DB_REQ_FAIL messages are logged at severity 4 in the event log. The log entries will look similar to the following: 08-00323 05/15/2001-00:51:31 SHM_-4-DB_REQ_FAIL shmDiskHdl 0x803276b4 SHM ERR: Database request on slot 8 failed, db = rslot. Conditions: Consecutive resetcd were executed on the PXMs in this node. This log can be seen under 2 conditions: 1. Under the normal operation of the PXM if this is logged, it is a problem with the communication between 2 tasks that needs to be investigated. 2. During any form of shelf reset like resetsys, abortrev, setrev etc. If this log is seen at around the time a shelf reset is happening, it is not a problem if this log is seen. This will not have any impact at all on the state of the shelf or the state of the configuration on the shelf. Workaround: None. Hardware: PXM45
CSCdu27030	Symptom: OAM CC Activation Cell correlation tag is incorrectly modified. Conditions: User notes that an F4-Seg Active-CC OAM cell with a correlation tag of 0x6A is returned to the sending device with a correlation tag of 0x00. Workaround: None. Hardware: AXSM1
CSCdu29780	Symptom: The line admin state is down because either there is NO DISK RECORD on the line, the line is defaulted to admin state down, or the disk record is there but it shows admin state down. Condition: Upgrading from older version to newer version and doing setrev's on multiple cards at the same time. Workaround: Do setrev on each card and wait until that is complete before doing the next card. Hardware: PXM45
CSCdv50574	Symptom: Incorrect usage statement generated. Condition: When the delapsln cli command is executed. Workaround: None. Hardware: AXSM1
CSCdv69400	Symptom: addchanloop on AXSME doesn't have option 2. Local loop in loopback. Condition: When addchanloop on AXSME. Workaround: Not known. Hardware: AXSME
CSCdx62800	Symptoms: MGX45 CLI Reference Manual needs updated. Conditions: 4 new commands missing out of the manual. Workaround: None. Hardware: PXM45/B
CSCdx82847	Symptom: Line status LED's on standby PXM1E always show green. Conditions: The line status LED on standby PXM1E are always show green even if the line is in LOS. This is inconsistent with other LEDs on the PXM1E. e.g., the ALARMs LEDs on the standby PXM1E remain OFF. We think that the line status LED should either reflect same as the active PXM1E or they remain OFF as of alarm LED. Workaround: None. Hardware: PXM1E
CSCdy09657	Symptom: dspdiagstatus does not display the state and role of SM's; It displays the info only for the PXM1E and SRM cards. Conditions: The PXM1E dspdiagstatus command does not display the state and role of SM's whereas the same command displays the state and role of the SM's in nodes with the PXM45. In case of a PXM1E node, the role and state info for SMs should say N.A (or something similar to indicate that NBSMs status is not displayed by this command). Workaround: None yet. Currently, "Idle/Unknown" is the role/state combination that is used to indicate that diags status does not apply to SM's. Hardware: PXM1E
CSCdy10480	Symptom: Default 0 SCT is not shown for FRSM12 Condition: Execute dspscts Workaround: The system will allow the user to configure port and card level SCTs even though the display does not show it. Hardware: PXM45
CSCdy16930	Symptom: addpart command is inconsistent when entering parameters. Condition: addparts commands takes hex values for some fields, for example if a value 3a is given for the field minVCI it would take that value and show as 58 which is decimal for 3a. Customer expects that a error message would pop up. Workaround: Unknown. Hardware: PXM1E
CSCdy23797	Symptom: pntrace commands not completely documented Condition: MGX CLI Manual vs the troubleshooting guide. Workaround: None. Trace commands beginning with pn will not be documented, because they are not customer commands. Thirteen new trace command are documented in the MGX PXM Command Reference, currently located at http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/wanbu/8850px45/release3/cmdref/index.htm" Hardware: PXM45/B
CSCdy36692	Symptom: Need warning messages for cnfport Conditions: Warning messages are needed to inform the user that cnfport is going to be changed. Workaround: None. Hardware: PXM1E
CSCdy37182	Symptom: dspcd shows lower back card empty for a full height back card. Conditions: None. Workaround: None. Not service impacting, only a display issue. Hardware: all
CSCdy41895	Symptoms: 'dspportsct vcThr' should match with the one shows on 'dspportsct qeVcThr' But the VSI_Signal values shown from SCT does not match to the actual HW value. Conditions: dspportsct vcThr & dspportsct qeVcThr Workaround: This is a display problem. The VSI_Signal VC Threshold values being display from the dspportsct or dspcdsct command is incorrect. Basically the AXSME software ignores the VC Threshold values being specified in SCT. Instead, the AXSME software would program a lower pre-defined threshold values for the VSI Signal channels. So the values in the HW are correct. Please ignore the VSI_signal values from the SCT. The lower pre-defined is needed because we want to limit our traffic flow on the VSI signaling channels prevent flooding the PXM45. If the PXM45 is flooded, then there will be some unpredictable and unreliable behaviors on PXM45. We are going to fix the display problem. Hardware: AXSME
CSCdy42620	Symptom: Danglers remain after using the CLI command delcons. This is the caveat with these commands. While provisioning connections in bulk (copycons/delcons), if the PNNI layer get busy due to re-route/de-route activity, then it will reject the deletion. Conditions: The command delcons was developed for Dev-test usage only. This command is not recommended to be used on a production node due to resource problems generated by the flood of traps on each con deletion. Workaround: Use delcon for each individual PVC until a better method is developed see PXM release notes for description of cli commands delcon and delcons usage. Hardware: frsm12
CSCdy46972	Symptom: Adding APS lines on the down lines does not show the correct error message. Conditions: Adding APS lines on the down lines does not show the correct error message. It shows as ERR:APS not allowed:wrong card type. On the PXM-45 it shows the correct error as ERR: working line must be up. Workaround: Unknown. Hardware: PXM1E
CSCdy46993	Symptom: APS command "clradjlnalmcnt" does not show the command option clearly Condition: emeanw36.8.PXM.a > clradjlnalmcnt 2.9 clradjlnalmcnt "<X.line>". It is not successful in the above format. But it also has another option as given below and it is successfully taking the command in that option. PXM.a > clradjlnalmcnt clradjlnalmcnt -<lineType> "<slot.line>" PXM.a > clradjlnalmcnt -sonet 2.9 Note: In MGX-45, it has only one option and it is successful. AXSM.a > clradjlnalmcnt clradjlnalmcnt "<bay.line>" AXSM.a > clradjlnalmcnt 1.3 AXSM.a > clradjlnalmcnt 1 clradjlnalmcnt "<bay.line>" AXSM.a > Workaround: Unknown. Hardware: PXM1E
CSCdy49757	Symptom: AUSM channel, port and SAR counters do not correctly count RM cells received from CPE Condition: The AUSM channel, port and SAR counters do not correctly handle RM cells when they are generated by the CPE (test-set). When RM cells are received by the AUSM card the baseline behavior is that they should be discarded by the UNI port. Indeed that is what is noted to happen for AUSM on PXM1E. The command dspconload" shows that no traffic is received from the AUSM when a stream of RM cells at 480 cps is generated by the test-set: Workaround: Unknown. Hardware: AUSM-8T1E1
CSCdy54607	Symptom: PXM command line interface paused indefinitely and would no longer accept commands. Conditions: Occurred after executing the memshow<noCmdBold) command from the command line interface. Workaround: None. Hardware: PXM45
CSCdy59294	Symptom: AUSM/PXM1E transmits invalid PTI=7 cells into network but cannot pass traffic out of far-end AUSM port. Condition: An abr1 PVC was provisioned between two AUSM-IMA ports: [Test Set A] <---> node1 to node2 <---> [Test Set B] Test set A generated 480 CPS of ATM cells with the PTI field set to 7 (invalid). The payload consisted of 48 byte 6A pattern. The channel, port and SAR counters on node1 indicate that traffic is being sent into the network. On the PXM1E card on node1 the "dspconload" command indicates that all the PTI=7 traffic is sent out the trunk interface. In fact there seems to be RM cell overhead in both directions. The "dspconload" command on node1 indicates that all PTI=7 traffic is being received on the trunk interface. However on the AUSM port on node2 the chan, port and SAR counters all remain at zero. It is very strange that the AUSM card handles PTI=7 cells differently on the Ingress and Egress directions. At one time the PVC was able to transmit PTI=7 cells end to end but it has only been observed to happen once. Workaround: Unknown. Hardware: AUSM-8T1E1
CSCdy59923	Symptom: Mounting nfs is not necessary, takes time and resources and can cause conflicts when nfs host is the same as another device. Conditions: Nfs host is mounted when coming up. Workaround: None. Hardware: PXM45/B
CSCdy59933	Symptom: Attempt to low level format with diskFormat and ataFormat fails on PXM-HD with the following error. pxm45bkup>diskFormat "C:" IDE: format in progress. This takes a while ........ .Device abort error .... status is 51 error is 10 Couldn't format "C:". value = -1 = 0xffffffff pxm45bkup>. Conditions: This condition is observed in 2.1 Release when the PXM-HD model is IC25N020ATCS04-0 or IBM-DJSA-205. The HDD model name can be viewed with the command ataShow. cmdBold>More Information: A low level format is not required in the field as these drives come preformatted from manufacturing. Using sysClrallcnf and recreating the file system with sysDiskCfgCreate will help to reinitialise a PXM-HD in the field. Workaround: None. Hardware: PXM45
CSCdy62765	Symptom: Standby PXM reset. The dsplog will look similar to the following example (slot 8 is active, 7 is standby in this example): 08A98502 09/05/2002-16:48:56 SHMA-7-FATAL_ERR_RPT E:00317 pnRedman shmRamSyncFatalErrRepor shmRamSyncFatalErrReport: AppId 0x1000c, tId 0x10054, tName pnRedman , Ref. pslot 7, callerPc 0x807c68e8, evtNum 0x1000 08A98509 09/05/2002-16:48:56 REDM-6-RmRamDbReset pnRedman checkSyncRamResetState Redman receive reset from RAMDB. Reset reason:-2 Note that the AppId, tId, tName could be any application on the node. Conditions: A RAM sync error triggered the standby PXM reset. Workaround: None. The standby PXM returned to service following the reset. Hardware: PXM45
CSCdy64715	Symptom: ataFormat() fails Conditions: when using IBM-DJSA-205 disks (Gb) Workaround: use ataFormat_20GBversion() Hardware: PXM45
CSCdy71223	Symptom: LOA yields inconsistent active clk state in 2 PXM1E nodes. Conditions: Create an LOA on 2 PXM1E nodes. Workaround: Unknown. Hardware: PXM1E
CSCdy73100	Symptom: Misspelled word in the syntax of the cnfpnni-node output. Conditions: When viewing the output, the word does is spelled deso. Workaround: None. Hardware: PXM45/B
CSCdy78398	Symptom: SAR errors not detected by SCM for 3 minutes. Condition: Tests consisting of SAR single bit errors were executed on active and standby AXSM cards. Workaround: Unknown. Hardware: AXSMB-OC3
CSCdy79293	Symptom: AXSM reset due to watchdog timeout Conditions: Unknown. Workaround: Reset card if necessary Hardware: AXSMB-OC3
CSCdy82219	Symptom: PNNI ports go into provisioning mode and spvcs fail when fault on active card or card switchover allowed to standby card with fault. Condition: Utopic 2 Bus CBC to ATMIZER bit tx/rx errors inserted on active or standby cards. Workaround: Unknown. Hardware: AXSMB-OC3
CSCdy82452	Symptom: QE48 fault not detected in standby state. Condition: User executed QE48 VC Table and QDB Memory Bank Fault Insertion test cases. Workaround: Unknown. Hardware: AXSM1
CSCdy82780	Symptom: Faulty card did not reset and come up as failed. Condition: Customer executed QE48 Tx UTOPIA3 to Humvee parity error fault insertion test case Workaround: Unknown Hardware: AXSM1
CSCdy82827	Symptom: No action taken by switch and no records in event log when fault inserted. Condition: Egress/Ingress QE QDB memory data bit errors fault insertion test case executed. Workaround: Unknown. Hardware: AXSME
CSCdy82836	Symptom: Standby AXSM-E card did not reset and error was not recorded in event log. Condition: Humvee ILT CAM data bit 8 tied to GND fault insertion test case was executed. Workaround: Unknown Hardware: AXSME
CSCdy82849	Symptom: When fault inserted on active or standby card, reset/switchover did not take place for 3 min. Condition:SWB10-Hold Atmizer in reset fault insertion test case was executed. Workaround: Unknown. Hardware: AXSME
CSCdy82872	Symptom: Card fault not reported in event log Conditions: Hold Port 1 secondary Tetra in reset fault insertion test case was executed on standby AXSM-E Workaround: Unknown Hardware: AXSME
CSCdy86511	Symptom: The AXSM reset due to a software error. See logs below. The error information is corrupted, see attachment with error information example. This is a customer node running 2.1(80). The card has been replaced and is being sent back for failure analysis. There is a core dump for the AXSM slot 3, see the bug desc. for the location of the core dump. Conditions: Workaround: Hardware: AXSME
CSCdz04750	Symptom: The FRSM8 card does not correctly process incoming Frames with incorrect CRC-16. Condition: The FRSM8 card does not correctly process incoming Frames with incorrect Frame Check Sum sequence. The port should discard these "corrupt" frames under the port counter "RcvFramesDiscCRCError:". Instead the frames get sent into the network. Workaround: Unknown. Hardware: PXM1E
CSCdz08738	Symptom: After node rebuild PXM1E went into mismatch with LowerBackcRd. Condition: slot-7 was active and slot-8 was standby. A power off/on was done on the node. After the rebuild slot-7 was coming up as active and slot-8 was coming up as standby. When slot-7 became active it is observed that it is in mismatch with LowerBackCard. When slot-8 became standby there was a switchover so that slot-8 became active and slot-7 got reset and came back up as standby. Workaround: Unknown Hardware: PXM1E
CSCdz18393	Symptom: xcnfln command does not have v.35 option included in the display. Condition: xcnfln command has the option for x21 and hssi. But it does not have the option for v35. We can configure the line using the x21 option for v.35. But it would be clear if that option also included in the xcnfln. Workaround: Unknown. Hardware: PXM1E
CSCdz25041	Symptom: No hssi option in the xcnfln command. Condition: 1. No hssi option in the xcnfln command 2. Adding the line loopback on the line which has loopback enabled gives wrong error message Error occurred during the SNMP SET operation !! Probable Reason: "Cannot change loopback" SNMP Error Code: 76 Set failed due to illegal parameter(s) Syntax: addlnloop "line_num" line number -- 1-2 for HSSI, 1-8 for V.35/X.21. It should say the line loopback is already enabled. --------------------------------------------------- 3. When we try to add the loopback with xcnfln command on the line with already enabled loopback it gives the wrong error message. Error occurred during the SNMP SET operation !! Probable Reason: "Cannot change loopback" SNMP Error Code: 76. Set failed due to illegal parameter(s). It should take it or it should say the loopback is already enabled. Workaround: Unknown. Hardware: PXM1E
CSCdz29332	Symptom: Unknown Error Code message returned on cli. Condition: When the dsppnni-timer command is executed with the incorrect node index. Workaround: None. Hardware: PXM45/B
CSCdz33358	Symptom: On an MGX45, a connection which had been indicating AIS in error was restored to normal operation. However, dspcon on slot 12 AXSM showed AIS being transmitted to the network even tho it was not being transmitted. Conditions: Workaround: none discovered. Hardware: AXSM1
CSCdz34835	Symptom: cnfln -e3 <bay.line> -len <length> did not work. Conditions: All conditions. Workaround: None. Hardware: PXM1E
CSCdz35839	Symptom: 3 x AXSM went unreachable from PXM45/B, traffic down, could not cc to modules, but dspcds from PXM showed card as ok Conditions: Not known --> Workaround: resetcd <AXSM slot no> Hardware: AXSMB-OC3
CSCdz40676	Symptom: cnfpnportsig command results in false warning when a value for vpi=0 is assigned. Condition: cnfpnportsig 7:2.6:26 -vpi 1. WARNING: Signaling VPI is outside of the port VPI range. Syntax: cnfpnportsig <portid>. Workaround: Unknown. Hardware: PXM1E
CSCdz40700	Symptom: dsplog for FRSMHS2/B does not show the line deleted in the message". Condition: ON FRSM-HSSI Module, line is deleted by using the delln command. But it is not showing in the dsplog that the line is deleted as it shows for other SM modules. Workaround: Unknown. Hardware: PXM1E
CSCdz40720	Symptom: Need to Delete Line Loopback before changing the line parameters on FRSM-HS2/B with V35 back card. Condition: On FRSM-HS2/B with FRSMHSSI cards, there is a need to delete the line loopback enabled on the line before changing the line parameters. This type of restriction is not there in other SM modules. Workaround: Unknown. Hardware: PXM1E
CSCdz40737	Symptom: dspcnfdiag is not updated after cnfdiagall command for SRM slot. Condition: The display is not updated after "cnfdiagall" for slot 15,16,31 & 32 (SRM). after a new node was installed we issued the "cnfdiagall enable disable" command. The display does not update the status for SRM slots. Workaround: Unknown. Hardware: PXM1E
CSCdz40750	Symptom: Trying to add redundancy with one of the card is in standby state gives unclear error message. Condition: PXM1E, slot 3 and 4 are having FRSM-HS2/B with FRSM-HSSI back cards. When we tried to add the redundancy when one of the card is in standby mode is not giving the clear error message. Later on it adds the redundancy though the command is failed. Workaround: Unknown. Hardware: PXM1E
CSCdz40766	Symptom: Adding redundancy with different back cards does not give the correct error message. Condition: Adding the 1:1 Redundancy with different back card is not giving the correct error message. On the node PXM1E slot 3 is with FRSM-HS2/B with the FRSM-HSSI back card. Slot 4 is with FRSM-HS2/B with FRSM-V35/X21 interface. Adding the redundancy does not give the correct error message. Workaround: Unknown. Hardware: PXM1E
CSCdz46078	Symptom: dspalms does not have hssi option Condition: dspalms does not have the " hssi " option as the line type. However, it does work, if you use x21 option Workaround: unknown Hardware: PXM1E
CSCuk38319	Symptom: VC-12 REI is seen on the tester connected to SRME. Conditions: Links added to VISM-PR-8E1. Workaround: None. Hardware: PXM45/B

Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

Table 36 lists the status of the known caveats from previous releases.

Table 36 Status of Severity 1, 2, and 3 Previous Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 

DDTs Issue	Status	Description
CSCdt54958	Severity 1; closed	Bug closed because the hardware part causing the problem was replaced.
CSCdw27075	Severity 1; closed	Bug closed when the problem was unreproducible.
CSCdx33812	Severity 1; closed	Bug closed because it was a hardware design limitation.
CSCdx48370	Severity 1; closed.	The hardware is working the way it was designed. Hardware: PXM1E
CSCdx54945	Severity 1; closed	Duplicate of CSCdx55987, which is still open.
CSCdy11654	Severity 1; closed	Fixed in Release 3.0.10
CSCdy37036	Severity 1; closed	Fixed in Release 3.0.20
CSCdy65077	Severity 1; closed	Fixed in Release 3.0.20
CSCdy66033	Severity 1; closed	Bug closed when problem was unreproducible.
CSCdy73727	Severity 1; open	Bug was discovered to be against the VISM/PR software
CSCdy75309	Severity 1; closed	Bug closed when problem was unreproducible.
CSCdy81930	Severity 1; closed	Bug closed because behavior is correct.
CSCdy82098	Severity 1; closed	Fixed in Release 3.0.20
CSCdy82600	Severity 1; closed	Bug closed because behavior is correct.
CSCdw10207	Severity 2; closed	Fixed in Release 3.0.10
CSCdw41209	Severity 2; closed	Fixed in Release 20.0.3.0
CSCdx17118	Severity 2; closed	Bug closed since it was verified that rerouting works on errored trunks.
CSCdx57346	Severity 2; closed	Fixed in Release 3.0.00
CSCdx59814	Severity 2; closed	Bug closed because it was a hardware design limitation.
CSCdx62011	Severity 2; closed	Fixed in Release 3.0.10.
CSCdx86863	Severity 2; closed	Bug closed because it could not be reproduced with newer images.
CSCdx89271	Severity 2; open	Bug was discovered to be against the IOS software.
CSCdy07641	Severity 2; closed	Fixed in Release 20.0.3.
CSCdy09052	Severity 2; closed	Fixed in Release 3.0.20.
CSCdy22021	Severity 2; closed	Bug closed when problem was unreproducible.
CSCdy22633	Severity 2; closed	Fixed in Release 3.0.20.
CSCdy24232	Severity 2; closed	Fixed in Release 3.0.20
CSCdy31818	Severity 2; closed	Duplicate of CSCdw48921, which is an open Severity 4 bug.
CSCdy35788	Severity 2; closed	Bug closed because there a valid workaround.
CSCdy36366	Severity 2; closed	Fixed in Release 3.0.20
CSCdy37018	Severity 2; closed	Fixed in Release 3.0.20
CSCdy37437	Severity 2; closed	Bug closed because problem not applicable for the release.
CSCdy37451	Severity 2; closed	Fixed in Release 3.0.20
CSCdy40247	Severity 2; closed	Bug closed because incorrect back card was being used.
CSCdy42188	Severity 2; closed	Duplicate of CSCdz28024, which is open
CSCdy42253	Severity 2; closed	Bug closed because capability not available on FRSM-12-T3E3 card
CSCdy43338	Severity 2; closed	Duplicate of CSCdw03223, which was closed because the behavior is correct.
CSCdy44390	Severity 2; closed	Fixed in Release 3.0.20
CSCdy44965	Severity 2; closed	Bug closed when problem was unreproducible.
CSCdy50998	Severity 2; closed	Fixed in Release 3.0.20
CSCdy53083	Severity 2; closed	Fixed in Release 3.0.20
CSCdy54351	Severity 2; closed	Fixed in Release 3.0.20
CSCdy55759	Severity 2; closed	Fixed in Release 3.0.20
CSCdy56415	Severity 2; closed	Duplicate of CSCdy84983, which is an open Severity 4 bug
CSCdy58998	Severity 2; closed	Fixed in Release 3.0.20
CSCdy61355	Severity 2; closed	Bug closed when problem was unreproducible.
CSCdy62916	Severity 2; closed	Duplicate of CSCdy88913, which is fixed in Release 3.0.20
CSCdy63336	Severity 2; closed	Fixed in Release 3.0.20
CSCdy64831	Severity 2; closed	Fixed in Release 3.0.20
CSCdy68455	Severity 2; closed	Fixed in Release 3.0.20
CSCdy69200	Severity 2; closed	Fixed in Release 3.0.20
CSCdy69205	Severity 2; closed	Fixed in Release 3.0.20
CSCdy69231	Severity 2; closed	Fixed in Release 3.0.20
CSCdy70426	Severity 2; closed	Fixed in Release 3.0.20
CSCdy70541	Severity 2; closed	Fixed in Release 3.0.20
CSCdy70780	Severity 2; closed	Fixed in Release 3.0.20
CSCdy71720	Severity 2; closed	Duplicate of CSCdy61622, which is open
CSCdy72288	Severity 2; closed	Fixed in Release 3.0.20
CSCdy72444	Severity 2; closed	Fixed in Release 3.0.20
CSCdy72593	Severity 2; closed	Fixed in Release 3.0.20
CSCdy72688	Severity 2; closed	Fixed in Release 3.0.20
CSCdy72711	Severity 2; closed	Fixed in Release 3.0.20
CSCdy72726	Severity 2; closed	Fixed in Release 3.0.20
CSCdy73536	Severity 2; closed	Fixed in Release 3.0.20
CSCdy73577	Severity 2; closed	Bug closed when problem was unreproducible.
CSCdy73583	Severity 2; closed	Duplicate of CSCdy70541, which is fixed in Release 3.0.20
CSCdy73683	Severity 2; closed	Duplicate of CSCdy69910, which is fixed in Release 3.0.10
CSCdy73728	Severity 2; closed	Fixed in Release 3.0.20
CSCdy74932	Severity 2; closed	Bug was discovered to be against the VISM/PR software
CSCdy75753	Severity 2; closed	Fixed in Release 3.0.20
CSCdy77458	Severity 2; closed	Fixed in Release 3.0.20
CSCdy77599	Severity 2; closed	Bug closed when problem was unreproducible.
CSCdy79315	Severity 2; closed	Fixed in Release 3.0.20
CSCdy80802	Severity 2; closed	Fixed in Release 3.0.20
CSCdy80871	Severity 2; closed	Duplicate of CSCdy80802, which is fixed in Release 3.0.20
CSCdy81725	Severity 2; closed	Fixed in Release 3.0.20
CSCdy82093	Severity 2; closed	Fixed in Release 3.0.20
CSCdy83276	Severity 2; closed	Duplicate of CSCdz24461, which is an open Severity 6 bug
CSCin15832	Severity 2; open	Bug was discovered to be against the CWM software
CSCin19333	Severity 2; open	Bug was discovered to be against the IOS software
CSCdx34833	Severity 3; closed	Bug was closed because the message appears when the correct command is entered.
CSCdy10115	Severity 3; closed	Fixed in Release 3.0.10
CSCdy25518	Severity 3; open	Bug is not applicable against Release 3.0.x images.
CSCdy29344	Severity 3; closed	Fixed in Release 3.0.20
CSCdy39198	Severity 3; closed	Fixed in CWM 11.0.10, patch 1
CSCdy42250	Severity 3; closed	Fixed in Release 3.0.20
CSCdy43404	Severity 3; closed	Fixed in Release 3.0.20
CSCdy46964	Severity 3; closed	Bug closed because capability not available for type of connection.
CSCdy55782	Severity 3; closed	Fixed in Release 3.0.20
CSCdy59858	Severity 3; closed	Bug closed because it is not a problem with Release 3.0 and up.
CSCdy64834	Severity 3; closed	Fixed in Release 3.0.20
CSCdy64846	Severity 3; closed	Fixed in Release 3.0.20
CSCdy64892	Severity 3; closed	Fixed in Release 3.0.20
CSCdy65252	Severity 3; closed	Fixed in Release 3.0.20
CSCdy67817	Severity 3; closed	Fixed in Release 3.0.20
CSCdy70165	Severity 3; closed	Fixed in Release 3.0.20
CSCdy72671	Severity 3; closed	Fixed in Release 3.0.20
CSCdy72707	Severity 3; closed	Fixed in Release 3.0.20
CSCdy78372	Severity 3; closed	Fixed in Release 3.0.20
CSCdy81403	Severity 3; closed	Fixed in Release 3.0.20
CSCdy82305	Severity 3; closed	Duplicate of CSCdy82849, which is open
CSCdy82328	Severity 3; closed	Fixed in Release 3.0.20
CSCdy82800	Severity 3; closed	Duplicate of CSCdy82780, which is open
CSCdy82897	Severity 3; closed	Duplicate of CSCdw55034, which is fixed in Release 3.0.20
CSCdt61581	Severity 4; open
CSCdx81165	Severity 4; open
CSCdy61482	Severity 4; open
CSCdv69323	Severity 6; open
CSCdy24461	Severity 6; open
CSCdy53146	Severity 6; closed	Bug was closed because there wasn't a need for this change.

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.20

Table 37 lists the resolved caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 software Release 3.0.20.

Table 37 Resolved Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Software Release 3.0.20 

DDTs Issue	Description
CSCdt61572	DLS:LAN port spurious interrupt: Message not record
CSCdt75468	upallports/dnallports commands need to be included
CSCdw49348	FRSM12: Sec Reserved BC go into UNKNOWN
CSCdw68495	AXSME locks up when it receives large number of OA
CSCdx25272	FRSM12:Replace VsiErr logging with SSI event loggi
CSCdx81404	P2MP_DT:Corrected HecErrs cells increment when APS
CSCdx85020	OAM : dspchandbgcnt shows non-Terminated AIS cells
CSCdy04692	FRSM12: Upport should not be successful if SCT fil
CSCdy04715	Reg3.0.10:No check in command line for bay.line in
CSCdy05769	FRSM12: After change ABR parameter
CSCdy08544	P2MP_RT:SPVM-4-ERROR & SPVC-4-ERROR observed after
CSCdy09033	CHK:dsphotstandby option 1 does not work if APS co
CSCdy09052	UPGD:dsphotstandby runs forever after PXM switchov
CSCdy09182	CHK: improper dsphotstandby output SONET T3E3
CSCdy11929	FRSM12: CC cmd does not return prompt all the time
CSCdy15287	REG3.0.10 restoreallcnf filed due to file empty ev
CSCdy18316	TB+ Hard: snmpPrxy assigns buffer once but frees i
CSCdy18792	3.0(10): unnecessary messages displayed on remote
CSCdy19339	reg3.0(10): error not displayed on cnfpart with vp
CSCdy20361	routenetadd command shows routedelete in syntax
CSCdy21163	REG3.0.10: dspvsicon -lvpi 0 not functioning
CSCdy21291	FRSM12: Invalid event reported for EM Stat manager
CSCdy21738	REG3.0.10:After multiple resets the serv modules a
CSCdy21915	tDbgInTask memLeak
CSCdy22633	dspcons
CSCdy22771	imagrp in Blocked state moving to Oper after switc
CSCdy24232	CORE_CARD_SWITCH message dropped on switchcc
CSCdy24243	AXSME does not support mib-walk on CISCO-WAN-ATM-C
CSCdy24431	FRSM12: quit on PXM45
CSCdy25589	SLT:Doesn't create record to log file when environm
CSCdy25713	For AXSM-32-T1E1-E
CSCdy29344	Line Module(Back card) removed Trap does not contai
CSCdy30310	REG3.0.10: PXM1E APS: alarm not in LOS when remove Rx P_Line
CSCdy32354	Need proper error message when rejecting adport 32
CSCdy34878	need warning message for delsct
CSCdy36366	MPG SPVC cost should include cost of traversing vi
CSCdy37018	need CLIs to display VC/Cos Thresholds in AXSME QE
CSCdy37036	UPgrade to 3.0(10.99)P1 caused FRSM12 Connection F
CSCdy37451	TB+ Hard2: IPC memLeak in buffer id 0x10002 and 0x10003
CSCdy38505	Memory leak:owner task:emRoot
CSCdy38561	PnSscop owner task memory leak
CSCdy38996	<EvtLog>tTnlnTsko1 logged severity 4 FIPC
CSCdy40747	improper error message when rejecting cnfcdmod wit
CSCdy42228	Connection not rerouted after turning restrict tra
CSCdy42250	SCT chksum don't match between sw distributed and C
CSCdy43404	correct alarm is not displayed for srm card
CSCdy44390	Discrepancy with CLI dsplncnt and ftp file for AXS
CSCdy44919	Conn route cost incorrectly calculated
CSCdy45214	CLI: remove cmdhistory since identical to history
CSCdy46259	need some debug functions to analyze the queues in
CSCdy49636	APS: csApsFailureStauts is always set to Channel M
CSCdy49641	Shm trap gen error:trap#60082 bad input pslot
CSCdy50998	P2MP_DT:remote switchover of AXSMB on resetting pr
CSCdy53083	<switchcc> Core dumped on slot #14 qe48CP Err
CSCdy53519	CLI: remove commands installhelp
CSCdy54351	SPVC mismatch on frame_discard between ram and dis
CSCdy54849	Have CLI options to configure and clear E3 trail t
CSCdy55759	The command memshow ? caused the PXM45 to hang.
CSCdy55782	no max login attempts to MGX45.
CSCdy55786	Upon receiving AIS
CSCdy56312	UPG: Version changes does not sent to dbServer in
CSCdy56582	CESM in mismatch/failed after runrev
CSCdy57731	use micro sec for tstdelay result
CSCdy58150	PXM1E: trap 60351 has wrong SCT ID when VUNI port
CSCdy58189	APS: csApsPrimarySection remains workingSection1 f
CSCdy58223	REG3.0.10: 24K SPVC fail when complex node(lowest
CSCdy58998	RGS:LSC controllers show the AXSME available rates
CSCdy59095	NBSM:SPI messages flooded console port after load
CSCdy63336	TB+ Hard2: pnRedMan memLeak in PXM1E
CSCdy64831	Not to reset NBSM on a burnboot
CSCdy64834	Avoid the non-native PXM go come up as Active or S
CSCdy64846	avoid bringing the non-native card as active in a
CSCdy64892	CPRO-7-SNMP_ERROR cutW1Taxk cpro_log_error debug m
CSCdy65077	<switchredcd> AXSM takes a long time to become act
CSCdy65252	once clock is unlockable it needs to be reconfigur
CSCdy65804	Imagrps complains of insufficient links
CSCdy65978	TB+ Hard2: memLeak by clk module in ipc pool 2
CSCdy67044	Files getting generated with delay of 10-13 min on
CSCdy67144	Slot info for CESM is different for active/stdby p
CSCdy68455	Z-REGS:Simul. Switchcc & XF switchover resulted in
CSCdy68481	APS:AXSME sends WorkIndex and ProtectionIndex as s
CSCdy69200	clk signals not available after APS switch
CSCdy69205	clk signals not available after APS switch
CSCdy69231	TB+ Hard2: PXM1E combos stby cd drops to idtmon af
CSCdy70426	Complex Node Rep. Bypass does not sort by AVCR.
CSCdy70692	FRSM12: cwFrChanFailed alarms should supersede cwF
CSCdy70752	TB+ Hard2: clk re-qualifies when reversion is enab
CSCdy70780	dspportcnt does not have Ingress counter
CSCdy72062	FRSM12: IPC mblk not freed in CM msg handler (tOam
CSCdy72288	dsptotals command on AXSME should not include via
CSCdy72671	AXSM/AXSM-E Humvee Out of Sync Error Detection/Rep
CSCdy72688	REG3.0.10: Online diag stat on FRSM12 not updating
CSCdy72707	XBAR: PXM to mcast xbar avail chg on cd reset
CSCdy72711	runrev caused aps port to fail
CSCdy72717	Ram sync error events in PCEMA
CSCdy72726	Oscillation between red. AXSM-E cds when ps failur
CSCdy73536	dspapslns shows OK OK for W & P lines with W Rx ca
CSCdy73668	frsm stay in boot/empty after clrcnf no PXM1E
CSCdy73728	Default SCTs sometimes get loaded during system br
CSCdy74962	PXM45C: resetsys cause redundant AXSM_T3_B cards t
CSCdy75930	cnfcli accepts incomplete commands causing inconsi
CSCdy76444	FRSM12: Max CIR in addcon/cnfcon should be 442100
CSCdy77067	PXM45 offline diag fails crossbar test with xbar e
CSCdy77458	Interface port information pointer messages seen i
CSCdy77834	use micro sec for tstdelay result
CSCdy79315	dspsesn command show ERR: Unknown control command
CSCdy80802	TUG3 #2
CSCdy81725	The sonet line alarm clear trap #60105 was not rec
CSCdy82093	Cnfln cause TLB load exception on AXSM running TBA
CSCdy82098	PXM45A Node ran out of STATIC memory
CSCdy82328	AnnexB: Found mismatch between AXSMB and RAD
CSCdy83743	discrepancy on number of tagged cells vbr-rt ingre
CSCdy83976	The croi task did not free the buffer after cc logout from p
CSCdy84333	stdby card reset while it was in init state and
CSCdy85039	aps dsplog -minor display issue
CSCdy85231	VT/VC level alarm display capability needed
CSCdy86129	Routing cost for some connection is incorrect.
CSCdy86578	VISM-E1 line is in alarm after the link is added
CSCdy86684	First coredump should be preserved in case of succ
CSCdy86950	dspcon on PXM for daxcon does not show remote node
CSCdy88913	AXSM reset caused by failed alarm file FTP
CSCdy88976	popup when clrerrhist command is executed
CSCdz00312	snmpMA task suspended - AXSM cards in slot 9-14 fa
CSCdz00771	SRM not displaying correct info for hardware rev
CSCdz01426	Several AXSMs show UNKNOWN for reserved backcard t
CSCdz01683	connection in mismatch after restoreallcnf.
CSCdz02611	no trap 60052 is received after removing active P
CSCdz04722	los on active clock standby clock goes through req
CSCdz06187	CWMMNR: node stuck in pxmbkup (infinite loop) due
CSCdz07991	Graceful upgrade for FRSM T3 cards fails
CSCdz10141	IMA device memory/register display routines show w
CSCdz11288	FRSM12: Big Traffic loss in UBR conn with WFQ enab
CSCdz11916	Cpro ramdisk error message should be suppressed un
CSCdz13329	PNNI should be able to handle unset NAKs and allow
CSCdz14692	AXSME Atlas reports frivolous errors causing HMM o
CSCdz15030	P2MP_DT: dnpnport ilmi UNI causes pnni-sum to go i
CSCdz15115	ipc comm epid create and bind need to check/valida
CSCdz16104	dspconload fails due to SW error
CSCdz17098	PXM45C: FRS interrupt shown as error instead of in
CSCdz17165	SM ports in down state after upgrade or resetsys
CSCdz22839	BRAM corruption on PXM45
CSCdz25071	interoperability testing between PXM1E and PXM-45 modules in
CSCdz25232	FRSM12: Need add trace func for IRQ for CoreDump
CSCdz27067	upgrade fails for some SMs
CSCdz27235	CLI hangs for more than 10 minutes
CSCdz28670	SSI SyncTimer Pool exhausted after script (dnilmi/upilmi)
CSCdz29644	FRSM-HS2/B card went in mismatch state after node rebuild
CSCdz31229	All AAL0/2 cells dropped on PXM QE0 on 1 conn after AUSM swi
CSCdz32627	free mem err on SES/MGX nodes
CSCdz32647	1e MR: NNI links stuck in building VC state impact all traff
CSCdz33744	Memory free failure on newly active PXM during switchover
CSCdz34912	graceful upgrade is not working or sm on PXM1E node
CSCdz35390	Cards stuck in init state during upgrade
CSCdz35621	Connections not routed between nodes
CSCdz36039	FRSM12: SW work around for CSCdz25577
CSCdz36119	CLI/SNMP query failed on AXSME IMA and card in Active-F
CSCdz37489	Shaping is not working correctly during boot up second RPM i
CSCdz39668	Gen stats files are generated with delay of 15 minutes on ax
CSCdz40517	Secondary Clock config lost when configuring the revertive o
CSCdz40649	frsm0hs2b with frsm hssi card resets when you down the connection
CSCdz41032	Setrev is not working to go back to a previous version
CSCdz41239	The PNNI Bypass entries display non zero values in one direc
CSCdz45071	FRSM-HS2B resets the stand by card in some specific operations.

Caveats for Release 3.0.10

This section provides information about caveats associated with Release 3.0.10 software.

Severity level 1, 2, and 3 caveats are organized in this section as follows:

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.10

•Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.10

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.10

Table 38 lists the Severity 1 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.10 software.

Table 38 Severity 1 Open Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 3.0.10 Software 

DDTs Issue	Description
CSCdt54958	Symptom: OC12 p-p jitter amplitude exceeded the 0.10 UI pp. Conditions: Unknown. Workaround: None. Hardware: AXSM1
CSCdw27075	Symptom: Unable to switchcc to a AXSM card in Y-redundancy configuration. The reason for that is that QE VI threshold has been exceeded and QE is discarding the incoming AAL5 frames. This situation may be met in PXM45A, where SAR overflow may occur (very rare). Note: customer should not let QE SAR overflow occur in PXM45A Conditions: After a switchredcd on an AXSM card pair in redundant mode. Workaround: None. Hardware: PXM45
CSCdx33812	Symptom: Xbar planes being shut done on the PXM45B. Conditions: Xbar errors being reported between slots 3, 7, and 8. Workaround: None. Hardware: PXM45B
CSCdx54945	Symptom: All external xtags are down. Attempts to switchcc to slot 5 (containing xtag interfaces) failed. Conditions: Standby PXM in slot 8 in empty reserve state. There are some P1SarErrors reported to the active PXM log. Workaround: None. Hardware: axsm1b_oc12
CSCdy11654	Symptom: User can neither "cc" nor "ccc" (high primary) to any slot with an RPM seated in it. "cc" to any other slot containing any other card type succeeds. Condition: IOS IPC memory buffer leaked for 21 days, zero resource were available for IPC, when this situation occurred. The MGX shelf is operating in simplex mode. Workaround: "switchcc" with duplex shelf "resetcd" with simplex shelf. Hardware:PXM45B
CSCdy37036	Symptom: AXSM-E card was failed after upgrading and on line diag cycle. Conditions: Card was upgraded. Workaround: Use the default SCT files provided for CARD SCT (AXSME_SCT.CARD.5) or change the CosB Max thresholds of all CosBs to be less than 300,000 in the SCT file. Hardware: frsm12
CSCdy61482	Symptom: SRM cards come up in failed state as seen with dspcd or dspcds Conditions: Node is coming up following a power failure or resetsys and the SRM(s) are removed and re-inserted while the PXM is in the active state Workaround: None Hardware: PXM1E
CSCdy65077	Symptom: Standby AXSM hung for approximately one minute - caused data loss. Conditions: Upon the execution of the switchredcd on slot #11 to #12. Workaround: None. Hardware: AXSMB-OC3
CSCdy66033	Symptom: Connections fails and doesn't route Conditions: MGX 8830, MGX 8850 Workaround: Under investigation Hardware: PXM1E
CSCdy75309	Symptom: After the node was powered down, connections were still in OK state. Conditions: Connections existed between two PXM1E nodes. When one node was downed, the connections on the other end went into the failed state. However, some connections (about 50 out of 2500) were still shown as OK on the switch. Workaround: Unknown. Hardware:PXM1E
CSCdy81906	Symptom: Slots 1 and 2 rebooted and failed. Condition: After a burnboot slot #8 and switchcc was executed on the shelf. Workaround: None. Hardware:PXM45B
CSCdy81930	Symptom: Port failed for over 9 minutes. Condition: Unknown. Workaround: None. Hardware:axsm1b_oc12
CSCdy82098	Symptom: Node failed to establish connections, and ports go to building state etc. Conditions: Heavily populated node with PXM45A cards. Workaround: Do resetsys. Hardware:PXM45
CSCdy82600	Symptom: Inconsistent redundancy on CESM cards on MGX 8850 with PXM1E. Conditions: Ungraceful upgrade was in progress for three cards in this slot. After the upgrade, 1:n redundancy was configured (slots 25 & 26 as active, slot27 as standby). Resetcd on slot 25 changed this state to standby and slot 27 to active for "dspcds". However, after "cc" from pxm slot 25 is active and 27 standby. Workaround: Unknown. Hardware:PXM1E

Table 39 lists the Severity 2 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.10 software.

Table 39 Severity 2 Open Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 3.0.10 Software 

DDTs Issue	Description
CSCdt61581	Symptom: Faulty card did not go into continuous reset during Utopia bus parity error failure Conditions: Utopia bus parity error fault insertion was being undertaken Workaround: Unknown. Hardware: PXM45
CSCdv53825	Symptom: sframetick lock config is lost. Conditions: When a switchcc is executed on the shelf. Workaround: None. Hardware: PXM45
CSCdv85607	Symptom: Core dump occurred for standby AXSME OC3 card though no activities. Conditions: AXSMEOC3 with standby card. Workaround: Unknown. Hardware: AXSME
CSCdw91580	Symptom: SRME APS switchover time > 250ms when either SRME front card or back card is removed. Conditions: When SRME is engaged in APS and either SRME front card or back card is removed. Workaround: Perform APS switching out from back card that need to be removed. It means that before removing the SRME card, insure that the SRME card is in standby state instead of active. Hardware: PXM1E
CSCdx17118	Symptom: Slower and partial reroutes for connections routed over trunks with errors or delay. Conditions: Introducing delay and bit errors on trunks between peer groups causes connection reroute delays. Workaround: Unknown. Hardware: PXM45
CSCdx45116	Symptom: Some of the connections are in alarm after stopbert testing Conditions: cnfbert, startbert then stopbert Workaround: dncon/upcon or dnport/upport can recover the connection from the alarm status. Hardware: AXSME-IMA
CSCdx57346	Symptom: Intercard communication is lost between PXM and AXSM cards. Conditions: User cannot access (CC) other cards in MGX2 chassis. Redundant PXM remains in init state. Workaround: None. Hardware: PXM45B
CSCdx59814	Symptom: Routed conns remain ok (no AIS) on line or card failure. Conditions: Two nodes with PXM1E-IMA cards and an frsm card each. Add one frsm port on the frsm card on each node. Add 1000 master end points terminating on frsm on Node1 and 1000 slaves end points terminating on frsm on Node2. Execute the test case FAIL_RECOVER_2 and FAIL_RECOVER_3. Some of the connections on the remote end still remain OK when they supposed to be in fail state. Workaround: None Hardware: FRSM-8T1E1
CSCdx62011	Symptom: Add imagrp to the node cause card to be in critical alarm, and when the other end imagrp is added, the active PXM1E on both nodes show card in critical alarm. Deleting all imagrp on both node, still show that the active PXM1E on both node in critical card alarm. Conditions: Active PXM1E show critical card alarms Workaround: Cause the active PXM1E to be reset (switchcc or resetcd) Hardware: PXM1E-IMA
CSCdx86863	Symptom: Low throughput for small frame size for the FRSM8T1- FRSM8T1-C ABRSTD-NIWPVC Conditions: The ABR Standard NIW PVC is configured from FRSM8T1--C on the cokemt36 to FRSM8T1-C on the emeagr36. The PVC values are CIR=1536 Kbps PIR=1536 Kbps IBS=2000 BC=65535, BE=65535. All other values are as per engineering and given below for your reference. The data-generator is connected to one of the FRSM port and other side of the FRSM port is looped. Data throughput decreases when the frame size decreases. The throughput values with different frame size is given below. FRAME SIZE THROUGHPUT 4510 Bytes 98% PIR 2000 BYTES 98% PIR 1500 BYTES 98% PIR 1000 BYTES 98% PIR 512 BYTES 97% PIR 256 BYTES 89%PIR 128 BYTES 89%PIR 64 BYTES 68%PIR Workaround: Unknown. Hardware: FRSM-8T1E1
CSCdx89271	Symptom: The RPM in slot 13 failed to load the primary config file. The RPM recovered in a standby state, with the default config as the running config. Conditions: The RPM at slot 13 has a 1.3 MB config file. The RPM are configured for 1:n redundancy, with slot 4 covering each slot. The redundant slot (4) did not have a card inserted during the node recovery from the rebuild caused by dip in voltage from the power source. Workaround: Unknown. Hardware: PXM45B
CSCdy07641	Symptom: dspcdalms and dspcdstatus 13 both shows wrong info for slot 13. Conditions: dspcdalms shows that slot 13 has -30 minor alarms and the command dspcdalms 13 specifies that it has -30 channel alarms. but slot 13 has a total of 10 channels on it which are in ok state. showed by dspcons. Workaround: Unknown. Hardware: FRSM-8T1E1
CSCdy09052	Symptom: dsphotstandby runs into infinity loop. Conditions: Do PXM switchover while dsphotstandby is in progress. Workaround: None. Hardware: PXM45
CSCdy22021	Symptom: tOam task was leaking memory in IPC buffer ids 0x10002 and 0x10003. Conditions: Unknown. Workaround: Unknown. Hardware: PXM1E
CSCdy22633	Symptom: Only on a specific node, and only on a specific slot pair, does the dspcons and dspcons -filt 4 command give syntax error usage information even though the command was correctly entered. Commands provide expected output on other slots in the node, and in the same slots in different nodes, the problem is not seen. Also there is also an error message logged for slot 11 every time the command "dspcons -filt 4" is issued, "cliCallXfunc: xFunc() Parameter validation failed non MIB-based command:". Conditions: The dspcons command with the filter option had failed due to the presence of connections on a port that did not exist. This could have been caused by two possible scenario: a) the port had disappeared off the port database, b) the connections were "dangling" connections that did not get cleaned up as part of a delete operation. Most of the clues found in the logs point to the latter. Workaround: The problem is not malignant and does not impact the normal functioning of the switch, a) It does not impact traffic, b) provisioning operation on the node should be possible, c) the port can be re-added if necessary and connections can be provisioned on the port. The only connections that cannot be re-added are those which are dangling in the database. d) The only impact of the dangling connections is that it reduces the number of connections that can be provisioned in the card. The problem can be rectified by deleting the dangling connections on the card. Hardware: AXSMB-OC3
CSCdy24461	Symptom: Spurious alarms being reported on AXSM line interface. Conditions: Unknown. Workaround: Unknown. Hardware: AXSMB-OC3
CSCdy31818	Symptom: Getting error message on RPM "% Transmit to PXM Timed out" while executing a few commands on the RPM. Show log in the RPM displays the following message: 00:01:46: rpmrscprtn: Partition VCC:part(0):cntlr(0) Out-Of-Synch (OnlyOnPXM) RPM [(slot=0 ifnum=0 part=0 cntlr=0 status=6): ingr:0 0 egr:0 0 vpi:0 0 vci:0 0 chans:0 0] PXM [(slot=0 ifnum=1 part=0 cntlr=0 status=0): ingr:0 0 egr:0 0 vpi:0 0 vci:0 0 chans:0 0] Conditions: An AXSM was inserted in place of an RPM. When the RPM was inserted back, some commands were timing out on the RPM with the error message "% Transmit to PXM Timed out" Workaround: None. Hardware: PXM45B
CSCdy35788	Symptom: LMI frames lost. It results in the LMI connection toggling. Conditions: Data Traffic is larger than OC-6 and there is more than 1000 connections in one or more ports. Workaround: LMI frames are handled by QE1210 SAR. Hardware: frsm12
CSCdy36366	Symptom: MPG SPVC cost should include cost of traversing via peer groups. Conditions: Only includes cost of higher level Hlinks, and source PG cost. Since the via peer group costs are not included, it's possible that we might not take a more optimized route during route optimization. Workaround: None. Hardware: PXM45B
CSCdy36971	Symptom: LMI failed when all ports passing DS3 rate traffic on over 1000 connections. Condition:42Mbps traffic pumped in to 1450 conns, snaked on 11 ports. Workaround: Limit the rate. Hardware:frsm12
CSCdy37018	Symptom: Discrepancy on both Vc and Cos thresholds between their configured values and those programmed on the hardware. Conditions: Having to use shell commands to view Vc and Cos thresholds. Need CLIs to display both Vc and Cos threshold values on the hardware. Workaround: None. Hardware: frsm12
CSCdy37437	Symptom: The egress OAM keep alive cells for a voice channel do not get enough bandwidth in the egress direction on an IMA port and as a result the voice PVC goes down. Conditions: There is enough data traffic to starve the egress OAM queue. Workaround: None. Hardware: AUSM-8T1E1
CSCdy37445	Symptom: IPC memory leaks were observed. In IPC buffer id 0x10002 the owner task "0x200bf" called: - CpiToAppCreateMsg+0xac - ssiIpcBufferCopy+0x6c. In IPC buffer id 0x10005 the owner task "0x200bf" called: - CpiToAppCreateMsg+0xac - ssiIpcBufferCopy+0x6c Conditions: On a PXM1E node that has been idle for more than 6+ hours. Workaround: Unknown. Hardware: PXM1E
CSCdy37451	Symptom: IPC memory leaks were observed. In IPC buffer id 0x10002 the owner task "0x100a6" called: - smtermd+0xbcc. In IPC buffer id 0x10003 the owner task "0x100a6" called: - smtermd+0xbcc Conditions: On the standby cd of a PXM1E node that has been idle for more than 6+ hours. Workaround: Unknown. Hardware: PXM1E
CSCdy39198	Symptom: Doesn't set up additional parameter (other than mandatory parameters) during APS Line addition. Conditions: During APS Line addition through SNMP, send additional parameters (like APS direction). Workaround: None. Hardware:AXSM1
CSCdy40247	Symptom: OC48B is in Active-F. Conditions: Unknown. Workaround: None. Hardware: axsm2b_oc48
CSCdy42188	Symptom: ISR memory leak in IPC buffer 0x10002 & 0x10003 in Pxm1e combo node. Conditions: Node is idle. Workaround: Unknown. Hardware: PXM1E
CSCdy42253	Symptom: SVCs are being reported differently from 2 different CLI outputs (dsppnport & dspport). dsppnport shows the correct number of SVCs and dspport shows control SVCs also Conditions: When the dspport command is executed on the AXSM-E, and dsppnport is executed on the PXM. Workaround: None. Hardware: frsm12
CSCdy43338	Symptom: After power cycle standby FRSM-VHS card resets twice Conditions: Configure 1:1 redundancy between two VHS cards. Keep the configurations on the primary active card. Do power cycle. Workaround: None. Hardware: frsm-vhs
CSCdy44390	Symptom: Switch dsplncnt for AXSME does not match FTP file on CWM. Conditions: AXSME_8OC3 card, checking INGRESS CLP0/1 Line Count Workaround: Unknown. Hardware: AXSME
CSCdy44965	Symptom: All AXSMEs failed in the shelf due to Max Card Reset reached. Conditions: Due to PXM45B resetting in slot #7 for no known reason. Workaround: None. Hardware: PXM45B
CSCdy46964	Symptom: tstpndelay does not work Conditions: When tstpndelay is issued for a SVC endpoint Workaround: None. Hardware: pxm1
CSCdy50998	Symptom: By doing setrev/resetcd for both the cards, active card on the remote gets reset. Conditions: Having all the lines configured for APS. This is applicable only for OC3. Description. This is fixed, however after doing the testing of our fix we have found that, if all the lines are unidirectional then problem does not exist. If the lines have bidirectional APS and in particular if the last line i.e. 2.8 is configured for APS then the problem persists. If we have 15 APS lines irrespective of Uni/Bi then our fix works. Only problem we have with the last line with bidirectional APS on other lines. Workaround: Unknown. Hardware: AXSMB-OC3
CSCdy51734	Symptom: Standby PXM went to empty state as seen in dspcds or dspcd. Conditions: None. Workaround: Issue resetcd on the standby PXM. Hardware: PXM45B
CSCdy51843	Symptom: CBC clocking affected on active and standby PXM1Es does not switch over to standby. Conditions: Fault was inserted on standby card 8 and it is never detected by the active card. Upon forced switch over, the standby did not take over and all the SM's were reset and never came back up. If you insert a card with CBC clocking affected in the standby slot, it is not detected. In this situation we may have a faulty standby card just sitting in the node. Workaround: Unknown. Hardware: PXM1E
CSCdy51865	Symptom: FI: ATMizer SAR SDRAM data bus corruption & ATMizerII SAR chip disable on active - does not switch over to standby Conditions: FI: ATMizer SAR SDRAM data bus corruption & ATMizerII SAR chip disable on active - does not switch over to standby. Both cards in ready state. When fault inserted on active it does not switch over to standby. All PNNI links go down, connections in fail state. Data traffic stops. Standby card resets after some time. Workaround: Unknown. Hardware: PXM1E
CSCdy52131	Symptom: FI: reset/failure on PXM1E is reported incorrectly in error log and reset type & error is not logged. Conditions: When we insert the QE0 reset (test 4a) fault. The log does not show reset type and error reason. FI card is in slot 8. When we insert reset QE1 (test 4b) fault on PXM1E. The failure and reset reason is not reported in the log correctly. The FI card is in slot 8 Workaround: Unknown. Hardware: PXM1E
CSCdy53083	Symptom: Core dump on slot #14, AXSM OC12 Conditions: Following a switchcc script running for about 3 days. Workaround: None. Hardware: axsm1b_oc12
CSCdy53476	Symptom: All service modules and standby PXM in the node reset/boot continuously. Conditions: Unknown failure of the standby PXM. Workaround: Remove the standby PXM and reset the active PXM. Hardware: PXM45B
CSCdy54351	Symptom: Slave end persistent SPVC mismatch on frame_discard field between ram and disk; i.e., disk shows for this connection frame_discard is OFF, but ram shows it is ON. Conditions: A routed persistent SPVC, where master end has frame_discard turned on. Then slave end persistent SPVC will have frame_discard field mismatch between ram and disk. Workaround: There are 2 ways to workaround: 1) From line card CLI, do upcon/dncon, or cnfcon for the given connection. 2) Switchcc from controller card. This will only fix the first 10 mismatched SPVC connections. Hardware: PXM45B
CSCdy55759	Symptom: Executed command "memshow ?" on PXM45 sw revision 2.1(80.0) and console stopped responding to commands. Conditions: Command "memshow ?" on active PXM45 sw rev 2.2(80.0) caused the console to hang. Workaround: No workaround at this time. Do not execute the command. Hardware: PXM45B
CSCdy56415	Symptom: dspdiagerr doesn't update failure message Conditions: When online diag running on active & standby PXMs and if the test fail on active PXM then the PXM switchover and dspdiagerr record the message and test will continue on the new standby PXM. But after the another test failed on the newly standby PXM, dspdiagerr removed the previous message and did not update with new failure message. Workaround: Unknown. Hardware: PXM1E
CSCdy58998	Symptom: The AXSME available rate shows only 1. Conditions: sh control VSI descriptor on LSC controllers Workaround: None. Hardware: PXM45
CSCdy59180	Symptom: Once it was observed that 4 SPVC failed to route. This failure was due to slave state of the connections were in wrong state. Conditions: When large number (250k) of SPVC rerouted. Workaround: None. Hardware: PXM45B
CSCdy60873	Symptom: After resetting the RPM-XF card, it went to fail state. Conditions: It happens mostly in the following condition. a) When the ssi chunk pool free pattern was set. (from shellconn, ssiChunkPoolsFillFreePatternSet 1 will enable this) b) run ipcMblkShow to see whether this pattern is set or not:If u see "x" in the first column of "FGESSIX...", then this is the case. pxm45>ipcMblkShow ipcMblkShow IPC buffer memory data:----------------------- Buffer area start: 0xe500000 Buffer area size: 27197440 Free buffer memory:3133024 Total buffers: 9600 Total mblks: 10100 Floating mblks: 500 Alloc/Free Statistics:---------------------- Buffers: AllocOk 266766, AllocErr 0, FreeOk 284099, FreeErr 0 Floating Mblks:AllocOk 17565, AllocErr 0, Lwm 462 data nb nb high nb alloc nb free cr iv rc FGESSIX id size chunk free wtMrk ok/fl ok/fl pt pa ev PSVHCSH name ----- ---- ----- ----- ----- -------- -- -------- -- -- -- -- ------- ---- 10002 32 10100 9868 426 284331 0 284099 0 0 0! 0 x.xa.xx IPC:Mblks 10003 376 5000 5000 176 202044 0 202044 0 0 0 0 x.xaxxx IPC:Buf_360 10004 1144 2000 2000 11 28069 0 28069 0 0 0 0 x.xaxxx IPC:Buf_1128 10005 4216 600 600 73 6237 0 6237 0 0 0 0 x.xaxxx IPC:Buf_4200 10006 8568 2000 1768 279 30416 0 30184 0 0 0 0 x.xaxxx IPC:Buf_8552 value = 0 = 0x0 Workaround:Reset the ssiChunk Pool Free pattern set (if it is enabled already). Do "ssiChunkPoolsFillFreePatternSet 0" to reset this option. Hardware:PXM45B
CSCdy61355	Symptom: XBAR alarms present on the new PXM45b Conditions: After running the sysFlashBootBurn command to upgrade the shelf. Workaround: None. Hardware:PXM45B
CSCdy61622	Symptom:1) All AXSM/AXSM-E cards without redundancy go to Active-F state 2) All AXSM/AXSM-E cards with redundancy switched over. The AXSM-E cards will switch back and forth between the redundant pair. Condition: If the active PXM tries to reset the standby PXM and the reset does not go through and it is put to FAILED state. Workaround: Remove the standby PXM which has been put to failed state. Hardware:PXM45B
CSCdy62916	Symptom: AXSM card in Active-F state as seen with dspcds or dspcd. The dsplog -sl for the failed slot will have a log signature similar to the following (slot 14 in this example): 14A00478 09/12/2002-23:58:06 SHMA-7-NFATAL_MAJ_ERPT E:00240 tCpro shmLocalCdNonFatalMajor shmLocalCdNonFatalMajorErrReport: AppId 0x10007, tId 0x1003c, tName tCpro , Ref. pslot 14, callerPc 0x80328e44, evtNum 0x3034 14A00477 09/12/2002-23:58:06 CPRO-4-RAMDISK_ERR tCpro cProWriteRamDisk RamDisk error : Fopen with lock failed; errno=133896 Conditions: None. Workaround: None. Hardware: PXM45B
CSCdy63336	Symptom: pnRedMan task is leaking memory in IPC pool 0x10002 and 0x10006 in a PXM1E. Conditions: One possible way to cause this IPC leak is that there are some plug-and-play ports on a given slot A (i.e., the port shows up on controller when slot A is active, but disappears when the slot is reset or pulled out), and the slot A is reset/pulled out for a short time. Workaround: To avoid above condition, make those ports persistent, by dnpnort/cnfpnportsig, etc. Hardware: PXM1E
CSCdy64831	Symptom: When a burnboot command is executed for a NBSM, the NBSM resets. Conditions: On execution the CLI command "burnboot <slot> <fw>" on any NBSMs like FRSM-8T1, VISM-8T1 and so on, the NBSM burns the boot to the flash and resets. This causes the NBSM to come up with the newly burnt boot image Workaround: This is as per the current design. On a burnboot, we expect the card to reset and come up with the new boot version. The boot upgrade should be done in the customer's maintenance window. Hardware: PXM1E
CSCdy65143	Symptom: Executing a dspcon on the PXM45b with an invalid VCI is displaying a connection with a different VCI and other invalid attributes. Conditions: Executing dspcon with an invalid VCI to display the connection. Workaround: None. Hardware: PXM45B
CSCdy68455	Symptom: Traffic was totally stopped on a XF redundancy setup. Conditions: A simultaneous switchcc and a XF switchover (physically pulling out the active card) was done on the node. Workaround: None. Hardware: PXM45
CSCdy69200	Symptom: Clock signals are not available after APS switch. Condition: If APS lines are switched from working line to protection line on the primary card, clock source for that line becomes unlockable. Basically in APS setup, if the local line is not available (LOS/LOF), clock signals obtained are of range. Clock signals should always be derived from the active line (Working or Protection). Workaround: Unknown. Hardware: AXSME
CSCdy69205	Symptom: Clock signals not available after APS switch Condition: If APS lines are switched from working line to protection line on the primary card, clock source for that line becomes unlockable. Basically in APS setup, if the local line is not available (LOS/LOF), clock signals obtained are of range. Clock signals should always be derived from the active line (Working or Protection). Workaround: Unknown. Hardware:AXSMB-OC3
CSCdy69231	Symptom: Standby PXM1E combo CC dropped into idtmon while loading runtime image in backup boot. Conditions: Power cycle Workaround: Unknown. Hardware: PXM1E
CSCdy69719	Symptom: ATMizer failure not handled in active PXM45B. Condition: When dip switch for fault insertion is turned on spl active HFIT pxm45B board. Workaround:The fault is detected by standby PXM45B. On active card, there is no workaround. Hardware:PXM45B
CSCdy70165	Symptom: Standby CC's active clock (primary clock) got re-qualified and it latched onto the secondary clock while active CC's clock remained primary and it never got re-qualified. Conditions: remove the standby CC's tBC Workaround: Unknown. Hardware: PXM1E
CSCdy70426	Symptom: 1. The bypasses are not ordered by AvCR. This means that bypasses with smaller bandwidth can be advertised ahead of ones with more bandwidth. However in most cases, the bypasses are advertised as full-meshed instead of spanning tree, so that the ordering of bypasses wouldn't matter, since all the bypasses are advertised. 2. The routing cost is not calculated correctly for via peer groups that are configured as complex nodes. This could affect finding an optimized route in MPG network. Conditions: The complex node that is turned on a node with a lot of bypasses Workaround: None. Hardware: PXM45B
CSCdy70541	Symptom: Primary clock status is lockable but still the active clock is internal clock... Conditions: The primary clock was configured from trunk 7:2.2:22 and it was active. The secondary clock was configured from trunk 7:2.11:11 and was in bad state because of no clock signal. To clear this problem from secondary clock the "cnfclksrc secondary 7:2.9:29" command was executed. The trunk 7:2.9:29 was an active trunk with PNNI-link established both ways. After executing this command the active clock status became from "internal clock" even though the primary clock is still in locked state. Also, the secondary clock is still shown as 7:2.11:11 instead of 7:2.9:29. Moreover, the status of secondary clock has became "UNKNOWN" Workaround: Port 2.11:11 is oper down. Bring it up active (either by loopback or physical cable) delclksrc secondary configure new clock source. Hardware: PXM1E
CSCdy70780	Symptom: There is no AXSME port ingress counter. This is creating a problem when using AXSME double density card. Conditions: dspportcnt does not provide an ingress counters. Workaround: Ingress counters are not provided with this version of software. They will be provided in the next release. Hardware: AXSME
CSCdy71223	Symptom: LOA yields inconsistent active clock state in 2 PXM1E nodes. Conditions: Create an LOA on 2 PXM1E nodes. Workaround: Unknown. Hardware: PXM1E
CSCdy71636	Symptom: The customer sees traffic stop in one direction spontaneously. Conditions: It happens spontaneously on an FRSM 8T1E1 card on a MGX1 shelf. MGX1 shelf is a feeder to an MGX 2 shelf. Workaround: Using CWM reconfigure the CIR of the connection or delete and re add the PVC. Hardware: PXM1E
CSCdy71720	Symptom: AXSM card switched to the redundant card then reset. Conditions: When the modified PXM jumper was pulled to simulate a 3.3V power converter failure. Workaround: None. Hardware: axsm1b_oc12
CSCdy72288	Symptom: dsptotals on AXSM-E card works differently from the specification. According to MGX 8850 Command Reference. Condition: CLI: dsptotals MGX 8850: commreference Workaround: None. Hardware: AXSME
CSCdy72444	Symptom: Statistical alarm does not clear after 24 hours Conditions: Line 2.3 went into statistical alarm. the line 2.3 went into major alarm and never cleared out of it. cnfalm -ds3 2.3 -dsev (major) was set. After 24 hours alarm should have cleared. Workaround: Unknown. Hardware: PXM1E
CSCdy72688	Symptom: When 'dspdiagstat', counters not updated on FRSM-12-T3E3. Conditions: Enable online diagnostics. Workaround: Unknown. Hardware:PXM45
CSCdy72711	Symptom: AXSM port (with APS) went down after runrev was executed on AXSM. Conditions: One of the APS lines was in SF. Workaround: Unknown. Hardware: axsm1b_oc12
CSCdy72726	Symptom: AXSM-E cards kept switching over, and transitional from boot/init/active/active-f. Condition:3.3V power supply chip failure was simulated on standby PXM. Workaround: Unknown. Hardware: AXSME
CSCdy73536	Symptom: dspapslns did not indicate SF condition for Working line that had been disconnected. Conditions: Rx of Working line had been pulled out. Workaround: Unknown. Hardware: axsm1b_oc12
CSCdy73577	Symptom: Oam_conn_upoamerr: failed reading ATLAS for connection status. Conditions: After multiple switchcc. Workaround: None. Hardware: PXM1E
CSCdy73583	Symptom: The clock has failed and is stuck in "clock set Nak" state. the clock frequency samples detected by the PXM1E are compliant and good. Conditions: 1. do a switchcc from 7->8, 2. do a switchredcd from 30->28 Workaround: Unknown. Hardware: PXM1E
CSCdy73683	Symptom: New connection across MPG stay in failed state. Conditions: Added few new connections across MPG. The connection stayed in failed state for 15+ minutes. The connections were in CTRLR-ABIT alarm but eventually came up OK. PXM1E node is acting as a PGL for the network. Last fail cause does not specify the error. Workaround: Unknown. Hardware: PXM1E
CSCdy73727	Symptom: VISM SVC call setups fail. Condition: Failure occurred after provisioning greater than 10 SVC(s) per second for more than 48 hours Workaround: None. Hardware: PXM45
CSCdy73728	Symptom: Some AXSM cards in a node were running default SCTs. Conditions: System had gone through a reset Workaround: Unknown. Hardware: AXSMB-OC3
CSCdy74714	Symptom: Runaway task logged in dsplog after cntl c was issued. Condition: The cntl c was issued to halt the dumpconfig command which was part of a script that was running on the shelf. Workaround: None. Hardware:PXM45B
CSCdy75753	Symptom: After burnboot when the card came up it still had old version. Condition: After executing burnboot on PXM1E the card reset and came up with old release. After doing it several times card did finally upgrade. Workaround: Use old way, sysFlashBootBurn. Hardware:PXM1E
CSCdy77458	Symptom: Interface port information pointer messages seen in the dsplog. Condition: During an upgrade or after a switchredcd is executed. Workaround: None. Hardware:PXM45B
CSCdy77599	Symptom: switchredcd 19 29 is not working. getting message of CLI internal error. Condition: Customer executed switchredcd 19 29, got error message of CLI internal error and card did not switch. These are the steps leading up to issue: customer upgraded from 3.0.10.176-a to 3.0.10.187-a, waited about 1 hour, did a switchcc, then did a switchredcd 19 29. Workaround: Unknown. Hardware:PXM1E
CSCdy79315	Symptom: Unknown control command in output of command execution. Condition: When the command dspsesn is executed via the CLI. Workaround: None. Hardware:PXM45B
CSCdy80802	Symptom: SRME E1-distribution is not working in AU-4 trib grouping. Condition: The user is seeing alarms on VISM-PR E1 lines after adding links from TUG3 #2 and #3 groups. Also RDV-V alarm is received in TUG3 #2, #2 group links. The RDI-V alarm is observed on the external Mux (OPM STM1). Workaround: None. Hardware:PXM45B
CSCdy80871	Symptom: SRME E1-distribution is not working in AU-4 trib grouping. Condition: The user is seeing alarms on VISM-PR E1 lines after adding links from TUG3 #2 and #3 groups. Also RDV-V alarm is received in TUG3 #2, #2 group links. The RDI-V alarm is observed on the external Mux (OPM STM1). Workaround: None. Hardware:PXM1E
CSCdy80912	Symptom:PXM45 card got reset 2+ times. Conditions: Reset AXSM cards, then standby PXM45, then active PXM. Workaround: None. Hardware:PXM45B
CSCdy81725	Symptom: The trap 60105 not create when the SONET line alarm cleared (PXM1E). Conditions: Interim 3.0.10 release. Workaround: None. Hardware:PXM1E
CSCdy82093	Symptom: cnfln on ds3 AXSM card cause tlb load exception. Conditions: Execute the command cnfln. Workaround: Unknown. Hardware:AXSM1
CSCdy83276	Symptom:Owner task tMAhandler did not free the memory (free/alloc caller :SarMgmIpcRxBufRet+0xd8. Conditions: Unknown. Workaround: Unknown. Hardware:PXM45B
CSCin15276	Symptom: DB is getting wrongly populated for targer_line_frm in line distribution table. Conditions: Add SRM links. Workaround: None. Hardware: PXM1E
CSCin15832	Symptom: Wrong port bit map populated in database for FRSM card. Conditions: Create a port on FRSM 8E1 card Workaround: Use CLI Hardware: FRSM-8T1E1
CSCin17591	Symptom: Admin_state should be populated at the time of config upload for RPM-PR sub interfaces. Conditions: Create SubIf's on RPM_PR card and do a cold start of CWM. Workaround: See CLI for admin state. Hardware: PXM1E
CSCin19333	Symptom: SNMP requests time out. Condition: This happens only when the SNMP request is for a RPM-XF card and usually when the card has just come up. Workaround: None. Hardware:PXM45

Table 40 lists the Severity 3 open caveats for the MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.10 software.

Table 40 Severity 3 Open Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 3.0.10 Software 

DDTs Issue	Description
CSCdu26141	Symptom: SHM-4_DB_REQ_FAIL messages are logged at severity 4 in the event log. The log entries will look similar to the following: 08-00323 05/15/2001-00:51:31 SHM_-4-DB_REQ_FAIL shmDiskHdl 0x803276b4 SHM ERR: Database request on slot 8 failed, db = rslot, in Conditions: Consecutive resetcd were executed on the PXMs in this node. This log can be seen under 2 conditions: 1. Under the normal operation of the PXM if this is logged, it is a problem with the communication between 2 tasks that needs to be investigated. 2. During any form of shelf reset like resetsys, abortrev, setrev etc. If this log is seen at around the time a shelf reset is happening, it is not a problem if this log is seen. This will not have any impact at all on the state of the shelf or the state of the configuration on the shelf. Workaround: None. Hardware: PXM45
CSCdu27030	Symptom: OAM CC Activation Cell correlation tag is incorrectly modified. Conditions: User notes that an F4-Seg Active-CC OAM cell with a correlation tag of 0x6A is returned to the sending device with a correlation tag of 0x00. Workaround: None. Hardware: AXSM1
CSCdv50574	Symptom: Incorrect usage statement generated. Conditions: When the delapsln CLI command is executed. Workaround: None. Hardware: AXSM1
CSCdv69323	Symptom: Shelf sends too many messages to CWM. Conditions: After the execution of switchredcd on the shelf. Workaround: None. Hardware: PXM45
CSCdx34833	Symptom: Popup message seen on the CLI display. Conditions: While the shelf was idle and no CLI command where being executed. Workaround: None. Hardware: PXM45B
CSCdx62800	Symptom: MGX45 CLI Reference Manual needs updated. Conditions: 4 new commands missing out of the manual. Workaround: None. Hardware: PXM45B
CSCdx81165	Symptom: Slot 11 does not send out AIS for DAX or Non-DAX SPVCs. Conditions: When slot #11 is the active slot Workaround: None. Hardware: AXSMB-OC3
CSCdx82847	Symptom: line status LED's on standby PXM1E always show green Conditions: The line status LED on standby PXM-1E always show green even if the line is in LOS. This is inconsistence with other LEDs on PXM-1E. e.g. the ALARMs LEDs on the standby PXM remain OFF. We think that the line status LED either reflect same as of active PXM or they remained OFF as of alarm LED. (On PXM-1 they remain OFF on standby PXM) Workaround: None. Hardware: PXM1E
CSCdy09657	Symptom: dspdiagstatus does not display the state and role of SM's; It displays the info only for the PXM1E and SRM cards. Conditions: PXM1E dspdiagstatus command does not display the state and role of SM's where as same command displays the state and role in MGX-45. In case of a PXM1E node, the role and state info for SMs should say N.A (or something similar to indicate that NBSMs status is not displayed by this command) Workaround: None yet. Currently, "Idle/Unknown" is the role/state combination that is used to indicate that diags status does not apply to SMs. This will be changed soon. Hardware: PXM1E
CSCdy10115	Symptom: Spurious event log messages for environmental alarms for DC supply are logged. Conditions: Unknown. Workaround: None. Hardware: PXM45
CSCdy10480	Symptom: Default 0 SCT is not shown for FRSM-12-T3E3. Conditions: Execute dspscts/ Workaround: The system will allow the user to configure port and card level SCTs even though the display does not show it. Hardware: PXM45
CSCdy16930	Symptom: addpart command is inconsistent when entering parameters. Conditions: addparts commands takes hex values for some fields, for example if a value 3a is given for the field min VCI it would take that value and show as 58 which is decimal for 3a. Customer expects that a error message would pop up. Workaround: Unknown. Hardware: PXM1E
CSCdy23797	Symptom: pntrace commands not completely documented. Conditions: MGX CLI Manual versus the troubleshooting guide. Workaround: None. Hardware: PXM45B
CSCdy24232	Symptom: dsplog indicates that a card does not exist. The log will look similar to the following (card 1 in this example): 01460 07/31/2002-18:32:10 SCM-4-NODEST tSCM scmProcDataMsg Card 1 doesn't exist, 105 21 Conditions: After a switchcc is executed. Workaround: None. Not service impacting. Hardware: PXM45B
CSCdy25518	Symptom: Switchapsln command can be executed on PXM-45 even though command has no relevance to hardware configuration. No error message is given. Conditions: Switchapsln can be executed from PXM-45 without user feedback indicating that command is not applicable to hardware configuration. Workaround: Unknown. Hardware: PXM45
CSCdy29344	Symptom: The back card removal trap does not contain the back card number. User can not make out which back card is removed. Conditions: When a back card is removed, trap 60059 will be sent. Workaround: Look at the dspcd output to find which back card is removed (depending upon the back card status). Hardware: PXM45B
CSCdy36692	Symptom: Need warning messages for cnfport Conditions: Customer wants warning messages to inform your about to change cnfport. Workaround: Unknown. Hardware: PXM1E
CSCdy37182	Symptom: dspcd shows lower back card empty for a full height back card. Conditions: None Workaround: None. Not service impacting. Display issue. Hardware: all
CSCdy41895	Symptom: 'dspportsct vcThr' should match with the one shows on 'dspportsct qeVcThr' But the VSI_Signal values shown from SCT does not match to the actual hardware value. Conditions: dspportsct vcThr & dspportsct qeVcThr Workaround: This is a display problem. The VSI_Signal VC Threshold values being display from the dspportsct or dspcdsct command is incorrect. Basically the AXSME software ignores the VC Threshold values being specified in SCT. Instead, the AXSME software would program a lower pre-defined threshold values for the VSI signal channels. So the values in the hardware are correct. Please ignore the VSI_signal values from the SCT. The lower pre-defined is needed because we want to limit our traffic flow on the VSI signaling channels prevent flooding the PXM45. If the PXM45 is flooded, then there will be some unpredictable and unreliable behaviors on PXM45. We are going to fix the display problem. Hardware: AXSME
CSCdy42250	Symptom: A difference exits between the checksum on the switch software distributed AXSME_SCT.PORT.53.V1 and the same AXSME_SCT.PORT.53.V1 after it has been uploaded and re-downloaded to the same switch using the SCT download. Conditions: SCT file has been upload and re-downloaded to the same switch using the SCT download from CWM. Workaround: First load the distributed SCT on the switch with addsct command. Once CWM and the SCT manager has detected the SCT. Remove the distributed SCT from the switch using the delsct command. Now the SCT can be load to all nodes requiring this SCT with the SCT download via from CWM. Most importantly there is nothing different between the two SCT files with respect to card parameter. The difference with the SCT files is in the SCT IDs in this case the 53 number. In the SCT manager it is recorded as 53 on the distribution SCT file it's recorded internally as 1. The CWM SCT is correct. Both will work. Hardware: frsm12
CSCdy42620	Symptom: Danglers remain after using the CLI command delcons. This is the caveat with these commands. While provisioning connections in bulk (copycons/delcons), if the PNNI layer get busy due to re-route/de-route activity, then it will reject the deletion. Conditions: The command delcons was developed for Dev-test usage only. This command is not recommended to be used on a production node due to resource problems generated by the flood of traps on each con deletion. Workaround: Use delcon for each individual PVC until a better method is developed see PXM release notes for description of CLI commands delcon and delcons usage. Hardware: frsm12
CSCdy43404	Symptom: Card alarm is not properly counted when using dspcdalms Conditions: dspcdalms shows that slot 32 has one major and one minor alarm but up on troubleshooting found that there is only one major LOS alarm on line 31.1 and no minor alarms. But in the alarm it's displaying a minor alarm too. dspcdalms shows the same for slot 15. Workaround: Unknown. Hardware: PXM1E
CSCdy46972	Symptom: Adding APS lines on the down lines does not show the correct error message. Conditions: Adding APS lines on the down lines does not show the correct error message. It shows as ERR:APS not allowed:wrong card type On MGX-45 it shows the correct error as ERR: working line must be up Workaround: Unknown. Hardware: PXM1E
CSCdy46993	Symptom: APS command "clradjlnalmcnt" does not show the command option clearly Conditions: emeanw36.8.PXM.a > clradjlnalmcnt 2.9 clradjlnalmcnt "<X.line>". It is not successful in the above format. But it also has another option as given below and it is successfully taking the command in that option. PXM.a > clradjlnalmcnt clradjlnalmcnt -<lineType> "<slot.line>". PXM.a > clradjlnalmcnt -sonet 2.9. Note: In MGX-45, it has only one option and it is successful. AXSM.a > clradjlnalmcnt clradjlnalmcnt "<bay.line>". AXSM.a > clradjlnalmcnt 1.3 AXSM.a > clradjlnalmcnt 1 clradjlnalmcnt "<bay.line>" AXSM.a > Workaround: Unknown. Hardware: PXM1E
CSCdy49757	Symptom: AUSM channel, port and SAR counters do not correctly count RM cells received from CPE Conditions: The AUSM channel, port and SAR counters do not correctly handle RM cells when they are generated by the CPE (test-set). When RM cells are received by the AUSM card the baseline behavior is that they should be discarded by the UNI port. Indeed that is what is noted to happen for AUSM on PXM1E. The command dspconload shows that no traffic is received from the AUSM when a stream of RM cells at 480 cps is generated by the test-set: Workaround: Unknown. Hardware: AUSM-8T1E1
CSCdy53146	Symptom: S1 byte for Synchronization Status Messaging not implemented properly. Conditions: On the AXSMB/OC12, and the AXSMB/STM1 Workaround: None. Hardware: axsm1b_oc12
CSCdy54607	Symptom: PXM command line interface paused indefinitely and would no longer accept commands Conditions: Occurred after executing the memshow<noCmdBold) command from the command line interface Workaround: None. Hardware: PXM45
CSCdy55782	Symptom: No consistency in the warning message for invalid login attempts. Conditions: When attempting to login to the shelf with incorrect User ID and password. Workaround: None. Hardware: PXM45B
CSCdy59294	Symptom: AUSM/PXM1e transmits invalid PTI=7 cells into network but cannot pass traffic out of far-end AUSM port. Conditions: An abr1 PVC was provisioned between two AUSM-IMA ports: [Test Set A] <---> emeagr36.1.1.300 to emeanw36.27.1.1.300 <---> [Test Set B]. Test set A generated 480 CPS of ATM cells with the PTI field set to 7 (invalid). The payload consisted of 48 byte 6A pattern. The channel, port and SAR counters on gr36 indicate that traffic is being sent into the network. On the PXM1e card on gr36 the "dspconload" command indicates that all the PTI=7 traffic is sent out the trunk interface. In fact there seems to be RM cell overhead in both directions. The "dspconload" command on emeanw36 indicates that all PTI=7 traffic is being received on the trunk interface. However on the AUSM port on NW36 the channel, port and SAR counters all remain at zero. It is very strange that the AUSM card handles PTI=7 cells differently on the Ingress and Egress directions. At one time the PVC was able to transmit PTI=7 cells end to end but it has only been observed to happen once. Workaround: Unknown. Hardware: AUSM-8T1E1
CSCdy59858	Symptom: Using inband management, not able to ping pxm1 feeders atm0 address when the PXM45's lnPci0 and atm0 subnet masks are different. The trigger is the deletion of the internal SVC between the AXSM and the PXM. Can be reproduced by doing a dnport/upport on the AXSM port which connects to the management router in the setup shown below: CWM station---ethernet---Router with ATM oc3 interface-----AXSM------PXM45-----AXSM-----PXM1 Conditions: Observed on MGX 8850 PXM45 running 2.1.75 Workaround: The problem is in the VxWorks routing table on the PXM45. The IP data to pxm1 first has to traverse PXM45 where it is switched to the AXSM connecting to the pxm1. 1. Switchcc on the PXM45 clears this condition. 2. Making PXM45 re-learn the route to pxm1 clears this issue. This can be done by initiating a telnet from PXM45 CLI to pxm1. Hardware: PXM45B
CSCdy59923	Symptom: Mounting nfs is not necessary, takes time and resources and can cause conflicts when nfs host is the same as another device. Conditions: Nfs host is mounted when coming up. Workaround: None. Hardware: PXM45B
CSCdy59933	Symptom: Attempt to low level format with diskFormat and ataFormat fails on PXM-HD with the following error: pxm45bkup>diskFormat "C:" IDE: format in progress. This takes a while .........Device abort error .... status is 51 error is 10 Couldn't format "C:". value = -1 = 0xffffffff pxm45bkup> Conditions: This condition is observed in 2.1 Release when the PXM-HD model is IC25N020ATCS04-0 or IBM-DJSA-205. The HDD model name can be viewed with the command ataShow. cmdBold>More Information: A low level format is not required in the field as these drives come preformatted from manufacturing. Using sysClrallcnf and recreating the file system with sysDiskCfgCreate will help to reinitialize a PXM-HD in the field. Workaround: None. Hardware: PXM45
CSCdy62765	Symptom: Standby PXM reset. The dsplog will look similar to the following example (slot 8 is active, 7 is standby in this example):08A98502 09/05/2002-16:48:56 SHMA-7-FATAL_ERR_RPT E:00317 pnRedman shmRamSyncFatalErrRepor shmRamSyncFatalErrReport:AppId 0x1000c, tId 0x10054, tName pnRedman , Ref. pslot 7, callerPc 0x807c68e8, evtNum 0x1000 08A98509 09/05/2002-16:48:56 REDM-6-RmRamDbReset pnRedman checkSyncRamResetState Redman receive reset from RAMDB. Reset reason:-2 Note that the AppId, tId, tName could be any application on the node. Conditions: A RAM sync error triggered the standby PXM reset. Workaround: None. The standby PXM returned to service following the reset. Hardware:PXM45
CSCdy64715	Symptom: ataFormat() fails. Conditions: When using IBM-DJSA-205 disks (Gb). Workaround: For 3.0.x, use ataFormat_20GBversion(). For 2.1.x, there is no workaround. Hardware:PXM45
CSCdy64834	Symptom: Possible loss of configuration. Conditions: Non-native standby PXM disk is inserted and before the card could come up to standby state, the active PXM resets. Workaround: None. Hardware:PXM1E
CSCdy64846	Symptom: Non-native PXM comes up as active with no databases Conditions: When native active PXM (with configuration/databases) has a hardware failure in a node with single PXM and a non-native PXM is inserted Workaround: None. Hardware: PXM1E
CSCdy64892	Symptom: The error message "CPRO-SNMP_ERROR cutW1Task cpro_log_error SNMP error; id = 117; err Connection does not exist in cPro db" appears. Conditions:MGX45, Version 2.1(80.0) Workaround: None. Hardware:PXM45
CSCdy65252	Symptom: Once clock is unlockable it needs to be reconfigured. Conditions: On PXM1E when line clock is configured and for some reason if it goes unlockable it need to be deleted and reconfigured even if the problems with line gets clear. For example, if a line configured as clock is an OC3 line and this line is config. for APS. In this case when primary card is active with both APS in okay state and if there is LOS on the working line the clock will go in unlockable state. Upon removing LOS from this line doesn't clear unlockable situation from the clock Workaround: Unknown. Hardware: PXM1E
CSCdy66033	Symptom: Connections fails and doesn't route Conditions: MGX 8830, MGX 8850 Workaround: Under investigation Hardware: PXM1E
CSCdy67817	Symptom: PNNI ports went into down in progress state and SPVCs failed during fault insertion testing. Conditions: Skystone Port 1 secondary in reset (SWC6) and (SWC5) faults were inserted on an active AXSM card. Workaround: Unknown. Hardware: AXSMB-OC3
CSCdy70165	Symptom: Standby CC's active clock (primary clock) got re-qualified and it latched onto the secondary clock while active CC's clock remained primary and it never got re-qualified. Conditions: remove the standby CC's tBC Workaround: Unknown. Hardware: PXM1E
CSCdy71223	Symptom: LOA yields inconsistent active clock state in 2 PXM1E nodes. Conditions: Create an LOA on 2 PXM1E nodes. Workaround: Unknown. Hardware: PXM1E
CSCdy72707	Symptom:1) All AXSM/AXSM-E cards without redundancy go to Active-F state 2) All AXSM/AXSM-E cards with redundancy switched over. The AXSM-E cards will switch back and forth between the redundant pair. Condition: If the Active PXM tries to reset the standby PXM and the reset does not go through and it is put to FAILED state. Workaround: Remove the standby PXM which has been put to failed state. Hardware:PXM45
CSCdy73100	Symptom: Misspelled word in the syntax of the cnfpnni-node output. Conditions: When viewing the output, the word does is spelled deso. Workaround: None. Hardware: PXM45B
CSCdy78372	Symptom: Card with Skystone failure came up as active-f and healthy card came up as failed. Condition: Resetsys was executed with fault present. Workaround: Unknown. Hardware:AXSMB-OC3
CSCdy78398	Symptom: SAR errors not detected by SCM till 3 min. Condition: Tests consisting of SAR single bit errors were executed on active and standby AXMS cards. Workaround: Unknown. Hardware:AXSMB-OC3
CSCdy81403	Symptom: When there is los on secondary clock the primary clock's status becomes bad. Condition: The primary clock is configured from trunk 7:2.9:29 and secondary clock is configured from 7:2.4:24. The secondary clock was active and primary clock was going through qualification state. At this time we created LOS on secondary clock, which is trunk 7:2.9:29. This made no clock signal status on secondary clock and also on primary clock. The primary clock stayed in this state for few seconds even though there was no LOS on it's trunk. After few seconds later the primary clock again went through the requalification and became active. Workaround: Unknown. Hardware:PXM1E
CSCdy82174	Symptom: PNNI ports went into down in progress and SPVCs failed. Condition: Customer was executing Fault Insertion case "CBC in reset mode" on active AXSM. Workaround: Unknown. Hardware:AXSMB-OC3
CSCdy82219	Symptom: PNNI ports go into provisioning mode and spvcs fail when fault on active card or card switchover allowed to standby card with fault. Condition: Utopic 2 Bus CBC to ATMIZER bit tx/rx errors inserted on active or standby cards. Workaround: Unknown. Hardware:AXSMB-OC3
CSCdy82305	Symptom: PNNI ports went down in progress and SPVCs failed when fault injected on active or switchredcd allowed to card with fault present. Condition: Hold ATMizer in reset mode (SWB9) Fault Insertion test case inserted on active or standby card. Workaround: Unknown. Hardware:AXSMB-OC3
CSCdy82328	Symptom: After FS clear K2 was carrying previous channel number for four frames leading to random behavior of other equipment. Condition: Initial condition:WS2 is primary and active line is WS2 Issue FS Issue FS clear. Active line and Primary section shall be WS1, and mismatch should not occur on either node. Workaround: None. Hardware: AXSMB-OC3
CSCdy82452	Symptom:QE48 fault not detected in standby state. Condition: User executed QE48 VC Table and QDB Memory Bank Fault Insertion test cases. Workaround: Unknown. Hardware:AXSM1
CSCdy82780	Symptom: Faulty card did not reset and come up as failed. Condition: Customer executed QE48 Tx UTOPIA3 to Humvee parity error fault insertion test case. Workaround: Unknown. Hardware:AXSM1
CSCdy82800	Symptom: Card with fault inserted came up as standby. Condition: Customer executed HUMVEE to SPEEDUP PLD UTOPIA 3 parity error fault insertion test cases. Workaround: Unknown. Hardware:AXSM1
CSCdy82827	Symptom: No action taken by switch and no records in event log when fault inserted. Condition: Egress/Ingress QE QDB memory data bit errors fault insertion test case executed. Workaround: Unknown. Hardware: AXSME
CSCdy82836	Symptom: Standby AXSM-E card did not reset and error was not recorded in event log. Conditions: Humvee ILT CAM data bit 8 tied to GND fault insertion test case was executed. Workaround: Unknown. Hardware: AXSME
CSCdy82849	Symptom: When fault inserted on active or standby card, reset/switchover did not take place for 3 min. Condition:SWB10-Hold Atmizer in reset fault insertion test case was executed. Workaround: Unknown. Hardware: AXSME
CSCdy82872	Symptom: Card fault not reported in event log. Condition: Hold Port 1 secondary Tetra in reset fault insertion test case was executed on standby AXSM-E. Workaround: Unknown. Hardware: AXSME
CSCdy82897	Symptom: Card reset or data discard did not take place when fault inserted. Condition: Pull down data bit 24 of port 1 ATLAS Egress SRAM to GND and Pull down data bit 56 of port 1 ATLAS Ingress SRAM to GND fault insertion test cases were executed. Workaround: Unknown. Hardware: AXSME

Status of MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Caveats Found in Previous Releases

Table 36 lists the status of the known caveats from previous releases.

Table 41 Status of Severity 1, 2, and 3 Previous Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 

DDTs Issue	Status	Description
CSCdx33812	Severity 1; closed.	The problem was due to a faulty card. Hardware: PXM45B
CSCdx48370	Severity 1; closed.	The hardware is working the way it was designed. Hardware: PXM1E
CSCdx53377	Severity 1; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx57063	Severity 1; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx61357	Severity 1; closed.	The problem could not be reproduced. Hardware: MGX-RPM-XF-512.
CSCdx65568	Severity 1; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx69070	Severity 1; closed.	Fixed in Release 3.0.10. Hardware: PXM45
CSCdx74396	Severity 1; Fixed in Release 3.0.10.	Hardware: CESM-8T1E11
CSCdx76563	Severity 1; Fixed in Release 3.0.10.	Hardware: FRSM-8T1E1
CSCdx77614	Severity 1; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdu86213	Severity 2; closed.	Problem was due to an Ethernet chip hardware problem. Hardware: PXM45
CSCdw64682	Severity 2; closed.	The customer agreed to close the bug. Hardware: AXSM OC-12 cards
CSCdw68448	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: AXSM
CSCdw92648	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: AXSME OC-12
CSCdw94593	Severity 2; closed.	Bug is not applicable to Release 3.0.10. Hardware: AXSM
CSCdx07885	Severity 2; closed.	Problem was because of an old programmable logic device. Hardware: AXSMB OC-3
CSCdx08713	Severity 2; closed.	This bug is a duplicate of CSCdx92471, which is closed because it could not be reproduced. Hardware: PXM1E
CSCdx11807	Severity 2; closed.	Fixed in Release 3.0.00. Hardware: MGX-RPM-XF-512
CSCdx12518	Severity 2; closed.	The customer agreed to close the bug. Hardware: AXSMB OC-3
CSCdx19953	Severity 2; closed.	The customer agreed to close the bug. Hardware: AXSMB OC-3
CSCdx29013	Severity 2; closed.	Problem could not be reproduced. Hardware: FRSM-12-T3E3
CSCdx31524	Severity 2; closed.	Documentation problem was fixed. Hardware: AXSME
CSCdx38504	Severity 2; closed.	Problem was due to faulty hardware. Hardware: RPM-PR
CSCdx40806	Severity 2; closed.	The software works as designed. Hardware: AXSME-32-T1E1-E
CSCdx44119	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: AXSMB OC-3
CSCdx44559	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45
CSCdx45338	Severity 2; closed.	The customer agreed to close the bug. Hardware: AXSMB OC-3
CSCdx45391	Severity 2; closed.	Duplicate of CSCdx44119, which was fixed in Release 3.0.00. Hardware: AXSMB OC-3
CSCdx49157	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdx50704	Severity 2; closed.	Duplicate of CSCdx55010, which was fixed in Release 3.0.10. Hardware: AXSMB OC-3
CSCdx53560	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: FRSM-12-T3E3
CSCdx53980	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: FRSM-12-T3E3
CSCdx54330	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: FRSM-12-T3E3
CSCdx57276	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx59414	Severity 2; closed.	Problem was fixed by the introduction of the PXM-UI-S3/B back card. Hardware: PXM1E
CSCdx64083	Severity 2; closed.	Problem was due to faulty hardware. Hardware: AXSM OC-48
CSCdx65353	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdx64484	Severity 2; closed.	Fixed by a new FPGA design. Hardware: FRSM-12-T3E3
CSCdx65353	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdx67985	Severity 2; closed.	Duplicate of CSCdx06370, which was fixed in Release 3.0.00. Hardware: PXM45B
CSCdx68088	Severity 2; closed.	The bug was fixed by design changes made for 3.0.00. Hardware: AXSMB OC-3
CSCdx68487	Severity 2; closed.	The bug could not be reproduced with different cards. Hardware: AXSMB OC-3
CSCdx69311	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx69886	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: FRSM-12-T3E3
CSCdx70242	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: AXSMB OC-12
CSCdx70819	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdx71109	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: FRSM-12-T3E3
CSCdx71179	Severity 2; closed.	Problem could not be reproduced. Hardware: PXM45B
CSCdx71196	Severity 2; closed.	Problem was due to faulty hardware. Hardware: AXSM OC-12
CSCdx71590	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: AXSM OC-12
CSCdx71608	Severity 2; closed.	Problem was due to faulty hardware. Hardware: PXM45B
CSCdx73274	Severity 2; closed.	It was decided that the scenario being tested was unlikely to happen in a customer's environment. Hardware: FRSM-12-T3E3
CSCdx73805	Severity 2; closed.	The problem could not be reproduced. Hardware: PXM1E
CSCdx74295	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx74583	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: AXSME
CSCdx74626	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: FRSM-12-T3E3
CSCdx76852	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdx77374	Severity 2; closed.	Duplicate of CSCdv62811, which is closed with the customer's agreement. Hardware: PXM45
CSCdx77485	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx77522	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdx77573	Severity 2; closed.	The bug was fixed by design changes made for 3.0.00. Hardware: AXSMB OC-12
CSCdx78739	Severity 2; closed.	Duplicate of CSCdx71590, which is fixed in Release 3.0.10.b. Hardware: PXM45B.
CSCdx79195	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45
CSCdx80130	Severity 2; closed.	Problem was discovered to be with the VISM images and not a problem with the PXM1E hardware or software. Hardware: VISM
CSCdx80725	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx81229	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx81842	Severity 2; closed.	Fixed in Release 3.0.10. Hardware: PXM45
CSCdt70323	Severity 3; closed.	Fixed in Release 3.0.10. Hardware: PXM45
CSCdu71423	Severity 3; closed.	The problem could not be reproduced. Hardware: AXSM
CSCdu71558	Severity 3; closed.	The software is working as designed. Hardware: AXSM OC-48
CSCdv22540	Severity 3; closed.	Duplicate of CSCdw29928, which was closed due to faulty hardware. Hardware: AXSMB OC-12
CSCdv48058	Severity 3; closed.	The customer agreed to close this bug. Hardware: AXSMB OC-12
CSCdv49510	Severity 3; closed.	The customer agreed to close this bug. Hardware: AXSMB
CSCdv62811	Severity 3; closed.	The customer agreed to close this bug. Hardware: AXSM
CSCdw08931	Severity 3; closed.	Fixed documentation error. Hardware: PXM45
CSCdw10207	Severity 3; closed.	Fixed in Release 3.0.10. Hardware: AXSM
CSCdx04460	Severity 3; closed.	The customer agreed to close this bug. Hardware: PXM45
CSCdx12589	Severity 3; closed.	Fixed in Release 3.0.10. Hardware: PXM1E
CSCdx31466	Severity 3; closed.	Fixed in Release 3.0.10. Hardware: PXM45
CSCdx41607	Severity 3; closed.	The feature was disabled starting with Release 3.0.00. Hardware: PXM45
CSCdx43364	Severity 3; closed.	This bug was discovered to be an RPM bug, and was fixed in 12.2(11.05)GLD and 12.2(11.05)T. Hardware: RPM
CSCdx45501	Severity 3; closed.	Fixed in Release 3.0.10. Hardware: PXM45B
CSCdx56762	Severity 3; closed.	Duplicate of CSCdv43875, which is fixed in Release 3.0.10. Hardware: PXM1E
CSCdx68030	Severity 3; closed.	Duplicate of CSCdx29174, which is fixed in Release 3.0.10. Hardware: PXM1E

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.10

Table 42 lists the resolved caveats for the MGX 8830/8850/8950 software Release 3.0.10.

Table 42 Resolved Caveats for MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Software Release 3.0.10 

DDTs Issue	Description
CSCdt70323	Change PXM burnboot process to not require console
CSCdv43250	DLS: no maximum login attempts to node
CSCdv82967	VUNI: misleading error msg while adding partition
CSCdw08931	clrallcnf, restoreallcnf not overwriting node LAN
CSCdw12286	Configuring Uni to Bi causes PSBF on PL when local
CSCdw16078	REG21: unknown BC reported for stby axsme after px
CSCdw36064	AXSM core dump during switchredcd stress testing
CSCdw36539	Modify fails for AXSME xpvc connections
CSCdw52114	Chip at location U20P is easily to be scrapped off
CSCdw55208	PLFM: Though almcnts are cleared dspalms show stat
CSCdw60931	PLFM: Lockoput option on remote bi-dir apsln not r
CSCdw64202	switchcc traffic disruption time > 250ms on PXM1E
CSCdw66236	dspchans on PXM1E does not display port/switch sid
CSCdw66847	Signalling COSB thresholds not programmed for ingr
CSCdw68448	Low accuracy problem on MBS policing.
CSCdw69483	Z-RED:switchredcd failed while wr mem is in proces
CSCdw71075	SRM allows ds3linecoding to be set to HDB3 on j
CSCdw71199	Error message from RPM-PR: RPM failed
CSCdw74792	JANPN:Cant stop dspchancnt display using ctrl-c
CSCdw78945	FRSM12: Lots of EM err of vsiAddConnToStats after
CSCdw79627	Info shown by dspconinfo on PXM and dsptotals on A
CSCdw80562	dspalm for E3 interface needs to be added
CSCdw84026	k_smRedMapEntry_set() calling cliAddred()
CSCdw87384	PRI: dspconinfo -detail false giving the wrong spv
CSCdw88500	dspred shows inconsistent Card Type for SRM slot
CSCdw92493	PXM1E loses traffic with FRSM8T1 and FRSM2T3 insta
CSCdw94593	cross commit / discrepancy in trunk bandwidth
CSCdw94596	PLFM: Err in traffic parameters when addcon with c
CSCdw94919	FRSM12: LMI path goes down when data traffic start
CSCdx01351	FRSM12: Port w/ Asyn enabled down after switchcc;a
CSCdx02135	PLFM:boot flash corrupted after burnboot 3.0(0.225
CSCdx02665	Connection counts displayed with dspport are incorr
CSCdx02968	When single PXM1E is used, only 1 slot of srm shou
CSCdx04867	JANPN:Allow pathtrace on control port for svcc-rcc
CSCdx05090	FRSM12: Cant add the last conn to reach limit if L
CSCdx06502	PXM1E:Incorret error message for addred when card
CSCdx06836	APS-B: Inter, AXSM/B in OpB mode after upgrade fro
CSCdx07103	cannot change ds3 lines to e3 in combo cd when all
CSCdx07885	EMEA axsmB fails intermittently with UnkAPS alarm
CSCdx09290	FRSM12: No.of Conns on a Partn shouldn't exceed Par
CSCdx10704	need CLIs to display VC/Cos Thresholds in AXSME QE
CSCdx10863	FRSM12:CISCO-WAN-AXIPOP-MIB.my needs updates
CSCdx12579	FRSM12:traffic drops after sending 5byte frame at
CSCdx12589	Wrong Code Can Run In MGX 8830 Without Warning
CSCdx13644	FRSM12: Local bus error with T3 traffic + over 10
CSCdx14140	AXSME-DD, add support for BC in the lower bay on A
CSCdx14463	FRSM12: problem when cnfsct multiple ports to the
CSCdx15478	No RDI-L and RDI-P is sent by the W and P Lines wh
CSCdx15780	FRSM12: Tstcon/Tstdelay/CC (OAM) broken on post 3.
CSCdx17703	RDI from ATM network by SIW con is not mapped into
CSCdx19404	Z-CDS: newly re-worked maker B cards didn't come up
CSCdx20667	FRSM12: Move frsm12 specific SCT file to frsm12 di
CSCdx21173	FRSM12: Some debug msg needs to be deleted when ad
CSCdx21223	NNI link goes into auto config state after switchc
CSCdx21895	Z-REGS: after clrallcnf node bring up, RPM-XF came
CSCdx24899	FRSM12: OAM alarm re-sync should not report lcn=33
CSCdx25180	PXM1E DevTest: SSCOP PDUs corrupted in stable link
CSCdx27983	AUTO:Same clock source as primary and secondary by
CSCdx29956	lost cell bus clock config after power cycle
CSCdx30231	AXSM dspvsicon not showing correct lVci
CSCdx30496	RGS:One new GIG backcard can not be detected if ds
CSCdx31466	CLI command delcons needs special privilege usage
CSCdx36523	error messages are recorded in log regarding NCDP
CSCdx37066	Wrong frStdABRTrm range in the Mibs
CSCdx39344	RGS:dspcd shows NO inserted BACKCARD but with acti
CSCdx43364	The snmp query on ifName responds five time for sw
CSCdx44119	APS:dsplog did not show the second APS switching.
CSCdx44453	could not delete an svcif when route is configured
CSCdx45501	dsppnni-routing-policy should match the display of
CSCdx45932	REG3.0: Rcv Frm Disc Illg Hdr on FRSM-12-T3E3 when fr fw
CSCdx46551	dspapsbkplane command only applicable to PXM1E wit
CSCdx48469	Feature for providing shelf filtered alarm status
CSCdx48591	REG3.0: SSCOP PDU corruption causes conns. to be u
CSCdx49157	Unable to change SSCOP PCR after changing from def
CSCdx49437	cnfcon caused false error logged on PXM1E
CSCdx50255	bnPathHoldDown and PTSE holddown timers have no ef
CSCdx50992	dspdiagstat show incorrect online diag statistics
CSCdx52205	CESM not allowed to come on-line due to clock issu
CSCdx52436	SLT: Cons did not recover after node rebuild - LCN
CSCdx53295	REG3.0: ilmiPassup task freeing a mem - MBLKINVALI
CSCdx53377	frsm/ausm go unreserved after switchcc
CSCdx53426	REG3.0: Once part added with dlciLen 4 cnfport dlc
CSCdx53560	Downed connection shown as failed
CSCdx53588	VISM Releases Active calls on PXM1E SWOVER
CSCdx54330	FRSM12: protection for concurrent access of avl tr
CSCdx55010	AXSM conn receiving AIS from switch receive side
CSCdx55704	FRSM12:ABR Seg Endpnt should not be set for non-ab
CSCdx56381	SM 0 byte card file
CSCdx57063	SPVC failed to route after service modules were re
CSCdx57101	SNTP does not work efficiently when configured thr
CSCdx57276	REG3.0: Ln not up after power cycle
CSCdx57455	Setrev should not be allowed after Runrev complete
CSCdx57591	SLT: Need to be able to configure > 50K conns afte
CSCdx59149	RFS: Trying to free NULL pointer
CSCdx59223	UPG:all NCDP ports shut down when NNI link out of
CSCdx60342	AXSME-T1E1 fails the compliance Pulse Mask Test
CSCdx61969	Have CLI options to configure and clear E3 trail t
CSCdx63688	dbIO tlb exception when setrev before commitrev is
CSCdx65353	SPVC: Cross Commit failed on some connections.
CSCdx65568	PXM1E switchover took 15 seconds after removal of
CSCdx66220	aps needs to reset rmi connection in case its unhe
CSCdx66979	Core Dumps created during DBsync between Act&Stby
CSCdx67473	restoreallncf aborts if current SW version differe
CSCdx69070	Memory Allocation Errors - dsplog leaking memory a
CSCdx69115	RPM Card Going into Failed State for a while after
CSCdx69886	FRSM12: Invalid line number passed to dalOamSetAla
CSCdx70242	Active BC removal/insertion caused SF, and oneWayI
CSCdx70819	Core Dumps created during DBsync between Act&Stby
CSCdx71109	FRSM12:After multiple switchcc, LCN for endpoints
CSCdx71649	CESM pnports down on PXM1E but ports active on CES
CSCdx72300	REG3.0: cnfcon allows MCR > PCR on stdABR conn
CSCdx72931	Enabling Drivers take 1.6 seconds during switchcc
CSCdx73996	preserving sw/fw vers result addred failure for AX
CSCdx74295	PXM1E node shows active/standby with two different
CSCdx74626	FRSM12 connection sends wrong trap
CSCdx76563	dspcons/dspchans results in response Getting Filte
CSCdx76697	Master is ok while slave is in failed state.
CSCdx76852	RGS:active RPM-PR backcards changed to empty after
CSCdx77522	APS: When 1 backcard missing, MGX send sd clear t
CSCdx77614	Multiple node PXMs failed and other PXM in active f
CSCdx77738	SCT chksum dont match between sw distributed and C
CSCdx77741	dsppnport shows some sm ports as down when they ar
CSCdx77992	PXM1E:primary clk get unlockable if u remove and i
CSCdx81229	dspcons from PXM1E show failed, but SM show them a
CSCdx81842	SLT:RPM-PR redundancy is lost after upgrade from 3
CSCdx81929	lsmProxy support for vism on PXM1E
CSCdx82275	Cannot create SPVCs up to the partition limits.
CSCdx82320	secondary SM not taking over if primary SM is out
CSCdx82867	dspcd does not display CLEI codes for some SMs
CSCdx83697	OAM task taking 20% CPU
CSCdx84039	PXM45 Multi-cast feature checkin
CSCdx84262	The tail end of the connection reroute to be impro
CSCdx85661	popup message appears on second telnet using cnfnd
CSCdx86090	receiving pnni complex node messages after switchc
CSCdx88597	OAM lpbk stops working after hugh OAM lpbk traffic
CSCdx89214	Both (A)&(S)PXM had rebuild trigger by unexpected
CSCdx92928	plx hangs on cold reset on frsm12 card
CSCdx94150	Memory corruption on FRSM - indicate no channel av
CSCdx94710	REG3.0: PXM1E: Remove 4 port OC3 backcard, outage
CSCdx95168	FRSM12: add OamSendLpbkCellTest() for hardening te
CSCdy00940	dspdiagstat show incorrect online diag statistics
CSCdy01984	tstdelay causes cell loss on CESM
CSCdy05684	Boundary condition causes lcn pool corruption in s
CSCdy06336	Need enhancement in resecd command
CSCdy06940	Need mechanism to resynch port status between PXM
CSCdy06992	clean up errors logged by pcema if get next on ifT
CSCdy07362	unable to up connection after downed
CSCdy07500	Stdby pxm in slot 7 stuck in empty state
CSCdy07862	cannot change abr-std shaper (pcr,mcr,icr) paramet
CSCdy07936	upon installation of nw stdby pxm card stuck in in
CSCdy10136	Call rate improvement to get to 160 calls/sec
CSCdy10441	FRSM-12-T3E3 interoperability with 4000 router u
CSCdy11654	Cannot CC nor CCC to slot with RPM card: IOS ipc b
CSCdy12781	FRSM12: Qbin Threshold for slot 14 is empty
CSCdy13722	(S)PXM cannot sync with primary rpm-xf slot after
CSCdy13924	Modification of fr-atm fails on PXM1E
CSCdy14060	UPgrade to 3.0(10.99)P1 caused AXSM-E connection f
CSCdy16914	TB+ Hard: FRSM-2CT3 in slot 6 stuck in boot w/ new
CSCdy16981	xcnfchanstdabr & xcnfchan on FRSM-T1 caused failed
CSCdy17852	dspport on AXSM-E and dsppnport on PXM report # SV
CSCdy18274	dspconinfo needs to separate out persistent and no
CSCdy18792	3.0(10): unnecessary messages displayed on remote
CSCdy19456	CLI failure on AXSM E due to database or memory pr
CSCdy20771	unable to add redundancy for slot 22
CSCdy21987	FRSM12:addcon for Frame Forwarding type returns DE
CSCdy24425	AXSM/B port did not come up after LOS cleared
CSCdy24836	<switchcc> Ram Sync Failed, eventlog message
CSCdy24873	<switchcc> Failed to send event to ctc state machi
CSCdy25348	Number of NCDP messages showing up in log
CSCdy26150	PTSE gets regenerated even with path down timer as
CSCdy26633	Need mechanism to resynch port status between PXM
CSCdy28633	after issuing xcnfconstdabr asum card is freezing
CSCdy28674	removing and inserting back card does not cause st
CSCdy29758	Standby PXM1E reset while syncing with the primary
CSCdy33523	ENVMON: Support for integrating alarms
CSCdy35413	AXSM/A/B does not transmit NULL for E3 tail trace
CSCdy37455	TB Hard2: memLeak in ipc buffer id 0x10003 (unique
CSCdy41151	Failure to make AAL2 SVC Calls after PXM1E SWOVE
CSCdy48320	switchredcd on slot 1 caused slot 1 to be stuck in boot stat
CSCdy56990	TB+ Hard2:mem alloc. failure in buffer 0x10003 after upgr
CSCdy59240	SwitchCC caused due to mainProc1 getting killed unexpectedly
CSCdy59372	CPU utilization hit 0% IDLE due to pnCcb, when connections r
CSCdy61503	Failed connections on MGX-2
CSCdy65628	line 2.5 went to LOF after switchcc.
CSCdy67350	clk signals not available after APS switch

Caveats for Release 3.0.00

This section provides information about caveats associated with Release 3.0.00 software.

Severity level 1, 2, and 3 caveats are organized in this section as follows:

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.00

•MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Resolved Caveats in Release 3.0.00

MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Open Caveats in Release 3.0.00

Table 43 lists the Severity 1 open caveats for the MGX 8830/8850/8950 Release 3.0.00 software.

Table 43 MGX 8830, MGX 8850 (PXM45/PXM1E), and MGX 8950 Release 3.0.00 Anomalies 

Bug ID	Description
S1Bugs
CSCdt54958	Symptom: OC12 p-p jitter amplitude exceeded the 0.10 UI pp. Conditions: Unknown Workaround: None. Hardware: AXSM OC-12 cards
CSCdu86213	Symptom: Cannot get large files from a switch using FTP. Data Connection Error is reported. Conditions: When a large file is uploaded from a shelf to a workstation, the Ethernet chip hangs and a data connection error is reported by the FTP client on the workstation. Workaround: Do not FTP files from on a workstation which is on the same subnet as the shelf. Hardware: PXM45
CSCdw27075	Symptom: Unable to CC to a AXSM card in Y-redundancy configuration. The reason for that is that QE VI threshold has been exceeded and QE is discarding the incoming AAL5 frames. This situation may be met in PXM45A, where SAR overflow may occur (very rare). Note: customer should not let QE SAR overflow occur in PXM45A. Conditions: After a switchredcd on an AXSM card pair in redundant mode. Workaround: None. Hardware: PXM45
CSCdx33812	Symptom: Xbar planes being shut done on the PXM45B. Conditions: Xbar errors being reported between slots 3, 7, and 8. Workaround: None. Hardware: PXM45B
CSCdx48370	Symptom: CBM1 throughput is 42% of OC-3 LR as opposed to 100% OC-3 LR. Conditions: Inject OC-3 LR traffic Workaround: None. Hardware: PXM1E
CSCdx53377	Symptom: SPVC fails after it was created Condition: SPVC failed because the service module was in an unreserved state. Workaround: 1) Call an api from the shell to re-reserve the slot sh>shmRemoteFrontCardReservedReport (logical_slot #). 2) Delete the ports, parts, connections on slots and readd them. Hardware: PXM1E
CSCdx54945	Symptom: All external xtags are down. Attempts to cc to slot 5 (containing xtag interfaces) failed. Conditions: Standby PXM in slot 8 in empty reserve state. There are some P1SarErrors reported to the active PXM log. Workaround: None. Hardware: PXM45
CSCdx57063	Symptom: Resource (lcn, vpi/vci) leak on NNI trunks. Conditions: Resetcd on service modules (where SPVC are terminated) and then deroute connections by using one of the following methods: a. reset via/remode node b. bring down NNI trunks c. rrtcon/dncon Workaround: None. Hardware: PXM1E
CSCdx61357	Symptom: MGX-RPM-XF-512 card froze and no crashinfo was logged. Conditions: Traffic was being pumped (182Mb/s) into 1 LVC. Workaround: None. Hardware: MGX-RPM-XF-512
CSCdx65568	Symptom: When active PXM1E trunk backcard is removed, switchover traffic outage is sometimes 1.5 sec or more. Conditions: None in particular. Workaround: None. Hardware: PXM1E
CSCdx69070	Symptom: Several possible symptoms including: - Inability or sporadic ability, to connect via telnet -"gray-out" of the node on the CWM topology map - no output from or receipt of an error message from 'dsplog' command or file system listing command 'ls' or other commands - standby PXM45 or AXSM service modules which remain in the "Boot" and/or "Init" or alternate between the two after a reload - inconsistent connection alarms on slave and master. (one side reporting alarm, the suspect side not) Conditions: System memory and/or file handle allocation may get into a marginal or maxed out state due to "ungraceful" exit from the 'dsplog' command multiple times. This includes exiting display of the command with any other method other than using the 'Q' option to quit or going to the end of the output. Workaround: On redundant systems with healthy standby PXM45 present, switchcc. On non-redundant systems: reset the single PXM45. Hardware: PXM45
CSCdx77614	Symptom: Multiple nodes with failed PXM45Bs (standby) and active-f (active). Conditions: When simulator nodes are sending addresses of length zero. Workaround: resetsys, or switchcc as long as the simulator is off. Hardware: PXM45B
S2 Bugs
CSCdt53631	Symptom: LOF criteria is not met per R5-225, for AXSM OC12 interface. Condition: OOF condition is cleared at the presence of three consecutive error free patterns rather than two. Workaround: Unknown. Hardware: AXSM OC-12 cards
CSCdu26365	Symptom: Card resets with device driver error or watchdog timeout. Conditions: Unknown. Workaround: None. Hardware: PXM45
CSCdu86213	Symptom: Cannot get large files from a switch using ftp. Data Connection Error is reported. Conditions: When a large file is uploaded from a shelf to a workstation, the ethernet chip hangs and a data connection error is reported by the ftp client on the workstation. Workaround: Do not ftp on a workstation which is on the same subnet as the shelf. Hardware: PXM45
CSCdv53825	Symptom: sframetick lock config is lost. Condition: When a switchcc is executed on the shelf. Workaround: None. Hardware: PXM45
CSCdv73419	Symptoms: Traffic loss on multi cast root connections with no indications of cell loss in any discard counters. Conditions: During ingress multi cast or slot multi cast, the switch may issue a grant for a root cell when it can not deliver to all requested slot destinations. This will only occur if there is a switch port alarm on a service module that is the target of a multi cast root cell. Workaround: There is no workaround. You can take action to remove the switch port alarm. If there are no switch port alarms then the problem will not occur. Hardware: AXSM
CSCdv85607	Symptom: Core dump occurred for standby AXSME OC3 card though no activities. Conditions: AXSME OC3 with standby card. Workaround: Unknown. Hardware: AXSME OC-3 cards
CSCdw64682	Symptom: AXSM core dumped. Conditions: On-line diag error (Xbar burst) was reported at the time. Workaround: None. Hardware: AXSM OC-12 cards
CSCdw68448	Symptom: The low accuracy of AXSM's MBS policing function for Rel.2.0 and 2.1. Condition: None. Workaround: None. Hardware: AXSM
CSCdw91580	Symptom: SRME APS switchover time > 250 ms when either SRME FC or BC is removed. Conditions: When SRME is engaged in APS and either SRME FC or BC is removed. Workaround: Perform APS switching out from back card that needs to be removed. It means that before removing the SRME card, check that the SRME card is in the standby state instead of the active state. Hardware: PXM1E
CSCdw92648	Symptom: Connection's ingress Qbin number is not programmed correctly according the card's SCT file. Condition: The card's SCT file is different from the port's SCT file. Workaround: Use the same version of SCT files for both card and port. Hardware: AXSME OC-12
CSCdw94593	Symptom: Cross commit failures between two shelves, and connection failures. Conditions: May have been triggered by enni tuneup procedure, which included adding and deleting enni ports. Workaround: None. Hardware: AXSM
CSCdx07885	Symptom: The AXSM card went to fail state, when trying to invoke off line diag or coming out of off line diag. Card will remain and failed/empty state until manually addressed. Conditions: The PXM trying to reset the AXSM card to start the offline diag or coming out of offline diag, the AXSM card is not getting reset and PXM declares it as in fail state. Workaround: Resetcd manually. Hardware: AXSMB OC-3
CSCdx08713	Symptom: display card alarms shows connections in Critical alarm. Traced them to chans on PXM1E but not shown anywhere else. Condition: Not known how they got there. Unable to reproduce. Workaround: None. Hardware: PXM1E
CSCdx11807	Symptom: Attempting to add incorrect redundancy for RPM-XF gives misleading error messages. Conditions: Attempting to add redundancy between RPM-PR and RPM-XF Attempting to add y-red between RPM-XF Attempting to add y-red between RPM-XF and RPM-PR (adding between RPM-PR and RPM-XF returns correct message). Workaround: None. Add correct redundancy (RPM-XF 1:n to RPM-XF). Hardware: MGX-RPM-XF-512
CSCdx12502	Symptom: Checksum error on SM_CON file. Conditions: An AXSME with no connections. The generated SM_CON has 27 bytes with a checksum error. Workaround: None. Hardware: AXSME OC-12
CSCdx12518	Symptom: No report of an LOS in certain conditions. Condition: When the transmit fiber is disconnected from the AXSM. Workaround: None. Hardware: AXSMB OC-3
CSCdx17118	Symptom: Reroute does not work properly with trunk errors or delay. Conditions: Trunk errors between peer groups. Some connection reroute delays introduced due to trunk errors. Workaround: Unknown. Hardware: PXM45
CSCdx19953	Symptom: Data transfer stopped. Condition: When the AXSM/B back cards were removed and re-inserted. Workaround: None. Hardware: AXSMB OC-3
CSCdx28385	Symptom: AXSM does not know SD after line failure in P line. Condition: Triggered by doing a resetcd on both the active and the standby AXSM. Workaround: After doing manual or force switch on that line pair, SD shows up on P line. Hardware: AXSMB OC-3
CSCdx28756	Symptom: If asynchronous updates is enabled on the LMI enabled ports, ports go down after switchcc and all data traffic is dropped. This problem does NOT happen if LMI is enabled but asynchronous updates is disabled. Conditions: Switchcc where FRSM12 ports have asynchronous updates enabled. Workaround: Unknown. Hardware: FRSM-12-T3E3
CSCdx29013	Symptom: In redundancy setup, on "switchredcd" or "resetcd" commands FRSM12 card doesn't come up after reset. The card gives watchdog timeout error producing core dump and resets again. On the second reset, the card comes up without any errors. This problem occurs occasionally. Conditions: Condition 1: When "switchredcd" command is used on FRSM12 redundancy pair, the card in active state goes to standby state after two resets. Condition 2: When standby/active card is reset by "resetcd" command, the card comes up after two resets. Workaround: None. Hardware: FRSM-12-T3E3
CSCdx31524	Symptom: Usage of delcons command. Condition: Resources are impacted. Workaround: Use delcon to delete each PVC one at a time. Hardware: AXSME
CSCdx38504	Symptom: RPM-PR cannot communicate successfully with the PXM. Condition: Power cycle the MGX 8850, the card recovered in a empty/reserve state. The RPM does boot successfully and can be viewed via the console CLI. dspcd on the PXM does not recognize the RPM. Workaround: None. Hardware: RPM-PR
CSCdx40806	Symptom: AXSME policer should not discard CLP1 cell on ABR connection. Conditions: On AXSME-T1E1, pass traffic (CLP=1) over PCR on ABR connection. Workaround: Unknown. Hardware: AXSME-32-T1E1-E
CSCdx44119	Symptom: The proper status is not being represented in the dsplog. Condition: When performing APS switch testing between BPX, and the MGX45. Workaround: None. Hardware: AXSMB OC-3
CSCdx44559	Symptom: A phantom level 0 node may appear in a Multiple Peer Group (MPG) It can be seen in the output of the command dsppnni-node-list as shown here: node # node id node name level ------- -------------------------------------------------- ---------- ------- 2 0:6:00.000c020000000100106d3839.35302d376200.00 0 <== Conditions: PNNI hierarchical network running multiple peer groups (MPG). Workaround: None. Hardware: PXM45
CSCdx45338	Symptom: The log should show SD and SD_clear as a pair in the dsplog. Condition: When you cause an SF via a error generator. Workaround: None. Hardware: AXSMB OC-3
CSCdx45391	Symptom: dsplog shows sf_decl_clear for w when it was never in SF. Condition: When Rx cable on AXSM is removed from the active line. Workaround: None. Hardware: AXSMB OC-3
CSCdx47744	Symptom: PXM cell bus can't handle more than 130 mbs per quadrant in any of the lower bay. PXM sends a corrupted cell (no end of frame) to the VISM and as a result VISM in slot 22 or 21 resets after all the buffers are filled out. Condition: All 6 slots (slot 17 - 22) configured with G.711 , packet size = 10 ms and VAD off. 10 calls per sec per VISM. Workaround: It should be ensured that the BW utilization does not exceed 130 mbs. G.711, 10 ms with VAD is not an ideal scenario. Customers using G.711 with VAD on or any of the compression codec should not have any problem. Hardware: PXM45B
CSCdx49157	Symptom: Can not change PCR of sscop back to the default value. Condition: After modifying it to a lower value of 4000. Workaround: None. Hardware: PXM45B
CSCdx50704	Symptom: Large number of 60310 traps sent to CWM. Condition: When SPVC's are put into alarm upon Line failure. Workaround: None. Hardware: AXSMB OC-3
CSCdx53560	Symptom: For downed connections, the "Operation status" field in "dspcon" command is displayed as "Failed" instead of "Down". The "Administration status" field shows the correct value "Down". Conditions: When a Connection is brought down using "dncon" command, "dspcon" command shows the "Operational status" as "Failed". Workaround: When the connection is down, in the output of "dspcon" command the "Operational status" field should be ignored and only the "Administration status" field should be considered. Hardware: FRSM-12-T3E3
CSCdx53980	Symptom: SW cannot access any register and LCN Ram of QE (i.e. SW get the zero contents for all of QE registers). Data Path is still working. If it happens, then QE cannot be configured. So, addCon or delCon will fail and all of QE counts will become zero. Conditions: After SW do a burst access to QE (3 QE write and 1 QE read) in resetQbin function. Workaround: Only do QE write access in resetQbin function. This workaround has no side-effect. Hardware: FRSM-12-T3E3
CSCdx54330	Symptom: Event log message from dsplog cli indicates LCN out of range. Conditions: Concurrent access to LCN value from LMI and OAM code during assignment/removal of LCN from a connection may return invalid LCN. Workaround: No action is required. Hardware: FRSM-12-T3E3
CSCdx55987	Symptom: All the external xtags are down at the RPM. Attempts to cc to AXSM in slot 5 (containing xtag interfaces) failed a couple of times. The control plane is passing traffic one way. Conditions: PXM in slot 8 standby in empty reserve state. Customer noted slow response at cli of AXSM prior to being unable to access slot 5 (axsm). The PXM logged P1 sar errors messages. The PXM also had a coredump triggered by cache errors. Workaround: Not known at this time. Hardware: AXSMB OC-12
CSCdx57276	Symptom: Line is not added back after power cycle. Condition: Power cycle node by removing the standby combo cards FRUs. Workaround: Unknown. Hardware: PXM1E
CSCdx57346	Symptom: Intercard communication is lost between PXM and AXSM cards. Conditions: User cannot access (CC) to other cards in MGX2 chassis. Redundant PXM remains in init state. Workaround: None. Hardware: PXM45B
CSCdx59414	Symptom: With a PXM1E using a UI-S3 backcard, some Ethernet packets outbound from the PXM1E may be dropped when the UI-S3 Ethernet port is connected to specific hubs/switches. Conditions: Problem is hardware specific for the PXM1E with UI-S3 backcard. Workaround: Use a Cisco approved hub/switch. Hardware: PXM1E
CSCdx64083	Symptom: OC48B card became Active-F Conditions: After burnboot. Workaround: Unknown. Hardware: AXSM OC-48
CSCdx64484	Symptom: Traffic stopped after multiple "switchcc" were done on the PXM45. This is a hardware (Frame Relay FPGA IFE) bug found in the IFE Rev.55 Conditions: Ports 1 to 12 connected with a snaked connection. Tester pumped-in traffic into port 1, a VC connection is provisioned between port 1 and port 2, port 2 connected to port 3 with a cable, and so on. All the following ports connected like this. Port 12 looped-back the traffic with a cable connection. If the tester pumped-in T3 rate traffic, the whole FRSM12 card runs at 12 X T3 rate traffic. Now at the PXM45, do "switchcc". After multiple "switchcc" between slot 7 and 8, the traffic on FRSM12 may stop. How many times of "switchcc" will cause the traffic stop? It is random. In some chassis, 4 to 6 times. In most chassis, it takes 30 to 40 times switchcc to make this problem occur. Workaround: To recover the FRSM12, reset the FRSM12. Hardware: FRSM-12-T3E3
CSCdx65353	Symptom: Connection cross-connect failure on AXSME. Conditions: While performing re-route testing with another Peer Group. Workaround: None. Hardware: PXM45B
CSCdx67985	Symptom: PXM degraded, but no xbar alarm reported. Condition: Upon the execution of 2 consecutive switchcc's. Workaround: None. Hardware: PXM45B
CSCdx68088	Symptom: No LCN for the master end when no route is specified. Condition: After adding a new spvc. Workaround: None. Hardware: AXSMB OC-3
CSCdx68487	Symptom: AXSM failed to come up, and is stuck in failed state. Conditions: 1+1 APS Annex B with large number of the connections routing over. Do AXSM switch over, and the newly active card reset after a little while. Workaround: Reset failed AXSM card. Hardware: AXSMB OC-3
CSCdx69311	Symptom: Occasionally, an upline on a DS3 line on the active PXM1E in a redundant PXM1E node causes the standby card to reset. The reason for the reset is "Software Error Reset" and the log indicates Line Hardware Failure. Conditions: If this problem happens, it is only on a combo PXM1E card and then only on certain DS3 lines. Workaround: If a certain DS3 line shows this problem, down it and avoid using it. Instead, use another DS3 line. Hardware: PXM1E
CSCdx69886	Symptom: During add connection, TLB load exception might occur. The event log message from dsplog and dsperr clis indicate error by the tcProAlm task with INVALID SSI SEM ID. Conditions: If the interface(port) is configured with LMI signalling. Workaround: Existing connections and traffic flow are still working without interruption. There is no need to take any immediate action. Reset card will clear the condition. Hardware: FRSM-12-T3E3
CSCdx70242	Symptom: Signal Failure and oneWayInside on 2 ports 9.1.1, and 9.1.2 Condition: The removal and insertion of the active backcard of AXSM in slot #9. Workaround: None. Hardware: AXSMB OC-12
CSCdx70819	Symptom: Active PXM resets standby PXM while in init state, creating a coredump. Conditions: DB synch between active and standby PXM. Workaround: None. Node recovers. Hardware: PXM45B
CSCdx71109	Symptom: dspchancnt cli returns error "ERR: Could not get LCN for the endpoint". If LCN is deleted, no data traffic can go through. Conditions: When switchcc is issued multiple times on PXM card. Workaround: Reset FRSM12 card restores all the LCN that were missing. Hardware: FRSM-12-T3E3
CSCdx71179	Symptom: Unable to provision a SPVC. Condition: While adding a spvc from a AXSM CLI. Workaround: Re-try adding the connection. Hardware: PXM45B
CSCdx71196	Symptom: OC12 AXSM/A Delpart failed with "Invalid Partition Number". Addpart failed with "Cannot allocate requested LCNs....". Conditions: 1. OC12 AXSM/A with 1+1 APS configured, then delapsln. 2. Do delpart on port 3 with IF=3. 3. Do addpart on port 4 with IF=4, Maxconn= 10 to 1000. Workaround: None. Hardware: AXSM OC-12
CSCdx71590	Symptom: Switchcc causes the AXSM cards to go into AXSM-F state. Conditions: MGX 8850, AXSM T3/E3 AXSM OC_12 Workaround: Under investigation. Hardware: AXSM OC-12
CSCdx71608	Symptom: PXM45B card makes all the PNNI-links to go down. Conditions: MGX 8850 PXM45B Workaround: Under investigation. Hardware: PXM45B
CSCdx73274	Symptom: Sometimes users are unable to cc to the FRSM12 card. It's later found that task Interrupt, tQESARDisp, and tQESARORcv took up 100% CPU. Conditions: Unknown. Workaround: Unknown. Hardware: FRSM-12-T3E3
CSCdx73805	Symptom: FRSMs take more than 60+ mins become active Conditions: Populate slot 1 thru 14 w/ FRSMs, perform clrsmcnf on all and immediately remove and re-insert all the cards. Workaround: None. Hardware: PXM1E
CSCdx74295	Symptom: Node with PXM1E shows active/standby with two different type of PXM1E cards. Condition: Customer removed the standby PXM1E and then inserted a different front card type. Card came up as standby/mismatch with the front cards showing active/standby. Workaround: Do not mix front card types. Hardware: PXM1E
CSCdx74396	Symptom: Clock signal is still being detected on CESM port even when line is in alarm. Conditions: When configuring a CESM port as a clock source and the cable is pulled out of the CESM port; good clocking signals are still being detected on this port. Workaround: None. Hardware: CESM-8T1E11
CSCdx74583	Symptom: Lost primary and secondary clock after PXM switchover. Conditions: Do PXM switchover by issuing switchcc. Workaround: None. Hardware: AXSME
CSCdx74626	Symptom: Discrepancy in connection status between FRSM12 CLI and CWM when Port alarm is cleared. Conditions: When Port alarm occurs, all connections on the port go to Failed state in both Switch database and CWM (Cisco Wan Manager) database. Later, when the port alarm is cleared, all connections in Switch database go to Active state but the connections in CWM database stay in failed state. When Port alarm occurs, the switch sends cwFrChanFailed(60618) for all connections on the port. But, when the Port alarm is cleared, the switch doesn't send cwFrChanActive(60617) trap. Port alarm can occur when the line on which port is added goes to alarm state or when the LMI signalling fails. Workaround: By initializing CWM Sync-up operation, the discrepancy in connection alarms can be removed. During Sync-up, CWM uploads Alarm file from the switch and updates alarm status of all connections. The Sync-up operation is periodic and happens once in 8 hours and the time is user configurable on CWM. Hardware: FRSM-12-T3E3
CSCdx76563	Symptom: Dspcons/dspchans does not work. Condition: When issuing the dspcons or dspchans command, the cons are not displayed. The cli responses with Getting Filter Resource Failed. Workaround: Reset the card. Hardware: FRSM-8T1E1
CSCdx76852	Symptom: RPM_PR back cards change status from active to empty. Conditions: After doing runrev on PXM. Workaround: Reload RPM-PR. Hardware: PXM45B
CSCdx77374	Symptom: Multiple traps being sent to CWM after 80 seconds. Conditions: When configuring APS SFBER=10-3 only. Workaround: None. Hardware: PXM45B
CSCdx77485	Symptom: The PXM1E combo trunk back card has 12 lines. The top 8 lines are T3 or E3 and the bottom 4 lines are SONET lines. The 4 SONET lines have two LEDs per line. The top LED is meant to show the signal detect function. That is, if there is a signal on the incoming line, then this LED will glow a steady green. If there is no signal, this LED will blink green. The LED on the bottom is meant to show the active/standby status of the line. In case of both Y-redundancy and APS configuration, the active line is steady green and standby is steady yellow. Currently, the signal detect LED will be functioning correctly. But the status LEDs will be turned OFF always. It will not reflect the status of the line. Conditions: Under all conditions, the status LEDs of the SONET lines on the combo back cards are OFF. Workaround: In case of Y-Redundancy, the status of the lines can be found from the CLI command "dspcd". If the PXM1E front card is active, then all the lines are active. If the PXM1E front card is standby, then all the lines are standby. In case of APS redundancy, the status of the lines can be found using the CLI command "dspapslns". Hardware: PXM1E
CSCdx77522	Symptom: CWM gets lots of sd clear traps, and dsplog dropped events. Conditions: When any backcard is removed. Workaround: None. Hardware: PXM45B
CSCdx77573	Symptom: Lower backcard APS OC12 lines switch. Conditions: When the upper backcard is removed from the same slot. Workaround: None. Hardware: AXSMB OC-12
CSCdx7873	Symptom: Subagent did not registered with the master agent. SNMP requests to that card failed Conditions: Switchcc, resetsys, or switchover and the SNMP subagent on the AXSM card failed to register with the SNMP master agent on the PXM. Workaround: Need to manually register the SNMP subagent through shellconn. 1) Verify that the SNMP subagent is not registered for that slot: a) nodeName.8.PXM.a > sh b) Is this slot listed below? pxm45>dispSubagents dispSubagents Subagent ID Shelf Number Slot Number 0 1 7 1 1 6 c) From above find the associated "Subagent ID" that corresponds to this slot. If it does not exist, then it is not registered with the SNMP master agent. d) pxm45>dispSubagent 1 dispSubagent 1 Subagent ID = 1 Subagent Shelf = 1 Subagent Slot = 6 Subagent AgentID = smSubagent Subagent State = 1 <=== Subagent RFD = 800112a Subagent WFD = 60710d4 If the "Subagent State" is not 1, then the subagent is not registered with the SNMP master agent. 2) Manually register the subagent a) cc to that slot b) nodeName.<slot>.AXSM.a > sh c) axsm1> SendWakeUpSsiMsg() d) axsm1> ssiSemGive(SAGlobalLock) e) repeat (1) to verify Hardware: PXM45B
CSCdx79195	Symptom: PXM45 resets RPM multiple times (with reason as Firmware Image Download failure). (Note: 1 extra reset is however required - Refer CSCdt81984). Conditions: During RPM bootup after node power-up/reset. Workaround: Reset the RPM. Hardware: PXM45
CSCdx80130	Symptom: CWM gets lots of sd clear traps, and dsplog dropped events. Conditions: When any backcard is removed. Workaround: None. Hardware: vism
CSCdx80725	Symptom: clrsmcnf does not cleanup BERT config from PXM. Condition: When on a slot on which BERT is configured, we do either clrsmcnf [all] or pull out service module during clrsmcnf. Workaround: Delete bert before doing clrsmcnf. Hardware: PXM1E
CSCdx81229	Symptom: Dspcons from PXM1E show some cons in failed state, but dspcons from the service module shows these cons as okay. Conditions: Alarms are not being sent to the service modules. Workaround: Unknown. Hardware: PXM1E
CSCdx81842	Symptom: Lost redundancy after upgrading to a newer image. Conditions: Node upgrade causing reset of the node (since no redundant PXM). Workaround: None. Hardware: PXM45
S3 Bugs
CSCdt54906	Symptom: OC3/OC12 J1 byte does not provide trace patch to FE NE. Condition: None. Workaround: None. Hardware: AXSM OC-3/OC-12
CSCdt70323	Symptom: Need non-shellconn method of burning PXM boot code which also does not require console access to each PXM. Condition: None. Workaround: None. Hardware: PXM45
CSCdu26141	Symptom: SHM-4_DB_REQ_FAIL messages are logged at Sev-4 in the event log. Condition: Consecutive resetcds were executed on the PXMs in this system. This log can be seen under 2 condition: 1. Under the normal operation of the PXM if this is logged, it is a problem with the communication between 2 tasks that needs to be investigated. 2. During any form of shelf reset like resetsys, abortrev, setrev etc. If this log is seen at around the time a shelf reset is happening, it is not a problem if this log is seen. This will not have any impact at all on the state of the shelf or the state of the configuration on the shelf. In the case of this particular bug, this log was seen at the time of a shelf reset hence it is not a problem to see this log. Workaround: None. Hardware: PXM45
CSCdu27030	Symptom: OAM CC Activation Cell correlation tag is incorrectly modified. Condition: User notes that an F4-Seg Active-CC OAM cell with a correlation tag of 0x6A is returned to the sending device with a correlation tag of 0x00. Workaround: None. Hardware: AXSM
CSCdu71423	Symptom: Popup message about LMI discovery on node. Condition: User executed 3 cli commands, and then the popup message appeared. Workaround: None. Hardware: AXSM
CSCdu71558	Symptom: Alarms on slot #11 and #12, during fault insertion testing. Condition: By inserting high speed link error on slot #7, active PXM Workaround: None. Hardware: AXSM OC-48
CSCdv22540	Symptom: AXSM core dumps. Condition: Burn boot was executed. Workaround: None. Hardware: AXSMB OC-12
CSCdv47986	Symptom: dspln/dsplns/dspalm/dspalms no longer reflect aps line failures (SF). Condition: An error injector was setup to inject an error rate sufficient to force the W line into SF. Workaround: Unknown. Hardware: AXSMB OC-12
CSCdv48058	Symptom: Event log and trapd.log file incorrectly show APS switchovers due to SD when the failure condition was SF. Conditions: SF condition was created on the active working line to induce a switchover. Workaround: Unknown. Hardware: AXSMB OC-12
CSCdv49510	Symptom: No indication on dspapslns of a condition causing port to go operationally down. At the node level, only an indication of a minor alarm from the line interface. Conditions: Tx cables were pulled from both the W and P lines of a 1+1 APS pair. Workaround: None. Hardware: AXSMB
CSCdv50574	Symptom: Incorrect usage statement generated. Condition: When the delapsln cli command is executed. Workaround: None. Hardware: AXSMB
CSCdv62753	Symptom: cnfabr error message is not clear that VS/VD is not supported on specific card types. Condition: AXSM cards. Workaround: Unknown. Hardware: AXSM
CSCdv62811	Symptom: APS line toggles between SF and SD. Condition: SF threshold set to 10-3, error injected at 10-2. Workaround: None. Hardware: AXSM
CSCdv69323	Symptom: Shelf sends too many messages to CWM. Condition: After the execution of switchredcd on the shelf. Workaround: None. Hardware: PXM45
CSCdw08931	Symptom: LAN IP retained after a clrallcnf. Condition: clrallcnf performed on node. Workaround: None. Hardware: PXM45
CSCdw10207	Symptom: APS switching between W and P lines when both are in alarm. Condition: W line is in LOS and P line may be in SD or SF or LOS condition. Workaround: None. Hardware: AXSM
CSCdw68495	Symptom: AXSME card is latched up when it receives high traffic of OAM loopback cells. Condition: AXSME card can handle up to 10,000 OAM loopback cell per sec. If the user is sending OAM loopback cell at a higher cell rate, AXSME may be latched up and has unsuspected behaviour. Workaround: If the user really want to pass OAM loopback at high cell rate, (s)he should enable the ingress channel loopback on the connection before (s)he starts to pump OAM loopback cell traffic. The command for enable the connection loopback is shown in the following. At CLI prompt: Enable connection loopback, addchanloop <ifNum> <vpi> <vci> <mode> Note: AXSME is supporting ingress channel loopback, so the valid parameter for mode is 1. Disable connection loopback, delchanloop <ifNum> <vpi> <vci> Hardware: AXSME OC-3
CSCdx04460	Symptom: Popup message is display during normal telnet session. Condition: After doing a resetsys on the shelf. Workaround: None. Hardware: PXM45
CSCdx12589	Symptom: PXM-45 can be booted with wrong code image for chassis. Condition: PXM-45 and HD back card previously configured in an 8850 chassis with *_mgx.fw firmware can boot in an MGX 8830 chassis with that same firmware. MGX 8830 Requires *_m30.fw firmware. Workaround: None. Hardware: PXM1E
CSCdx31466	Symptom: Danglers remain after using the CLI command delcons. This is the caveat with these commands. While provisioning connections in bulk (copycons/delcons), if the PNNI layer get busy due to re-route/de-route activity, then it will reject the deletion. Condition: The command delcons was developed for Dev-test usage only. This command is not recommended to be used on a production node due to resource problems generated by the flood of traps on each con deletion. Workaround: Use delcon for each individual PVC until a better method is developed see PXM release notes for description of cli commands delcon and delcons usage. Hardware: PXM45
CSCdx33947	Symptom: Ingress and Egress cell count from "dsppotcnt" do not reflect the actual count. Conditions: Unknown. Workaround: None. Hardware: AXSM OC-12
CSCdx34833	Symptom: Popup message seen on the cli display. Condition: While the shelf was idle and no cli command where being executed. Workaround: None. Hardware: PXM45B
CSCdx41607	Symptom: User cannot reliably determine how signalling was assigned on a pnport via runtime cli. Condition: dsppnportsig or other cli commands do not show how a signalling type was assigned to a pnport. It shows what was assigned to a type but not how it was assigned. Workaround: Use shell-conn commands or look at log file to determine how signalling was assigned. Hardware: PXM45
CSCdx43364	Symptom: The OID represents the interface name (ifName). The interface "sw1" is the main switch interface on the RPM. There can be only one main switch interface that can exist per RPM card and multiple sub-Interfaces. The switch subinterfaces (subinterfaces of the main switch interface) are represented by "sw1.x" on RPM. This snmp response is returned by the RPM. The ifTable does not display multiple instances for "sw1". The snmp query on ifName seems to always return "sw1" 5 times. This is not correct. Condition: If we do snmpget on ifName, then it's possible to see multiple records for the same "Sw1" interface. To get the ifIndex for a particular interface, we can try to walk on ifDescr. Workaround: None. Hardware: PXM45
CSCdx45501	Symptom: Command display field do not match the cnf fields. Condition: When executing the cnfpnni-routing-policy, and the dsppnni-routing-policy command. Workaround: None. Hardware: PXM45B
CSCdx56762	Symptom: snmpRat Task crashes if Standby PXM1E does not have IP address configured. Condition: This happens only in a redundant PXM1E configuration if the standby does not have a valid IP address configured. Workaround: Manually configure an IP address on the Standby PXM1E card (at the backup boot prompt) before the standby comes up. Hardware: PXM1E
CSCdx62800	Symptoms: MGX45 CLI Reference MAnual needs updated. Conditions: 4 new commands missing out of the manual. Workaround: None. Hardware: PXM45
CSCdx68030	Symptom: The addlnloop command does not display option for E3 and DS3. Conditions: When issuing the addlnloop command without an argument, the display does not show the E3 or DS3 options. Workaround: Issue the addlnloop command with the -E3 or -DS3 options. Hardware: PXM1E
CSCdx81165	Symptom: Slot 11 does not send out AIS for DAX or Non-DAX SPVC's. Conditions: When slot #11 is the active slot. Workaround: None. Hardware: AXSMB OC-3

Anomalies Resolved in Release 3.0.00

Table 44 lists the anomalies resolved in Release 3.0.00. Specifically, these are anomalies opened against version 2.0 or 2.1 images and fixed in 3.0--but not fixed in 2.0 or 2.1.

Table 44 Anomalies Resolved in Release 3.0.00

Bug	Description
S1 Bugs
CSCdw66847	Symptom: Signalling thresholds on the cosb 16 not working in packet discard mode. Conditions: If the signalling traffic is artificially pumped at a very high rate (ex: OC3/OC12) the qbin thresholds for cosb number 16 are discarding the cells indiscriminately. Workaround: Change the signalling cosb number to 14 (it is available) in the card's SCT file.

Known Route Processor Module or MPLS Caveats

For information about caveats with the RPM-PR or RPM/B card, refer to Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for MGX Release 1.2.11 and MGX Release 3.

For information about caveats with the RPM-XF card, refer to Release Notes for Cisco MGX Route Processor Module (RPM-XF) for MGX 8850 (PXM45) Release 3.0.10.

MGX-RPM-XF-512 Caveats

The new MGX-RPM-XF-512 card is supported in MGX 8850 (PXM45) starting with Release 3.0.00 and in MGX 8950 starting with Release 3.0.10.

For information about caveats with the MGX-RPM-XF-512 card, refer to Release Notes for Cisco MGX Route Processor Module (RPM-XF) for Release 3.0.10 of MGX 8850 (PXM45).

Acronyms

Table 45 describes the acronyms used in this document.

Table 45 Acronyms and Their Descriptions  

Acronym	Description
AINI	ATM Inter-Network Interface
APS	automatic protection switching
ATM	asynchronous transmission mode
AXSM	ATM Switch Service Module
B-ISUP	Broadband ISDN User Part
BPX	an earlier Cisco backbone switch
CLI	command line interface
CWM	Cisco Wide Area Network Manager
DSLAM	digital subscriber line access module
IETF	Internet Engineering Task Force
LDP	label distribution protocol
LSC	label switch controller
LSP	label switched paths
LSR	label switch router
MIB	management information base
MPG	multiple peer group
MPLS	multiple protocol label switching
NCDP	network clock distribution protocol
PER	product enhancement request
PNNI	private network-to-network interface
PXM	processor switch module
RPM	route processor module
RPM-PR	route processor module - Premium
RPM-XF	route processor module - Express Forwarding
SCT	service class template
SLA	service level agreement
SM	service module (a card)
SNMP	simple network management protocol
SPVC	soft permanent virtual connection
SVC	switched virtual circuit
UNI	User-Network Interface
VCI	virtual channel identifier
VPI	virtual path identifier

Documentation

The documents listed in this section are for the releases that are compatible with Release 3.0.20.

---

Note The technical documentation that supports this release may include descriptions of features not implemented as of this printing.

---

Changes to this Document

Table 46 describes changes made to these release notes that caused the release notes to go from OL-5179-01 Rev. A0, December 11, 2003 to OL-5179-01 Rev. B0 on January 21, 2004.

Table 46 Changes that Caused Revision B of this Document

Section	Change
Frame Discard Feature	Describes changes in the behavior of the Frame Discard feature from Releases 3.0.23 to 4.0.12.
Frame Discard	A Note describes an important caveat for virtual path connections (VPCs) that were added with frame discard enabled before releases 3.0.23 or 4.0.10.
All	Some terminology was corrected, for example MGX1 became MGX1. (MGX1 represents the MGX switches that use a PXM1 controller card; MGX 2 represents the MGX switches that use a PXM45 or a PXM1E card.)

Related Documentation

Table 47 lists the release notes that support platforms that are interoperable with release 3.0.20. Release notes are available online only.

Table 48 through Table 58 list the Cisco publications that support the previous major release of these interoperable platforms. The publications contain additional information related to the operation of this product and associated equipment in a Cisco WAN switching network.

Table 47 Release Notes for Interoperable Platforms 

Product	Release	Part	Location
CWM (for Solaris 8)	11.0.10P1	OL-3476-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/svplus/11/index.htm
CWM (for Solaris 7)	11.0.10P1	OL-3477-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/svplus/11/index.htm
MGX 8230, 8250, and MGX 8850 (PXM1)	1.2.13	OL-3484-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/12/rnotes/index.htm
MGX 8850 (PXM45), MGX 8850 (PXM1E), and MGX 8830	3.0.20	OL-3482-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/relnote/index.htm
MGX 8950	3.0.20	OL-3483-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8950/relnotes/index.htm
BPX/IGX	9.3.45	OL-3489-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/bpx8600/9_3_4/rnote/index.htm
SES	3.0.20	OL-3485-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/bpx8600/pnni_ses/rel30/relnotes/index.htm
MGX-RPM-PR-256/512	12.2(11)T2	OL-3481-01	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/rpm/relnotes/index.htm
MGX-RPM-XF-512	12.2(11)YP	OL-2912-01 B0	http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/rpm/relnotes/index.htm

Cisco WAN Manager Release 11

The product documentation for the Cisco WAN Manager (CWM) network management system for Release 11 is listed in Table 48.

Table 48 Cisco WAN Manager Release 11 Documentation 

Title	Description
Cisco WAN Manager Installation Guide for Solaris 7, Release 11 DOC-7813567=	Provides procedures for installing Release 11 of the CWM network management system and Release 5.4 of CiscoView on a Solaris 7 platform.
Cisco WAN Manager Installation Guide for Solaris 8, Release 11 DOC-7814230=	Provides procedures for installing Release 11 of the CWM network management system and Release 5.4 of CiscoView on a Solaris 8 platform.
Cisco WAN Manager User's Guide, Release 11 DOC-7813568=	Describes how to use the CWM Release 11 software, which consists of user applications and tools for network management, connection management, network configuration, statistics collection, and security management.
Cisco WAN Manager SNMP Service Agent, Release 11 DOC-7813569=	Provides information about the CWM Simple Network Management Protocol Service Agent, an optional adjunct to CWM that is used for managing Cisco WAN switches using SNMP.
Cisco WAN Manager Database Interface Guide, Release 11 DOC-7813542=	Provides information about accessing the CWM Informix OnLine database that is used to store information about the network elements.

Table 49 WAN CiscoView Release 3 Documentation 

Title	Description
WAN CiscoView Release 3 for the MGX 8220 Edge Concentrator, Release 5 DOC-7812768=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco MGX 8220 Edge Concentrator.
WAN CiscoView Release 3 for the MGX 8850 Edge Switch, Release 1 DOC-7811242=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco MGX 8850 Edge Switch.
WAN CiscoView Release 3 for the MGX 8250 Edge Concentrator, Release 1 DOC-7811241=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco MGX 8250 Edge Concentrator.
WAN CiscoView Release 3 for the MGX 8230 Multiservice Gateway, Release 1 DOC-7810926=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco MGX 8230 Multiservice Gateway.
WAN CiscoView for Release 2 of the MGX 8850 DOC-7810349=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco MGX 8850 switch.
WAN CiscoView Release 3 for IGX 8400 Switches DOC-78111243=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco IGX 8400 switch.
WAN CiscoView Release 3 for BPX 8600 Switches DOC-7811244=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco BPX 8600 switch.
WAN CiscoView Release 3 for the BPX SES PNNI Controller DOC-7812303=	Provides instructions for using this network management software application that allows you to perform minor configuration and troubleshooting tasks for element management of the Cisco BPX SES1 PNNI2 Controller.

1 SES = Service Expansion Shelf Private Network-to-Network Interface 2 PNNI = Private Network-to-Network Interface

Cisco MGX 8850 (PXM45) Multiservice Switch Release 3

The product documentation for installing and operating the Cisco MGX 8850 (PXM45) Multiservice Switch Release 3 is listed in Table 50.

Table 50 Cisco MGX 8850 (PXM45) Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8850 (PXM45 and PXM1E) Hardware Installation Guide, Release 3 DOC-7814250=	Describes how to install the Cisco MGX 8850 switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The Cisco MGX 8850 switch uses either a PXM45 or a PXM1E controller card and provides support for both broadband and narrowband service modules.
Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Command Reference, Release 3 DOC-7814789=	Describes the PXM commands that are available on the CLI1 of the Cisco MGX 8830, Cisco MGX 8850, and Cisco MGX 8950 switches.
Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3 DOC-7814788=	Describes how to configure the Cisco MGX 8850 (PXM45) and the Cisco MGX 8950 switches with a PXM45 controller to operate as ATM edge or core switches. This guide also provides some operation and maintenance procedures.
Cisco SNMP Reference for MGX 8850 (PXM45 and PXM1E), MGX 8950, and MGX 8830, Release 3 DOC-7814747=	Provides information on all supported MIB2 objects, support restrictions, and traps for AXSM, AXSM-E, SRME, FRSM12, PXM45, PXM1E, RPM-PR, and RPM-XF.
Cisco Frame Relay Software Configuration Guide and Command Reference for the MGX 8850 FRSM12 Card, Release 3 DOC-7810327=	Describes how to use the high-speed Frame Relay (FRSM-12-T3E3) commands that are available in the CLI of the Cisco MGX 8850 (PXM45) switch.
Cisco AXSM Software Configuration Guide and Command Reference for MGX 8850 (PXM45) and MGX 8950, Release 3 DOC-7814257=	This guide explains how to configure the AXSM cards for operation and contains a command reference that describes the AXSM commands in detail. The AXSM cards covered in this manual are the AXSM, AXSM/B, AXSM-E, and AXSM-32-T1E1-E.
Cisco MGX and SES PNNI Network Planning Guide DOC-7813543=	Provides guidelines for planning a PNNI network that uses the Cisco MGX 8850 (PXM45 and PXM1E), Cisco MGX 8950, and the Cisco BPX 8600 switches. When connected to a PNNI network, each Cisco BPX 8600 Series Switch requires an SES3 for PNNI route processing.
Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3 OL-2768-01 (online only)	Describes how to install and configure the Cisco MGX Route Processor Module (RPM-XF) in the Cisco MGX 8850 Release 3 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Cisco VISM Installation and Configuration Guide, Release 3.0 OL-2521-01 (online only)	Describes how to install and configure VISM4 in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides troubleshooting, maintenance, cable and connector specifications, and Cisco CLI command configuration information.
Regulatory Compliance and Safety Information for the Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Switches DOC-7814790=	Provides regulatory compliance, product warnings, and safety recommendations for the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 switches.

1 CLI = command line interface 2 MIB = Management Information Base 3 SES = Service Expansion Shelf 4 VISM = Voice Interworking Service Module

Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3

The product documentation for installing and operating the Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3 is listed in Table 51.

Table 51 Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8850 (PXM45 and PXM1E) Hardware Installation Guide, Release 3 DOC-7814250=	Describes how to install the Cisco MGX 8850 routing switch. This documentation explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The Cisco MGX 8850 switch uses either a PXM45 or a PXM1E controller card and provides support for both broadband and narrowband service modules.
Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3 DOC-7814248=	Describes how to configure the Cisco MGX 8850 (PXM1E) and the Cisco MGX 8830 switches with PXM1E controller cards to operate as ATM edge switches. This guide also provides some operation and maintenance procedures.
Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Command Reference, Release 3 DOC-7814789=	Describes the PXM commands that are available on the CLI of the Cisco MGX 8830, Cisco MGX 8850, and Cisco MGX 8950 switches.
Cisco SNMP Reference for MGX 8850 (PXM45 and PXM1E), MGX 8950, and MGX 8830, Release 3 DOC-7814747=	Provides information on all supported MIB objects, support restrictions, and traps for AXSM, AXSM-E, SRME, FRSM12, PXM45, PXM1E, RPM-PR, and RPM-XF.
Cisco Frame Relay Software Configuration Guide and Command Reference for MGX Switches (PXM1E) DOC-7814255=	Provides software configuration procedures for provisioning connections and managing the FRSM cards supported in this release. Also provides command descriptions for all FRSM commands.
Cisco AUSM Software Configuration Guide and Command Reference for MGX 8850 (PXM1E) and MGX 8830, Release 3 DOC-7814254=	Provides software configuration procedures for provisioning connections and managing the AUSM cards supported in this release. Also provides command descriptions for all AUSM commands.
Cisco CESM Software Configuration Guide and Command Reference for MGX 8850 (PXM1E) and MGX 8830, Release 3 DOC-7814256=	Provides software configuration procedures for provisioning connections and managing the CESM cards supported in this release. Also provides command descriptions for all CESM commands.
Cisco MGX and SES PNNI Network Planning Guide DOC-7813543=	Provides guidelines for planning a PNNI network that uses Cisco MGX 8850 (PXM45 and PXM1E), Cisco MGX 8950, and Cisco BPX 8600 switches. When connected to a PNNI network, each Cisco BPX 8600 Series Switch requires an SES for PNNI route processing.
Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3 OL-2768-01 (online only)	Describes how to install and configure the Cisco MGX Route Processor Module (RPM-XF) in the Cisco MGX 8850 Release 3 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Cisco VISM Installation and Configuration Guide, Release 3.0 OL-2521-01 (online only)	Describes how to install and configure VISM in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides troubleshooting, maintenance, cable and connector specifications, and Cisco CLI command configuration information.
Regulatory Compliance and Safety Information for the Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Switches DOC-7814790=	Provides regulatory compliance, product warnings, and safety recommendations for the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 switches.

Cisco MGX 8950 Multiservice Switch Release 3

The product documentation for installing and operating the Cisco MGX 8950 Multiservice Switch Release 3 is listed in Table 52.

Table 52 Cisco MGX 8950 Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8950 Hardware Installation Guide, Release 3 DOC-7814147=	Describes how to install the Cisco MGX 8950 core switch. This documentation explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The Cisco MGX 8950 switch uses a PXM45/B controller card and provides support for broadband service modules.
Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Command Reference, Release 3 DOC-7814789=	Describes the PXM commands that are available on the CLI of the Cisco MGX 8830, Cisco MGX 8850, and Cisco MGX 8950 switches.
Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3 DOC-7814788=	Describes how to configure the Cisco MGX 8850 (PXM45) and the Cisco MGX 8950 switches with a PXM45 controller to operate as ATM edge or core switches. This guide also provides some operation and maintenance procedures.
Cisco AXSM Software Configuration Guide and Command Reference for MGX 8850 (PXM45) and MGX 8950, Release 3 DOC-7814257=	This guide explains how to configure the AXSM cards for operation and contains a command reference that describes the AXSM commands in detail. The AXSM cards covered in this manual are the AXSM, AXSM/B, AXSM-E, and AXSM-32-T1E1-E.
Cisco SNMP Reference for MGX 8850 (PXM45 and PXM1E), MGX 8950, and MGX 8830, Release 3 DOC-7814747=	Provides information on all supported MIB objects, support restrictions, and traps for AXSM, AXSM-E, SRME, FRSM12, PXM45, PXM1E, RPM-PR, and RPM-XF.
Cisco MGX and SES PNNI Network Planning Guide DOC-7813543=	Provides guidelines for planning a PNNI network that uses the Cisco MGX 8850 (PXM45 and PXM1E), Cisco MGX 8950, and the Cisco BPX 8600 switches. When connected to a PNNI network, each Cisco BPX 8600 Series Switch requires an SES for PNNI route processing.
Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3 OL-2768-01 (online only)	Describes how to install and configure the Cisco MGX Route Processor Module (RPM-XF) in the Cisco MGX 8850 switch Release 3. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Regulatory Compliance and Safety Information for the Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Switches DOC-7814790=	Provides regulatory compliance, product warnings, and safety recommendations for the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 switches.

SES PNNI Controller Release 3

The product documentation for installing and operating the Service Expansion Shelf (SES) Private Network-to-Network Interface (PNNI) Controller Release 3 is listed in Table 53.

Table 53 SES PNNI Controller Release 3 Documentation 

Title	Description
Cisco SES PNNI Controller Software Configuration Guide, Release 3 DOC-7814258=	Describes how to configure, operate, and maintain the SES PNNI Controller.
Cisco SES PNNI Controller Command Reference, Release 3 DOC-7814260=	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 Cisco MGX 8850 (PXM45 and PXM1E), Cisco MGX 8950, and the Cisco BPX 8600 switches. When connected to a PNNI network, each Cisco BPX 8600 Series Switch requires an SES for PNNI route processing.

Cisco MGX 8830 Multiservice Switch Release 3

The product documentation for installing and operating the Cisco MGX 8830 Multiservice Switch Release 3 is listed in Table 54.

Table 54 Cisco MGX 8830 Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8830 Hardware Installation Guide, Release 3 DOC-7814547=	Describes how to install the Cisco MGX 8830 edge switch. This documentation explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The Cisco MGX 8830 switch uses a PXM1E controller card and provides PNNI support for narrowband service modules.
Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3 DOC-7814248=	Describes how to configure the Cisco MGX 8850 (PXM1E) and the Cisco MGX 8830 switches with PXM1E controller cards to operate as ATM edge switches. This guide also provides some operation and maintenance procedures.
Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Command Reference, Release 3 DOC-7814789=	Describes the PXM commands that are available on the CLI of the Cisco MGX 8830, Cisco MGX 8850, and Cisco MGX 8950 switches.
Cisco SNMP Reference for MGX 8850 (PXM45 and PXM1E), MGX 8950, and MGX 8830, Release 3 DOC-7814747=	Provides information on all supported MIB objects, support restrictions, and traps for AXSM, AXSM-E, SRME, FRSM12, PXM45, PXM1E, RPM-PR, and RPM-XF.
Cisco AUSM Software Configuration Guide and Command Reference for MGX 8850 (PXM1E) and MGX 8830, Release 3 DOC-7814254=	Provides software configuration procedures for provisioning connections and managing the AUSM cards supported in this release. Also provides command descriptions for all AUSM commands.
Cisco CESM Software Configuration Guide and Command Reference for MGX 8850 (PXM1E) and MGX 8830, Release 3 DOC-7814256=	Provides software configuration procedures for provisioning connections and managing the CESM cards supported in this release. Also provides command descriptions for all CESM commands.
Cisco Frame Relay Software Configuration Guide and Command Reference for MGX Switches (PXM1E) DOC-7814255=	Provides software configuration procedures for provisioning connections and managing the FRSM cards supported in this release. Also provides command descriptions for all FRSM commands.
Cisco VISM Installation and Configuration Guide, Release 3.0 OL-2521-01 (online only)	Describes how to install and configure VISM in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides troubleshooting, maintenance, cable and connector specifications, and Cisco CLI command configuration information.
Regulatory Compliance and Safety Information for the Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Switches DOC-7814790=	Provides regulatory compliance, product warnings, and safety recommendations for the Cisco MGX 8830, Cisco MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 switches.

Cisco WAN Switching Software Release 9.3

The product documentation for installing and operating the Cisco WAN Switching Software Release 9.3 is listed in Table 55.

Table 55 Cisco WAN Switching Software Release 9.3 Documentation 

Title	Description
Cisco BPX 8600 Series Installation and Configuration, Release 9.3.30 DOC-7812907=	Provides a general description and technical details of the Cisco BPX broadband switch.
Cisco WAN Switching Command Reference, Release 9.3.30 DOC-7812906=	Provides detailed information on the general command line interface commands.
Cisco IGX 8400 Series Installation Guide, Release 9.3.30 OL-1165-01 (online only)	Provides hardware installation and basic configuration information for Cisco IGX 8400 Series Switches that are running Switch Software Release 9.3.30 or earlier.
Cisco IGX 8400 Series Provisioning Guide, Release 9.3.30 OL-1166-01 (online only)	Provides information for configuration and provisioning of selected services for the Cisco IGX 8400 Series Switches that are running Switch Software Release 9.3.30 or earlier.
9.3.42 Version Software Release Notes Cisco WAN Switching System Software OL-2911-01 (online only)	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.
Cisco IGX 8400 Series Regulatory Compliance and Safety Information DOC-7813227=	Provides regulatory compliance, product warnings, and safety recommendations for the Cisco IGX 8400 Series Switch.

Cisco MGX 8850 (PXM1) Edge Concentrator Switch Release 1

The product documentation for installing and operating the Cisco MGX 8850 (PXM1) Edge Concentrator Switch Release 1 is listed in Table 56.

Table 56 Cisco MGX 8850 (PXM1) Edge Concentrator Switch Release 1 Documentation 

Title	Description
Cisco MGX 8850 Multiservice Switch Installation and Configuration, Release 1.1.3 DOC-7811223=	Provides installation instructions for the Cisco MGX 8850 (PXM1) Edge Concentrator Switch.
Cisco MGX 8800 Series Switch Command Reference, Release 1.1.3 DOC-7811210=	Provides detailed information on the general command line for the Cisco MGX 8850 (PXM1) Edge Concentrator Switch.
Cisco MGX 8800 Series Switch System Error Messages, Release 1.1.3 DOC-7811240=	Provides error message descriptions and recovery procedures.
Cisco MGX 8850 Multiservice Switch Overview, Release 1.1.3 OL-1154-01 (online only)	Provides a technical description of the system components and functionality of the Cisco MGX 8850 (PXM1) Edge Concentrator Switch from a technical perspective.
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1 DOC-7812278=	Describes how to install and configure the Cisco MGX Route Processor Module (RPM/B and RPM-PR) in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Cisco VISM Installation and Configuration Guide, Release 3.0 OL-2521-01 (online only)	Describes how to install and configure VISM in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides troubleshooting, maintenance, cable and connector specifications, and Cisco CLI command configuration information.
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1) Software Version 1.2.11 OL-2916-01 (online only)	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.

Cisco MGX 8250 Edge Concentrator Switch Release 1

The documentation for installing and operating the Cisco MGX 8250 Edge Concentrator Switch Release 1 is listed in Table 57.

Table 57 Cisco MGX 8250 Edge Concentrator Switch Release 1 Documentation 

Title	Description
Cisco MGX 8250 Edge Concentrator Installation and Configuration, Release 1.1.3 DOC-7811217=	Provides installation instructions for the Cisco MGX 8250 Edge Concentrator Switch.
Cisco MGX 8250 Multiservice Gateway Command Reference, Release 1.1.3 DOC-7811212=	Provides detailed information on the general command line interface commands.
Cisco MGX 8250 Multiservice Gateway Error Messages, Release 1.1.3 DOC-7811216=	Provides error message descriptions and recovery procedures.
Cisco MGX 8250 Edge Concentrator Overview, Release 1.1.3 DOC-7811576=	Describes the system components and functionality of the Cisco MGX 8250 Edge Concentrator Switch from a technical perspective.
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1 DOC-7812278=	Describes how to install and configure the Cisco MGX Route Processor Module (RPM/B and RPM-PR) in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Cisco VISM Installation and Configuration Guide, Release 3.0 OL-2521-01 (online only)	Describes how to install and configure VISM in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides troubleshooting, maintenance, cable and connector specifications, and Cisco CLI command configuration information.
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1) Software Version 1.2.11 OL-2916-01 (online only)	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.

Cisco MGX 8230 Edge Concentrator Switch Release 1

The documentation for installing and operating the Cisco MGX 8230 Edge Concentrator Switch Release 1 is listed in Table 58.

Table 58 Cisco MGX 8230 Edge Concentrator Switch Release 1 Documentation 

Title	Description
Cisco MGX 8230 Edge Concentrator Installation and Configuration, Release 1.1.3 DOC-7811215=	Provides installation instructions for the Cisco MGX 8230 Edge Concentrator Switch.
Cisco MGX 8230 Multiservice Gateway Command Reference, Release 1.1.3 DOC-7811211=	Provides detailed information on the general command line interface commands.
Cisco MGX 8230 Multiservice Gateway Error Messages, Release 1.1.3 DOC-78112113=	Provides error message descriptions and recovery procedures.
Cisco MGX 8230 Edge Concentrator Overview, Release 1.1.3 DOC-7812899=	Provides a technical description of the system components and functionality of the Cisco MGX 8230 Edge Concentrator Switch from a technical perspective.
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1 DOC-7812278=	Describes how to install and configure the Cisco MGX Route Processor Module (RPM/B and RPM-PR) in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Cisco VISM Installation and Configuration Guide, Release 3.0 OL-2521-01 (online only)	Describes how to install and configure VISM in the Cisco MGX 8850 (PXM1), Cisco MGX 8250, and Cisco MGX 8230 switches. Also provides troubleshooting, maintenance, cable and connector specifications, and Cisco CLI command configuration information.
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1) Software Version 1.2.11 OL-2916-01 (online only)	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.

Obtaining Documentation

These 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 this URL:

http://www.cisco.com

Translated documentation is available at this 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

---

Note Beginning May 2003, the multiservice switch documentation listed in Table 48 through Table 58 are no longer orderable. They are available online only.

---

You can order other Cisco documentation in these ways:

•Registered Cisco.com users (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 Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

How to Find Multiservice Switch Customer Documents Online

There are several ways you can find Multiservice Switch customer documents online.

If the Part Number is Known

Use the following procedure if you know or can find the document's part number.

---

---

Step 1 Obtain the document's part number from the "Guide to Multiservice Switch Documentation" that shipped with your product, or from the "Related Documentation" section in this Preface.

Step 2 In your browser's URL field, type www.cisco.com.

Step 3 In the top right search field, enter the document part number (for example, OL-3842-01) and click on GO.

---

If the Part Number is Not Known

Use the following procedures if you do not know or cannot find the document's part number.

Finding Cisco WAN Manager Documents

To find Cisco WAN Manager customer documents online:

---

---

Step 1 In your browser's URL field, type http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cwm.

Step 2 Look for the CWM release number.

---

Finding Multiservice Switch Documents

To find Multiservice Switch customer documents online:

---

---

Step 1 In your browser's URL field, type http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm.

Step 2 Look for the switch name, then release number (for example, MGX 8850 (PXM1E), then Release 4).

Documentation Feedback

You can submit comments electronically on Cisco.com. In the Cisco Documentation home page, click the Fax or Email option in the "Leave Feedback" section at the bottom of the page.

You can e-mail your comments to bug-doc@cisco.com.

You can submit your comments by mail by using the response card behind the front cover of your document or by writing 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 online 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 with these tasks:

•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

If you want to obtain customized information and service, you can self-register on Cisco.com. To access Cisco.com, go to this URL:

http://www.cisco.com

Technical Assistance Center

The Cisco Technical Assistance Center (TAC) is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two levels of support are available: the Cisco TAC Web Site and the Cisco TAC Escalation Center.

Cisco TAC inquiries 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.

The Cisco TAC resource that you choose is based on the priority of the problem and the conditions of service contracts, when applicable.

Cisco TAC Web Site

You can use the Cisco TAC Web Site 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 this URL:

http://www.cisco.com/tac

All customers, partners, and resellers who have a valid Cisco service 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 this URL to register:

http://www.cisco.com/register/

If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC Web Site, you can open a case online by using the TAC Case Open tool at this URL:

http://www.cisco.com/tac/caseopen

If you have Internet access, we recommend that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. 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 automatically opens a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this 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). When you call the center, please have available your service agreement number and your product serial number.

CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or Website 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. (0401R)

Copyright © 2003, 2004 Cisco Systems, Inc.
All rights reserved.