3.0.20 Release Notes for MGX 8850 (PXM45), MGX 8850 (PXM1E), and MGX 8830 [Cisco MGX 8800 Series Switches]

Table Of Contents

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

Contents

About Release 3.0.20

Type of Release

Locating Software Updates

Release Note Document Changes

New Features and Enhancements in 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

Service Class Template File Information

New Commands

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

VISM Limitations

RPM-PR and RPM-XF Limitations

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

Important Upgrade Notes

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

MGX 8830 Caveats

MGX 8830 Open Caveats in Release 3.0.20

Status of MGX 8830 Caveats Found in Previous Releases

MGX 8830 Resolved Caveats in Release 3.0.20

MGX 8850 Caveats

MGX 8850 Open Caveats in Release 3.0.20

Status of MGX 8850 Caveats Found in Previous Releases

MGX 8850 Resolved Caveats in Release 3.0.20

Known Route Processor Module or MPLS Caveats

MGX-RPM-XF-512 Caveats

Acronyms

Documentation

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

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Cisco TAC Web Site

Cisco TAC Escalation Center

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

Contents

About Release 3.0.20

These release notes describe the system requirements, new features, and limitations that apply to Release 3.0.20 of the MGX 8850 (PXM45), MGX 8850 (PXM1E), and the MGX 8830 multiservice switch. These notes also contain Cisco support information.

Release 3.0.20 improves upon the previous 3.0.00 and 3.0.10 Releases for the MGX 8850 and MGX 8830 by providing enhancements to existing features and capabilities.

These release notes accompany the technical manuals listed in the "Related Documentation" section.

For information about MGX 8950 Release 3.0.20, see the Release Notes for Cisco MGX 8950 Software Release 3.0.20.

Type of Release

Release 3.0.20 is a software release for the MGX 8830 PNNI routing switch.

Release 3.0.20 is a software release for the MGX 8850 (PXM1E) switch.

Release 3.0.20 is a software release for the MGX 8850 (PXM45) switch.

Locating Software Updates

Software updates are located at Cisco Connection Online (CCO) at the following location:

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

Software updates are located at Cisco Connection Online (CCO) at the following location:

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

Release Note Document Changes

These changes have been made to this document since the Rev. A0, December 11, 2002 revision.

•Replaced reference to MGX 8830, MGX 8850 (PXM1E and PXM45), and MGX 8950 Command Reference, Release 3, at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/axsm/index.htm with AXSM Software Configuration Guide and Command Reference for MGX 8850 (PXM45) and MGX 8950, Release 3, at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/axsm/index.htm.

•Removed non-supported SRM-3T3/C card from hardware tables and from Limitations section.

•Added the caution about replacing T1 or T3 cards with E1 or E3 cards (or vice versa) to use the clrsmcnf command.

•Added syntax for enableaxsmbaps command to clarify usage.

•Added limitation about when configuring virtual interfaces on AXSM cards, that the physical interface must be of the same ATM header type.

•Added missing SMB-4-155 back card for the AXSM-8-155-E front card.

New Features and Enhancements in 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.

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/8950 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)

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

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.

Service Class Template File Information

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

New Commands

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 3 lists Cisco WAN or Cisco IOS products that are interoperable with Release 3.0.20.

Table 3 MGX 3.0.20 Compatibility Matrix

Product

N

N-1

N-2

CWM

11.0.10P1

11.0.10

N/A

MGX 8230, 8250, and MGX 8850 (1.x only)

1.2.13

1.2.02

1.1.34/1.1.42

MGX 8850, PXM45

3.0.20

3.0.10

2.1.80

MGX 8850, PXM1E

3.0.20

3.0.10

3.0.00

MGX 8830

3.0.20

3.0.10

3.0.00

MGX 8950

3.0.20

3.0.10

2.1.80

BPX/IGX

9.3.45

9.3.42/9.3.36

9.2.41

BXM FW

MFW

MFV

MFR

UXM FW

ACJ

ACH

ABT

URM FW

XBB

XBB

XBA

MGX 8220

5.0.19

4.1.12

—

SES

3.0.20

3.0.10

1.1.79

MGX-RPM-PR-256/512

12.2(11)T2

12.2(11)T1

12.2(8)T4

MGX-RPM-XF-512

12.2(11)YP

12.2(8)YP

—

VISM

3.1.00

2.2.1

—

MGX and RPM Software Version Compatibility Matrix

Table 4 lists the software that is compatible for use in a switch running Release 3.0.20 software.

Table 4 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.020.000_bt.fw

3.0.20

pxm45_003.000.020.000_mgx.fw

3.0.20

3.0.20

PXM45/B

PXM1E-4-155

pxm1e_003.000.020.000_bt.fw

3.0.20

pxm1e_003.000.020.000_mgx.fw
(MGX 8850 chassis only)

3.0.20

3.0.20

PXM1E-8-T3E3

PXM1E-16-T1E1

PXM1E-COMBO
See note below.

PXM1E-4-155

pxm1e_003.000.020.000_bt.fw

3.0.20

pxm1e_003.000.020.000_m30.fw
(MGX 8830 chassis only)

3.0.20

3.0.20

PXM1E-8-T3E3

PXM1E-16-T1E

PXM1E-COMBO
See note below.

AXSM-1-2488

axsm_003.000.020.000_bt.fw

3.0.20

axsm_003.000.020.000.fw

3.0.20

3.0.20

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.020.000_bt.fw

3.0.20

axsme_003.000.020.000.fw

3.0.20

3.0.20

AXSM-8-155-E

AXSM-16-T3E3-E

AXSM-32-T1E1-E

FRSM-12-T3E3

frsm12_003.000.020.000_bt.fw

3.0.20

frsm12_003.000.020.000.fw

3.0.20

3.0.20

MGX-VISM-PR-8T1

vism_8t1e1_VI8_BT_3.1.00.fw

3.1.00

vism_8t1e1_003.051.000.000.fw (CALEA version)

vism_8t1e1_003.001.000.000.fw (non-CALEA version)

3.51.0.0 (CALEA),3.1.00 (non-CALEA)

3.51.0.0 (CALEA),3.1.00 (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.002.000.fw

20.0.2.0

20.0.2.0

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.003.000.fw

20.0.3.0

20.0.3.0

MGX-AUSM-8E1/B

AX-FRSM-8E1

frsm_8t1e1_FR8_BT_1.0.02.fw

1.0.02

frsm_8t1e1_020.000.003.000.fw

20.0.3.0

20.0.3.0

AX-FRSM-8E1-C

AX-FRSM-8T1

AX-FRSM-8T1-C

MGX-FRSM-HS2/B

frsm_vhs_VHS_BT_1.0.04.fw

1.0.04

frsm_vhs_020.000.003.000.fw

20.0.3.0

20.0.3.0

MGX-RPM-PR-256

rpm-boot-mz.122-11.T2

12.2(11)T2

rpm-js-mz.122-11.T2

12.2(11)T2

12.2(11)T2

MGX-RPM-PR-512

MGX-RPM-XF-512

rpmxf-boot-mz.122-11.YP

12.2(11)YP

rpmxf-js-mz.122-11.YP

12.2(11)YP

12.2(11)YP

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

Additional Notes

The SNMP MIB release for 3.0.20 is mgxmibs3020.tar.

Table 5 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 5 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:

•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 6 lists MGX 8850 (PXM45) APS connectors.

Table 6 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 7 lists MGX 8850 (PXM1E) APS connectors.

Table 7 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 8 lists MGX 8830 APS connectors.

Table 8 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 9 lists Product IDs, 800 part numbers, and revision levels for the MGX 8850 (PXM45).

Table 9 Card Numbers and Revisions Supported in Release 3.0.20 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-8T1¹

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-CON²

800-05307-01

-A0

MGX-8850-APS-CON1

800-20640-01

-A0

¹R means that this is a redundant card.

²Either connector works for the AXSM cards in the MGX 8850 (PXM45).

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

Table 10 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-LHLX¹

—

MGX-GE-SX1

—

MGX-GE-ZX1

—

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

MGX 8850 (PXM1E) Product IDs and Card Types

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

Table 11 Card Numbers and Revisions Supported in Release 3.0.20 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-SFP¹

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-8E1²

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/B³

800-05463-02

-A0

800-05501-01

-A0

MGX-8850-APS-CON

800-20640-01

-A0

MGX-APS-CON

800-05307-01

-A0

¹These cards are required only if you need modular optics with the PXM1E-COMBO back card.

²R means that this is a redundant card.

³The SCSI2-2HSSI/B card has two different 800 part numbers, and both part numbers are valid.

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

Table 12 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-SFP2¹

—

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

—

¹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 13 lists Product IDs, 800 part numbers, and revision levels for the MGX 8830.

Table 13 Card Numbers and Revisions Supported in Release 3.0.20 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-SFP¹

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-8E1²

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/B³

800-05463-02

-A0

800-05501-01

-A0

MGX-VISM-PR-8E1

800-07991-02

-A0

MGX-VISM-PR-8T1

800-07990-02

-A0

¹These cards are required only if you need modular optics with the PXM1E-COMBO back card.

²R means this is a redundant card.

³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 14 lists MGX 8830 front and back card types and whether APS connectors are supported.

Table 14 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-SFP¹

—

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

—

¹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.20.

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

•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 nonactive 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 nonsignaling 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 nongraceful. 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).

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

No restrictions have been identified.

Restrictions for Release 3.0.10

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.

•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 15 describes the configurable parameters for the cnfapsln command.
Table 15 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 16 describes the configurable parameters for the cnfapsln command.

Table 16 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 17 to help you determine which APS line is not functioning properly.

Note Table 17 is updated for Release 3.0.00.

Table 17 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 18 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 18 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 18 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.20

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.20 from Releases 2.1.80 and 3.0.10.

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

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

Important Upgrade Notes

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 nongraceful 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 uses the minVPI defined in the partition.

Installation and Upgrade Procedures

The procedures to upgrade to Release 3.0.10 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 order 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

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

MGX 8830 Caveats

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

•MGX 8830 Open Caveats in Release 3.0.20

•Status of MGX 8830 Caveats Found in Previous Releases

•MGX 8830 Resolved Caveats in Release 3.0.20

MGX 8830 Open Caveats in Release 3.0.20

Table 19 describes the Severity 1 open caveats for MGX 8830 Release 3.0.20.

Table 19 Severity 1 Open Caveats in MGX 8830 3.0.20 Software

DDTs Issue

Description

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

Table 20 describes the Severity 2 open caveats for MGX 8830 Release 3.0.20.

Table 20 Severity 2 Open Caveats in MGX 8830 3.0.20 Software

DDTs Issue

Description

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

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

CSCdy36815

Symptom: FRSM floods dsplog on pxm1e.

Conditions: Anytime an LCN gets out of alarm.

Workaround: Unknown.

Hardware: frsm-8t1e1

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

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

CSCdy71636

Symptom: The customer sees traffic stop in one direction spontaneously

Conditions: It happens spontaneously on an FRSM 8T1E1 card on a POP1 shelf. POP1 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

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

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

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

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

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

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

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 21 describes the Severity 3 open caveats for MGX 8830 Release 3.0.20.

Table 21 Severity 3 Open Caveats in MGX 8830 3.0.20 Software

DDTs Issue

Description

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

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

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

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

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

CSCdy71223

Symptom: LOA yields inconsistent active clk state in 2 PXM1E nodes.

Conditions: Create an LOA on 2 PXM1E nodes.

Workaround: Unknown.

Hardware: pxm1e

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

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

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

Status of MGX 8830 Caveats Found in Previous Releases

Table 22 lists the status of the caveats found in previous releases.

Table 22 Status of Caveats for Previous Releases

DDTs Issue

Status

Description

CSCdx48370

Severity 1; closed.

The hardware is working the way it was designed. Hardware: PXM1E

CSCdy66033

Severity 1; closed

Bug closed when problem was reproducible.

CSCdy75309

Severity 1; closed

Bug closed when problem was unreproducible.

CSCdy82600

Severity 1; closed

Bug closed because behavior is correct.

CSCdw41209

Severity 2; closed

Fixed in Release 20.0.3.0

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.

CSCdy07641

Severity 2; closed

Fixed in Release 20.0.3.

CSCdy22021

Severity 2; closed

Bug closed when problem was unreproducible.

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

CSCdy42188

Severity 2; closed

Duplicate of CSCdz28024, which is open

CSCdy43338

Severity 2; closed

Duplicate of CSCdw03223, which was closed because the behavior is correct.

CSCdy56415

Severity 2; closed

Duplicate of CSCdy84983, which is an open Severity 4 bug

CSCdy63336

Severity 2; closed

Fixed in Release 3.0.20

CSCdy64831

Severity 2; closed

Fixed in Release 3.0.20

CSCdy69231

Severity 2; closed

Fixed in Release 3.0.20

CSCdy70541

Severity 2; closed

Fixed in Release 3.0.20

CSCdy72444

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

CSCdy75753

Severity 2; closed

Fixed in Release 3.0.20

CSCdy77599

Severity 2; closed

Bug closed when problem was unreproducible.

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

CSCin15832

Severity 2; open

Bug was discovered to be against the CWM software

CSCdy43404

Severity 3; closed

Fixed in Release 3.0.20

CSCdy64834

Severity 3; closed

Fixed in Release 3.0.20

CSCdy64846

Severity 3; closed

Fixed in Release 3.0.20

CSCdy65252

Severity 3; closed

Fixed in Release 3.0.20

CSCdy70165

Severity 3; closed

Fixed in Release 3.0.20

CSCdy64834

Severity 3; closed

Fixed in Release 3.0.20

CSCdy64846

Severity 3; closed

Fixed in Release 3.0.20

CSCdy65252

Severity 3; closed

Fixed in Release 3.0.20

CSCdy81403

Severity 3; closed

Fixed in Release 3.0.20

CSCdy61482

Severity 4; open

CSCdy24461

Severity 6; open

MGX 8830 Resolved Caveats in Release 3.0.20

Table 23 lists the resolved caveats for the MGX 8830 Release 3.0.20 software.

Table 23 Resolved Caveats for MGX 8830 3.0.20 Software

DDTs Issue

Description

CSCdy18316

TB+ Hard: snmpPrxy assigns buffer once but frees i

CSCdy21738

REG3.0.10:After multiple resets the serv modules a

CSCdy21915

tDbgInTask memLeak

CSCdy25589

SLT:Doesn't create record to log file when environm

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, cnfsct

CSCdy37451

TB+ Hard2: IPC memLeak in buffer id 0x10002 and 0x10003

CSCdy38505

Memory leak:owner task:emRoot

CSCdy40747

improper error message when rejecting cnfcdmod wit

CSCdy43404

correct alarm is not displayed for srm card

CSCdy45214

CLI: remove cmdhistory since identical to history

CSCdy46259

need some debug functions to analyze the queues in

CSCdy49641

Shm trap gen error:trap#60082 bad input pslot

CSCdy53519

CLI: remove commands installhelp, cleanhelp, dsphe

CSCdy54849

Have CLI options to configure and clear E3 trail t

CSCdy55782

no max login attempts to MGX45.

CSCdy55786

Upon receiving AIS, line did not change looptime to

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

CSCdy58223

REG3.0.10: 24K SPVC fail when complex node(lowest

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

CSCdy65252

once clock is unlockable it needs to be reconfigur

CSCdy65978

TB+ Hard2: memLeak by clk module in ipc pool 2, 4

CSCdy67144

Slot info for CESM is different for active/stdby p

CSCdy69231

TB+ Hard2: pxm1e combos stby cd drops to idtmon af

CSCdy70752

TB+ Hard2: clk re-qualifies when revertion is enab

CSCdy72717

Ram sync error events in PCEMA

CSCdy73668

frsm stay in boot/empty after clrcnf no pxm1e

CSCdy75930

cnfcli accepts incomplete commands causing inconsi

CSCdy81725

The sonet line alarm clear trap #60105 was not rec

CSCdy84333

stdby card reset while it was in init state and

CSCdy85039

aps dsplog -minor display issue

CSCdz00771

SRM not displaying correct info for hardware rev

CSCdz02611

no trap 60052 is received after removing active P

CSCdz04722

los on active clock standby clock goes through req

CSCdz07991

Graceful upgrade for FRSM T3 cards fails

CSCdz11916

Cpro ramdisk error message should be suppressed un

CSCdz13329

PNNI should be able to handle unset NAKs and allow

CSCdz17165

SM ports in down state after upgrade or resetsys

CSCdz25071

interoperability testing between PXM1E and PXM-45 modules in

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

CSCdz40517

Secondary Clock config lost when configuring the revertive o

CSCdz40649

frsm0hs2b with frsm hssi card resets when you down the connection

CSCdz45071

FRSM-HS2B resets the stand by card in some specific operations.

MGX 8850 Caveats

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

•"MGX 8850 Open Caveats in Release 3.0.20"

•"Status of MGX 8850 Caveats Found in Previous Releases"

•"MGX 8850 Resolved Caveats in Release 3.0.20"

MGX 8850 Open Caveats in Release 3.0.20

Table 24 lists the Severity 1 open caveats for the MGX 8850 Release 3.0.20 software.

Table 24 Severity 1 Open Caveats for MGX 8850 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 25 lists the Severity 2 open caveats for the MGX 8850 Release 3.0.20 software.

Table 25 Severity 2 Open Caveats for MGX 8850 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

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 POP1 shelf. POP1 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

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 with frsm hssi card resets when you down the connection.

Condition: FRSM-HS2/B WITH FRSM-HSSI CARD RESETS WHEN YOU DOWN THE PVC ON NODE pxm1e, FRSM-HS2/B WITH FRSM-HSSI back card are there in the slot 3 and 4. It is configured as 1:1 redundancy when you down the pvc using dncon, the 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 26 lists the Severity 3 open caveats for the MGX 8850 Release 3.0.20 software.

Table 26 Severity 3 Open Caveats for MGX 8850 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: axsm1b_oc3

CSCdy79293

Symptom: AXSM reset due to watchdog timeout

Conditions: Unknown.

Workaround: Reset card if necessary

Hardware: axsm1b_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: axsm1b_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: axsm1b_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 8850 Caveats Found in Previous Releases

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

Table 27 Status of Severity 1, 2, and 3 Previous Caveats for MGX 8850

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.

CSCdx54945

Severity 1; closed

Duplicate of CSCdx55987, which is still open.

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 8850 Resolved Caveats in Release 3.0.20

Table 28 lists the resolved caveats for the MGX 8850 software Release 3.0.20.

Table 28 Resolved Caveats for MGX 8850 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 frivilous 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.

Table 29

Table 30

Table 31

Table 32

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 supports MGX 8850 (PXM45), 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 33 describes the acronyms used in this document.

Table 33 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

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.

Related Documentation

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

Table 35 through Table 45 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 34 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 35.

Table 35 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 36 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 SES¹ PNNI² Controller.

¹SES = Service Expansion Shelf Private Network-to-Network Interface

²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 37.

Table 37 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 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 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 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 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.

¹CLI = command line interface

²MIB = Management Information Base

³SES = Service Expansion Shelf

⁴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 38.

Table 38 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 39.

Table 39 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 40.

Table 40 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 41.

Table 41 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 42.

Table 42 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 43.

Table 43 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 44.

Table 44 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 45.

Table 45 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

You can order 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).

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.

Copyright © 2002, 2003 Cisco Systems, Inc.
All rights reserved..

Cisco MGX 8800 Series Switches

3.0.20 Release Notes for MGX 8850 (PXM45), MGX 8850 (PXM1E), and MGX 8830

Hierarchical Navigation

Downloads

Table Of Contents

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

Contents

About Release 3.0.20

Type of Release

Locating Software Updates

Release Note Document Changes

New Features and Enhancements in 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

Service Class Template File Information

New Commands

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

VISM Limitations

RPM-PR and RPM-XF Limitations

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

Copyright © 2002, 2003 Cisco Systems, Inc.
All rights reserved..