About Release 5.2.20

Version .201 of Release 5.2.20 is a patch release that does not introduce new features. The resolved anomalies for Version .201 are listed in Table 11.

These release notes describe the features, system requirements, and limitations that apply to Release 5.2.20 of the Cisco MGX 8850, Cisco MGX 8950, and Cisco MGX 8830 multiservice switches. These notes also contain Cisco support information.

Type of Release

Release 5.2.20 is a software release for the following Cisco MGX multiservice switches:

Features in Release 5.2.20

This sections describes the features in Release 5.2.20.

MPSM Licensing

Release 5.2.20 enforces licenses through sales and support, rather than through software locks. Table 1 lists the MPSM licenses that are required for MPSM services and features. You must purchase licenses for the services and features that you plan to use on each MSPM card.

Release 5.2.20 removes the PXM commands that support software locks and license alarms, and changes the commands that display alarm information. The following commands are removed or changed:

•Removed PXM commands:

–cnflic

–dsplics

–dspliccds

–dspliccd

–dsplicnodeid

–dsplicalms

•Changed PXM commands:

–clrallcnf—No longer has the clrLicense argument

–dspndalms—No longer displays license alarms

–dspcdalms—No longer displays license alarms

The MIB for Release 5.2.20 does not change, but returned license information is no longer valid.

Features in Release 5.2.10

Version .201 of Release 5.2.10 adds UDI compliance for the Cisco MGX 8830/B chassis, and Version .202 changes the Cisco product identifier (PID) from MGX8830/B to MGX8830/B-CH. The UDI consists of the Cisco product identifier, version identifier (VID), and serial number (SN).

The show inventory command displays the PID, VID, and SN for each product in the chassis. The following example shows typical UDI information for the Cisco MGX 8830/B chassis:

MGX-VXSM-T3 Card

Release 5.2.00 introduces a third VXSM card for the support of T3 lines. The card consists of a front card with six T3 ports and a half height back card with three T3 ports. The front card can be configured with either a single back card or two back cards.

AXSM-8-622-XG Card

The AXSM-8-622-XG is an 8-port OC-12/STM-4 card that supports clear-channel OC-12c/STM-4 or OC-12/STM-4 channelized down to OC-3c/STM-1 and DS3. This card complements the family of AXSM-XG cards, which includes the AXSM-16-155-XG, AXSM-4-2488-XG, and AXSM-1-9953-XG.

The AXSM-8-622-XG card has the following functionality:

•Independent channelization of each line.

•Common software for the MGX 8850, MGX 8830, and MGX 8950 chassis

•Maximum bandwidth is 2.4 Gbps when installed in a MGX 8850 or MGX 8830 chassis

•Maximum bandwidth is full card bandwidth when installed in MGX 8950 chassis

The AXSM-8-622-XG supports direct connection to BPX nodes with all ENNI functions available on AXSM and AXSM/B.

The AXSM-8-622-XG card has the following restrictions:

•All lines on the same bay must have the same SONET/SDH configuration

•Up to 1 ms of traffic loss after reconfiguration of lines/paths on the same bay

•The AXSM-XG does not support AutoRoute CoS queues

Graceful Upgrades to AXSM-XG Cards

In this release, you can gracefully upgrade AXSM, AXSM/B and AXSM-E cards to AXSM-XG cards. The AXSM-16-155-XG and AXSM-8-622-XG cards have a higher port density than the equivalent AXSM-E cards, and the AXSM-16-155-XG and AXSM-8-622-XG have better traffic management support than their AXSM/B counterparts.

Graceful upgrades simplify the process of migrating to the newer AXSM-XG cards. During the upgrade, the MGX control processor transfers the configuration/connection database from the previously installed AXSM card to the new AXSM-XG, which preserves all connection configurations. The upgrade process might cause an outage of up to four minutes.

You can install and operate any number of AXSM-XG cards in conjunction with AXSM, AXSM/B or AXSM-E in an MGX 8850 chassis equipped with the PXM45 processor. You can install and operate any number of AXSM-XG cards in conjunction with AXSM/B in an MGX 8950.

Card redundancy is supported only between identical front and back card pairs. For example, an AXSM-16-155-XG can only be redundant to another AXSM-16-155-XG, where the two front cards use an identical set of back cards.

•Supported on the BNC-3-T3E3 back card only and only in channelized mode. In other words, MLPPP is not supported for E3 in any form or unchannelized T3.

PXM45/C Support in the MGX 8830/B Chassis

A PXM45/C controller in an MGX8830/B chassis provides support for a selection of narrowband and broadband interfaces in an 8-slot chassis. The PXM45/C controller's 45Gbps switch matrix makes it possible to aggregate and switch traffic from a mix narrowband, DS3/E3, OC-3c/STM-1 and OC-12/STM-4 ATM ports, and simplifies the process of scaling a network node as connection counts increase.

Mobile PNNI Support

This release adds the Mobile PNNI feature to the existing PNNI functionality. Generally a PNNI network has a fixed hierarchy where each element has a fixed point of attachment. Mobile PNNI extends a fixed network infrastructure to mobile ATM switches that are roaming in the network. To maintain connectivity when the location of the mobile ATM switch changes, mobile switches are allowed to dynamically change peer group membership. To implement this feature, you establish a link to the fixed network; the mobile network then finds the proper peer group and hierarchy and joins the network.

Mobile PNNI allows each mobile network to build its own PNNI hierarchy and integrate the hierarchy of the fixed network as a logical group node (LGN). In the context of mobile PNNI, it is called Mobile LGN. A mobile logical group node has the capability to dynamically change its membership from one peer group to another as it attaches to different fixed switches. A mobile logical group node is only allowed to join a parent peer group of one of the fixed switches.

Compression and Multiplexing Support for RPM-PR Cards

The MGX-RPM-1FE-CP (one-port, Fast Ethernet-Co-processor) back card is an MGX8850/RPM-PR back card that off-loads the following processes from the Route Processor Module (RPM-PR):

4. Use SCTs with VC thresholds of at least 50000 microseconds for the VSI signaling service type. New SCTs 5,6 and 54, 55 (SCTs for the T3/E3, Combo cards, and IMA group links, respectively) update the VC threshold and have minor version = 1. Upgrade your custom SCTs to the new recommended VC thresholds and change the minor version. You can gracefully upgrade an SCT with a minor version change without interrupting traffic. The SCT chapter of the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2 explains how to upgrade a SCT file to a new minor version.

AXSM and AXSM/B

The AXSM and AXSM/B SCTs have the following characteristics:

•SCT 2—Policing enabled, PNNI

•SCT 3—Policing disabled, PNNI

•SCT 4—Policing enabled, MPLS and PNNI

•SCT 5—Policing disabled, MPLS and PNNI

The filenames and checksums for the SCT files are as follows:

•AXSM_SCT.PORT.0.V1:Cchecksum is = 0x6aadd6c6= 1789777606

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

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

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

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

•AXSM_SCT.CARD.0.V1: Checksum is = 0x6aadd6c6= 1789777606

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

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

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

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

To confirm that the checksum of the SCT file and the file on the node match, enter dspsctchksum <filename>.

AXSM-E

The AXSM-E SCTs have the following characteristics:

•CARD and PORT SCT 5—Policing enabled for PNNI, disabled for MPLS

•PORT SCT 6—Policing disabled, used for PNNI ports.

•CARD and PORT SCT 52—Policing enabled on PNNI, disabled on MPLS

•PORT SCT 53—Policing disabled on PNNI and MPLS

•PORT SCT 54— Policing enabled on PNNI, disabled on MPLS

•PORT SCT 55—Policing disabled on PNNI and MPLS

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

•AXSME_SCT.PORT.5.V1: Checksum is = 0x793c56d0= 2033997520

•AXSME_SCT.PORT.6.V1: Checksum is = 0xe92db9a5= 3912087973

•AXSME_SCT.PORT.52.V1: Checksum is = 0x51241b7a= 1361320826

•AXSME_SCT.PORT.53.V1: Checksum is = 0x34bdf8b9= 884865209

•AXSME_SCT.PORT.54.V1: Checksum is = 0xb5df2c5c= 3051301980

•AXSME_SCT.PORT.55.V1: Checksum is = 0xc5d355c8= 3318961608

•AXSME_SCT.CARD.5.V1: Checksum is = 0x793c56d0= 2033997520

•AXSME_SCT.CARD.52.V1: Checksum is = 0x972810ac= 2535985324

AXSM-XG

The AXSM-XG SCTs have the following characteristics:

•CARD SCT 2—Policing disabled on PNNI and MPLS. Applied in ingress direction based on backplane bandwidth.

•Maximum of 2000 connections. Any combination of Frame Relay and ATM connections is allowed.

•Support for FR-FR, FR-ATM, ATM-FR, ATM-VISM, and ATM-CE SPVC connection types, where one of the end-points resides on the MPSM-16-T1E1 card. The MPSM-16-T1E1 cannot be the CE end point for ATM-CE connections because the MPSM-16-T1E1 does not support circuit emulation.

•Connections provisioned on the PNNI control plane on the MGX 8850 platform using the MSF switch architecture based VSI (Virtual Switch Interface).

•Connections provisioned on the MGX 8850 PNNI control plane using the MSF switch architecture based Virtual Switch Interface (VSI)

•Licensing of the supported features

Multilink PPP Feature for CDMA2000 and EVDO

The MPSM-16-T1E1 implements Multilink PPP, which is a key protocol in a larger application defined by CDMA2000. In this application, the MGX 8850 (PXM45) aggregates traffic from several BTS site routers (MWR) and transfers that traffic to an IP network. The aggregation point in the MGX 8850 (PXM45) is the RPM-XF. Traffic from all of the BTS routers are transported over PPP links (typically on T1/E1 links) and brought into the MGX 8850 (PXM45) through an MPSM-16-T1E1 card. The MPSM-16-T1E1 transforms the PPP payload into AAL5 cells, which it sends to the RPM-XF using ciscoPPPoAAL5 encapsulation.

With growth in traffic in the CDMA2000 application, you might need to add additional T1/E1 links between the MWR and the MPSM-16-T1E1. The MLPPP feature simplifies the process of adding incremental bandwidth because it can aggregate capacity of individual T1/E1 lines. Because the IP payloads are small (typically voice) and the overhead associated with PPP (MLPPP) packets increases with smaller payloads, PPPMUX functionality is utilized on the MPSM-16-T1E1. In EV-DO, multiplexing is not used.

The connection between MPSM and RPM-XF is setup as a PVC connection. The bandwidth of this PVC depends on the number of operation PPP links on an MP bundle. RPM-XF terminates the PPPoAAL5 data and routes the IP traffic to the backbone IP network.

MPSM-155-T3E3 and MPSM-16-T1E1 Online Diagnostics

The online diagnostic tests run on regular intervals for both on the active and standby state of the MPSM cards to check the health of the devices and data paths. The online diagnostics test the following devices and data paths:

•Data path from the CPU on the MPSM to the CBC slave loopback on the MPSM through Winpath 0

•Data path from the CPU on MPSM to the CBC master loopback on the PXM via Winpath 1

•Winpath memory access test (packet, parameter, host memory)

•Write/read memory access test for internal devices

•Validate front card NVRAM checksum

•Validate flash checksum

PNNI Current Route Feature

Current Route feature provides the path information for active Point-to-Point (P2P) SPVCs/SPVPs master-end connections. The path information contains the lowest level physical node and egress trunk information of the path on which the connection is currently routed.

This feature uses the ATM standards based connTrace message to obtain the current route information. CWM uses the configuration upload file mechanism to request available path information of connections on a periodic or an on-demand basis.

This feature works in single peer group and multiple peer group networks. The current path can be used by the network administrators and planners to engineer the trunk use and to direct how connections should be routed.

Operational and Redundancy Limitations

•Master ended connections have the current route information. Slave ended connections do not have this information.

•The configuration upload file contains a snapshot of the current route information at the time that the switch receives a configuration upload request from CWM. Therefore, the snapshot might not contain the latest information, and connection trace information that the switch receives after the file is created is not included in the file.

•If congestion occurs on a node, the connTrace message sent by the CLI and by the Current Route feature is dropped. The two connTrace messages are not distinguishable. This limitation also applies to connTrace ACK messages that are received on a congested node.

•After changing a node ID, disable and then re-enable the current route feature on each node in the network using the new CLI command, cnfndcurrte.

This command flushes all existing current route information and starts collecting new information. After disabling the current route feature, wait at least 9 seconds (the time-out period for a conn-trace message) before re-enabling it. This inhibits processing of stale connTrace messages.

•The connection path information for a connection traversing more than 20 nodes is not stored in the current route path table. Therefore, such connections do not have current route information.

•The current route path does not include the destination termination port (normally slave endpoint UNI port). The destination port is set to zero in the current route path, which is similar to preferred route.

The current route feature has the following redundancy limitations:

•The current route feature provides redundancy. However, because the current route must not reduce routing performance, some connections might not have redundant current route information on the standby PXM.

For those connections that do not have redundant current route information at the time of a switchcc, their current route information is obtained through the normal scanning on the active card when the old standby becomes the new active.

•After a standby PXM card is inserted and reset, the active card sends the current route information to the standby card only after its state changes from Init to Standby. This avoids increasing the time it takes for the redundant card to come up to the Standby state, ready for switchcc.

The Standby state is not redundant until the current route update is completed. Therefore, a switchcc that occurs before all current route information is sent to the redundant card results in some connections not having current route information on the newly active card. The current route information for those connections is obtained during the normal current route scanning and processing.

•When inserting or resetting the standby PXM, enter the command dspndcurrte and verify that Bulkupdate is complete before performing a switchcc.

Feature Specifications

The current route feature has the following limits:

•A maximum of 10K path entries per node are supported.

•A maximum of 5K node ID entries per node are supported.

•A maximum of 2K ports on PXM1E systems are supported when current route is enabled.

An attempt to enable the current route feature on a node which has more than 2K ports is not allowed and results in error. If the current route feature is enabled and more than 2K ports are subsequently added, this feature or other applications might not work properly.

•A maximum of 100K connections are supported PXM45/B systems when current route is enabled.

An attempt to enable current route on a node which has more than 100K connections results in error. If the current route feature is enabled and more than 100K connections are subsequently added, this feature or other applications might not work properly.

PNNI Product Enhancements

The Link Selection enhancement adds new functionality to parallel links to which link selection criteria is provisioned to `minAW' (`minAWlinks'). This feature can be activated through the CLI. If these enhancements are not activated, the existing `link selection' behavior is used.

This enhancement introduces a command (cnfpnni-svcc-rcc-param) to configure the connection parameters associated with SVCC-RCC connections at each level of the PNNI hierarchy.

PER 8281

Path bypass selection configuration

In a complex node multiple peer group topology, the path that has the highest available cell rate (AvCR) is advertised as the bypass. Typically this path has higher cost, so the calls routed over the pass bypass might always take the worst path. This enhancement adds an option to the cnfpnni-routing-policy command to specify the criteria for bypass path selection.

PER 8282

Administrative Weigh (AW) Pruning

Currently a trunk is included in the best path selection even if it has a single cell per second of AvCR. This enhancement introduces an AvCR threshold parameter to the cnfpnni-routing-policy command so that trunks with BW below the threshold are excluded from the best path search.

PER 8287

Consistent PNNI Link Selection

Allows application of the same link selection mechanism to connections of all service categories (ABR, UBR, CBR and VBR) on `minAW links'.

Allows provisioning `epsilon-equal AW parallel links' among the `minAW parallel links' between two switches. The switch calculates the `epsilon' value based on user inputs.

If `epsilon-equal AW parallel links' exist between two switches along the selected shortest path, `link selection' applies. For `epsilon-equal AW parallel links', the secondary `link selection criteria' is maxAvCR. If all links have the same AvCR, the connections are routed according to load balance criteria.

PER 8540

Preferred Route Enhancements

The cnfndidrtes command has a new parameter for indicating that the same node is being configured and that the preferred route status should not change. A connection that was on a preferred route before the change would not be groomed by route optimization.

PER 8660

Link Selection Enhancements for MPG (multi-peer group) Pref Rt Conns

PER 8807

Routing Policy Enhancements

This enhancement adds a parameter value to the cnfpnni-routing-policy command that selects from equal administrative weight (AW) paths using the number of minimum hops. If multiple epsilon-equal AW paths with the same minimum-hops exist, a second load balance parameter specifies the tiebreak criteria.

PXM1E OAM Enhancement

The PXM1E processes the following OAM loopback cells:

•End-to-end OAM loopback cells—Used for background connection continuity verification. These cells might be sent by a VISM card or router.

•Segment OAM loopback cells—Used for diagnostic testing between segment endpoints. These cells are sent for the following CLI commands: tstdelay, tstconsegep, and tstpndelay.

This release moves the task of extracting and injecting OAM loopback cells at the PXM1E from the Atlas to the QE1210. Unlike with Atlas, the QE1210 can distinguish between segment and end-to-end OAM loopback cells. The QE1210 extracts only the segment OAM loopback cells, while transparently passing the end-to-end OAM loopback cells.

Because the end-to-end OAM loopback cells no longer require software processing, the previous limitations for the OAM loopback cell rate on the PXM1E no longer apply. These cells are now processed in the QE1210 hardware and are limited only by the available line bandwidth.

Each PXM1E segment endpoint has a polling-induced queue extraction delay of up to 10 ms for a segment OAM loopback cell. This delay is not imposed on end-to-end cells or segment cells at nonsegment endpoints.

IP Management Connections through the RPM

You can manage the MGX 8850 node from the traditional Ethernet or console port, or you can set up one of the following connections:

•Through the AXSM or MPSM cards using an SVC to the PXM card

•Through the RPM card using a PVC to the PXM card

This release changes the PXM svcifconfig command to support management connections through the RPM card.

The IP addresses of hosts accessing the MGX 8850 node are stored in a RAM cache. Because this cache has a limit of 50 entries, only 50 IP hosts can actively access the node at one time. New IP hosts are blocked until the cache clears (as result of inactivity from some hosts) to make room for new entries.

Use this solution to manage only one MGX 8850 node through RPM, not an entire network of nodes.

Note If you are connected to the MGX node using the RPM and accidentally delete the SPVC, the connection drops. To restore RPM access, you must re-add the SPVC using the console port or Ethernet port.

Note If the clrallcnf, clrcnf, or clrsmcnf commands are executed, the persistent data pertaining to the IP connections is lost and connections are dropped. To restore RPM access, you must reconfigure the RPM and PXM cards for IP connectivity, using the console port or Ethernet port.

System Requirements

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

Limitations, Restrictions, and Notes

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

MGX Chassis Bandwidth Limitations

The total bandwidth of all cards and configured ports in your MGX switch must not exceed the total switch capacity. If you install more cards or configure more ports than your switch can support, your switch may drop traffic. This section describes the bandwidth limits, card placement, and oversubscription options for narrowband cards. It also provides the solution for anomaly CSCei02096.

Bandwidth Limits

An MGX 8850 (PXM45) chassis supports up to OC-12 aggregate bandwidth for narrowband cards, within the following limitations:

•Each pair of slots in the upper bay supports a total of OC-6 aggregate cellbus throughput.

•Each pair of slots in the lower bay supports a total of OC-6 aggregate cellbus throughput.

•Each half of the lower bay can support total OC-6 aggregate cellbus bandwith.

•The left half of the switch can support a total of OC-9 aggregate cellbus throughput. This includes both the top and bottom bays, combined.

•The right half of the switch can support a total of OC-9 aggregate cellbus throughput. This includes both the top and bottom bays, combined.

Note These limits do not apply to broadband cards such as the AXSM, AXSME, AXSM-XG, RPM-XF and VXSM. Broadband cards use a serial bus, rather than the cell bus.

Card Placement Guidelines

To fully use the bandwidth of MPSM-T3E3-155 cards, install cards according to the following guidelines:

•Install MPSM-T3E3-155 cards so that they are balanced on the left side and right side of your switch (8 slots apart). For example, if you are installing two active MPSM-T3E3-155 cards in your switch, and you place one MPSM-T3E3-155 card in slot 6, then you should place the second MPSM-T3E3-155 in slot 14.

•Install no more than four active MPSM-T3E3-155 cards in a single Cisco MGX switch.

•Install broadband cards, such as RPM-XF and AXSM cards, between MPSM-T3E3-155 cards. These cards use a different backplane bus and do not affect the narrowband bandwidth.

Placement of the MPSM-T3E3-155 is especially important because of the total card capacity. Other narrowband cards also utilize cellbus capacity, but they have smaller bandwidth requirements and place less load on the backplane.

Bandwidth Oversubscription

You can install more than the recommended number of cards under the following circumstances:

•You do not configure the full port rate available to each card installed in your switch.

•You use statistical multiplexing of traffic to support overbooking of cell bus traffic. Statistical multiplexing works better for a T3 port that is channelized down to DS1s than it does for a T3 port that uses its full T3 capacity.

If you do not have such information available when installing your switch, you must follow the general recommendations to provide adequate bandwidth margins.

PXM1E Switch Limitations

The following notes apply to PXM1E based switches—MGX 8850 (PXM1E) and MGX 8830:

•Y-red is not supported on the MCC electrical back card.

•For inter-card APS to work on the PXM1E-8-155, and one front card is missing or not available, both back cards must be present. A front card cannot drive the alternate trunk back card when its own local trunk back card is absent.

•MPLS controller is not supported on PXM1E.

•PXM1E clock source is supported by VISM-PR, CESM, and AUSM cell bus service module cards. CESM and AUSM can provide one clock source, either primary or secondary.

•Only SPVCs and SPVPs are supported on cell bus service modules. SVCs are not supported on CBSMs.

•No bandwidth CAC support exists on the cell bus service modules, except for the RPM card, which is checked against the OC-3 card rate. For example, for a given RPM, the bandwidth allocated to all connections might not exceed the OC-3 rate. Bandwidth CAC is supported on the PXM1E uplink port.

•The maximum bandwidth to be distributed among cell bus service modules is approximately an OC-10 rate while traffic on the network interfaces on PXM1E can achieve true OC-12 line rate.

•Traffic must be balanced between the cell bus controllers (CBC) to achieve the OC-10 rate. The traffic must be distributed equally at a rate of about OC-5 on the two CBCs.

The CBCs 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. Traffic above the OC-6 rate is dropped. However, if only one CBC is used and the other CBC is not used, then the CBC can achieve an OC-10 rate.

On an MGX 8850, the CBCs are split between the left and right side of the chassis: CBC0 supports slots 1-6 and 17-22 and CBC1 supports slots 9-14 and 25-30. On an MGX 8830, CBC0 supports slots 3,5,10, and 12 and CBC1 supports slots 4,6,11, and 13. Balance traffic by evenly distributing cell-based cards on the left and right sides of the chassis.

PXM1E Hardware Limitations

PXM1E hardware limitations are as follows:

•For inter-card APS to work on the PXM1E-8-155 with one front card missing or unavailable, both back cards must be present. A front card cannot drive the alternate trunk back card when its own local trunk back card is absent.

•During hardware upgrade from PXM1E-4-155 to PXM1E-8-155, at the time when the inserted card types are different (one PXM1E-4-155 card set and one PXM1E- 8-155 card set), the standby trunk back card functionality is not available. Therefore, LED functionality is not available, and APS lines do not work on that back card. Modular optical transceiver (SFP-8-155) mismatches are not reported for that back card, and SFP-8-155 mismatches are not reported during hardware upgrades.

•Because the PXM1E-4-155 and PXM1E-8-155 back cards support LC and SC interfaces respectively, the following restriction applies when upgrading from PXM1E-4-155 to PXM1E-8-155 hardware:

After replacing the first PXM1E-4-155 card with the PXM1E-8-155 card set, update cabling for the PXM1E-8-155 interfaces with an LC-SC converter.

Similarly, after the second card set is replaced, perform the same update for the interfaces on the new card set. Otherwise, the upgrade is not graceful and becomes service affecting, until appropriate cables are installed.

•When MGX-8850-APS-CON is used, and one trunk back card is removed, screw the remaining back card in completely to ensure that the contacts are fully engaged.

•When MGX-8850-APS-CON is used, the Combo card and the PXM1E-4-155 card do not require a mini-backplane, but the PXM1E-8-155 does. Therefore, to support graceful upgrade to the PXM1E-8-155 card in the future, insert a mini-backplane with the PXM1E-4-155.

PXM1E Reserved VCIs

You cannot provision the following reserved VCIs:

•On a feeder trunk, VPI.VCI 3.8 is reserved for inband communication with the feeder shelf, and 3.31 is used for the feeder trunk Annex.G ILMI.

•VPI = 0 and VCI = 5 are used for SSCOP for UNI signaling ports. If the port is configured for non-signaling (univer = none), no VPI/VCI is reserved.

•VUNI uses configured VPI and VCI = 5 for SSCOP.

•EVUNI uses minimum VPI and VCI = 5 for SSCOP.

•NNI uses VPI = 0, VCI = 18 for PNNI RCC.

•VNNI uses configured VPI for the port and the VCI = 18 for PNNI RCC.

•EVNNI uses minimum VPI and the VCI = 18 for PNNI RCC.

•VPI = 0 and VCI = 16 are used for ILMI if ILMI is enabled. VUNI and VNNI uses configured VPI for the port and VCI = 16 for ILMI. Similarly, ILMI for EVNNI or EVUNI uses a minimum VPI and VCI = 16.

Multipoint enhances network efficiency because multiple streams of data can be replaced by a single transmission up to the multicast distribution point, typically a MGX with PXM45. Point-to-multipoint differs from broadcast because it replicates packets only to specific destination endpoints in the multicast distribution tree.

The MGX 8830 (PXM1E) and MGX 8850 (PXM1E) can be used in conjunction with an MGX (PXM45) in a network to support point-to-multipoint connections. The PXM45 hardware performs cell replication to multiple destination endpoints. The MGX with PXM1E functions as the originating node or as an intermediate node of a point-to-multipoint connection. If necessary, MGX with PXM1E can perform limited branching or cell replication to support multiple parties, or leaves, of a point-to-multipoint connection.

Enabling cell replication or branching of more than two leaves per root in the PXM1E node is not recommended for mission-critical point-to-multiple connections because of potential ATM cell drops. PXM1E Parity Errors

The PXM1E handles parity errors as follows:

•If the PXM1E card has a CBC CBH RAM parity error and all connections do not have traffic, then the PXM1E card fails to detect this parity error and does not switch over to the standby card. Also, all service module cards reset.

•The PXM1E standby card comes up even after a QE TS RAM parity error.

PXM1E Policing Accuracy

The PXM1E card has a policing accuracy limitation. The policing rate is defined as 50000000/PCR, so if the PCR is comparable to the OC-12 line rate (1412830), the policing rate parameter is a relative small number (50000000/1412830 = ~35.38996).

Because the PXM1E performs integer division, the decimal results are truncated and the policing parameter is not calculated accurately. Moreover, the policing rate parameter is stored as an exponent (5-bits) and mantissa (9-bits), which cannot represent a small number accurately. Therefore, a 100% accurate policing parameter cannot be configured for large PCR values.

To ensure that you get the rate that you have specified, the software configures policing at the next larger rate that the hardware supports. For example, if you program a connection with PCR = 1400000, the software programs the actual policing rate to be 1428571. For a worse-case scenario, if you configure a VBR2 connection with a PCR of 1400010 and the ingress user traffic is 1428570, there is no policing because the ATM policing rate is actually 1428571.

PXM45 and PXM1E System Limitations

The following limitations apply to PXM45 and PXM1E systems:

•Because of granularity limitations in the AXSM-E hardware, cell traffic does not reach the configured PCR rate when WFQ is enabled. For connections that have WFQ enabled, configure a PCR of 101% of the actual required rate. ABR has the same Qbin priority as UBR in the SCT tables. In this case ABR and UBR share excess bandwidth if WFQ is enabled.

•The percentage trunk utilization with overbooking is calculated using the following formula:

–(overbooked MaxCR - overbooked ACR)/overbooked MaxCR. This occurs when you are interoperating with SES from Release 3.0.x and later.

–ACR = MaxCR - (trunk utilization/overbooking factor).

–overbooked ACR = ACR/overbooking factor.

–overbooked MaxCR = MaxCR/overbooking factor.

•The overbooked ACR is calculated differently for MGX and SES.

–On MGX, the bandwidth for all current connections on the port are considered overbooked when calculating the trunk utilization.

–On the SES, the bandwidth for all current connections on the port are not considered overbooked when calculating the trunk utilization.

Therefore, the trunk utilization calculation is lower on the MGX than on the SES when there are existing connections on the port with an overbooking factor configured. This in turn yields a lower percentage trunk utilization on the MGX compared to the SES.

•The PXM45/A card is not supported in Release 5.0.00 and later.

•Disable complex node for physical nodes (the lowest level node) to decreases memory usage without decreasing functionality. Complex node should only be turned on for logical nodes.

•Simple Network Timing Protocol CWM MIB is not supported.

Maximum Threshold Accuracy

The PXM45 and PXM1E have a limitation with the accuracy of the maximum threshold. 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). Therefore, you cannot calculate an exact 100% correct discard rate.

To ensure that you obtain the rate that you have specified, the software configures Qbin depth at the next larger rate that the hardware supports. As a result, Int. Cell Gap (ICG) and Relative Service Delay (RSD) are truncated.

Clearing the Configuration on Redundant PXM45 and PXM1E Cards

These notes apply to redundant cards.

•Because of checks to prevent an inserted card from affecting the system, an additional step might be required when inserting two non native 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).

SPVC Interoperability Limitations

•Terminating single-ended SPVCs on MGX switch with legacy service modules is not supported.

•Origination of single-ended SPVCs, with slavepers flag, from legacy service modules (FRSM, CESM, and RPM) is not supported.

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

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

•The tstdelay command is not available at the slave end of a single-ended SPVC for MGX 8850. For SES-PNNI, the command is available from the PXM even for the slave endpoint.

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

•If single-ended SPVCs originate from MGX switches, they can only be configured from the CLI and not from CWM.

•Single-end provisioning is not supported for DAX connections as 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 nonpersistent.

•When the persistent slave endpoint of an existing SPVC connection is deleted and the master endpoint remains, the connection might get established as a single-ended SPVC connection. In this case, CWM shows the connection as Incomplete.

•Override of SVC connections on a VPI because of an incoming SPVP request for that VPI is not supported. Only the following override options are supported:

–spvcoverridesvc

–spvcoverridesvp

–spvpoverridesvp

Service Card Limitations

This section describes service card limitations.

AXSM Channel Loopback Limitation

The channel loopback tests the integrity of the connection (channel) at the local UNI or across the network. The system returns an error message if the connection is broken or incorrect data arrives at the end of the loopback. The maximum number of connection loopbacks that can exist on an AXSM is 8 for Release 2.1 and later. The addchanloop command in the Cisco MGX 8800/8900 Series Command Reference, Release 5.2 incorrectly states the limit as 256.

AXSM-16-155-XG with MCC Back Card Limitations

You might experience the following scenario when card to card APS is configured on one card but not the other:

The Protection Line Status in dspapslns or dspapsln shows OK if the other side has added the card redundancy and activated the line but not the APS. If the back cards are SFP back cards, the Protection Line Status is in SF in the same setup.

From CLI screen on the side of APS added, the only way to find out if the remote APS has been added is through the Receive chanfield and modefield in dspapsln. The following display shows the APS status during configuration:

For GR253:

Receive k2 chanfield - Null Channel

Receive k2 modefield - Undefined

After adding remote APS (with MCC):

Receive k2 chanfield - Null Channel

Receive k2 modefield - UNI1+1 or Bi depending on mode

For ITU (or AnnexA)

Receive k2 chanfield - Null Channel

Receive k2 modefield - Undefined

After adding remote APS:

Receive k2 chanfield - Null Channel

Receive k2 modefield - Undefined

For AnnexB:

Receive k2 chanfield - Null Channel

Receive k2 modefield - Undefined

After adding remote APS:

Receive k2 chanfield - Working Section 1 or 2

Receive k2 modefield - Undefined

AXSM-32-T1E1-E and PXM1E-16-T1E1 Card Limitations

The following notes apply to the AXSM-32-T1E1-E and PXM1E-16-T1E1 cards:

•IMA version fall back is part of IMA group operation. If a group is configured with Version 1.1 and it is connected to a far end group which is configured with Version 1.0, this group falls back to Version 1.0.

•The IMA link Loss of IMA Frame (LIF) and Link Out of Delay Synchronization (LODS) defect integration times are configurable.

•ATM layer configuration for line and IMA ports takes an additional parameter, AIS enable. It is enabled by default.

•In T1 mode, payload scrambling is disabled by default and in E1 mode it is enabled by default on all lines and IMA groups.

•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 E1. They are not supported for the T1 interface.

•HMM support is not available for the IMA and the Framer devices. When a switchover occurs, it can take up to 3.5 seconds for the IMA groups to recover. Data is lost until the groups recover.

•IMA Autorestart (persistent RX IMA ID) feature is supported.

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

•ITC clocking mode on IMA is not supported.

•One-way transmission delay of more than 500 ms on the T1/E1 IMA links is not supported.

•There is 5 ms fluctuation on IMA delay tolerance.

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

–Any changes to this IMA group configuration are temporarily 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 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.

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

•The port number in the pnport (shelf.slot:subslot.port:subport) could be a random number. Do not interpret this number as line or IMA group number. Refer to anomaly CSCdy08500.

•PNNI requires SCR = 453 cells per second and PCR = 969 cells per second for the control connection.

•SSCOP requires of SCR = 126 cells per second and PCR = 2000 cells per second.

AXSM-E Card OAM Limitations

The following notes apply to AXSM-E OAM cells:

•Any connection can receive E2E/OAM loopback cells up to the line rate, as long as the policing policy permits it.

•The AXSM-E card can receive up to 1,500 segment OAM loopback cells per second for all connections operating in the normal mode (not loopback), assuming an even flow rate. Any excessive segment OAM loopback cells are dropped.

For example, if only one connection exists, that connection can receive 1,500 segment OAM loopback cells per second. If 2,000 connections exist on an AXSM-E card, and each connection passes one segment OAM loopback cell per second, then only 1,500 of the connections can receive loopback cells at any given second. The additional 500 loop back cells are not received for that second.

General AXSM Card Limitations

If ER stamping is used, the rate interval does not provide sufficient accuracy to be completely effective. As a result, when an AXSM card has a PNNI link that is congested with mixed CBR/ABR traffic, cells are dropped. This condition only occurs when ER stamping is enabled and CI is disabled on an AXSM PNNI link where CBR/ABR traffic causes congestion on the link.

Use the CI/EFCI mechanism for rate feedback rather than the ER stamping mechanism, especially if CBR/ABR traffic is expected.

AXSM-XG Signal Level Limitation

The IR/LR/XLR SFP modules need a 10 db attenuator when connected with short cables. Otherwise, the signal overloads the receiver.

ATM Multicast Limitation

Configure an MGX 8950 with ATM multicast as follows:

•MGX 8950 system loaded with AXSM/Bs without AXSM-XG cards in the system.

•MGX 8950 system loaded with all AXSM-XG based cards without AXSM/Bs in the system.

An MGX 8950 system with a mix of AXSM-XG and AXSM/B cards is not recommended for the ATM multicast application because of limitations in the backplane serial buses. The workaround for MGX 8950 systems that must have a mix of AXSM-XG and AXSM/B cards is to configure the PNNI node as branching restricted.

cnfpnni -node 1 -branchingRestricted on.

Priority Bumping Limitation

When you enable priority bumping on the node, you cannot change the booking factor for AXSM signaling ports. You can still change the booking factor for non-signaling ports.

AXSM Card APS Limitations

Thee APS feature has the following limitations:

•For AXSM APS, the back card of the active card must be present for correct APS operation.

•AXSM front cards need the corresponding back card for correct APS operation. In other words, the AXSM cards do not support cross back card removal—the upper back card of one AXSM and lower back card of another AXSM.

•If you remove the upper back card of the active front AXSM, it triggers an active card switch. At this point the APS is still operational. However, if the lower back card of the current active AXSM is removed, it does not trigger switching because the standby card is missing the back card.

•Port LED lights on AXSM-E, AXSM-XG and PXM1E front cards indicate the receive status of physical line connected to it only when the card is in the active state. For a standby AXSM-E, AXSM-XG, and PXM1E card, the LEDs always remains green when the lines are in LOS irrespective of which lines are active.

MPSM Card Limitations

The MPSM cards have the following limitations:

•The MPSM-T3E3-155 card does not support the LMI Autosense feature.

•The MPSM-8T1-FRM and MPSM-8E1-FRM cards do not support the LMI Autosense feature.

•If a combination of RPM-PR and MPSM-T3E3-155 cards are being installed in slots served by the same cell bus, then enable Option 10 of cnfndparms (auto clock rate setting) before installing the MPSM-T3E3-155 and RPM-PR cards. This note applies when two RPM-PR cards or two MPSM-T3E3-155 cards (or one RPM-PR and one MPSM-T3E3-155 card) are inserted into slots under the same cell bus master, for example, slots 5 and 6 or 3 and 4.

•The MPSM cards are cell bus based cards, and they have limitations that suggest only a few of these cards could be used in a chassis when running at full port rate.

In reality, the full port rate available is rarely used. Statistical multiplexing of traffic across many ports can allow overbooking of the cell bus capacity just as it allows overbooking of trunk capacity. Estimates on how much overbooking is practical without dropping cells relies on the network's characteristics, such as the mix of service types, port speeds, and offered traffic loads as a percentage of port speed or as generated cell rates. Work with your Cisco Customer Engineering representative to help you characterize the quantity of MPSM cards suitable for your network.

•If you order MPSM cards with systems, the MPSM licenses can be shipped on the PXM card. For more information, see Documentation.

MPSM-16-T1E1 Card PPP Limitation

On the RPM-XF, Rated Priority Queue is not supported; SAR based QoS is enabled instead. The traffic on priority queue can exceed the limit even if the class-based weighted fair (CBWF) queues are relatively free. RPM-XF supports absolute priority only, where the upper limit on the traffic is layered using the policing command.

CBSM Card Limitations

Cell Bus Service Modules (CBSM), formerly known as narrowband service modules, have the following limitations:

•When switchredcd is entered at the same time as a PXM switchover occurs, either through the switchcc/resetcd command at the PXM or because of a failure, the switchover can fail.

Conditions: switchredcd is entered at the PXM command line to perform CBSM Switchover, but the PXM switches over (manual or automatic) before the service module switchover is complete.

Symptom: Service module did not switch over after switchredcd.

If the PXM switches over before the CBSM switchover completes, the following can occur:

–The switchover might not be complete and the standby card is in an indeterminate state. The dspcd command from PXM still shows it as 'standby' and later switchover (because of active service module removal or reset) fails, causing loss of traffic. The switchredcd command also fails.

–The switchredcd from PXM again causes the failure because the standby service module is not able to allocate memory.

Workaround: Reset the standby service module card.

•Each CBSM has the following maximum number of connections:

–FRSM-8 = 1,000

–FRSM-2CT3 = 4,000

–FRSM-2T3 = 2,000

–FRSM-2E3 = 2,000

–CESM-8 = 248

IGX Feeder Limitation

After adding an IGX as a feeder to a SES/BPX or MGX node, the IGX has a default node number that might not be unique within the network. If the number is not unique, modify it to a unique node number by entering rnmnd <x>, where x is unique with respect to all other AutoRoute nodes. To find the other node numbers, enter dspnds +n. Failing to assign a unique number could cause the CWM Databroker to incorrectly form a hybrid connection database. The CWM GUI might show the connection as incomplete.

Clock Source Limitations

•The FRSM card does not support clock source configuration. Attempts to configure the clock source are not recorded in the database.

•When resetcd is invoked, the primary and secondary (if configured) clock sources are recommitted. Recommitted means that the primary and secondary get requalified. The node temporarily uses the internal oscillator until the clock is requalified, and then locks onto the primary clock source again.

Clearing Card Configuration Notes

The clear service module configuration feature has the following behavior:

•Do not execute clrsmcnf on more than one card at a time.

•If a controller card switchover occurs before the clear service module configuration operation is complete, the clrsmcnf command must be re-entered to ensure that the configuration is completely cleared and to avoid incomplete cleanup.

•The clrsmcnf command might result in a discrepancy in the PNNI configuration. For example, some connections might be in the mismatch state.

•If the clrsmcnf command is entered with the <all> option to clear the software version for the slot as well, then cell bus service modules go into the boot/empty state and broadband service modules (for example, AXSM or MPSM-155-T3E3) enter the fail/active state.

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

PNNI Limitations

This section describes limitations to PNNI links and routing.

Logical Link Limits

The number of logical links in the higher levels of the PNNI hierarchy is limited to 30 per level when the complex node configuration is enabled. The limit is essential to reduce the processing time for finding the bypasses between the logical links. A significant change in bandwidth in one of the links within the peer group triggers the bypass calculation. The bypasses are usually found from one logical link to another.

If there are n logical links, the calculation involves the finding n*n bypasses. If the number of logical links n is large, calculating the bypasses requires significant processing resources. The number of logical links can be controlled by configuring the appropriate number of aggregation tokens for the outside links for that peer group.

Preferred Route Limitations

Preferred routes have the following limitations:

•Preferred routes are not supported for connections with endpoints on the RPM-PR.

•Upgrading from any Release 3.0.x is nongraceful. During the upgrade, the preferred route identifier information for each connection is lost, and the preferred route identifier must be reprovisioned on the service module cards.

Also, the preferred route table at the PXM controller is lost. Connections that have already been routed with preferred routing remain, and no alarms for these connections occur. If a node in the PNNI network is removed by physical decommissioning and if any nodes in the network had preferred routes that contained the removed node as one of the hops, you must manually delete and modify the preferred routes.

•When a connection is routed on a route other than its preferred route and if the preferred route becomes available, the connection is not automatically routed back to its preferred route. You must deroute and reroute using configuration commands (optrte, rrtcon, dncon/upcon, and so on). QoS precedence over the preferred route does not apply to multipeer group networks (CSCdz40310).

•A preferred route configured with a higher node ID cannot be blocked (CSCdz41145, CSCdz49001). Because of differences in physical port numbering, non-MGX nodes can only be the terminating nodes in a preferred route.

•Preferred route status is supported in Release 5.0.00 and later. After an upgrade, manually reconfigure using commands like cnfcon. This step is necessary one time after the upgrade, and does not need to be repeated on subsequent upgrades.

Priority Route Limitations

Priority routing has the following limitations:

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

•The RPM does not support configuration of routing priority. The PXM assigns a priority of 8 to all RPM-mastered SPVCs.

•The addcon command on SES does not support routing priority; all added SPVCs are assigned a routing priority of 8. Use the cnfcon command to change the routing priority of the SPVCs.

•Changing the routing priority for DAX connections does not change the priority of the associated SVCs. The SPVCs are not derouted and rerouted if only the endpoint parameters are changed, and routing priority is an end-point parameter. Also, because DAX connections are never derouted even when the UNI port goes down and the rrtcon command does not support DAX connections, the routing priority change never gets reflected. The only way to reflect this change is to enter a dncon and then upcon. Because DAX connections are never derouted, the effect of this limitation is void.

•Priority routing operates in a best effort manner for 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, releases can be transmitted out-of-order. This is because releases of other calls must not be held up if you are not able to send releases on one of the congested interfaces. The calls that were not released could be higher priority calls.

•Lower priority SPVCs can be routed ahead of higher priority SPVCs. This can occur after several failed attempts to route higher priority SPVCs. To prevent starvation of lower priority SPVCs after these failures, the software starts to route lower priority SPVCs and postpones higher priority SPVCs routing.

Persistent Topology Limitations

The persistent topology feature has the following limitations:

•In a mixed network of pre-Release 4.0.00 and 4.0.00 or later nodes, only the node name and the node ID are shown for a pre-Release 4.0.00 node in the Topo DB. This is because the feature is not present in pre-Release 4.0.00 nodes.

•If a peer group is made up of physical nodes with pre-Release 4.0.00 logical nodes, the information for the logical node is stored in the Topo DB. This is because there is no way to distinguish between physical nodes and pre-Release 4.0.00 logical nodes. Logical nodes with Release 4.0.00 or later software release are not stored in the Topo DB.

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

•When the node ID of a node is changed, the old node ID is added back into the Topo DB as a new node entry. In addition, the old node ID still is stored in the Topo DB of all the other nodes in the peer group. To delete this entry, wait for an hour so that the PTSEs with the old node ID is flushed from the DB of all the nodes in the peer group. Then, delete the information of the old node ID from the Topo DB.

•It is possible that the gateway nodes are not in sync 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 PG, and another gateway node is configured, then the info 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 deleting a node from the peer group, the node info must be deleted from all the nodes in that peer group, even the non-gateway-node nodes. Otherwise, the node info 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.

Fault Isolation and Trace Limitations

This section describes fault isolation and trace limitations.

Serial Bus Path Fault Isolation Limitation

The Serial Bus Path Fault Isolation feature isolates errors on local cards only. However, when a common error occurs on the switching fabric card, this feature does not resolve the error. As a result, a problem on the PXM card or the XM-60 is reported by all cards that detect the symptoms of this problem.

Cell Bus Path Fault Isolation and Recovery Limitations

Cell bus path fault isolation has the following limitations:

•The isolation procedures can isolate the cell bus path in the serial bus service modules (for example, AXSM, AXSM/B, AXSM-E) and all communication with the standby controller card and the cell bus service modules (for example, FRSM, CESM). These procedures cannot isolate cell bus path failures involving the ATMizer SAR, which is used for all inter-card communication except polling, between the active controller card and the serial bus based service modules.

•The isolation procedures can isolate the cell bus path failures to the active controller card only. This isolates the active controller card faults for the inter-card communication over the cell bus from the active controller card to the service modules and the standby controller card. 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.

•At least two cards (two service modules or one service module and one standby PXM) must exist to isolate cell bus path failures to the active controller card.

•Only failures that are detected by periodic polling trigger the isolation procedures. Failures reported from other sources in the system about a service module or the standby controller card, due to the cell bus path failures, do not initiate the isolation procedures. Such failures reset the card for 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.

•No separate trap or alarm is generated for the active controller card cell bus path when the fault is isolated to the active controller card. Use the event logs to investigate events triggered by the card reset and switchover traps.

CLI Access Level Notes

Configuration of CLI access levels has the following limitations:

•Not all CLI command access levels can be changed and a command cannot be changed to CISCO_GP group access level.

•Only the switch software can generate the access level binary file. This file has an authentication signature which must be validated before the file can be used. Any manual changes to the file 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.

•Command names are verified, but an invalid command name might be parsed and be added to the binary file. However, this invalid name is ignored later.

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

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

Disk Space Maintenance Notes

The firmware does not audit the disk space usage and remove unused files, so you must manually manage the disk space in C: and E: drives.

Manually delete 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. This avoids a shortage of disk space for storing event logs.

To remove files from the active controller card:

Step 1 Change to the directory that needs grooming.

cc <directory_name>

Step 2 List the directory to identify old files that can be removed and available disk space.

ll

Step 3 Remove any old files (you may also use wild cards in the filename).

rm <complete_filename>

Step 4 List the directory to see if the file has been removed and disk space is available.

ll

Non-native Controller Front Card and PXM-HD Card Notes

The following notes pertain to non-native front card controllers and the PXM-HD card:

•When the front controller cards or the PXM-HD back cards are swapped within the same system, the system performs a non-native card check. As a result, the controller card that attempts to come up as Active/Active might get reset twice.

•When a non-native PXM1E front card or a PXM-HD card is inserted into the standby controller slot, after the standby controller front card becomes Active/Standby, the active controller front card copies its hard disk content over to the standby controller card. The active controller front card does not automatically remove hard disk content from the active or standby controller card.

•The system keeps only the two most recent copies of the saved system configuration in the C:/CNF directory. You can use FTP to transfer all the saved configuration files in C:/CNF to a local server for future reference. All files under C:/CNF are not replicated to the standby controller card under any circumstances.

Other Limitations and Restrictions

Other limitations and restrictions are as follows:

•When configuring virtual interfaces (for example, VUNI, VNNI, EVUNI, EVNNI), the physical interface must all be the same ATM header type, either UNI or NNI. The signaling that is applied to a virtual port is independent of the actual virtual port ATM header. The only limit is that the VPI value must be within the UNI ATM header range(see CSCdz33652).

•If you clear the channel counters using the clrchancnt command while you are monitoring the channel counts using the dspchancnt command, the counters return incorrect values. To display correct data, enter the dspchancnt again .

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

•The clrsmcnf does not work while an upgrade is in progress.

•If RPM-PR or RPM-XF is configured as a Label Switch Controller (LSC), execution of clrsmcnf command on those LSC slots is rejected.

•Configuration information is not synchronized between PXMs during upgrades. You must reboot the standby PXM after it enters a stable state to synchronize changes made during the upgrade.

•Release 3.0.00 or later with PXM45/B supports up to 250,000 connections.

•The BPX does not support NCDP.

Installation and Upgrade Procedures

Do not upgrage to Release 5.1 and later from Release 4.0.17 and earlier.

For information on the following installation and upgrade procedures, refer to the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2.

Upgrade Information

The upgrade appendix in the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2 contains the following procedures:

•Graceful PXM1E and PXM45 Boot Upgrades

•Non-Graceful PXM1E and PXM45 Boot Upgrades

•Graceful PXM1E and PXM45 Runtime Software Upgrades

•Non-Graceful PXM1E and PXM45 Runtime Software Upgrades

•Graceful Service Module Boot Upgrades

•Non-Graceful Service Module Boot Upgrades

•Graceful Service Module Runtime Software Upgrades

•Non-Graceful Service Module Runtime Software Upgrades

•Graceful RPM-PR and RPM-XF Boot Software Upgrades

•Graceful RPM-PR and RPM-XF Runtime Software Upgrades

•Non-Graceful RPM-PR and RPM-XF Boot Software Upgrades

•Non-Graceful RPM-PR and RPM-XF Runtime Software Upgrades

•Installing SCT Files

Upgrading AXSM-XG Cards

The following notes apply to AXSM-XG card upgrades:

•When installing AXMS-XG cards into a node that has a release earlier than Release 4.0.15, all of the other cards in the node must be upgraded first to Release 5.0.

•When configuring virtual interfaces (for example, VUNI, VNNI, EVUNI, or EVNNI), the physical interface must be of all one ATM header type, either UNI or NNI. The signaling that is applied to a virtual port is independent of the actual virtual port ATM header. The only limit is that the VPI value must be within the UNI ATM header limitations.

Upgrading the VISM-PR Image

If you are upgrading the VISM-PR image to Release 3.2.1x or later and the PXM1E or PXM45 image from Release 4.x or earlier to Release 5.x, first upgrade the VISM-PR cards. Then, upgrade the PXM1E or PXM45 cards in the same node.

Do not configure the new VISM features until you have fully upgraded the network. After you upgrade your network to PXM1E or PXM45 Release 5.x or later and VISM-PR to Release 3.2.1x or later, apply the standard upgrade process.

Maintenance Information

The upgrade appendix in the Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2 contains the following procedures:

•Replacing PXM1E-4-155 cards and with PXM1E-8-155 Cards

•Replacing PXM45/A or PXM45/B Cards with PXM45/C Cards.

Anomalies in Release 5.2.20

This section contains the known, resolved, and changed status anomalies in Release 5.2.20.

For information about anomalies with the VXSM card, refer to Release Notes for the Cisco Voice Switch Service Module (VXSM), Release 5.2.10.

For information about anomalies with the VISM card, refer to Release Notes for the Cisco Voice Interworking Service Module (VISM), Release 3.3.25.

Known Anomalies in Release 5.2.20

Headline: Alarm in B/W MPSM-MF line and FRSM CAS line takes more than 2 hours to clear.

Symptom: Framing errors on MPSM E1 lines.

Conditions: Occurs with MPSM line in MF or MF-CRC mode, when connected to FRSM-8 in CCS/CCS-CRC mode.

Workaround: Configure a different framing mode for the line.

Hardware: MPSM-16-T1E1

CSCeh20665

Headline: AXSM-XG NVRAM gets corrupted

Symptom: AXSM-XG cards show up as having a corrupted NVRAM.

Condition: If an AXSM-XG card is moved to a different slot or chassis type (for example 8850 to 8950) while the chassis/PXM is powered off there is a remote chance that the NVRAM will be corrupted and the card will fail to boot on the next card initialization.

Workaround: Ensure that the chassis and PXMs are powered up before installing the AXSM-XG cards in the new slot.

Symptom: On an MPSM-T3E3-155 card configured with redundancy, executing a delppplink followed immediately by a dnpath results in a RamSync error on the standby card and the card resets. This problem is repeatable only from the test script, not from the CLI.

LMI Autosense is not supported on MPSM-8T1-FRM and MPSM-8E1-FRM cards. Therefore, the LMI Autosense steps in the following procedures apply to the FRSM cards only:

•Chapter 2, "Adding Frame Relay Ports"

•Chapter 2, "Configuring Frame Relay Ports"

Also, the LMI Autosense options in the following commands apply to the FRSM card only:

•addport

•cnfport

•xcnfport

Cisco MGX 8800/8900 Series Configuration Guide, Release 5.2 Updates

The following sections are updated:

•Appendix A—Graceful upgrades to AXSM-XG

•Appendix F—MPSM licensing updates

For information about updated commands for the graceful update feature, see the Cisco MGX 8800/8900 Series Command Reference, Release 5.2.

Appendix A: Downloading and Installing Software Upgrades

Upgrading an AXSM/A, AXSM/B, or AXSM-E to an AXSM-XG

The AXSM-16-155-XG and AXSM-8-622-XG cards have a higher port density than the equivalent AXSM-E cards, and the AXSM-16-155-XG and AXSM-8-622-XG have better traffic management support than their AXSM/B counterparts. Using the procedures in this section, you can gracefully upgrade AXSM, AXSM/B and AXSM-E cards to AXSM-XG cards.

Graceful upgrades simplify the process of migrating to the newer AXSM-XG cards. During the upgrade, the MGX control processor transfers the configuration/connection database from the previously installed AXSM card to the new AXSM-XG, which preserves all connection configurations. The upgrade process might cause an outage of up to four minutes.

A cable adapter (PN 39-0258-01) is available for AXSM-XG upgrades (single-mode and multimode).

Supported Configurations

Graceful hardware upgrades from AXSM-A/B/E OC-3/OC-12 release 4.0.17 or later to AXSM-XG OC-3/OC-12 in standalone or redundancy mode with Y-cable configurations are supported.

Limitations

The following limitations apply to graceful upgrades:

•AXSM-A/B do not support Y-cable in MMF configuration

•AXSM-XG-622 lines cannot be set to both SONET and SDH on the same bay. If the card to upgrade has both SONET and SDH lines on the same back card, separate the lines into different bays before starting the migration.

•AXSM OC-48 cards cannot be gracefully upgraded to AXSM-XG OC-48 cards in the MGX 8950 chassis because the back cards are physically incompatible. However, non-graceful upgrade is supported.

•Upgrade of AXSM-A/B/E with SMB-4-155 to AXSM-XG with an electrical back card (MCC-8-155) is not supported because of hardware limitations of the MCC-8-155 back card.

•No more than 6 SCTs can be loaded onto the AXSM-XG at one time.

Preparing to Upgrade

Before performing the upgrade procedures, perform the following tasks:

•Upgrade all other cards to Release 5.2. This is very important, because failure to upgrade will cause connections on the upgraded card to other AXSM cards to change to the mismatch state.

•Verify that the AXSM to upgrade has less than 126,976 connections, which is the maximum number of AXSM-XG connections.

•Verify that the system is in good working order. This includes checking for alarms and verifying redundancy operation. Resolve any existing problems before starting the upgrade.

•Do not attempt to upgrade an electrical back card with APS.

Converting Custom SCTs

The AXSM-A/B/E SCT files are not compatible with the AXSM-XG SCT files. The upgrade procedure automatically updates the default SCT files to the new format. However, customers that use custom SCTs must convert them to the AXSM-XG format before performing the upgrade. The following tables show the AXSM SCT mapping for Cisco-provided SCTs.

Table 24 AXSM-A/B to AXSM-XG SCT Mapping

AXSM-A/B

AXSM-XG

AXSM_SCT.CARD.0.V1

AXSMXG_SCT.CARD.2.V1

AXSM_SCT.CARD.2.V1

AXSMXG_SCT.CARD.2.V1

AXSM_SCT.CARD.3.V1

AXSMXG_SCT.CARD.2.V1

AXSM_SCT.CARD.4.V1

AXSMXG_SCT.CARD.2.V1

AXSM_SCT.CARD.5.V1

AXSMXG_SCT.CARD.2.V1

AXSM_SCT.PORT.0.V1

AXSMXG_SCT.PORT.410.V1 (OC-3) /

AXSMXG_SCT.PORT.310.V1 (OC-12)

AXSM_SCT.PORT.2.V1

AXSMXG_SCT.PORT.410.V1 (OC-3) /

AXSMXG_SCT.PORT.310.V1 (OC-12)

AXSM_SCT.PORT.3.V1

AXSMXG_SCT.PORT.400.V1 (OC-3) /

AXSMXG_SCT.PORT.300.V1 (OC-12)

AXSM_SCT.PORT.4.V1

AXSMXG_SCT.PORT.410.V1 (OC-3) /

AXSMXG_SCT.PORT.310.V1 (OC-12)

AXSM_SCT.PORT.5.V1

AXSMXG_SCT.PORT.400.V1 (OC-3) /

AXSMXG_SCT.PORT.300.V1 (OC-12)

Table 25 AXSM-E to AXSM-XG SCT Mapping

AXSM-E

AXSM-XG

AXSME_SCT.CARD.5.V1

AXSMXG_SCT.CARD.2.V1

AXSME_SCT.CARD.52.V1

AXSMXG_SCT.CARD.2.V1

AXSME_SCT.PORT.0.V1

AXSMXG_SCT.PORT.410.V1 (OC-3) /

AXSMXG_SCT.PORT.310.V1 (OC-12)

AXSME_SCT.PORT.5.V1

AXSMXG_SCT.PORT.410.V1 (OC-3) /

AXSMXG_SCT.PORT.310.V1 (OC-12)

AXSME_SCT.PORT.6.V1

AXSMXG_SCT.PORT.400.V1 (OC-3) /

AXSMXG_SCT.PORT.300.V1 (OC-12)

To convert custom AXSM-A/B/E SCTs to AXSM-XG SCTs:

Step 1 Map the existing AXSM-A/B/E SCT to the new AXSM-XG SCT using Table 24 or Table 25.

For example, if the existing SCT was derived from AXSM_SCT.PORT.2.V1 (which has policing enabled for PNNI), the new SCT must be derived from AXSMXG_SCT.PORT.410.V1(which is specific for the OC-3 card and has policing enabled for PNNI).

Step 2 Using a tool such as CWM, port the custom settings from the existing AXSM-A/B/E SCT to the new AXSM-XG SCT.

Step 3 Save the new AXSM-XG SCT using the same SCT ID that the existing SCT uses.

For example, if the existing SCT is named AXSM_SCT.PORT.40.V1, save the new SCT as AXSMXG_SCT.PORT.40.V1.

Graceful Upgrade Procedure

This section explains how to gracefully upgrade an AXSM-A/B/E card to an AXSM-XG card, and includes an example of upgrading an AXSM-A card to an AXSM-8-622-XG card.

Note If you experience problems with the upgrade, you can cancel it using the abortrev command.

The following display shows the example system, which includes two redundant AXSM/A cards to be upgraded, using the PXM dspcd command. Slot 10 is the active card, and slot 11 is the standby card. Inter-card APS is not configured, but lines 10.1.1 and 11.1.1 are connected using a single mode fiber Y-cable.

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 May. 20, 2005 22:38:56 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: NONE

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

02 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Active/Active AXSM_4OC12 NONE 11 PRIMARY SLOT

11 Standby/Active AXSM_4OC12 NONE 10 SECONDARY SLOT

12 Active/Active AXSM_1OC48 NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

To perform a graceful upgrade of a AXSM A/B/E to AXSM-XG card, follow these steps.

Step 1 Delete any intercard APS configured on the AXSM A/B/E cards to be upgraded using the delapsln command.

Note Deleting APS may cause traffic outages.

Step 2 From the AXSM A/B/E card, enter the dspconinfo command and record the existing connection information. You will use this information later to verify successful migration of existing connections to the new AXSM-XG card.

Step 3 From the PXM issue the loadrev command, specifying the active slot of the redundancy pair, software version, and axsmxg keyword. The axsmxg keyword specifies that you are upgrading both hardware and software.

For example:

M8850_NY.7.PXM.a > loadrev 10 5.1(206.15)A axsmxg

one or more card(s) in the logical slot may be reset.

loadrev: Do you want to proceed (Yes/No)? y

Replace the card in slot 11 with AXSMXG now

M8850_NY.7.PXM.a >

After entering the loadrev command, the card in slot 11 changes to the Mismatch state. For example:

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 May. 20, 2005 22:51:50 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: MAJOR

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

02 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Active-U/Active AXSM_4OC12 NONE 11 PRIMARY SLOT

11 Mismatch-U/Empty AXSM_4OC12 MAJOR 10 SECONDARY SLOT

12 Active/Active AXSM_1OC48 NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

Step 4 Insert the new AXSM-XG front card, back cards, and cables in the standby slot of the redundancy pair. The AXSM-XG card comes up in the STANDBY-U state.

The output of the PXM dspcds command for the example is as follows.

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 May. 21, 2005 00:04:47 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: MAJOR

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

02 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Active-U/Active AXSM_4OC12 NONE 11 PRIMARY SLOT

11 Standby-U/Active AXSM-8-622-XG MAJOR 10 SECONDARY SLOT

12 Active/Active AXSM_1OC48 NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

Note The card may remain in Mismatch state if old hardware was still plugged in after a card reset with the new card type.

Step 5 Load the boot code on the standby AXSM-XG card using the PXM burnboot command, specifying the standby slot number and the boot code version. The standby AXSM-XG card is reset and upgraded to the specified boot software version.

For example:

M8850_NY.7.PXM.a > burnboot 11 5.1(206.15)A

WARNING! burnboot is a destructive command if used improperly.

Please DO NOT Abort or Reset the PXM/SM when the command is in progress,

as this may corrupt the Boot image.

The card in slot 11 will be reset.

burnboot: Do you want to proceed (Yes/No)? y

Step 6 If SCM is being used for statistics collection, disable statistics collection using the SCM GUI.

Note You cannot disable statistics collection using the MGX CLI; you must use the SCM GUI.

Step 7 From the PXM, enter the runrev command, specifying the active slot of a redundancy pair, the version number, and the axsmxg keyword.

Note In some cases, such as failed slot hardware, you must force the action using the -f option.

For example:

M8850_NY.7.PXM.a > runrev 10 5.1(206.15)A axsmxg

one or more card(s) in the logical slot may be reset.

runrev: Do you want to proceed (Yes/No)? y

Replace the card in slot 10 with AXSMXG now

M8850_NY.7.PXM.a >

After issuing the runrev command, the PXM dspcds command shows card 10 in the Mismatch state.

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 May. 21, 2005 00:52:00 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: MAJOR

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

02 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Mismatch-U/Empty AXSM_4OC12 MAJOR 11 PRIMARY SLOT

11 Active-U/Active AXSM-8-622-XG NONE 10 SECONDARY SLOT

12 Active/Active AXSM_1OC48 NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

Step 8 Insert the second AXSM-XG hardware, including front card, back cards, and cables.

Removing the existing hardware from the active slot invokes a redundancy switchover, and the standby AXSM-XG card transitions to the ACTIVE-U state.

The newly inserted AXSM-XG card becomes the standby card and transitions to the STANDBY-U state.

The output of the PXM dspcds command is as follows:

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 May. 21, 2005 01:01:06 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: NONE

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

02 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Standby-U/Active AXSM-8-622-XG NONE 11 PRIMARY SLOT

11 Active-U/Active AXSM-8-622-XG NONE 10 SECONDARY SLOT

12 Active/Active AXSM_1OC48 NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

Note The card may remain in Mismatch state if old hardware was still plugged in after a card reset with the new card type.

Step 9 If SCM is being used for statistics collection, verify that the new card is ready for statistics collection and then enable statistics collection using the SCM GUI.

Note You cannot enable statistics collection using the MGX CLI.

Step 10 Load the boot code on the second AXSM-XG card using the PXM burnboot command, specifying the new standby slot number and the boot code version. The new standby AXSM-XG card is reset and upgraded to the specified boot software version. For example:

M8850_NY.7.PXM.a > burnboot 10 5.1(206.15)A

WARNING! burnboot is a destructive command if used improperly.

Please DO NOT Abort or Reset the PXM/SM when the command is in progress,

as this may corrupt the Boot image.

The card in slot 10 will be reset.

burnboot: Do you want to proceed (Yes/No)? y

M8850_NY.7.PXM.a >

Step 11 Restore APS if it was previously present using the addapsln command.

Step 12 Verify that both cards have become ACTIVE-U and STANDBY-U using the PXM dspcds command:

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 May. 21, 2005 01:13:23 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: NONE

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

02 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Standby-U/Active AXSM-8-622-XG NONE 11 PRIMARY SLOT

11 Active-U/Active AXSM-8-622-XG NONE 10 SECONDARY SLOT

12 Active/Active AXSM_1OC48 NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

Step 13 Verify that the upgrade was successful.

a. From the AXSM-XG card, enter the dspconinfo command and verify successful migration of all existing connections to the AXSM-XG redundancy pair. If necessary, wait for the migration to complete.

b. From the AXSM-XG card, enter the dspcd command and verify that all line, port, partition, and connections are correct, and that it displays the type of card from which this AXSM-XG was upgraded.

Note You can revert to the previous hardware and software using the abortrev command.

Step 14 From the PXM, enter the commitrev command, specifying the slot number, version number, and axsmxg keyword.

Non-Graceful Upgrade Procedure

This section explains how to upgrade AXSM-A/B/E cards to AXSM-XG cards, and includes an example of upgrading an AXSM-A card to an AXSM-8-622-XG card.

The following display shows the card status in the example system, using the PXM dspcd command. The AXSM/A card in slot 12 is operating normally and is ready to upgrade.

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 Jun. 22, 2005 18:44:09 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: NONE

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE 02 PRIMARY SLOT

02 Standby/Active AXSM_4OC12 NONE 01 SECONDARY SLOT

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Active/Empty RPM NONE NA NO REDUNDANCY

11 Empty --- --- --- ---

12 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

27 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

To perform a non-graceful upgrade of a AXSM A/B/E to AXSM-XG card, follow these steps.

Step 1 From the AXSM A/B/E card, enter the dspconinfo command and record the existing connection information. You will use this information later to verify successful migration of existing connections to the new AXSM-XG card.

Step 2 From the PXM issue the loadrev command, specifying the slot of the card to upgrade, software version, and axsmxg keyword. The axsmxg keyword specifies that you are upgrading both hardware and software.

M8850_NY.7.PXM.a > loadrev 12 5.1(206.20)A axsmxg

one or more card(s) in the logical slot may be reset.

loadrev: Do you want to proceed (Yes/No)? y

M8850_NY.7.PXM.a >

After entering the loadrev command, the card in slot 12 changes to the Active-U state. For example:

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 Jun. 22, 2005 19:16:32 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: MAJOR

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE 02 PRIMARY SLOT

02 Standby/Active AXSM_4OC12 NONE 01 SECONDARY SLOT

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Active/Empty RPM NONE NA NO REDUNDANCY

11 Empty --- --- --- ---

12 Active-U/Active AXSM_4OC12 MAJOR NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

27 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

M8850_NY.7.PXM.a >

Step 3 If SCM is being used for statistics collection, disable statistics collection using the SCM GUI.

Note You cannot disable statistics collection from the MGX CLI; you must use the SCM GUI.

Step 4 From the PXM card, enter the runrev command, specifying the slot number, the version number, and the axsmxg keyword.

For example:

M8850_NY.7.PXM.a > runrev 12 5.1(206.20)A axsmxg

one or more card(s) in the logical slot may be reset.

runrev: Do you want to proceed (Yes/No)? y

Replace the card in slot 12 with AXSMXG now

After entering the runrev command, card 12 changes to the Mismatch state.

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 Jun. 22, 2005 19:16:32 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: MAJOR

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE 02 PRIMARY SLOT

02 Standby/Active AXSM_4OC12 NONE 01 SECONDARY SLOT

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Active/Empty RPM NONE NA NO REDUNDANCY

11 Empty --- --- --- ---

12 Mismatch-U/Empty AXSM_4OC12 MAJOR NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

27 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

Step 5 Insert the new AXSM-XG front card, back cards, and cables. The new AXSM-XG card comes up in the ACTIVE-U state.

Enter the PXM dspcds command again:

M8850_NY.7.PXM.a > dspcds

M8850_NY System Rev: 05.01 Jun. 22, 2005 19:40:26 GMT

Chassis Serial No: SAA03211181 Chassis Rev: B0 GMT Offset: 0

Node Alarm: NONE

Card Front/Back Card Alarm Redundant Redundancy

Slot Card State Type Status Slot Type

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

01 Active/Active AXSM_4OC12 NONE 02 PRIMARY SLOT

02 Standby/Active AXSM_4OC12 NONE 01 SECONDARY SLOT

03 Active/Active VXSM_155 NONE NA NO REDUNDANCY

04 Active/Active AXSME_16T3E3 NONE NA NO REDUNDANCY

05 Active/Active AXSM_4OC12 NONE NA NO REDUNDANCY

06 Active/Active AXSM_16OC3_B NONE NA NO REDUNDANCY

07 Active/Active PXM45C NONE 08 PRIMARY SLOT

08 Standby/Active PXM45C NONE 07 SECONDARY SLOT

09 Active/Active RPM_PR NONE NA NO REDUNDANCY

10 Active/Empty RPM NONE NA NO REDUNDANCY

11 Empty --- --- --- ---

12 Active-U/Active AXSM-8-622-XG NONE NA NO REDUNDANCY

13 Active/Active FRSM_2CT3 NONE NA NO REDUNDANCY

14 Empty --- --- --- ---

15 Empty --- --- --- ---

16 Empty --- --- --- ---

27 Empty --- --- --- ---

29 Active/Active FRSM_8T1 NONE NA NO REDUNDANCY

30 Active/Active FRSM_8E1 NONE NA NO REDUNDANCY

31 Empty --- --- --- ---

32 Empty --- --- --- ---

Note The card may remain in Mismatch state if old hardware was still plugged in after issue of card reset with the new card type.

Step 6 Load the boot code on the AXSM-XG card using the PXM burnboot command, specifying the slot number and the boot code version. The standby AXSM-XG card is reset and upgraded to the specified boot software version. For example:

M8850_NY.7.PXM.a > burnboot 12 5.1(206.20)A

WARNING! burnboot is a destructive command if used improperly.

Please DO NOT Abort or Reset the PXM/SM when the command is in progress,

as this may corrupt the Boot image.

The card in slot 12 will be reset.

burnboot: Do you want to proceed (Yes/No)? y

Step 7 If SCM is being used for statistics collection, verify that the new card is ready for statistics collection and then enable statistics collection using the SCM GUI.

Note You cannot enable statistics collection using the MGX CLI.

Step 8 Verify that the upgrade was successful.

a. From the AXSM-XG card, enter the dspconinfo command and verify successful migration of all existing connections to the AXSM-XG. If necessary, wait for the migration to complete.

b. From the AXSM-XG card, enter the dspcd command and verify that all line, port, partition, and connections are correct, and that it displays the type of the card from which this AXSM-XG was upgraded.

Note You can revert to the previous hardware and software using the abortrev command.

Step 9 From the PXM, enter the commitrev command, specifying the slot number, version number, and axsmxg keyword.

M8850_NY.7.PXM.a > commitrev 12 5.1(206.20)A axsmxg

After you enter the PXM commitrev command, the PXM dspcds command displaysthe following:

Product Documentation DVD

The Product Documentation DVD is a library of technical product documentation on a portable medium. The DVD enables you to access installation, configuration, and command guides for Cisco hardware and software products. With the DVD, you have access to the HTML documentation and some of the PDF files found on the Cisco website at this URL:

The Product Documentation DVD is created monthly and is released in the middle of the month. DVDs are available singly or by subscription. Registered Cisco.com users can order a Product Documentation DVD (product number DOC-DOCDVD= or DOC-DOCDVD=SUB) from Cisco Marketplace at the Product Documentation Store at this URL:

To see security advisories, security notices, and security responses as they are updated in real time, you can subscribe to the Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed. Information about how to subscribe to the PSIRT RSS feed is found at this URL:

Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you have identified a vulnerability in a Cisco product, contact PSIRT:

An emergency is either a condition in which a system is under active attack or a condition for which a severe and urgent security vulnerability should be reported. All other conditions are considered nonemergencies.

Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product (for example, GnuPG) to encrypt any sensitive information that you send to Cisco. PSIRT can work with information that has been encrypted with PGP versions 2.x through 9.x.

Never use a revoked encryption key or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page at this URL:

If you do not have or use PGP, contact PSIRT to find other means of encrypting the data before sending any sensitive material.

Product Alerts and Field Notices

Modifications to or updates about Cisco products are announced in Cisco Product Alerts and Cisco Field Notices. You can receive Cisco Product Alerts and Cisco Field Notices by using the Product Alert Tool on Cisco.com. This tool enables you to create a profile and choose those products for which you want to receive information.

Obtaining Technical Assistance

Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The Cisco Technical Support & Documentation website on Cisco.com features extensive online support resources. In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact your reseller.

Cisco Technical Support & Documentation Website

The Cisco Technical Support & Documentation website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day at this URL:

Access to all tools on the Cisco Technical Support & Documentation website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

Note Use the Cisco Product Identification Tool to locate your product serial number before submitting a request for service online or by phone. You can access this tool from the Cisco Technical Support & Documentation website by clicking the Tools & Resources link, clicking the All Tools (A-Z) tab, and then choosing Cisco Product Identification Tool from the alphabetical list. This tool offers three search options: by product ID or model name; by tree view; or, for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.

Tip Displaying and Searching on Cisco.com

If you suspect that the browser is not refreshing a web page, force the browser to update the web page by holding down the Ctrl key while pressing F5.

To find technical information, narrow your search to look in technical documentation, not the entire Cisco.com website. On the Cisco.com home page, click the Advanced Search link under the Search box and then click the Technical Support & Documentation.radio button.

To provide feedback about the Cisco.com website or a particular technical document, click Contacts & Feedback at the top of any Cisco.com web page.

Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco engineer. The TAC Service Request Tool is located at this URL:

For S1 or S2 service requests, or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

To open a service request by telephone, use one of the following numbers:

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—An existing network is "down" or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operations are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Severity 3 (S3)—Operational performance of the network is impaired while most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

•The Cisco Product Quick Reference Guide is a handy, compact reference tool that includes brief product overviews, key features, sample part numbers, and abbreviated technical specifications for many Cisco products that are sold through channel partners. It is updated twice a year and includes the latest Cisco channel product offerings. To order and find out more about the Cisco Product Quick Reference Guide, go to this URL:

•Cisco Press publishes a wide range of general networking, training, and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

•Packet magazine is the magazine for Cisco networking professionals. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can subscribe to Packet magazine at this URL:

•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

•Networking Professionals Connection is an interactive website where networking professionals share questions, suggestions, and information about networking products and technologies with Cisco experts and other networking professionals. Join a discussion at this URL:

•"What's New in Cisco Documentation" is an online publication that provides information about the latest documentation releases for Cisco products. Updated monthly, this online publication is organized by product category to direct you quickly to the documentation for your products. You can view the latest release of "What's New in Cisco Documentation" at this URL:

All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0601R)