Cisco MGX 8800 Series Switches

Table Of Contents

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

Contents

About Release 3.0.00

Type of Release

Locating Software Updates

New Features and Enhancements in Release 3.0.00

High Density Frame Relay FRSM-12-T3E3 Card

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

About the New MGX 8830 Switch

About the New MGX 8850 (PXM1E) Switch

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

MGX-RPM-XF-512 Card

Hardware Features

Software Features

DSL Access Support — Single-ended SPVC Configuration

250K Connections

Path and Connection Trace

Network Clock Distribution Protocol (NCDP)

Simple Network Time Protocol (SNTP)

Priority Routing

Per Connection Overbooking

Preferred Routing

Clear Service Module Configuration (clrsmcnf)

Disk Sync Verify

AXSM and AXSM-E Virtual UNI

Persistent Topology

SCT File Management and User-Configurable Names

Detection of Non-native Controller Front Card and HDD Card

VISM-PR Card

Enhancements

Service Class Template (SCT) File Information

System Requirements

Software/Firmware Compatibility Matrix

MGX and RPM Software Version Compatibility Matrix

Additional Compatibility Information

Hardware Supported

New Hardware in Release 3.0.00

APS Connectors

MGX 8850 (PXM45) Product IDs and Card Types

MGX 8850 (PXM1E) Product IDs and Card Types

MGX 8830 Product IDs and card types

New and Changed Commands

Limitations, Restrictions, and Notes for 3.0.00

MGX Release 3.0.00 Limitations

Policing Accuracy for PXM1E

Maximum Threshold Accuracy for PXM45 and PXM1E

Limitations for PXM1E-based Switches

FRSM-12-T3E3 Limitations

Disk Space Maintenance

Non-native Controller Front Card and HDD Card

clrsmcnf Limitations

APS Limitations

Limitations and Restrictions for PNNI Features

Path and Conn Trace

SNTP

Priority Routing

SPVC Interop

Preferred Route feature

Persistent Topology Feature

NCDP

Manual Clocking

AXSM Limitations

VISM Limitations

RPM-PR and RPM-XF Limitations

Restrictions

Formatting Disks

Saving Configurations

Other Limitations and Restrictions

Clearing the Configuration on Redundant PXM45 and PXM1E Cards

Limitations and Restrictions for 2.1.x

General Limitations, Restrictions, and Notes

Limitations for rteopt via parallel links

Important Notes

APS Management Information

Preparing for Intercard APS

Managing Intercard APS Lines

Troubleshooting APS Lines

Installing and Upgrading to Release 3.0.00

Important Note

Installation and Upgrade Procedures

Upgrade Process Overview

Quickstart Procedures for Software Upgrades

Browsing the File System

Copying Software Files to the Switch

Upgrade Procedures for PXM45 and AXSM Cards

Troubleshooting Upgrade Problems

Documentation

Related Documentation

Cisco WAN Manager Release 11.0.00

Cisco MGX 8850 (PXM45) Multiservice Switch Release 3

Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3

Cisco MGX 8950 Multiservice Switch Release 3

Service Expansion Shelf PNNI Controller Release 3

Cisco MGX 8830 Multiservice Switch Release 3

Cisco WAN Switching Software Release 9.3.40

MGX 8850 (PXM1) Multiservice Switch Release 1.2.10

MGX 8250 Edge Concentrator Release 1.2.10

MGX 8230 Edge Concentrator Release 1.2.10

Ordering Documentation

Documentation on the World Wide Web

Documentation CD-ROM

Documentation Feedback

Technical Assistance

Cisco.com

Technical Assistance Center

Contacting TAC by Using the Cisco TAC Website

Contacting TAC by Telephone

Caveats

MGX 8830 Anomalies

MGX 8850 Anomalies

Known Anomalies in Release 3.0.00

Anomalies Resolved in Release 3.0.00

Known Route Processor Module or MPLS Anomalies

MGX-RPM-XF-512 Anomalies

Acronyms

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

---

Contents

About Release 3.0.00

These release notes describe the system requirements, new features, and limitations that apply to Release 3.0.00 of the MGX 8850 and the new MGX 8830 multi-service switch. These notes also contain Cisco support information.

MGX Release 3.0.00 introduces the new MGX 8830 and MGX 8850 (PXM1E) switches, Cisco's new 1.2G multiservice edge switches with PNNI routing.

For PXM45-based switches (that is, MGX 8850 (PXM45) and MGX 8950), MGX Release 3.0.00 provides the tools for more powerful scaling. MGX Release 3.0.00 allows networks based on the MGX 8850 (PXM45) or MGX 8950 to scale to new heights in supported connections, going from the current 40K to 100K persistent connections per node, in addition to up to 150K transient connections. MGX Release 3.0.00 also allows service providers to expand ABR with VS/VD capability on the MGX 8850(PXM45) platform by doubling the number of ports supported on the AXSM/E cards.

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

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

Type of Release

Release 3.0.00 is a hardware and software release for the new MGX 8830 PNNI routing switch.

Release 3.0.00 is a software and hardware release for the new MGX 8850 (PXM1E) switch.

Release 3.0.00 is a software and hardware release for the MGX 8850 (PXM45) switch.

Locating Software Updates

This is the location for the MGX 8850 software:

•ftp://ftp.cisco.com/cisco/wan/beta/0588xgm.

This is the location for the MGX 8950 software:

•ftp://ftp.cisco.com/cisco/wan/beta/0598xgm.

This is the location for the MGX 8830 software:

•ftp://ftp.cisco.com/cisco/wan/beta/0388xgm.

New Features and Enhancements in Release 3.0.00

Release 3.0.00 contains these new features:

•High Density Frame Relay FRSM-12-T3E3 card

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

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

•MGX-RPM-XF-512 Card

•DSL Access Support — Single-ended SPVC configuration

•250K Connections

•Path and Connection Trace

•Network Control Distribution Protocol

•Simple Network Time Protocol

•Priority Routing

•Per Connection Overbooking

•Preferred Routing

•Clear Service Module Configuration (clrsmcnf)

•Disk Sync Verify

•AXSM and AXSM-E Virtual UNI

•Persistent Topology

•SCT File Management and User Configurable Names

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

•VISM-PR Card

High Density Frame Relay FRSM-12-T3E3 Card

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

•Interfaces: Frame Relay UNI/NNI, Frame Forwarding

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

•FRF.5, FRF.8.1 interworking

•LMI, enhanced-LMI, FRF.1.2

•Ingress per-VC queuing, Frame-based policing

•Standard ABR with VS/VD

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

This card is supported on the MGX 8850 (PXM45) switch. (This card is not supported on PXM1E-based switches, that is, MGX 8850 (PXM1E) and MGX 8830.

Benefits

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

•Frame-based IP services

•DS3 Frame Relay Service

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

The new PXM1E-based switches include:

•MGX 8850 (PXM1E)

•MGX 8830

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

•FRSM 8T1/8E1, HS2B

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

•AUSM 8T1/E1

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

•SRM-E and SRM-3T3/C

•Support for RPM-PR controller

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

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

•Planned connection limit - one of the following:

•27K (both terminating and via connections)

•16K DAX connections

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

•Support for 1:1 redundancy

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

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

This card is supported on the MGX 8850 (PXM1E) and the MGX 8830.

About the New MGX 8830 Switch

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

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

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

About the New MGX 8850 (PXM1E) Switch

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

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

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

The complete list of architecture mode supported by software is:

•1+1 GR253

•1:1 GR253

•1+1 G.783 Annex A

•1:1 G.783 Annex A

•1+1 G.783 Annex B

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

Benefits

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

MGX-RPM-XF-512 Card

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

Hardware Features

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

•Full height Serial Line based Router module.

•Dual OC24 ATM SAR.

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

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

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

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

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

Software Features

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

•Edge LSR functions.

•Label Switch Controller.

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

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

•Frame based MPLS and Cell based MPLS support.

•PNNI SPVC/SPVP connection Management.

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

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

•Support for IP Multicast.

•PPP services. PPPoA

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

The MGX-RPM-XF-512 card is supported on the MGX 8850 (PXM45) switch.

DSL Access Support — Single-ended SPVC Configuration

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

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

Benefits

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

250K Connections

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

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

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

Benefits

Customers can provision more connections on each switch.

Path and Connection Trace

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

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

Benefits

Standards based feature enables interoperability with other vendor equipment.

Network Clock Distribution Protocol (NCDP)

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

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

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

Benefits

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

Simple Network Time Protocol (SNTP)

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

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

Benefits

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

Priority Routing

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

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

Benefits

The customer can offer prioritized services based on connection priority.

Per Connection Overbooking

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

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

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

Benefits

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

Preferred Routing

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

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

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

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

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

Benefits

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

Clear Service Module Configuration (clrsmcnf)

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

The clrsmcnf feature is supported on the following modules.

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

•MGX 8950: AXSM/B, RPM-PR

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

Benefits

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

Disk Sync Verify

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

AXSM and AXSM-E Virtual UNI

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

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

Benefits

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

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

Persistent Topology

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

This feature will deliver the following functionality:

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

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

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

•Support redundancy of the cumulative topology database.

Benefits

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

SCT File Management and User-Configurable Names

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

Detection of Non-native Controller Front Card and HDD Card

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

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

•C:FW

•C:SCT

•F:SCT

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

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

VISM-PR Card

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

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

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

Enhancements

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

Table 2 List of Product Enhancement Requests in MGX Release 3.0.00

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

Service Class Template (SCT) File Information

This section contains SCT file information for Release 3.0.00.

PXM1E

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

•PXM1E_SCT.PORT.5

•PXM1E_SCT.PORT.6

The default SCTs provided with Release 3.0.00 are as follows:

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

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

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

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

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

ABR VSVD parameters are not supported due to hardware limitation.

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

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

•AXSME_SCT.CARD.5

•AXSME_SCT.PORT.5

•AXSME_SCT.PORT.6

AXSM and AXSM/B

•SCT 2 - policing enabled, PNNI

•SCT 3 - policing disabled, PNNI

•SCT 4 - policing enabled, MPLS and PNNI

•SCT 5 - policing disabled, MPLS and PNNI

The check sum for the SCT files are as follows

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

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

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

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

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

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

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

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

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

AXSM-E

These are the new AXSM-E SCT files:

•SCT 52 - policing enabled, PNNI

•SCT 53 - policing disabled, PNNI

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

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

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

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

FRSM-12-T3E3

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

•ATM CAC is not supported.

•UPC cannot be configured using SCT

•WFQ and ABR is not supported in the port SCT

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

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

•SCT 4 - PNNI

The checksum is:

•FRSM12_SCT.PORT.4 checksum = 0x28539d36

• FRSM12_SCT.CARD.4 checksum = 0x28539d36

System Requirements

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

Software/Firmware Compatibility Matrix

Table 3 lists Cisco WAN or IOS products that are interoperable with Release 3.0.00.

Table 3 MGX 3.0.00 Compatibility Matrix

Product	N	N-1	N-2
CWM	11.0.00	10.5.10 patch 1	N/A
MGX 1	1.2.10	1.2.01	1.1.40
MGX 2	3.0.00	2.1.76	2.0.16
BPX/IGX	9.3.40	9.3.36	9.2.41
BXM FW	MFV	MFR	MFN
UXM FW	ACH	ABT	N/A
URM FW	XBB	XBA	N/A
MGX 8220	5.0.18	4.1.12	N/A
SES	3.0.00	1.1.75	1.0.16
RPM IOS	12.2(8)T4	12.2(8)T2	N/A

MGX and RPM Software Version Compatibility Matrix

Table 4 lists the software that is compatible for use in a switch running Release 3.0.00 software. Note that the AXSM/B cards use the same software as AXSM cards.

Table 4 MGX and RPM Software Version Compatibility Matrix

Board Pair	Boot Software	Minimum Boot Code Version	Runtime Software	Latest Firmware Version	Minimum Firmware Version
PXM45	pxm45_003.000.000.000_bt.fw	3.0.00	pxm45_003.000.000.000_mgx.fw	3.0.00	3.0.00
PXM45/B	pxm45_003.000.000.000_bt.fw	3.0.00	pxm45_003.000.000.000_mgx.fw	3.0.00	3.0.00
PXM1E-4-155 (MGX 8850 chassis)	pxm1e_003.000.000.000_bt.fw	3.0.00	pxm1e_003.000.000.000_mgx.fw	3.0.00	3.0.00
PXM1E-8-T3E3 (MGX 8850 chassis)
PXM1E-T3E3-155 (MGX 8850 chassis)
PXM1E-4-155 (MGX 8830 chassis)	pxm1e_003.000.000.000_bt.fw	3.0.00	pxm1e_003.000.000.000_m30.fw	3.0.00	3.0.00
PXM1E-8-T3E3 (MGX 8830 chassis)
PXM1E-T3E3-155 (MGX 8830 chassis)
AXSM-1-2488	axsm_003.000.000.000_bt.fw	3.0.0	axsm_003.000.000.000.fw	3.0.00	3.0.00
AXSM-16-155
AXSM-4-622
AXSM-16-T3/E3
AXSM-1-2488/B	axsm_003.000.000.000_bt.fw	3.0.00	axsm_003.000.000.000.fw	3.0.00	3.0.00
AXSM-16-155/B
AXSM-4-622/B
AXSM-16-T3/E3/B
AXSM-2-622-E	axsme_003.000.000.000_bt.fw	3.0.00	axsme_003.000.000.000.fw	3.0.00	3.0.00
AXSM-8-155-E
AXSM-16-T3E3-E
FRSM-12-T3E3	frsm12_003.000.000.000_bt.fw	3.0.0	frsm12_003.000.000.000.fw	3.0.0	3.0.0
VISM-PR-8T1	vism_8t1e1_VI8_BT_3.0.00.fw	3.0.0	vism_8t1e1_003.050.000.000.fw (CALEA image) vism_8t1e1_003.000.000.000.fw (non-CALEA image)	3.0.0	3.0.0
VISM-PR-8E1	vism_8t1e1_VI8_BT_3.0.00.fw	3.0.0	vism_8t1e1_003.050.000.000.fw (CALEA image) vism_8t1e1_003.000.000.000.fw (non-CALEA image)	3.0.0	3.0.0
MGX-SRME	N/A	N/A	N/A	N/A	N/A
SRM3T3/C	N/A	N/A	N/A	N/A	N/A
CESM-8E1	cesm_8t1e1_CE8_BT_1.0.02.fw	1.0.02	cesm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
CESM-8T1/B	cesm_8t1e1_CE8_BT_1.0.02.fw	1.0.02	cesm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
AUSM-8T1/B	ausm_8t1e1_AU8_BT_1.0.02.fw	1.0.02	ausm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
AUSM-8E1/B	ausm_8t1e1_AU8_BT_1.0.02.fw	1.0.02	ausm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
FRSM-8T1	frsm_8t1e1_FR8_BT_1.0.02.fw	1.0.02	frsm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
FRSM-8E1	frsm_8t1e1_FR8_BT_1.0.02.fw	1.0.02	frsm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
FRSM-8T1-C	frsm_8t1e1_FR8_BT_1.0.02.fw	1.0.02	frsm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
FRSM-8E1-C	frsm_8t1e1_FR8_BT_1.0.02.fw	1.0.02	frsm_8t1e1_020.000.001.000.fw	20.0.1.0	20.0.1.0
FRSM-HS2/B	frsm_vhs_VHS_BT_1.0.04.fw	1.0.04	frsm_vhs_020.000.001.000.fw	20.0.1.0	20.0.1.0
RPM-PR	rpm-boot-mz.122-8.T4	12.2(8)T4	rpm-js-mz.122-8.T4	12.2(8)T4	12.2(8)T4
MGX-RPM-XF-512	rpmxf-p12-mz.122-8.YP	12.2(8)YP	rpmxf-boot-mz.122-8.YP	12.2(8)YP	12.2(8)YP

Additional Compatibility Information

The RPM IOS releases are as follows:

•RPM-PR card IOS release number is 12.2(8)T4.

•RPM/B card IOS release number is 12.2(8)T4.

•RPM-XF card IOS release number is 12.2(8)YP

The MGX-RPM-XF-512 image name and size are:

•Runtime File: rpmxf-p12-mz.122-8.YP, 7445884

•Boot File: rpmxf-boot-mz.122-8.YP , 2650352

Additional Notes

The following notes provide additional compatibility information for this release:

•You can gracefully upgrade to Release 3.0.00 from Release 2.1.80. A switch running 2.0.16 or below must be upgraded to 2.1.80 before being upgraded to 3.0.00.

•

•MGX 3.0.00 interoperates with SES PNNI 3.0.00 plus BPX Switch Software (SWSW) 9.3.40 plus BXM MFV.

•This release supports feeder connections from Cisco MGX 8850 Release 1.2.10. Please see the "Release Notes for MGX 8850, 8230, and 8250 Software Version 1.2.10" for feeder feature issues. Release notes can be downloaded from http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm

•You must use CWM Release 11.0.00 to manage networks that contain MGX switches running Release 3.0.00.

•The RPM-PR software in this release is based on IOS release 12.2(8)T4.

•The SNMP MIB release for 3.0.00 is mgx8850rel300mib.tar.

Hardware Supported

This section lists:

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

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

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

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

•MGX 8850 (PXM45)

•MGX 8850 (PXM1E)

•MGX 8830

New Hardware in Release 3.0.00

The following new hardware is supported by the Release 3.0.00 software. Features enabled by the hardware are described in New Features and Enhancements in Release 3.0.00.

•MGX 8830 (new chassis, uses PXM1E processor card)

•PXM1E

•FRSM-12-T3E3

•MGX-RPM-XF-512

APS Connectors

Table 5 lists MGX 8850 APS connectors.

Table 5 MGX 8850 APS Connectors

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

---

Note On the MGX 8830, the SRM-E does not need an APS connector since the cross-coupling traces are incorporated into the back plane.

---

MGX 8850 (PXM45) Product IDs and Card Types

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

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

Table 6 Card Numbers and Revisions Supported in Release 3.0.00 for MGX 8850 (PXM45) 

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

1 either connector works for MGX 8850 (PXM45)

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

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

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

MGX 8850 (PXM1E) Product IDs and Card Types

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

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

Table 8 Card Numbers and Revisions Supported in Release 3.0.00 for MGX 8850 (PXM1E) 

Product ID	800 P/N	Min. Revision
PXM1E-4-155	800-18588-03	-A0
PXM1E-8-T3E3	800-18590-03	-A0
PXM1E-T3E3-155	800-18604-03	-A0
MGX-T3E3-155	800-18698-02	-A0
MMF-1-155-SFP	10-1308-01	-A0
SMFLR-1-155-SFP	10-1280-01	-A0
SMFIR-1-155-SFP	10-1283-01	-A0
FRSM-12-T3E3	800-18731-02	-A0
SMB-6-T3E3	800-08799-01	-A0
MGX-RPM-XF-512	800-09307-03	-A0
MGX-XF-UI	800-09492-01	-A0
MGX-1OC12POS-IR	800-08359-05	-A0
MGX-1GE	800-18420-03	-A0
MGX-GE-SX	30-1301-01	-A0
MGX-GE-LHLX	30-1299-01	-A0
MGX-GE-ZX	10-1439-01	-A0
MGX-VISM-PR-8T1	800-07990-02	-A0
MGX-VISM-PR-8E1	800-07991-02	-A0
MGX-SRME	800-14224-02	-A0
MGX-SMFIR-1-155	800-14460-02	-A0
MGX-STM1-EL-1	800-14479-02	-A0
MGX-8850-APS-CON	800-20640-01	-A0
MGX-APS-CON	800-05307-01	-A0
SRM-3T3/C	800-05648-01	-A0
BNC-3T3-M	800-03148-02	-A0
VISM-8T1 Not supported	800-04399-01	-A0
VISM-8E1 Not supported	800-04398-01	-A0
CESM-8E1	800-02751-02	-A0
SMB-8E1	800-02287-01	-A0
R-SMB-8E1	800-02410-01	-A0
RJ48-8E1	800-02408-01	-A0
R-RJ48-8E1	800-02409-01	-A0
CESM-8T1/B	800-08613-02	-A0
RJ48-8T1	800-02286-01	-A0
R-RJ48-8T1	800-02288-01	-A0
MGX-RJ48-8E1	800-19310-01	-A0
AUSM8T1/B	800-04809-01	-A0
AUSM-8E1/B	800-04810-01	-A0
FRSM-8T1	800-02437-04	-A0
FRSM-8E1	800-02438-04	-A0
FRSM-8T1-C	800-02461-04	-A0
FRSM-8E1-C	800-02462-04	-A0
MGX-12IN1-8S	800-18302-01	-A0
FRSM-HS2/B	800-17066-01	-A0
SCSI2-2HSSI/B	800-05463-02	-A0
SCSI2-2HSSI/B	800-05501-01	-A0
MMF-4-155/C	800-07408-02	-A0
SMFIR-4-155/C	800-07108-02	-A0
SMFLR-4-155/C	800-07409-02	-A0
PXM-UI-S3	800-05787-02	-A0
SMB-8-T3	800-05029-02	-A0
SMB-8-E3	800-04093-02	-A0

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

Front Card Type	Back Card Types	Needs APS-CON?
PXM1E-4-155	MMF-4-155/C	N/A
	SMFIR-4-155/C	N/A
	SMFLR-4-155/C	N/A
	PXM-UI-S3	N/A
PXM1E-8-T3E3	SMB-8-T3	N/A
	SMB-8-E3	N/A
	PXM-UI-S3	N/A
PXM1E-T3E3-155	MGX-T3E3-155	N/A
	MMF-1-155-SFP1	N/A
	SMFLR-1-155-SFP1	N/A
	SMFIR-1-155-SFP1	N/A
	PXM-UI-S3	N/A
FRSM-12-T3E3	SMB-6-T3E3	N/A
MGX-VISM-PR-8T1	AX-RJ48-8T1 AX-R-RJ48-8T1	N/A
MGX-VISM-PR-8E1	AX-SMB-8E1 AX-R-SMB-8E1 AX-RJ48-8E1 AX-R-RJ48-8E1 MGX-RJ48-8E1	N/A
MGX-SRME	MGX-SMFIR-1-155	Yes
	MGX-STM1-EL-1	Yes
SRM3T3/C	BNC-3T3-M	N/A
CESM-8E1	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
CESM-8T1/B	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
AUSM8T1/B	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
AUSM-8E1/B	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
FRSM-8T1	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
FRSM-8E1	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
FRSM-8T1-C	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
FRSM-8E1-C	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
FRSM-HS2/B	SCSI2-2HSSI/B	N/A
	MGX-12IN1-8S	N/A

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

MGX 8830 Product IDs and card types

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

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

Table 10 Card Numbers and Revisions Supported in Release 3.0.00 for MGX 8830 

Product ID	800 P/N	Min. Revision
PXM1E-4-155	800-18588-03	-A0
PXM1E-8-T3E3	800-18590-03	-A0
PXM1E-T3E3-155	800-18604-03	-A0
MGX-T3E3-155	800-18698-02	-A0
MMF-1-155-SFP1	10-1308-01	-A0
SMFLR-1-155-SFP12	10-1280-01	-A0
SMFIR-1-155-SFP2	10-1283-01	-A0
MGX-SRME	800-14224-02	-A0
MGX-SMFIR-1-155	800-14460-02	-A0
MGX-STM1-EL-1	800-14479-02	-A0
SRM3T3/C	800-05648-01	-A0
BNC-3T3-M	800-03148-02	-A0
CESM-8E1	800-02751-02	-A0
SMB-8E1	800-02287-01	-A0
R-SMB-8E1	800-02410-01	-A0
RJ48-8E1	800-02408-01	-A0
R-RJ48-8E1	800-02409-01	-A0
CESM-8T1/B	800-08613-02	-A0
RJ48-8T1	800-02286-01	-A0
R-RJ48-8T12	800-02288-01	-A0
MGX-RJ48-8E1	800-19310-01	-A0
AUSM8T1/B	800-04809-01	-A0
AUSM-8E1/B	800-04810-01	-A0
FRSM-8T1	800-02437-04	-A0
FRSM-8E1	800-02438-04	-A0
FRSM-8T1-C	800-02461-04	-A0
FRSM-8E1-C	800-02462-04	-A0
MGX-12IN1-8S	800-18302-01	-A0
FRSM-HS2/B	800-17066-01	-A0
SCSI2-2HSSI/B	800-05463-02	-A0
SCSI2-2HSSI/B	800-05501-01	-A0
MMF-4-155/C	800-07408-02	-A0
SMFIR-4-155/C	800-07108-02	-A0
SMFLR-4-155/C	800-07409-02	-A0
PXM-UI-S3	800-05787-02	-A0
SMB-8-T3	800-05029-02	-A0
SMB-8-E3	800-04093-02	-A0

1 These cards are required only if you need modular optics with the PXM1E Combo back card 2 R- means this is a redundant RJ48 card

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

Front Card Type	Back Card Types	Needs APS-CON?
PXM1E-4-155	MMF-4-155/C	No
	SMFIR-4-155/C	No
	SMFLR-4-155/C	No
	PXM-UI-S3	N/A
PXM1E-8-T3E3	SMB-8-T3	N/A
	SMB-8-E3	N/A
	PXM-UI-S3	N/A
PXM1E-T3E3-155	MGX-T3E3-155	No
	MMF-1-155-SFP1	N/A
	SMFLR-1-155-SFP1	N/A
	SMFIR-1-155-SFP1	N/A
	PXM-UI-S3	N/A
MGX-SRME	MGX-SMFIR-1-155	Yes
	MGX-STM1-EL-1	Yes
SRM3T3/C	BC-3T3-M	N/A
CESM-8E1	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
CESM-8T1/B	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
AUSM8T1/B	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
AUSM-8E1/B	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
FRSM-8T1	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
FRSM-8E1	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
FRSM-8T1-C	RJ48-8T1	N/A
	R-RJ48-8T1	N/A
FRSM-8E1-C	SMB-8E1	N/A
	R-SMB-8E1	N/A
	RJ48-8E1	N/A
	R-RJ48-8E1	N/A
	MGX-RJ48-8E1	N/A
FRSM-HS2/B	SCSI2-2HSSI/B	N/A
	MGX-12IN1-8S	N/A

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

Table 12

New and Changed Commands

Refer to the "MGX 8850, MGX 8950, and MGX 8830 Command Reference, Release 3" for details about new and changed commands. This manual is available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm. To access it, click on the switch name (for example, MGX 8850 (PXM45), click on Release 3, and then click on the Command Reference link.

Limitations, Restrictions, and Notes for 3.0.00

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

MGX Release 3.0.00 Limitations

Policing Accuracy for PXM1E

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

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

(Refer to anomalies CSCdw72256, CSCdw72459, CSCdw72971, CSCdw73652, CSCdw67564)

Maximum Threshold Accuracy for PXM45 and PXM1E

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

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

(Refer to anomalies CSCdw89558, CSCdw85738, CSCdw89101, CSCdw89123)

Limitations for PXM1E-based Switches

•MPLS controller is not supported on JANUS

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

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

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

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

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

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

Reserved VCIs

Here are the reserved VCIs that the customer cannot provision:

•vpi=0, vci=5 is used for SSCOP for UNI signaling ports (UNI, none ports don't need signaling). If it is a Virtual Terminal or EVUNI, then the minimum vpi and the VCI=5 are used for SSCOP.

•vpi=0, vci=18 is used for PNNI RCC (If the port is not NNI, or Virtual NNI, then you don't need this).

•vpi=0, vci=16 is used for ILMI if ILMI is enabled. Similarly for Virtual Terminal or EVUNI, it is minimum vpi and vci=16.

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

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

FRSM-12-T3E3 Limitations

The following limitations summarize the FRSM-12-T3E3 adherence to the current Functional Specification:

•E3: Considered for a future release. Hardware has been verified.

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

•BERT: Not supported.

•Sub-rate DS3: Considered for a future release. Hardware has been verified.

•Online and Offline Diagnostics: Considered for a future release.

•Complete core dump feature: Considered for a future release.

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

Port limitations:

•4 bytes header length with Stratcom LMI is not supported

•LMI on Frame Forwarding port is not supported

•If LMI is configured, Port header length cannot be changed

Connection Limitations:

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

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

•chanType cannot be modified

•If Port header length is 2 bytes, Max DLCI number is 1023

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

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

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

•For Frame Forward port, the max connections is 1

•For Frame Relay port, the max connections is 4000

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

•CIR can only be 0 for uBR connections

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

•If CIR != 0, BC should be nonzero

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

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

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

Maximum connections depending on LMI type:

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

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

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

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

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

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

Frame forwarding anomaly CSCdx45932:

•Engineering evaluated the idea of changing the CLI to set a hard configuration of 2 byte headers, however, if we hard configure the Port to 2 Byte headers only there is a potential we could discard real traffic if the end user use 4 byte headers. Engineering believes it is better to allow both and for the customer to work with the end user to set the values correctly. This anomaly requires hardware and software fixes, so it will be fixed in a future 3.x release.

Disk Space Maintenance

As the firmware doesn't audit the disk space usage and remove unused files, the disk space in C: and E: drives should be manually monitored and any unused saved configuration files, core files and firmware files and the configuration files of the MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards should be promptly deleted manually to avoid shortage of disk space to store event logs, configuration upload files in the C: drive and the configuration of MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards in the E: drive.

Non-native Controller Front Card and HDD Card

When a non-native PXM1E or HDD back card is inserted in the Standby controller slot, the firmware doesn't clean up the drives which have free disk space below 30%. So, when the standby controller card comes up, it needs to be verified whether the contents have been cleaned up or not.

When a non-native PXM1E or HDD back card is inserted in the Standby controller slot, the firmware doesn't clean up the non-auto configuration files in the E:RPM directory. These non-auto configuration files in the E:RPM directory have to be manually cleaned up after the Standby controller card becomes ready.

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

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

clrsmcnf Limitations

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

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

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

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

APS Limitations

For AXSM-B APS, the backcard of the active card MUST be present for APS to function

New commands dspadjlnalm and dspadjlnalmcnt are now supported on AXSMB

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

Limitations and Restrictions for PNNI Features

PNNI requires SCR=453 cells/sec and PCR=969 cells/sec for the control connection.

SSCOP requires SCR=126 cells/sec and PCR=2000 cells/sec.

Path and Conn Trace

1. Path trace is not supported on the control port.

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

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

SNTP

The CWM MIB is not supported in Release 3.0.00.

Priority Routing

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

•RPM does not support configuration of routing priority. All RPM mastered SPVCs will be assigned a routing priority of 8 by the PXM.

•addcon command on SES does not have support for specifying the routing priority. All the added SPVCs are assigned a routing priority of 8. cnfcon can be used to change the routing priority of the SPVCs.

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

•Changing the routing priority for dax connections, will not change the priority of the associated pn-cons (SVCs), this is because the SPVCs will not be derouted and rerouted if just the end-point parameters are changed, and routing priority is a end-point parameter. Also since dax connections are never derouted even when the UNI port goes down and rrtcon command is not supported for dax connections, the routing priority change will never get reflected. The only way for this to get reflected is to do a dncon and upcon. The very fact that dax connections are never derouted, the effect of this limitation is voided.

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

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

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

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

SPVC Interop

1. NNI SPVC Addendum Version 1.0 is not supported.

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

3. Terminating single-ended SPVCs on MSSBU switch Legacy Service Modules is not supported.

4. Origination of Single ended spvcs (with -slavepersflag) from Legacy Service Modules (FRSM, CESM, VISM & RPM) is not supported.

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

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

7. tstdelay shall not be available at the slave end of a single-ended SPVC for POPEYE2. In case of Orion, the command is available from the PXM even for the slave endpoint.

8. The slave end of a single-ended SPVC shall not be visible to CWM.

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

10. Single-end Provisioning will not be supported for DAX connections as no value addition is seen for Interoperability.

11. SPVC Statistics shall not be available for the slave endpoint of a single-ended SPVC because this endpoint is non-persistent.

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

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

•spvcoverridesvc

•spvcoverridesvp

•spvpoverridesvp.

Preferred Route feature

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

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

c) All the links specified in the preferred should be PNNI links

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

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

f) If any of the nodes in the pnni network is removed via physical de-commissioning and if any of the nodes in the network had some preferred routes that contain the removed node as one of the hops, then the preferred route(s) has to be deleted/modified manually.

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

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

Persistent Topology Feature

1. In a mixed network of pre-Release 3.0.00 and 3.0.00 or later nodes, only the node name and the node id will be shown for a pre-Release 3.0.00 node in the topo DB. This is because the feature is not present in pre-Release 3.0.00 nodes.

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

3. To delete a node info entry from the Topo DB, first remove the node itself from the network, either by disconnecting the cables, or downing all the links between that node and the network. Wait for an hour. Then, delete that node from the 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 will still be stored in the other nodes, until they are flushed from those nodes. This would happen within an hour's time, but it is configurable as a PNNI timer value. If the node is deleted from the 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.

4. 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 will still be stored in the topo DB of all the other nodes in the PG. In order 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 PG, and then delete the info of the old node id from the topo DB.

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

6. When deleting a node from the PG, the node info must be deleted from all the nodes in that PG, 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.

NCDP

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

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

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

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

5. Revertive option is not provided in NCDP.

Manual Clocking

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

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

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

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

AXSM 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 is supporting a PNNI link which is congested with mixed CBR/ABR traffic, cells will be dropped. This condition only occurs when ER stamping is enabled and CI is disabled on an AXSM PNNI link, along with CBR/ABR traffic running so as cause congestion on the link.

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

VISM Limitations

For details on VISM limitations, refer to the "Release Notes for Cisco Voice Interworking Service Module Release 3.0(0)". These release notes, part OL-2523-01, are available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm. They are found under the switch name and release number (for example, MGX 8850 (PXM45), Release 3.0.00.

RPM-PR and RPM-XF Limitations

Starting with Release 3.0.00, Route Processor Module (RPM) cards have their own release notes. For details on RPM cards, refer to the "Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for MGX Release 1.2.10 and MGX Release 3.0.00" or the "Release Notes for Cisco MGX Route Processor Module (RPM-XF) for MGX 8850 (PXM45) Release 3.0.00". These release notes are available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm. They are found under the switch name (for example, MGX 8850 (PXM45), Release 3, Route Processor Module, Release Notes.

Restrictions

Formatting Disks

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

Saving Configurations

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

Other Limitations and Restrictions

•clrsmcnf will not work for redundant service modules.

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

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

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

•The maximum number of 250k connections supported in Release 3.0.00 with PXM45/B.

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

•NCDP is not supported on BPX.

Clearing the Configuration on Redundant PXM45 and PXM1E Cards

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

After a clrallcnf, the user needs to explicitly clean up stale SCT files (refer to anomaly CSCdw80282).

Limitations and Restrictions for 2.1.x

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

•General limitations, restrictions, and notes

•APS management information and open issues

•Clearing the configuration on redundant PXM45/B cards

General Limitations, Restrictions, and Notes

The following limitations and restrictions apply to this release.

•For a graceful upgrade, you must upgrade from version 2.1.80, or 2.0.16 or below to 2.1.80 to 3.0.00.

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

•APS is not supported on AXSM-1-2488/B.

•Of 192 PNNI interfaces, up to 100 interfaces can be signaling ports. The other 92 interfaces should be non-signaling ports, such as non self-supporting ports.

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

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

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

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

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

•Partition ID 1 is reserved for PNNI.

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

•If an active AXSM card is stuck in the active INIT state, the standby PXM will not go to the standby Ready state until the active AXSM goes to a steady state. Steady states are: Active Ready, Failed, Mismatch, Empty, Empty Reserved, Standby Ready. With redundancy configured, if a standby AXSM card is stuck in a standby init state, with an active Active AXSM already in a Active Ready state, the standby PXM will go to the standby Ready state without any delay. If both AXSMs in the redundancy pair are not in a steady state, then the standby PXM will not go to the standby Ready state until one or both of the 2 AXSM cards are in the active Ready state.

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

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

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

•Here is information about anomaly CSCdx29956. The release note enclosure contains these fields: Bug CSCdx29956, CSC.mssbu.sw, Enclosure 2 of 2, mgx, Retitled 020413 by ddts. Symptom: Cellbus clock configuration defaults after a power cycle. Condition: Set one of the cell bus clock speeds to 42 MHz and power cycle the node. Workaround: Re-configure cell bus clock after a node rebuild.

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

Limitations for rteopt via parallel links

The following are limitations for rteopt via parallel link.

link 1 . . . . . .. . . .. . . . .link 2

Node A ------------- Node B -------------- Node C

fwd & bwd aw= 500 fwd & bwd aw= 1000

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

link 3 fwd & bwd aw = 2000

Configuration:

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

•link 2 has forward and backward admin weight set to 1000

•link 3 has forward and backward admin weight set to 2000

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

Scenario 1: Link 2 is down (e.g., via dnpnport), connections are re-routed right away but Node A hasn't had that info updated in the routing tables yet.43

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

Now if link 2 is up, if you do rteopt on Node A, it gets the new route, the new path selected has a cost of 3000.

Since spvc has 3000, it doesn't re-route through link 2.

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

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

Scenario 4 (for ABR and UBR): link selection doesn't apply to ABR and UBR. (via cnfpnni-selection. This is exactly the same as Scenario 3 as ABR and UBR follow load balancing on parallel links instead of choosing the minaw link.

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

Workaround

If you dnpnport on link 2 (connections will be routed via link 3), after uppnport on link 2, then use cnfpnni-intf to change the existing admin weight on link 2 to lesser value, e.g., 800 (from 1000).

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

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

Important Notes

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

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

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

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

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

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

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

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

APS Management Information

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

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

---

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

---

The APS command dspadjlnalm was new to release 2.1.70. Refer to the "MGX 8850 Command Reference for Release 2.1" at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r21/index.htm for further details about the commands mentioned in these release notes.

---

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

---

The following are some open issues in this release:

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

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

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

Preparing for Intercard APS

The following components are required for intercard APS:

•two front cards.

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

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

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

M8xx0_NY.1.AXSM.a > dspapsbkplane

Line-ID   Primary Card Signal Status       Secondary Card Signal Status

                    Slot #1                             Slot #2        

  1.1               PRESENT                             PRESENT

  1.2               PRESENT                             ABSENT 

  2.1               PRESENT                             ABSENT 

  2.2               PRESENT                             ABSENT 

Remote Front Card : PRESENT 

Top Back Card     : ENGAGED 

Bottom Back Card  : ENGAGED 

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

M8xx0_LA.1.AXSM.a > dspapsbkplane

Line-ID   Primary Card Signal Status       Secondary Card Signal Status

                    Slot #1                             Slot #2        

  1.1               PRESENT                             ABSENT

  1.2               ABSENT                              ABSENT 

  2.1               PRESENT                             ABSENT 

  2.2               ABSENT                              ABSENT 

Remote Front Card : ABSENT 

Top Back Card     : ENGAGED 

Bottom Back Card  : NOT-ENGAGED 

---

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

---

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

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

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

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

Managing Intercard APS Lines

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

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

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

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

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

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

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

---

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

---

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

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

Figure 1

Standard APS Configuration

Figure 2

Crossed APS Configuration

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

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

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

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

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

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

Table 1 describes the configurable parameters for the cnfapsln command.

Table 13 cnfapsln Command Parameters

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

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

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

Manual line switch from protection to working succeeded on line 1.1.1

Table 2 describes the configurable parameters for the cnfapsln command.

Table 14 switchapsln Command Parameters

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

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

M8xx0_LA.1.AXSM.a > dspapslns

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

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

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

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

Troubleshooting APS Lines

Port light behavior changed in Release 3.0.00 as follows:

Port lights on AXSM /B front cards indicate the receive status of APS lines. The active front card always displays the status of the active line. The standby card always displays the status of the inactive line. If only one APS line fails, the line failure LED is always displayed on the standby front card.

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

---

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

---

---

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

---

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

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

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

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

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

Use the following procedure to troubleshoot APS lines.

---

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

M8xx0_LA.1.AXSM.a > dsplns

                                           Medium Medium 

  Sonet  Line     Line     Line    Frame   Line   Line     Alarm   APS 

  Line  State     Type     Lpbk   Scramble Coding Type     State   Enabled

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

   1.1     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Enable

   1.2     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Disable

   2.1     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Disable

   2.2     Up sonetSts12c NoLoop   Enable  Other ShortSMF    Clear Disable

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

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

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

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

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

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

---

Note Table 15 is updated for Release 3.0.00.

---

Table 15 Troubleshooting APS Line Problems Using the dspaps Command

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

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

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

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

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

Table 16 Troubleshooting Card Problems

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

---

Installing and Upgrading to Release 3.0.00

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

---

Caution A direct upgrade from 2.0.16 or below to 3.0.00 is not supported. You must upgrade to release 2.1.76 or 2.1.80 first before going to 3.0.00. If you have AXSM-E cards, a direct upgrade from a release prior to 2.1.80 to 3.0.00 is not supported. You must upgrade to 2.1.80 before going to 3.0.00.

---

The MGX 8850 (PXM1E) and MGX 8830 switches are introduced with release 3, and therefore cannot be upgraded to release 3.

The MGX 8850 (PXM45) switch can be gracefully upgraded to Release 3.0.00 from Releases 2.1.80. If the switch is running 2.0.16, it must be upgraded to 2.1.80, then Release 3.0.00.

Important Note

On a system running a pre-3.0.00 version of software, if there are AXSM/B (i.e., AXSM model B) cards in the shelf configured and running APS, we should check to see if the slots are reserved for AXSM/B or AXSM/A (check using dspcd command) before upgrading to 3.0.00 version of software. If they are reserved for model A, then there is no limitation. There is no limitation if APS is not configured either.

If they are reserved for AXSM/B and are running APS, then we would have a problem upon upgrade to 3.0.00 version with the card coming up with APS operational mode B, instead of the expected APS operational mode A. To overcome this problem, the steps in Single Card Scenario or Redundant Scenario need to be followed:

The workaround consists of basically reserving the AXSM card to Model A before upgrading the AXSM to 3.0.00. This workaround does not cause traffic loss.

Single card scenario

---

Step 1 Find out the AXSM-B front card type using dspcds command.

Step 2 Issue the following shellconn command on the PXM:

gShmFcResNvramIdSet <AXSM slot #>, <modelA NVid from Table 17>

It does not matter if the command is issued before upgrading the PXM or after. But the command should be issued before upgrading the AXSM. Table 17 shows how to map a given AXSM/B card with the corresponding AXSM/A NovramID.

Table 17 AXSM-B card mapping to corresponding AXSM-A NovramID

Model B FC type	Model A Nvid
1port OC48-B	0x184
16port OC3-B	0x180
4port OC12-B	0x17E

---

Note No workaround has been provided for T3E3 card, because the APS functionality is not affected for T3E3 cardtype.

---

Redundant scenario

Issue the shellconn command for both the primary and secondary slot#.

Installation and Upgrade Procedures

The procedures in this section were extracted from two different manuals. The procedures appear in "Appendix A, Downloading and Installing Software Upgrades" in:

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

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

In this section, references to "chapters" refer to chapters in the above manuals.

---

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

---

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

---

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

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

•MGX 8850 (PXM45)

•MGX 8850 (PXM1E)

•MGX 8830

Step 3 Click on Release 3.

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

---

Upgrade Process Overview

The following procedures are described in the remainder of this section:

•Upgrade Process Overview

•Quickstart Procedures for Software Upgrades

•Browsing the File System

•Copying Software Files to the Switch

•Upgrade Procedures for PXM45 and AXSM Cards

•Troubleshooting Upgrade Problems

---

Note To upgrade RPM-PR runtime software and boot software, refer to the "Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3" (DOC-7814248=). To upgrade MGX-RPM-XF-512 runtime software and boot software, refer to "Cisco MGX 8850 (PXM45/B) and MGX 8950 Software Configuration Guide, Release 3" (DOC-7814577=).

---

---

Caution To prevent serious problems, upgrade software on the node to Release 3.0.00 before inserting any of the hardware cards that are new for Release 3.0.00.

---

This section provides a series of quickstart procedures that describe how to perform graceful and non-graceful upgrades to the switch. To perform a graceful upgrade on a switch card, the card must be operating in redundant mode with another switch card of the same type. When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections.

---

Note Graceful upgrades to Release 3.0.00 are supported from Release 2.1.80. If the switch is running 2.0.16 or below, it must be upgraded to 2.1.80 before upgrading to Release 3.0.00.

---

When a card to be upgraded is not operating in redundant mode, you must do a non-graceful upgrade, which disrupts all traffic that passes through the card. For PXM45 cards, an ungraceful upgrade interrupts all traffic passing through the switch. For all other types of cards, an ungraceful upgrade affects only the traffic that passes through that card.

Each type of switch card runs boot and runtime software. The recommended sequence for upgrading the software (i.e., firmware) on switch cards is as follows:

1. PXM45 boot software

2. PXM45 runtime software

3. AXSM boot software

4. AXSM runtime software

---

Note If you plan to upgrade PXM45 cards and AXSM cards, upgrade the PXM45 cards first. Wait until the PXM45 cards are operating in active and standby modes with the correct software before upgrading AXSM cards. The software version used by the PXM45/B cards should be equal to or later than the version used on the AXSM, AXSM/B, and AXSM-E cards.

---

Typically, the boot software requires less frequent upgrades. However, in this release, both the boot and runtime software need to be upgraded.

When you upgrade the software on a switch card, proceed as follows:

•Decide whether you are performing a graceful or non-graceful upgrade

•Follow the appropriate quickstart procedure for that type of upgrade

•For additional information on a task within a quickstart procedure, see the subsection to which the procedure refers

The next subsection presents the quickstart procedures for switch card software upgrades.

Quickstart Procedures for Software Upgrades

The following subsections provide quickstart procedures for the following upgrades:

•Preparing for Upgrades

•Graceful PXM45 Boot Upgrades

•Non-Graceful PXM45 Boot Upgrades

•Graceful PXM45 and AXSM Runtime Software Upgrades

•Non-Graceful PXM45 and AXSM Runtime Software Upgrades

•Graceful AXSM Boot Upgrades

•Non-Graceful AXSM Boot Upgrades

---

Caution A CP port session is required because you will be resetting the node and entering commands in "Backup Boot mode," which is not accessible through other connection methods.

---

Preparing for Upgrades

Before you can upgrade the software on any card, you must copy the software to your switch and then log into the switch. The following table describes how to prepare for software upgrades on any card:

	Command	Description
Step 1	ftp	Copy the boot and runtime files you want to use to your switch. FTP the AXSM and PXM45 boot and runtime images to the C:FW directory. See "Copying Software Files to the Switch," which appears later in this section.
Step 2	username password	Establish a CLI session with the standby PXM45 card using the CP port on the UI back card and a user name with CISCO_GP privileges.
Step 3	saveallcnf	This optional step saves the current configuration to the hard disk of the active PXM45 card. (The command can only be issued on the active PXM card.) Refer to "Saving a Configuration" in Chapter 7, "Switch Operating Procedures."

Graceful PXM45 Boot Upgrades

When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections.

When a boot software upgrade is required, the procedure for upgrading redundant PXM45 cards updates the standby card and then makes that card active. This method ensures a smooth transition to the new software and preserves all established calls. Any calls that are not established are lost.

A graceful upgrade of the boot software does the following:

1. Loads the new software on the standby PXM45 card

2. Makes the standby PXM45 card active

3. Loads the new software on the formerly active (now standby) PXM45 card

---

Note Avoid making configuration changes while upgrading PXM45 software. Configuration changes can be lost when the PXM45 is reset during the upgrade. Upgrade the software on the node to Release 3.0.00 before installing the FRSM-12-T3E3 or MGX-RPM-XF-512.

---

To upgrade the runtime software, use the following procedure.

	Command	Purpose
Step 1		Copy the boot files you want to use to the switch and log into the active PXM45 card.
Step 2	sysPxmRemove	At the backup boot prompt, enter the sysPxmRemove command: This step prevents the active card from resetting the standby card while you are working with it.
Step 3	sysFlashBootBurn "Filename" reboot username password dspcds; dsprevs	Burn the boot software. Remember to enter quotation marks before and after the boot software filename. For example: sysFlashBootBurn "C:FW/pxm45_003.000.000.000_bt.fw" See "Upgrading PXM45 Boot Software," which appears later in this section.
Step 4	username password	Establish a CLI session with the active PXM45 card (which is the non-upgraded card) using the CP port on the UI-S3 back card and a user name with CISCO_GP privileges.
Step 5	switchcc y	Switch the roles of the active and standby cards so you can upgrade the non-upgraded card in standby mode.
Step 6	sh sysBackupBoot	Using the CP port connection, change to the PXM45 Backup Boot mode. Note that the software versions 2.0.11 and earlier require you to press Return during the reboot sequence to enter backup boot mode. See "Changing to PXM45 Backup Boot Mode" in Appendix B, "PXM45 Backup Boot Procedures.".
Step 7	sysPxmRemove	At the backup boot prompt, enter the sysPxmRemove command: This step prevents the active card from resetting the standby card while you are working with it.
Step 8	sysFlashBootBurn "Filename" reboot username password dspcds; dsprevs	Burn the boot software. Remember to enter quotation marks before and after the boot software filename. For example: sysFlashBootBurn "C:FW/pxm45_003.000.000.000_bt.fw" See "Upgrading PXM45 Boot Software," which appears later in this section. The boot software is now upgraded on both the active and standby cards. The card that was active before the upgrade is now operating in standby mode.

Non-Graceful PXM45 Boot Upgrades

Ungraceful upgrades disrupt all switch traffic and are usually used in lab installations where the use of standalone cards provides no opportunity for a graceful upgrade. The quickstart procedure is provided as an overview and as a quick reference.

---

Note Avoid making configuration changes while upgrading PXM45 software. Configuration changes can be lost when the PXM45 is reset during the upgrade.

---

---

Caution To prevent serious problems, upgrade software on the node to Release 3.0.00 before inserting any of the hardware cards that are new for Release 3.0.00.

---

	Command	Purpose
Step 1		Copy the boot files you want to use to the switch and log into the active PXM45 card.
Step 2	sh sysBackupBoot	Using the CP port connection, change to the PXM45 Backup Boot mode.
Step 3	sysFlashBootBurn "Filename" reboot username password dspcd; dsprevs	Burn the boot software. Remember to enter quotation marks before and after the boot software filename. For example: sysFlashBootBurn "C:FW/pxm45_003.000.000.000_bt.fw" See "Upgrading PXM45 Boot Software," which appears later in this section.

Graceful PXM45 and AXSM Runtime Software Upgrades

When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections.

This quickstart procedure applies to both PXM45 and AXSM cards and does the following:

1. Loads the new software on the standby PXM45 or AXSM card

2. Makes the standby card active

3. Loads the new software on the formerly active (now standby) card

---

Note If you plan to upgrade PXM45 cards and AXSM cards, upgrade the PXM45 cards first. Wait until the PXM45 cards are operating in active and standby modes with the correct software before upgrading AXSM cards. The software version used by the PXM45/B cards should be equal to or later than the version used on the AXSM, AXSM/B, and AXSM-E cards. When AXSM boot software is to be upgraded, it should be upgraded before upgrading the runtime software.

---

---

Caution To prevent serious problems, upgrade software on the node to Release 3.0.00 before inserting any of the hardware cards that are new for Release 3.0.00.

---

---

Note Avoid making configuration changes while upgrading PXM45 software. Configuration changes can be lost when the PXM45 is reset during the upgrade.

---

To upgrade the runtime software, use the following procedure.

	Command	Purpose
Step 1		Copy the runtime files you want to use to the switch and log into the active PXM45 card.
Step 2	dspcds; dsprevs; dsprevs -s commitrev <slot> <revision>	Verify that all previous upgrades have been committed. If a previous upgrade has not been committed, commit to the new upgrade. See "Committing to a Runtime Software Upgrade," which appears later in this section.
Step 3	loadrev <slot> <revision> dspcds; dsprevs -s	Load the new runtime software on the standby card.
Step 4	runrev <slot> <revision> dspcds; dsprevs -s dspcd <slot>	Switch over to the standby card and load the new runtime software on the new standby (non-upgraded) card.
Step 5	commitrev <slot> <revision> dspcds dsprevs dsprevs -s	This command prevents an accidental switch back to a previous software revision if someone enters the abortrev command. Enter the commitrev command after the former active card comes up in the standby-U state. Cisco Systems recommends that you avoid configuration changes until after you have run the commitrev or abortrev commands. See "Aborting a Runtime Software Upgrade" and "Committing to a Runtime Software Upgrade," both of which appear later in this section.

Non-Graceful PXM45 and AXSM Runtime Software Upgrades

Ungraceful upgrades disrupt all switch traffic and are usually used in lab installations where the use of standalone cards provides no opportunity for a graceful upgrade. The quickstart procedure is provided as an overview and as a quick reference.

---

Note If you plan to upgrade PXM45 cards and AXSM cards, upgrade the PXM45 cards first. Wait until the PXM45 cards are operating in active and standby modes with the correct software before upgrading AXSM cards. The software version used by the PXM45/B cards should be equal to or later than the version used on the AXSM, AXSM/B, and AXSM-E cards. When AXSM boot software is to be upgraded, it should be upgraded before upgrading the runtime software.

---

---

Caution To prevent serious problems, upgrade software on the node to Release 3.0.00 before inserting any of the hardware cards that are new for Release 3.0.00.

---

---

Note Avoid making configuration changes while upgrading PXM45 software. Configuration changes can be lost when the PXM45 is reset during the upgrade.

---

	Command	Purpose
Step 1		Copy the runtime files you want to use to the switch and log into the active PXM45 card.
Step 2	dspcds; dsprevs -s commitrev <slot> <revision>	Verify that all previous upgrades have been committed. If a previous upgrade has not been committed, commit to the new upgrade. See "Committing to a Runtime Software Upgrade," which appears later in this section.
Step 3	loadrev <slot> <revision> dspcds; dsprevs -s	Define the new software version to be used.
Step 4	runrev <slot> <revision> dspcds; dsprevs -s	Reset the card and run the new runtime software version.
Step 5	commitrev <slot> <revision> dspcds dsprevs -s dsprevs	This command prevents an accidental switch back to a previous software revision if someone enters the abortrev command. Cisco Systems recommends that you avoid configuration changes until after you have run the commitrev or abortrev commands. See "Aborting a Runtime Software Upgrade" and "Committing to a Runtime Software Upgrade," both of which appear later in this section.

Graceful AXSM Boot Upgrades

When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections. The quickstart procedure is provided as an overview and as a quick reference.

---

Note If you plan to upgrade PXM45 cards and AXSM cards, upgrade the PXM45 cards first. Wait until the PXM45/B cards are operating in active and standby modes with the correct software before upgrading AXSM cards. The software version used by the PXM45/B cards should be equal to or later than the version used on the AXSM, AXSM/B, and AXSM-E cards.

---

	Command	Purpose
Step 1		Copy the boot files you want to use to the switch and log into the active PXM45 card.
Step 2	burnboot <slot> <revision> dspcd <slot> dsprevs	Burn the boot software on the standby AXSM card by specifying the slot number of the standby card. See "Upgrading Boot Software on an AXSM Card," which appears later in this section.
Step 3	switchredcd <fromSlot> <toSlot>	Activate the upgraded card and place the non-upgraded card in standby mode.
Step 4	burnboot <slot> <revision> dspcd <slot> dsprevs	Burn the boot software on the non-upgraded, standby AXSM card by specifying the slot number of the standby card. See "Upgrading Boot Software on an AXSM Card," which appears later in this section.

Non-Graceful AXSM Boot Upgrades

Ungraceful upgrades disrupt all switch traffic and are usually used in lab installations where the use of standalone cards provides no opportunity for a graceful upgrade. The quickstart procedure is provided as an overview and as a quick reference.

---

Note If you plan to upgrade PXM45 cards and AXSM cards, upgrade the PXM45 cards first. Wait until the PXM45 cards are operating in active and standby modes with the correct software before upgrading AXSM cards. The software version used by the PXM45/B cards should be equal to or later than the version used on the AXSM, AXSM/B, and AXSM-E cards.

---

	Command	Purpose
Step 1		Copy the boot files you want to use to the switch and log into the active PXM45 card.
Step 2	burnboot <slot> <revision> dspcd <slot> dsprevs	Burn the boot software on the standby AXSM card by specifying the slot number of the standby card. See "Upgrading Boot Software on an AXSM Card," which appears later in this section.

Browsing the File System

The active PXM45 hard disk stores log files, configuration files, and boot and runtime software. The switch operating system supports a set of UNIX-like commands that you can use to locate log files or manage software updates. Table 18 lists commands that you can use to browse the file system.

---

Note File and directory names in the switch file system are case sensitive. Also, some of the commands listed in Table 18 are not available at all administrator access levels.

---

Table 18 File System Commands at Switch Prompt 

Command	Description
cd	Change directories. Access level required: ANYUSER or above.
copy	Copies a file from one location to another. Syntax: copy <source file name> <destination file name> Access level required: GROUP1 or above.
del	Deletes a file. Syntax: del <file name> Access level required: GROUP1 or above.
ll	List directory contents using long format, which includes the name, size, modification date, and modification time for each file. This command also displays the total disk space and free disk space. Syntax: ll Access level required: ANYUSER or above.
ls	List directory contents using the short format, which displays filenames, total disk space, and free disk space. Syntax: ls Access level required: ANYUSER or above.
pwd	Display the present working directory. Syntax: pwd Access level required: ANYUSER or above.
rename	Renames a file. Syntax: rename <old file name> <new file name> Access level required: GROUP1 or above.
whoami	Lists the login name for the current session. Syntax: whoami Access level required: ANYUSER or above.

Copying Software Files to the Switch

This section describes how to copy software files to the MGX 8850 switch. The switch cards use boot software and runtime software. Each PXM45 and AXSM card uses the boot software to define communications between the card components and to enable cards to start up. The runtime software defines how the card operates after startup.

---

Note The boot and runtime software are installed on the switch at the factory. Before you copy new files to the switch, verify that you need to update the files by comparing the file versions on the disk to the file versions in Table 4.

---

The MGX 8850 switches provide a File Transfer Protocol (FTP) service to support file transfers to the switch. If you have FTP client software and network connectivity to both the switch and the server where the software files are stored, you can use FTP to transfer files directly from the server to the switch.

---

Note The following procedure describes how to copy files to the switch when the runtime software is up and running (showing the node name switch prompt). When the runtime software cannot load, copy the software files to the switch as described in "Transferring Software Files to and from the Switch" in Appendix B, "PXM45 Backup Boot Procedures."

---

---

Step 1 Locate the files you want to download from http://www.cisco.com/public/sw-center/wan/wan-planner.shtml.

Step 2 Using a workstation with FTP client software, transfer PXM45, RPM-XF, and AXSM files from the server to the switch directory C:/FW. For RPM-PR, the file goes to E:/RPM.

The procedure you use for transferring the files depends on the FTP client software you are using. When initiating the FTP connection, remember the following:

•Select the switch by entering its IP address.

•When prompted for a username and password, enter the username and password you use when managing the switch.

•When configuring file transfer options, select binary mode for the file transfer.

Step 3 To verify that the new PXM45, RPM-XF, and AXSM files have been transferred to the switch, log into the switch and display the contents of the C:/FW directory (E:/FW for RPM-XF).

Step 4 Using a workstation with FTP client software, transfer RPM-PR files from the server to the switch directory E:/RPM.

---

Note You must use a capital E when referencing the E drive in switch commands.

---

Step 5 To verify that the new RPM-PR files have been transferred to the switch, log into the switch and display the contents of the E:/RPM directory.

For more information on browsing the switch file system, see "Browsing the File System," which appears earlier in this section.

---

Upgrade Procedures for PXM45 and AXSM Cards

The following sections describe procedures that support upgrades to PXM45 and AXSM cards. For complete upgrade procedures, see "Quickstart Procedures for Software Upgrades," which appears earlier in this section. The procedures in this section detail some of the tasks listed in the quickstart procedures.

Upgrading PXM45 Boot Software

This section describes how to upgrade the PXM45 boot software on a single PXM45 card. If you are performing a graceful upgrade, use the quickstart procedure described in "Graceful PXM45 Boot Upgrades," which appears earlier in this section. The following procedure provides detailed information on the upgrade task within the quickstart procedure.

---

Step 1 If you have not done so already, establish a CLI session with the active PXM45 card using the CP port on the UI-S3 back card and a user name with CISCO_GP privileges.

Step 2 If you have not done so already, change to PXM45 Backup Boot mode as described in "Changing to PXM45 Backup Boot Mode" in Appendix B, "PXM45 Backup Boot Procedures.".

Step 3 To burn the boot software on the PXM45, enter the sysFlashBootBurn command as follows:

pxm45bkup> sysFlashBootBurn "filename"

Replace filename with the complete path to the boot file on the PXM45 hard drive. For example:

pxm45bkup> sysFlashBootBurn "C:FW/pxm45_003.000.000.000_bt.fw"

Step 4 When the switch prompts you to confirm this action, type y and press Return.

When the boot software burning process is complete, the switch displays a message similar to the following:

Flash download completed ... 

value = 0 = 0x0

Step 5 When the boot software has been burned, reset the card with the reboot command. For example:

pxm45bkup> reboot

Be patient and wait for Login prompt to appear.

Step 6 When the Login prompt appears, log in to the switch as you do at the beginning of a CLI session. The switch prompt should appear.

M8xx0_NY.8.PXM.a > 

Step 7 To confirm that the PXM45 card is now using the correct boot software, enter the dsprevs command.

M8xx0_NY.8.PXM.a > dsprevs

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 17:01:54 PST

MGX8850                                              Node Alarm: CRITICAL

Physical  Logical   Inserted       Cur Sw              Boot FW             

Slot      Slot      Card           Revision            Revision            

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

01        01        AXSM_4OC12     3.0(0.0)         3.0(0.0)         

02        01        AXSM_4OC12     3.0(0.0)         3.0(0.0)         

03        03        AXSM_4OC12     3.0(0.0)         3.0(0.0)         

04        04        ---            ---                 ---                 

05        05        ---            ---              3.0(0.0)         

06        06        ---            ---              3.0(0.0)         

07        07        PXM45          3.0(0.0)         3.0(0.0)         

08        07        PXM45          3.0(0.0)         3.0(0.0)         

09        09        RPM_PR         ---                 ---                 

10        10        ---            ---                 ---                 

11        11        ---            ---                 ---                 

12        12        ---            ---                 ---                 

13        13        ---            ---                 ---                 

14        14        ---            ---                 --- 

Step 8 Use dspcd to see the condition of the PXM45 card. You should see active/active and no card alarm.

The Boot FW Rev row in the display should show the new revision as shown in the following example:

8850_NY.7.PXM.a > dspcd

8850_NY                          System Rev: 03.00   Jun. 18, 2002 22:47:23 PST

MGX8850                                              Node Alarm: NONE

Slot Number    7    Redundant Slot:  8

                    Front Card          Upper Card          Lower Card

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

Inserted Card:      PXM45               UI Stratum3         PXM HardDiskDrive  

Reserved Card:      PXM45               UI Stratum3         PXM HardDiskDrive  

State:              Active              Active              Active         

Serial Number:      SBK050302AF         SBK045203PJ         SBK044602HJ 

Prim SW Rev:        3.0(0)              ---                 ---

Sec SW Rev:         3.0(0)              ---                 ---

Cur SW Rev:         3.0(0)              ---                 ---

Boot FW Rev:        3.0(0)              ---                 ---

800-level Rev:      A0                  A0                  A0   

800-level Part#:    800-06147-08        800-05787-02        800-05052-04

CLEI Code:          BAA670YCAA          BA7IBCLAAA          BA7IADNAAA 

Reset Reason:       On Power up

Card Alarm:         NONE                

Failed Reason:      None                

Miscellaneous Information:

Type <CR> to continue, Q<CR> to stop:

After you confirm the upgrade to the first PXM45 card, the boot software upgrade for that card is complete.

---

Loading the Runtime Upgrade Software

This section describes how to load the runtime upgrade software in preparation for running it. Production switches should have redundant cards installed, so that upgrades can occur without interrupting traffic. For graceful upgrades, the upgrade software is loaded on the standby card first, and then the control is switched to upgraded card so that the other card can be upgraded.

The best way to assess the boot software upgrade status of a card is to enter the dsprevs command (without any parameters), as in the following example:

M8xx0_NY.8.PXM.a > dsprevs

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 17:14:58 PST

MGX8850                                              Node Alarm: CRITICAL

Physical  Logical   Inserted       Cur Sw              Boot FW             

Slot      Slot      Card           Revision            Revision            

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

01        01        AXSM_4OC12     3.0(0.0)         3.0(0.0)         

02        01        AXSM_4OC12     3.0(0.0)         3.0(0.0)         

03        03        AXSM_4OC12     3.0(0.0)         3.0(0.0)         

04        04        ---            ---                 ---                 

05        05        ---            ---              3.0(0.0)         

06        06        ---            ---              3.0(0.0)         

07        07        PXM45          3.0(0.0)         3.0(0.0)         

08        07        PXM45          3.0(0.0)         3.0(0.0)         

09        09        RPM_PR         ---                 ---                 

10        10        ---            ---                 ---                 

11        11        ---            ---                 ---                 

12        12        ---            ---                 ---                 

13        13        ---            ---                 ---                 

14        14        ---            ---                 --- 

The current (Cur SW Revision) software revision label indicates the status of an upgrade for runtime 
software. The boot (Boot FW Revision) label indicates the status of an upgrade for the boot software. 

To assess the runtime software upgrade status of a card, enter the dsprevs -s command. For example:

M8xx0_NY.8.PXM.a > dsprevs -s

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 17:10:49 PST

MGX8850                                              Node Alarm: CRITICAL

Phy. Log. Cur Sw           Prim Sw          Sec Sw           Rev Chg           

Slot Slot Revision         Revision         Revision         Status            

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

01   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

02   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         --- 

03   03   3.0(0.0)         3.0(0.0)         3.0(0.0)         --- 

04   04   ---              ---              ---              ---               

05   05   ---              3.0(0.0)         3.0(0.0)         ---               

06   06   ---              3.0(0.0)         3.0(0.0)         ---               

07   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

08   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

09   09   ---              ---              ---              ---               

10   10   ---              ---              ---              ---               

11   11   ---              ---              ---              ---               

12   12   ---              ---              ---              ---               

13   13   ---              ---              ---              ---               

14   14   ---              ---              ---              --- 

The current (Cur SW Revision), primary (Prim SW Revision), and secondary (Sec SW Revision) runtime software revision labels indicate the status of an upgrade for runtime software. In this example, these numbers match because the software upgrade has not started.

The primary software revision indicates which revision a card will run if it becomes active, and the secondary revision indicates an alternate revision that the card will use if the abortrev command is entered. (For more information on aborting an upgrade, see "Aborting a Runtime Software Upgrade," which appears later in this section.) The current software revision represents the software the active card is using. During a runtime upgrade, the Rev Change Status column shows when the revision command is in progress and subsequently when it is done.

The normal sequence of commands for a runtime software upgrade is loadrev, runrev, and commitrev. Table 19 shows how the software revision levels change during a graceful runtime software upgrade. Software Versions Reported During Graceful Upgrades

Table 19 Software Versions Reported During Graceful Upgrades

Software Revision	Before Upgrade		After loadrev		After runrev		After commitrev
	Slot 7	Slot 8	Slot 7	Slot 8	Slot 7	Slot 8	Slot 7	Slot 8
	Active	Standby	Active	Standby	Standby	Active	Active	Standby
Primary	2.1(80)	2.1(80)	2.1(80)	2.1(80)	3.0(00)	3.0(00)	3.0(00)	3.0(00)
Secondary	2.1(80)	2.1(80)	3.0(00)	3.0(00)	2.1(80)	2.1(80)	3.0(00)	3.0(00)
Current	2.1(80)	2.1(80)	2.1(80)	3.0(00)	3.0(00)	3.0(00)	3.0(00)	3.0(00)

For non-graceful upgrades, the load process defines the software version to which the switch is about to be upgraded. Table 20 shows how the revision levels change during a non-graceful upgrade.

Table 20 Software Versions Reported During Non-Graceful Upgrades

Software Revision	Before Upgrade	After loadrev	After runrev	After commitrev
Primary	2.1(80)	2.1(80)	3.0(00)	3.0(00)
Secondary	2.1(80)	3.0(00)	2.1(80)	3.0(00)
Current	2.1(80)	2.1(80)	3.0(00)	3.0(00)

If you are performing a graceful upgrade, use the quickstart procedure described in "Graceful PXM45 and AXSM Runtime Software Upgrades," which appears earlier in this section. The following procedure provides detailed information on the load task within the quickstart procedure.

---

Step 1 To load the upgrade runtime software version on a PXM45 or AXSM card, enter the following command:

mgx8850a.7.PXM.a > loadrev <slot> <revision>

Replace <slot> with the card slot number for the card to be upgraded, and replace <revision> with the software version number for the update. For graceful upgrades, you can specify either the active or the standby card. The switch software will automatically load the upgrade runtime software on the standby card when it is installed. The following example shows how to enter this command:

mgx8850a.7.PXM.a > loadrev 7 3.0(0)

After you enter the loadrev command, the standby card comes up in the standby-U state.

You can find the software version number in Table 3. You can also determine the version number from the runtime software filename as described in "Determining the Software Version Number from Filenames," which appears in Chapter 7, "Switch Operating Procedures."

Step 2 When prompted to confirm the command, type y and press Return to continue.

Step 3 To verify that the load command was processed correctly, enter the dsprevs -s command and check the status of the software revision levels.

M8xx0_NY.8.PXM.a > dsprevs -s

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 01:16:26 PST

MGX8850                                              Node Alarm: CRITICAL

Phy. Log. Cur Sw           Prim Sw          Sec Sw           Rev Chg           

Slot Slot Revision         Revision         Revision         Status            

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

01   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

02   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         --- 

03   03   3.0(0.0)         3.0(0.0)         3.0(0.0)         --- 

04   04   ---              ---              ---              ---               

05   05   ---              3.0(0.0)         3.0(0.0)         ---               

06   06   ---              3.0(0.0)         3.0(0.0)         ---               

07   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         --- 

08   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---  

09   09   ---              ---              ---              ---               

10   10   ---              ---              ---              ---               

11   11   ---              ---              ---              ---               

12   12   ---              ---              ---              ---               

13   13   ---              ---              ---              ---               

14   14   ---              ---              ---              --- 

---

Note In a standalone configuration, the switch does not start the upgraded runtime software until the runrev command is entered. In a redundant configuration, the switch starts the upgraded runtime software on the standby card. The standby card does not become active until the runrev command is entered.

---

---

Activating the Upgraded Runtime Software

After you load the upgraded runtime software for a PXM45 or AXSM card, enter the runrev command to start using the software. The version levels for graceful and non-graceful upgrades change as shown earlier in Table 19 and Table 20. The following procedure describes how to activate the upgraded runtime software.

---

Step 1 To start using the new runtime software version on a PXM45 or AXSM card, enter the following command:

mgx8850a.7.PXM.a > runrev <slot> <revision>

Replace <slot> with the card slot number, and replace <revision> with the software version number specified with the loadrev command. For graceful upgrades, you can specify either the active or the standby card. The switch software will automatically run the upgrade runtime software on the standby card when it is installed. The following example shows how to enter this command:

mgx8850a.7.PXM.a > runrev 7 3.0(0)

The active card is reset, and the former standby card comes up in the active-U state.

Step 2 When prompted to confirm the command, type y and press Return to continue.

Step 3 To verify that the load command was processed correctly, enter the dsprevs -s command and check the status of the software revision levels.

M8xx0_NY.8.PXM.a > dsprevs -s

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 01:16:26 PST

MGX8850                                              Node Alarm: CRITICAL

Phy. Log. Cur Sw           Prim Sw          Sec Sw           Rev Chg           

Slot Slot Revision         Revision         Revision         Status            

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

01   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

02   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

03   03   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

04   04   ---              ---              ---              ---               

05   05   ---              3.0(0.0)         3.0(0.0)         ---               

06   06   ---              3.0(0.0)         3.0(0.0)         ---               

07   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

08   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

09   09   ---              ---              ---              ---               

10   10   ---              ---              ---              ---               

11   11   ---              ---              ---              ---               

12   12   ---              ---              ---              ---               

13   13   ---              ---              ---              ---               

14   14   ---              ---              ---              --- 

Step 4 When the former active PXM45 comes up in the standby-U state, enter the commitrev command to commit to that software version. This step is optional. The dsprevs -s command shows that runrev is done.

After the runrev command is entered, the switch starts running the new runtime software revision. The secondary software revision shows that a previous revision is still available. Whenever the secondary runtime software revision is different from the primary and current runtime software revisions, you can revert back to the secondary software revision as described in "Aborting a Runtime Software Upgrade," which appears later in this section.

---

Upgrading Boot Software on an AXSM Card

---

Note The AXSM upgrade procedures are the same for AXSM, AXSM/B, and AXSM-E cards.

---

The upgrade procedure for the boot software on a single AXSM card is the same for graceful and non-graceful upgrades. The difference between the graceful and non-graceful boot software upgrades is the sequence of commands before and after the upgrade on a single card. For information on the proper sequence see "Graceful AXSM Boot Upgrades" or "Non-Graceful AXSM Boot Upgrades," both of which appear earlier in this section.

To upgrade the boot software, use the following procedure.

---

Step 1 Copy the new boot software files for the AXSM card to the switch as described in "Copying Software Files to the Switch," which appears earlier in this section.

Step 2 Establish a CLI session with the switch using a user name with SERVICE_GP privileges or higher.

Step 3 To burn the new AXSM boot software, enter the burnboot command from the active PXM45 card. For example:

mgx8850a.7.PXM.a > burnboot <slot> <revision>

Replace <slot> with the slot number of a standalone AXSM card or an AXSM card operating in standby mode. Replace <revision> with the software revision number to which you are upgrading. For example:

mgx8850a.7.PXM.a > burnboot 1 3.0(0)

Step 4 When prompted to confirm the upgrade, type y and press Return.

After you confirm the upgrade, the new boot software is burned into the AXSM card and the card is reset. Be patient, the card reset takes some time. You can use the dsprevs command to display the status of the AXSM card. At first, the status may show that the card slot is empty or the card is rebooting. Reenter the command periodically to see the current status of the card. When the card status returns to active or standby, you are ready to continue.

M8xx0_NY.8.PXM.a > dsprevs

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 17:14:58 PST

MGX8850                                              Node Alarm: CRITICAL

Physical  Logical   Inserted       Cur Sw              Boot FW             

Slot      Slot      Card           Revision            Revision            

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

01        01        AXSM_4OC12     3.0(0.0)            3.0(0.0)         

02        01        AXSM_4OC12     3.0(0.0)            3.0(0.0)         

03        03        AXSM_4OC12     3.0(0.0)            3.0(0.0)         

04        04        ---            ---                 ---                 

05        05        ---            ---                 3.0(0.0)         

06        06        ---            ---                 3.0(0.0)         

07        07        PXM45          3.0(0.0)            3.0(0.0)         

08        07        PXM45          3.0(0.0)            3.0(0.0)         

09        09        RPM_PR         ---                 ---                 

10        10        ---            ---                 ---                 

11        11        ---            ---                 ---                 

12        12        ---            ---                 ---                 

13        13        ---            ---                 ---                 

14        14        ---            ---                 ---                 

M8xx0_NY.8.PXM.a > 

Step 5 To confirm that the AXSM card is now using the correct boot software, enter the dsprevs command.

After you confirm the boot software upgrade to the AXSM card, the boot software upgrade for that card is complete.

---

Aborting a Runtime Software Upgrade

After upgrading PXM45 or AXSM runtime software, you can revert to the previously used version of software at any time, as long as you have not committed to the new software version with the commitrev command (which is described in the next section).

---

Note Reverting to the previously used version of runtime software terminates all calls in progress.

---

To revert to the previously used runtime software version, use the following procedure.

---

Step 1 Establish a configuration session using a user name with SERVICE_GP privileges or higher.

Step 2 To display the software revisions known to the switch, enter the dsprevs -s command.

M8xx0_NY.8.PXM.a > dsprevs -s

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 01:16:26 PST

MGX8850                                              Node Alarm: CRITICAL

Phy. Log. Cur Sw           Prim Sw          Sec Sw           Rev Chg           

Slot Slot Revision         Revision         Revision         Status            

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

01   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

02   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

03   03   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

04   04   ---              ---              ---              ---               

05   05   ---              3.0(0.0)         3.0(0.0)         ---               

06   06   ---              3.0(0.0)         3.0(0.0)         ---               

07   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

08   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

09   09   ---              ---              ---              ---               

10   10   ---              ---              ---              ---               

11   11   ---              ---              ---              ---               

12   12   ---              ---              ---              ---               

13   13   ---              ---              ---              ---               

14   14   ---              ---              ---              --- 

To complete the next step, you need to know the secondary software revision shown in the display.

---

Note If the primary and secondary software revisions are the same, there is no other revision level to revert back to.

---

Step 3 To abort use of the primary software revision and revert back to the secondary software revision, enter the following command:

mgx8850a.7.PXM.a > abortrev <slot> <revision>

Replace <slot> with the card slot number for the active PXM45 or AXSM card, and replace <revision> with the software version number for the secondary software revision.

Step 4 To verify that the standby card is running the previously used software version, enter the dsprevs -s command to view the software version in use.

M8xx0_NY.8.PXM.a > dsprevs -s

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 01:16:26 PST

MGX8850                                              Node Alarm: CRITICAL

Phy. Log. Cur Sw           Prim Sw          Sec Sw           Rev Chg           

Slot Slot Revision         Revision         Revision         Status            

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

01   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

02   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

03   03   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

04   04   ---              ---              ---              ---               

05   05   ---              3.0(0.0)         3.0(0.0)         ---               

06   06   ---              3.0(0.0)         3.0(0.0)         ---               

07   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

08   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

09   09   ---              ---              ---              ---               

10   10   ---              ---              ---              ---               

11   11   ---              ---              ---              ---               

12   12   ---              ---              ---              ---               

13   13   ---              ---              ---              ---               

14   14   ---              ---              ---              --- 

---

Committing to a Runtime Software Upgrade

Committing to an upgrade does the following:

•Disables use of the abortrev command to revert back to the previously used version of software

•Enables upgrading of the current version of software and other cards

Once you are sure that an upgrade is stable, you can use the commitrev command to commit that software version. This prevents other administrators from inadvertently reverting to the previous version. You must also commit the current software version before you can upgrade to another software version or other additional cards.

---

Note If you do not run the commitrev command in a PXM or AXSM upgrade, the upgrade is not complete and you cannot upgrade any other like card in the switch.

---

To commit the currently running runtime software version, use the following procedure:

---

Step 1 Establish a configuration session using a user name with SERVICE_GP privileges or higher.

Step 2 Determine if there is an unfinished upgrade by doing the following:

a. If necessary, use the cc command to select the active PXM45 card.

b. Enter the dsprevs -s command.

M8xx0_NY.8.PXM.a > dsprevs -s

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 01:16:26 PST

MGX8850                                              Node Alarm: CRITICAL

Phy. Log. Cur Sw           Prim Sw          Sec Sw           Rev Chg           

Slot Slot Revision         Revision         Revision         Status            

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

01   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

02   01   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

03   03   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

04   04   ---              ---              ---              ---               

05   05   ---              3.0(0.0)         3.0(0.0)         ---               

06   06   ---              3.0(0.0)         3.0(0.0)         ---               

07   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

08   07   3.0(0.0)         3.0(0.0)         3.0(0.0)         ---               

09   09   ---              ---              ---              ---               

10   10   ---              ---              ---              ---               

11   11   ---              ---              ---              ---               

12   12   ---              ---              ---              ---               

13   13   ---              ---              ---              ---               

14   14   ---              ---              ---              --- 

c. Check the dsprevs -s command report to see if the same software revision is listed for the current (Cur SW Rev), primary (Prim SW Revision), and secondary (Sec SW Rev) software revisions.

If all version numbers are identical, the runtime software can be upgraded. There is no need to commit to the current software revision.

Step 3 To commit to the software version, enter the following command:

mgx8850a.7.PXM.a > commitrev <slot> <revision>

Replace <slot> with the card slot number for the active PXM45 or AXSM card, and replace <revision> with the software version number for the currently used software version. To display the software version numbers, use the dsprevs -s command to view the software version in use.

M8xx0_NY.8.PXM.a > dsprevs -s

M8xx0_NY                         System Rev: 03.00   Jun. 18, 2002 01:16:26 PST

MGX8850                                              Node Alarm: CRITICAL

Phy. Log. Cur Sw           Prim Sw          Sec Sw           Rev Chg           

Slot Slot Revision         Revision         Revision         Status            

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

01   01   3.0(0.0)          3.0(0.0)         3.0(0.0)         ---               

02   01   3.0(0.0)          3.0(0.0)         3.0(0.0)         ---               

03   03   3.0(0.0)          3.0(0.0)         3.0(0.0)         ---               

04   04   ---               ---              ---              ---               

05   05   ---               3.0(0.0)         3.0(0.0)         ---               

06   06   ---               3.0(0.0)         3.0(0.0)         ---               

07   07   3.0(0.0)          3.0(0.0)         3.0(0.0)         ---               

08   07   3.0(0.0)          3.0(0.0)         3.0(0.0)         ---               

09   09   ---               ---              ---              ---               

10   10   ---               ---              ---              ---               

11   11   ---               ---              ---              ---               

12   12   ---               ---              ---              ---               

13   13   ---               ---              ---              ---               

14   14   ---               ---              ---              --- 

---

Note Cisco Systems recommends that you avoid configuration changes until after you have run the commitrev or abortrev commands.

---

---

Troubleshooting Upgrade Problems

Table 21 lists symptoms of upgrade problems and suggestions on how to correct them.

---

Tips When troubleshooting problems on standby PXM45 cards or cards that do not start up to the active state, establish communications through the boot IP address or through the console port.

---

Table 21 Troubleshooting Upgrade Problems 

Primary Symptom	Secondary Symptom	Suggested Action
loadrev or runrev command fails		The loadrev command is blocked when a previous upgrade has not been completed with the commitrev command. Use the dsprev -s command to locate the cards that are still being upgraded. For more information on a particular card, enter the dspcd <slot> command and verify that the Current, Primary, and Secondary software revision numbers are identical. If the numbers are not identical, issue the commitrev <slot> command. Enter the dspcds command (or dsprevs or dsprev -s) and verify that the standby card is in standby state. Also look for a -U or -D in the dspcds command display, which indicates that the card is in the process of being upgraded (-U) or downgraded (-D). The loadrev and runrev commands are blocked whenever the standby card is not in standby state or an upgrade or downgrade is in progress.
After restart, the switch stops displaying messages and does not display a prompt.		Press Return to display the prompt.
After restart, switch stops at backup boot prompt: pxm45bkup>. (Use a console port connection to see this. If you missed the startup messages, enter the reboot command.)	The switch displays the message: Can not open file C:/version.	The version file is probably missing. Create the version file as described in "Initializing the Switch" in Chapter 2, "Configuring General Switch Features."
	The switch displays the message: Unable to determine size of C:/FW/filename.	The version recorded in the version file doesn't match software installed in the C:FW directory. Enter the sysVersionShow command to see which file the PXM45 is trying to load. Verify that the correct software is installed on the switch using the commands described in "Browsing the File System in Backup Boot Mode" in Appendix B, "PXM45 Backup Boot Procedures." If the runtime software is not on the hard disk, copy it to the hard disk as described in "Transferring Software Files to and from the Switch" in Appendix B, "PXM45 Backup Boot Procedures." If a typo is entered when initializing the switch, re-enter the sysVersionSet command, enter the sysVersionShow command to verify the correct setting, and then reboot the switch with the reboot command.
	The switch displays the message: Please run sysDiskCfgCreate.	The hard disk is formatted, but not ready for operation. Enter the sysDiskCfgCreate command. For more information, refer to "Initializing the PXM45 Hard Disk" in Appendix B, "PXM45 Backup Boot Procedures."
Standby PXM45 continually reboots. You can view the rebooting process through the console port.		The active PXM45 card cannot bring up the standby card. The following procedure assumes that this card has just been installed in the switch and that you have given the standby card sufficient time to synchronize with the Active card. Interrupt the boot cycle by pressing Return. Timing is important, so you might have to press Return multiple times. When the pxm45bkup prompt appears, immediately enter the sysPxmRemove command to prevent the Active card from rebooting the standby card while you are working on it. Enter the sysChangeEnet command and verify that the inet on ethernet (e) and gateway inet (g) values are set to the boot and gateway IP address set with the bootChange command on the active card. Also, verify that the boot device is set to lnPci. The sysChangeEnet command works like the bootChange command, which is described in "Setting the Boot IP Address" in Chapter 2, "Configuring General Switch Features." Enter the sysClrallcnf command to clear any configuration data on the standby card set. This command does not clear the boot IP address set with the sysChangeEnet command.
After restart, the switch stops at shell prompt: pxm45>.		If the Return key is pressed at one of the auto-boot prompts during start up, the switch stops in shell mode. Enter the reboot command to restart the switch and avoid pressing the Return key.
The non-active PXM45 will not transition out of the active init state.	One or more non-standby AXSM cards are in a transitional state.	A non-standby AXSM card is a standalone AXSM card or the card within a redundant AXSM pair that is trying to go active. When a non-standby AXSM card is in a transitional state, such as the init state, the PXM45 cannot transition to the standby state. When all non-standby cards have reached a steady (non-transitional) state, the PXM45 will transition to a steady state. Steady states include the following: active ready, failed, mismatch, empty, empty reserved, and standby ready. Note When either card in a redundant AXSM pair is active, that AXSM pair is not preventing the standby PXM45 from transitioning to a steady state. The standby PXM45 is only affected when both cards in a redundant pair are in a transitional state.

Documentation

Release notes ship with the switch. You can also download the release notes and other documentation from http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm, or you can order printed manuals (see "Ordering Documentation").

---

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

---

Related Documentation

The following Cisco publications contain additional information related to the operation of this product and associated equipment in a Cisco WAN switching network.

Cisco WAN Manager Release 11.0.00

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

Table 22 Cisco WAN Manager Release 11 Documentation 

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

Cisco MGX 8850 (PXM45) Multiservice Switch Release 3

The product documentation for the installation and operation of the MGX 8850 Multiservice Switch for Release 3 is listed in Table 23.

Table 23 Cisco MGX 8850 (PXM45) Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8850 Hardware Installation Guide, Release 3 (PXM45/B and PXM1E) DOC-7814250=	Describes how to install the MGX 8850 multiservice switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8850 switch uses either a PXM45 or a PXM1E controller card and provides support for both broadband and narrow band service modules.
Cisco MGX 8850, MGX 8950, and MGX 8830 Command Reference (PXM45/B and PXM1E), Release 3 DOC-7814245=	Describes how to use the PXM and AXSM commands that are available for the MGX 8850, MGX 8950, and MGX 8830 switches.
Cisco Frame Relay Software Configuration Guide and Command Reference for the MGX 8850 FRSM12 Card, Release 3 DOC-7810327=	Describes how to use the high-speed Frame Relay (FRSM12) commands that are available for the MGX 8850 switch.
Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3 DOC-7814577=	Describes how to configure MGX 8850 and MGX 8950 switches with PXM45 controller cards to operate as ATM edge or core switches. This guide also provides some operation and maintenance procedures.
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3 and SES Release 3 DOC-7814261=	Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
Cisco VISM Installation and Configuration Guide, Release 3 OL-2521-01 (online only)	Describes how to install and configure VISM1 in several MGX 8000 Series switches. This guide is available online only.
Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3 OL-2768-01 (online only)	Describes how to install and configure the MGX Route Processor Module (RPM-XF) in the MGX 8850 Release 3 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1 DOC-7812510=	Describes how to install and configure the MGX Route Processor Module (RPM-PR) in the MGX 8850 Release 2.1 and later switches. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.10 and Release 3 78-14243-01	Provides the latest feature, upgrade, and compatibility information, as well as known and resolved anomalies for RPM-PR.

1 VISM = Voice Interworking Service Module

Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3

The product documentation for the installation and operation of the Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3 is listed in Table 24.

Table 24 Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8850 Hardware Installation Guide (PXM45/B and PXM1E), Release 3 DOC-7814250=	Describes how to install the MGX 8850 multiservice switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8850 switch uses either a PXM45 or a PXM1E controller card and provides support for both broadband and narrow band service modules.
Cisco MGX 8850, MGX 8950, and MGX 8830 Command Reference (PXM45/B and PXM1E), Release 3 DOC-7814245=	Describes how to use the PXM and AXSM commands that are for the the MGX 8850, MGX 8950, and MGX 8830 switches.
Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3 DOC-7814248=	Describes how to configure MGX 8850 and MGX 8830 switches with PXM1E controller cards to operate as ATM edge switches. This guide also provides some operation and maintenance procedures.
Cisco Frame Relay Software Configuration Guide and Command Reference for MGX Switches (PXM1E) DOC-7814255=	Provides software configuration procedures for provisioning connections and managing the FRSM cards supported in this release. Also provides command descriptions for all FRSM commands.
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3 and SES Release 3 DOC-7814261=	Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1 DOC-7812510=	Describes how to install and configure the MGX Route Processor Module (RPM-PR) in the MGX 8850 Release 3 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.10 and Release 3 78-14243-01	Provides the latest compatibility information, as well as known and resolved anomalies for RPM-PR.

Cisco MGX 8950 Multiservice Switch Release 3

The product documentation for the installation and operation of the MGX 8950 Multiservice Switch for Release 3.0.00 is listed in Table 25.

Table 25 Cisco MGX 8950 Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8950 Hardware Installation Guide, Release 3 DOC-7814147=	Describes how to install the MGX 8950 core switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8950 switch uses a PXM45/B controller card and provides support for broadband service modules.
Cisco MGX 8850, MGX 8950, and MGX 8830 Command Reference (PXM45/B and PXM1E), Release 3 DOC-7814245=	Describes how to use the PXM and AXSM commands that are available for the MGX 8850, MGX 8950, and MGX 8830 switches.
Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3 DOC-7814577=	Describes how to configure MGX 8850 and MGX 8950 switches with PXM45 controller cards to operate as ATM edge or core switches. This guide also provides some operation and maintenance procedures.
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3 and SES Release 3 DOC-7814261=	Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1 DOC-7812510=	Describes how to install and configure the MGX Route Processor Module (RPM-PR) in the MGX 8950. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.10 and Release 3 78-14243-01	Provides the latest feature, upgrade, and compatibility information, as well as known and resolved anomalies for RPM-PR.

Service Expansion Shelf PNNI Controller Release 3

The product documentation for the installation and operation of the Service Expansion Shelf (SES) PNNI Controller is listed in Table 26.

Table 26 SES PNNI Controller Release 3 Documentation 

Title	Description
Cisco SES PNNI Controller Software Configuration Guide, Release 3 DOC-7814258=	Describes how to configure, operate, and maintain the SES PNNI Controller.
Cisco SES PNNI Controller Command Reference, Release 3 DOC-7814260=	Provides a description of the commands used to configure and operate the SES PNNI Controller.
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3 and SES Release 3 DOC-7814261=	Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.

Cisco MGX 8830 Multiservice Switch Release 3

The product documentation for the installation and operation of the MGX 8830 Multiservice Switch Release 3.0.00 is listed in Table 27.

Table 27 Cisco MGX 8830 Multiservice Switch Release 3 Documentation 

Title	Description
Cisco MGX 8830 Hardware Installation Guide, Release 3 DOC-7814547=	Describes how to install the MGX 8830 edge switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8830 switch uses a PXM1E controller card and provides PNNI support for narrow band service modules.
Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3 DOC-7814248=	Describes how to configure MGX 8850 and MGX 8830 switches with PXM1E controller cards to operate as ATM edge switches. This guide also provides some operation and maintenance procedures.
Cisco MGX 8850, MGX 8950, and MGX 8830 Command Reference (PXM45/B and PXM1E), Release 3 DOC-7814245=	Describes how to use the PXM and AXSM commands that are available in the CLI of the MGX 8850, MGX 8950, and MGX 8830 switches.
Cisco Frame Relay Software Configuration Guide and Command Reference for MGX Switches (PXM1E) DOC-7814255=	Provides software configuration procedures for provisioning connections and managing the FRSM cards supported in this release. Also provides command descriptions for all FRSM commands.
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3 and SES Release 3 DOC-7814261=	Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1 DOC-7812510=	Describes how to configure the MGX Route Processor Module (RPM-PR) in the MGX 8830 Release 3 switch. Also provides troubleshooting, maintenance, and basic Cisco IOS configuration information. (For RPM-PR software configuration information only.)
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1 DOC-7812278=	Describes how to install the MGX Route Processor Module (RPM-PR) in the MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting and maintenance information, cable and connector specifications, and basic RPM-PR slot and redundancy limitations and constraints. (For RPM-PR hardware installation information only.)
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.10 and Release 3 78-14243-01	Provides compatibility information, as well as known and resolved anomalies for RPM-PR.

Cisco WAN Switching Software Release 9.3.40

The product documentation for the installation and operation of the Cisco WAN Switching Software Release 9.3.40 is listed in Table 28.

Table 28 Cisco WAN Switching Software Release 9.3.40 Documentation 

Title	Description
Cisco BPX 8600 Series Installation and Configuration, Release 9.3.30 DOC-7812907=	Provides a general description and technical details of the BPX broadband switch.
Cisco WAN Switching Command Reference, Release 9.3.30 DOC-7812906=	Provides detailed information on the general command line interface commands.
Cisco IGX 8400 Series Installation Guide OL-1165-01 (online only)	Provides hardware installation and basic configuration information for IGX 8400 Series switches that are running Switch Software Release 9.3.30 or earlier.
Cisco IGX 8400 Series Provisioning Guide OL-1166-01 (online only)	Provides information for configuration and provisioning of selected services for the IGX 8400 Series switches that are running Switch Software Release 9.3.40 or earlier.
Cisco IGX 8400 Series Regulatory Compliance and Safety Information DOC-7813227=	Provides regulatory compliance, product warnings, and safety recommendations for the IGX 8400 Series switch.
9.3.40 Version Software Release Notes for Cisco WAN Switching System Software 78-13538-01	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.

MGX 8850 (PXM1) Multiservice Switch Release 1.2.10

The product documentation for the installation and operation of the MGX 8850 (PXM1) Multiservice Switch is listed in Table 29.

Table 29 MGX 8850 (PXM1) Multiservice Switch Release 1.2.10 Documentation 

Title	Description
Cisco MGX 8850 Multiservice Switch Installation and Configuration, Release 1.1.3 DOC-7811223=	Provides installation instructions for the MGX 8850 multiservice switch.
Cisco MGX 8800 Series Switch Command Reference, Release 1.1.3 DOC-7811210=	Provides detailed information on the general command line for the MGX 8850 switch.
Cisco MGX 8800 Series Switch System Error Messages, Release 1.1.3 DOC-7811240=	Provides error message descriptions and recovery procedures.
Cisco MGX 8850 Multiservice Switch Overview, Release 1.1.3 OL-1154-01 (online only)	Provides a technical description of the system components and functionality of the MGX 8850 multiservice switch from a technical perspective.
Cisco VISM Installation and Configuration Guide, Release 3 OL-2521-01 (online only)	Describes how to install and configure VISM in several MGX 8000 Series switches. This guide is available online only.
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1 DOC-7812278=	Describes how to install and configure the MGX Route Processor Module (RPM/B and RPM-PR) in the MGX 8850, MGX 8250, and MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (Release 1), Software Version 1.2.10 (PXM1) 78-14247-01	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.10 and Release 3 78-14243-01	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.

MGX 8250 Edge Concentrator Release 1.2.10

The documentation for the installation and operation of the MGX 8250 Edge Concentrator is listed in Table 30.

Table 30 MGX 8250 Edge Concentrator Release 1.2.10 Documentation 

Title	Description
Cisco MGX 8250 Edge Concentrator Installation and Configuration, Release 1.1.3 DOC-7811217=	Provides installation instructions for the MGX 8250 Edge Concentrator.
Cisco MGX 8250 Multiservice Gateway Command Reference, Release 1.1.3 DOC-7811212=	Provides detailed information on the general command line interface commands.
Cisco MGX 8250 Multiservice Gateway Error Messages, Release 1.1.3 DOC-7811216=	Provides error message descriptions and recovery procedures.
Cisco MGX 8250 Edge Concentrator Overview, Release 1.1.3 DOC-7811576=	Describes the system components and functionality of the MGX 8250 Edge Concentrator from a technical perspective.
Cisco VISM Installation and Configuration Guide, Release 3 OL-2521-01 (online only)	Describes how to install and configure VISM in several MGX 8000 Series switches. This guide is available online only.
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1 DOC-7812278=	Describes how to install and configure the MGX Route Processor Module (RPM/B and RPM-PR) in the MGX 8850, MGX 8250, and MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (Release 1), Software Version 1.2.10 (PXM1) 78-14247-01	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.10 and Release 3 78-14243-01	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.

MGX 8230 Edge Concentrator Release 1.2.10

The documentation for the installation and operation of the MGX 8230 Edge Concentrator is listed in Table 31.

Table 31 MGX 8230 Edge Concentrator Documentation 

Title	Description
Cisco MGX 8230 Edge Concentrator Installation and Configuration, Release 1.1.3 DOC-7811215=	Provides installation instructions for the MGX 8230 Edge Concentrator.
Cisco MGX 8230 Multiservice Gateway Command Reference, Release 1.1.3 DOC-7811211=	Provides detailed information on the general command line interface commands.
Cisco MGX 8230 Multiservice Gateway Error Messages, Release 1.1.3 DOC-78112113=	Provides error message descriptions and recovery procedures.
Cisco MGX 8230 Edge Concentrator Overview, Release 1.1.3 DOC-7812899=	Provides a technical description of the system components and functionality of the MGX 8250 Edge Concentrator from a technical perspective.
Cisco VISM Installation and Configuration Guide, Release 3 OL-2521-01 (online only)	Describes how to install and configure VISM in several MGX 8000 Series switches. This guide is available online only.
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1 DOC-7812278=	Describes how to install and configure the MGX Route Processor Module (RPM/B and RPM-PR) in the MGX 8850, MGX 8250, and MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (Release 1), Software Version 1.2.10 (PXM1) 78-14247-01	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.10 and Release 3 78-14243-01	Provides new feature, upgrade, and compatibility information, as well as known and resolved anomalies.

Ordering Documentation

Cisco documentation is available in the following ways:

•Registered Cisco Direct Customers can order printed Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/public/ordsum.html

Starting with MGX 2.1.60 and its associated releases, printed documentation is offered through the "Printed Information Ordering" site, which can be accessed through:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

•Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/go/subscription

•Non-registered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by calling 800 553-NETS(6387).

Documentation on the World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following sites:

•http://www.cisco.com (for example, http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm)

•http://www-china.cisco.com

•http://www-europe.cisco.com

Documentation CD-ROM

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription as mentioned above.

Documentation Feedback

If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.

You can e-mail your comments to bug-doc@cisco.com or msspubs-feedback@cisco.com.

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Attn: Document Resource Connection
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.

Cisco.com

Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.

Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.

Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.

To access Cisco.com, go to http://www.cisco.com

Technical Assistance Center

The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.

Contacting TAC by Using the Cisco TAC Website

If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:

http://www.cisco.com/tac

P3 and P4 level problems are defined as follows:

•P3—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

•P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.

In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.

---

Note To register for Cisco.com, go to http://www.cisco.com/register/

---

If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at http://www.cisco.com/tac/caseopen

Contacting TAC by Telephone

If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

P1 and P2 level problems are defined as follows:

•P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.

•P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.

Caveats

This section provides information about known anomalies.

MGX 8830 Anomalies

Table 32lists the anomalies and known workarounds for release 3.

Table 32 MGX 8830 Anomalies

Bug	Description
S1 Bugs
CSCdx48370	Symptom: CBM1 throughput is 42% of OC-3 LR as opposed to 100% OC-3 LR. Conditions: Inject OC-3 LR traffic Workaround: None. Hardware: PXM1E
CSCdx53377	Symptom: SPVC fails after it was created Condition: SPVC failed because the service module was in an unreserved state. Workaround: 1) Call an api from the shell to re-reserve the slot sh>shmRemoteFrontCardReservedReport (logical_slot #). 2) Delete the ports, parts, connections on slots and readd them. Hardware: PXM1E
CSCdx57276	Symptom: Line is not added back after power cycle. Conditions: Power cycle node by removing the standby combo cards FRUs. Workaround: Unknown. Hardware: PXM1E
CSCdx59414	Symptom: With a PXM1E using a UI-S3 backcard, some Ethernet packets outbound from the PXM1E may be dropped when the UI-S3 Ethernet port is connected to specific hubs/switches. Conditions: Problem is hardware specific for the PXM1E with UI-S3 backcard. Workaround: Use a Cisco approved hub/switch. Hardware: PXM1E
CSCdx69311	Symptom: Occasionally, an upline on a DS3 line on the active PXM1E in a redundant PXM1E node causes the standby card to reset. The reason for the reset is "Software Error Reset" and the log indicates Line Hardware Failure. Conditions: If this problem happens, it is only on a combo PXM1E card and then only on certain DS3 lines. Workaround: If a certain DS3 line shows this problem, down it and avoid using it. Instead, use another DS3 line. Hardware: PXM1E
CSCdx73805	Symptom: FRSMs take more than 60+ mins become active Conditions: Populate slot 1 thru 14 w/ FRSMs, perform clrsmcnf on all and immediately remove and re-insert all the cards. Workaround: None. Hardware: PXM1E
CSCdx74295	Symptom: Node with PXM1E shows active/standby with two different type of PXM1E cards. Condition: Customer removed the standby pxm1e and then inserted a different front card type. Card came up as standby/mismatch with the front cards showing active/standby. Workaround: Do not mix front card types. Hardware: PXM1E
CSCdx74396	Symptom: Clock signal is still being detected on CESM port even when line is in alarm. Conditions: When configuring a CESM port as a clock source and the cable is pulled out of the CESM port; good clocking signals are still being detected on this port. Workaround: None. Hardware: CESM-8T1E11
CSCdx76563	Symptom: Dspcons/dspchans does not work. Condition: When issuing the dspcons or dspchans command, the cons are not displayed. The cli responses with Getting Filter Resource Failed. Workaround: Reset the card. Hardware: FRSM-8T1E1
CSCdx77485	Symptom: The PXM1E combo trunk back card has 12 lines. The top 8 lines are T3 or E3 and the bottom 4 lines are SONET lines. The 4 SONET lines have two LEDs per line. The top LED is meant to show the signal detect function. That is, if there is a signal on the incoming line, then this LED will glow a steady green. If there is no signal, this LED will blink green. The LED on the bottom is meant to show the active/standby status of the line. In case of both Y-redundancy and APS configuration, the active line is steady green and standby is steady yellow. Currently, the signal detect LED will be functioning correctly. But the status LEDs will be turned OFF always. It will not reflect the status of the line. Conditions: Under all conditions, the status LEDs of the SONET lines on the combo back cards are OFF. Workaround: In case of Y-Redundancy, the status of the lines can be found from the CLI command "dspcd". If the PXM1E front card is active, then all the lines are active. If the PXM1E front card is standby, then all the lines are standby. In case of APS redundancy, the status of the lines can be found using the CLI command "dspapslns". Hardware: PXM1E
CSCdx80130	Symptom: CWM gets lots of sd clear traps, and dsplog dropped events. Conditions: When any backcard is removed. Workaround: None. Hardware: PXM45B
CSCdx80725	Symptom: Lower backcard APS OC12 lines switch. Conditions: When the upper backcard is removed from the same slot. Workaround: None. Hardware: AXSMB OC-12
CSCdx81229	Symptom: Dspcons from pxm1e show some cons in failed state, but dspcons from the service module shows these cons as okay. Conditions: Alarms are not being sent to the service modules. Workaround: Unknown. Hardware: PXM1E
S3 Bugs
CSCdx12589	Symptom: PXM-45 can be booted with wrong code image for chassis. Condition: PXM-45 and HD back card previously configured in an 8850 chassis with *_mgx.fw firmware can boot in an 8830 chassis with that same firmware. MGX8830 Requires *_m30.fw firmware. Workaround: None. Hardware: PXM1E
CSCdx68030	Symptom: The addlnloop command does not display option for E3 and DS3. Conditions: When issuing the addlnloop command without an argument, the display does not show the E3 or DS3 options. Workaround: Issue the addlnloop command with the -E3 or -DS3 options. Hardware: PXM1E

MGX 8850 Anomalies

Severity level 1 and 2 anomalies are organized as follows:

•Known Anomalies in Release 3.0.00

•Anomalies Resolved in Release 3.0.00

Known Anomalies in Release 3.0.00

Table 33 lists the anomalies and known workarounds for release 3.

Table 33 MGX 8850 Release 3.0.00 Anomalies

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

Anomalies Resolved in Release 3.0.00

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

Table 34 Anomalies Resolved in Release 3.0.00

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

Table 35 Anomalies Resolved in Release 3.0.00

Known Route Processor Module or MPLS Anomalies

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

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

MGX-RPM-XF-512 Anomalies

The new MGX-RPM-XF-512 card supports MGX 8850 (PXM45), Release 3.0.00.

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

Acronyms

Table 36 lists acronyms used in these release notes.

Table 36 Acronyms and Their Descriptions  

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

This document is to be used in conjunction with the documents listed in the "Related Documentation" section.

AccessPath, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That's Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, PIX, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

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

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