Guest

Cisco MGX 8800 Series Switches

2.1.00 Release Notes for MGX 8850 Software

 Feedback

Table Of Contents

Release Notes for Cisco MGX 8850 Software Version 2.1.00

Contents

Introduction

Terms

Hardware Supported

Software Compatibility

New and Changed Information

New Features in Release 2.1.00

MPLS LSC/LER Support on RPM-PR for MGX 8850-PXM45

RPM 1:N Redundancy

Label Switch Controller Redundancy for MPLS Control Plane

MPLS VPN support on RPM

MPLS Class of Service

RPM Auto-Config

MGX-PXM1 (8230/8250/8850-PXM1) MPLS Interworking with MGX 8850 PXM45

BPX 8600-S42ES and MGX 8850-PXM45 Connection Management Interoperability

Crossbar Fabric Load Sharing Using PXM45 and PXM45/B

Features Supported on Release 2.0

Additional Deliverables

New CLI Commands

Changed Commands

Removed Commands

Upgrading to a New Software Release

Upgrade Procedure Overview

PXM45 Upgrades

AXSM Upgrades

Upgrading Software on a Non-Redundant AXSM Card

Aborting the Revisions for Both the PXM Cards and AXSM Cards

RPM Upgrades

Installation Notes

Upgrade Path

Limitations and Restrictions

APS Status Information

Recommendations

Important Notes

Caveats

Open Caveats for MPLS

Open Caveats for MGX 8850

Related Documentation

Documentation Corrections

Obtaining Documentation

Ordering Documentation

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


Release Notes for Cisco MGX 8850 Software Version 2.1.00


Contents

This document contains the following sections:

"Introduction" section

"Hardware Supported" section

"Software Compatibility" section

"New and Changed Information" section

"New Features in Release 2.1.00" section

"New CLI Commands" section

"Upgrading to a New Software Release" section

"Installation Notes" section

"Limitations and Restrictions" section

"Important Notes" section

"Caveats" section

"Related Documentation" section

"Technical Assistance" section

Introduction

These release notes describe the upgrade procedures for version 2.1.00, software upgrade procedures, hardware supported by the release, network support, and software limitations. The notes also contain Cisco support information. Follow-on releases are planned to add new features, and can be found in the Marketing Road Map.

Terms

In these notes, the term fall back refers to returning ungracefully to the original software version.

Hardware Supported

Table 1 lists the hardware supported in Release 2.1.00.

Table 1 Hardware Supported

Model
800 Part Number
Revision

PXM45

800-06147-07

B0

PXM45/B

800-09266-03

A0

PXM-UI-S3

800-05787-02

A0

PXM-HD

800-05052-03

A0

AXSM-1-2488

800-05795-05

A0

SMFSR-1-2488-FC

800-05490-05

A0

SMFXLR-1-2488-FC

800-05793-05

A0

SMFLR-1-2488-FC

800-06635-04

A0

AXSM-16-155

800-05776-06

A0

AXSM-4-622

800-05774-09

B0

AXSM-16-T3E3

800-05778-08

A0

SMFIR-2-622

800-05383-01

A1

SMFLR-2-622

800-05385-01

A1

SMB-8-T3-BC

800-05029-02

A0

SMB-8-E3-BC

800-04093-02

A0

MMF-8-155

800-04819-01

A1

SMFIR-8-155

800-05342-01

B0

SMFLR-8-155

800-05343-01

A1

APS RDNT CON

800-05307-01

A0

RPM-PR-256

800-07178-02

A0

RPM-PR-512

800-07656-02

A0

RPM-4E/B

800-12134-01

A0

Software Compatibility

Table 2 lists software and firmware compatibilities.

Table 2 Software Compatibility Matrix

Board Pair
Latest Boot Code Version
Minimum
Boot Code
Version
Firmware
Latest
Firmware
Version
Minimum
Firmware
Version

PXM45

pxm45_002.001.000.000_bt.fw

2.1.0.0

pxm45_002.001.000.000_mgx.fw

2.1.0.1

2.1.0.1

AXSM-1-2488

axsm_002.001.000.000_bt.fw

2.1.0.0

axsm_002.001.000.000.fw

2.1.0.1

2.1.0.1

AXSM-16-155

axsm_002.001.000.000_bt.fw

2.1.0.0

axsm_002.001.000.000.fw

2.1.0.1

2.1.0.1

AXSM-4-622

axsm_002.001.000.000_bt.fw

2.1.0.0

axsm_002.001.000.000.fw

2.1.0.1

2.1.0.1

AXSM-16-T3/E3

axsm_002.001.000.000_bt.fw

2.1.0.0

axsm_002.001.000.000.fw

2.1.0.1

2.1.0.1

RPM

rpm-boot-mz.121-5.2.XT

121-5.2.XT

rpm-js-mz.121-5.2.XT

121-5.2.XT

121-5.2.XT


MGX 2.1.00 interoperates with SES PNNI 1.0.11plus BPX Switch Software (SWSW) 9.3.10 plus BXM MFJ.

MGX 2.1.00 operates with MGX 1.1.31 and MGX 1.1.32 as a feeder. Please see 1.1.31/1.1.32 release notes for bugs related to the feeder features. As of this printing, these release notes are posted at http://www.cisco.com/univercd/cc/td/doc/product/w1anbu/mgx8850/1_1_31/relnote/index.htm.

Route Processor Module (RPM) 2.1.00 is based on IOS Release 12.1(5)T.

RPM software is different for Release 1.1.31/1/1/32 and 2.1.00.

New and Changed Information

This section describes new features and commands in Release 2.1.00.

New Features in Release 2.1.00

MPLS LSC/LER Support on RPM-PR for MGX 8850-PXM45

Label switching enables routers at the edge of a network to apply simple labels to packets (frames), allowing devices in the network core to switch packets according to these labels with minimal lookup activity. Label switching in the network core can be accomplished by running Multiprotocol Label Switching (MPLS) on MGX 8850-PXM45 using Release 2.1.00 (or higher) and IOS Release based on 12.1(5)T.

For multiservice networks, MPLS enables the MGX 8850-PXM45 switch to provide ATM, Frame Relay, and IP Internet service all on a single platform in a highly scalable way. Support services on a common platform provide operational cost savings and simplify provisioning for multi-service providers. Label switching avoids the scalability problem of too many router peers and provides support for a hierarchical structure within an ISP network, improving scalability and manageability. Furthermore, label switching provides a platform for advanced IP services, such as Virtual Private Networks and IP Class of Service (CoS) on ATM switches.

MPLS, when integrated on MGX 8850-PXM45 switches, takes advantage of switch hardware that is optimized to take advantage of the fixed length of ATM cells, and to switch these cells at wire speeds.

MPLS on MGX 8850-PXM45 Features

MGX 8850-PXM45 as an ATM-LSR

Up to four IP Class of Services based on the Diffserv model using Parallel MPLS Label

Switched Paths(LSPs).

Separate Queues for different classes of IP traffic

Class-based Weighted Fair Queuing (CB-WFQ) for IP Classes

Ships in the Night mode between MPLS and PNNI

Use of Virtual Switch Interface (VSI) Protocol to provide IP+ATM integration.

Multiple Resource partitions

Support for MPLS VSI Virtual Trunks

Support for MPLS-based Virtual Private Networks based on RFC 2547 and RFC 2283

IP Routing Protocols: RIPv2, OSPF, IS-IS, EIGRP, BGPv4 (with extensions based on RFC 2283)

Interworking with MGX 8250, MGX 8230, MGX 8850-PXM1, BPX 8650, and BPX 8680-IP for End-to-End MPLS Edge and Core functions

RPM 1:N Redundancy

RPM 1:N redundancy is used to switch configuration and traffic from one RPM module to another module. The main benefits are:

Support for RPM Warm redundancy

Support for RPM 1:1 warm redundancy with n=1

Support for only Layer 2 state restoration. Layer 3 state restored via convergence.

Support for redundancy between the same card types.

LAN interface redundancy supported with MAC addresses of primary RPM copied to standby RPM.

Guidelines:

addred is not allowed between RPM/B and RPM-PR.

To configure redundancy, the Primary and Secondary RPM cards need to be in the Active state.

Removal of the primary RPM back card does not cause switchover to the secondary RPM.

Administrator needs to execute write memory (WR MEM) on the Primary cards after executing addred on the PXM card.

If the Secondary card is redundant to Primary cards "x" and "y", the administrator cannot delete redundancy for "x" only.

switchcc immediately after executing softswitch can cause problems. We recommend waiting at least 5 seconds after softswitch to initiate a switchcc.

IOS software on a Secondary card should be the same or higher version than the primary.

Label Switch Controller Redundancy for MPLS Control Plane

In the MGX 8850-PXM45, the RPM-PR acts as a Label Switch Controller (LSC). This enables the MGX to function as an ATM-LSR. The Label Switch controller is the Multiprotocol Label Switching (MPLS) control plane for the MGX and is a central point of failure if no redundancy is provided.

With this feature, two independent MPLS controllers, via VSI, control separate partitions in the IP+ATM switch, creating a set of two identical subnetworks. Multipath IP routing chooses to use both subnetworks equally, leading to identical connections in both subnetworks. If a controller in one subnetwork fails, then multipath IP routing very quickly diverts traffic to the other subnetwork.

LSC redundancy differs from hot-standby redundancy in that the LSCs do not need copies of each other's internal state or database, thus increasing reliability. LSC redundancy is simpler than hot-standby redundancy because it is not necessary to set up new connections when a controller fails. The LSC redundancy architecture requires the same amount of equipment as a network with hot-standby controllers, except that the controllers act independently, rather than in hot-standby mode.

MPLS VPN support on RPM

The IP virtual private network (VPN) feature for Multiprotocol Label Switching (MPLS) allows a Cisco IOS network to deploy scalable IPv4 Layer 3 VPN backbone services. An IP VPN is the foundation companies use for deploying or administering value-added services, including applications and data-hosting network commerce, and telephony services to business customers.

In private local area networks (LANs), IP-based intranets have fundamentally changed the way companies conduct their business. Companies are moving their business applications to their intranets to extend over a wide area network (WAN). Companies are also embracing the needs of their customers, suppliers, and partners by using extranets (an intranet that encompasses multiple businesses). With extranets, companies reduce business process costs by facilitating supply-chain automation, electronic data interchange (EDI), and other forms of network commerce. To take advantage of this business opportunity, service providers must have an IP VPN infrastructure that delivers private network services to businesses over a public infrastructure.

MPLS Class of Service

The Class of Service (CoS) feature for Multiprotocol Label Switching (MPLS) enables network administrators to provide differentiated types of service across an MPLS network. Differentiated service satisfies a range of requirements by supplying for each packet transmitted the particular kind of service specified for that packet by its CoS. Service can be specified in different ways, for example, using the IP precedence bit settings in IP packets.

There are two different approaches to providing MPLS class of service:

1) Frame-based MPLS Class of Service. In this method, MPLS is configured using RFC 1483 ATM PVCs, and service differentiation is attained by weighted random early detect (WRED) and class-based weighted fair queueing techniques (CBWFQ).

2) Cell-based MPLS Class of Service. In this method MPLS is enabled by the Label switch controller on the ATM switches. Service differentiation is attained by setting up separate label switch paths for separate IP precedences. A maximum of 4 classes of service or 4 label-switched paths are supported per IP prefix.

The default Class of Service mappings are shown in Table 3.

Table 3 Class of Service Mappings

Class of Service Mapping
Class of Service
TOS

Available

0

TOS 0/4

Standard

1

TOS 1/5

Premium

2

TOS 2/6

Control

3

TOS 3/7


RPM Auto-Config

Check if there is a configuration file on both the PXM E: and RPM disk, and the flash for the specific RPM slot.

If there is a config file (auto_config_slot##) only on the PXM disk, boot from PXM E:.

If there is no config file on the PXM disk, then the default (NVRAM) or the user configure path (boot config e:****) will be used.

If the config files exist on both E: and flash, then compare the tag in each file. The tag will be saved in the configuration file and is uniquely composed of a timestamp.

If the comparison result is the same, boot from the flash.

If the comparison is not the same, boot from PXM E:.

MGX-PXM1 (8230/8250/8850-PXM1) MPLS Interworking with MGX 8850 PXM45

This feature allows RPM cards as Edge LSRs in PXM1-based platforms to interwork with PXM45 Label Switch Controller (LSC) functions. The MPLS VSI Virtual trunks feature in Release 2.1.00 enables definition of one VP-tunnel per Edge LSR on PXM1 to be mapped to one VSI Virtual trunk on the PXM45 under the control of the RPM acting as a Label Switch Controller.

BPX 8600-S42ES and MGX 8850-PXM45 Connection Management Interoperability

This release achieves full interoperability of connection management (PNNI, SVC, SPVC, ILMI, UNI, and OAM) between BPX 8600 (with Service Expansion Shelf [SES] controller) and MGX 8850-PXM45. The scope of this interoperability is limited to BXM cards on the BPX switch and AXSM cards on the MGX 8850 switch. This is a highly desired feature, for customers can now build mixed PNNI networks of BPX 8600 (with SES) and MGX 8850-PXM45 platforms with connection management interoperability.

Crossbar Fabric Load Sharing Using PXM45 and PXM45/B

The Crossbar fabric load sharing provides the MGX 8850-PXM45 with a scalable and highly reliable data transport mechanism. In the MGX 8850-PXM45 architecture, the control and user data is partitioned into separate transport planes. The control data is transmitted through the Cell Bus Controller (CBC) and the user data on the AXSM module is transmitted using the Crossbar switching fabric on the PXM45 module. The MGX 8850-PXM45 can support 6 switching planes (3 per PXM45 card). Using load sharing, the user traffic can be transmitted across any of the Crossbar switch fabric planes. Command Line Interface (CLI) support is provided to enable/disable the load sharing feature with the default being "enable". When the feature is enabled, all the switch planes pass traffic simultaneously.

When upgrading from 2.0.13 to 2.1.00, load sharing is disabled by default.

Load sharing is a differentiating feature for the MGX 8850-PXM45 and provides a huge competitive advantage. With load sharing, if a switch control plane fails, there is no switchover required to the redundant standby PXM45 card.

Features Supported on Release 2.0

All the previous features supported in Release 2.0.x, such as PXM45, AXSM, AXSM redundancy, APS, PXM1 to PXM45 feeder and more, as specified in the feature descriptions for each release, are also supported in Release 2.1.00.

Additional Deliverables

SNMP MIB

The MIB release for 2.1.00 is mibs2012.

New CLI Commands

These commands are new to Release 2.1.00:

abortallsaves

actaudit

addlnloop

addlpback

addred

ccc

checkflash

clralm

clralmcnt

clrbecnt

clrchancnts

clrcnf (new as of 2.0)

clrloginmsg

clrportcnts

clrqosdefault

cnfcbclk

cnfloginmsg

cnfpasswd

cnfpswdreset or cnfpasswdreset

conntrace (new to 2.0.12)

core

dbgcon

dellpback

delpnni-node (new to 2.0.12)

delpnni-summary-addr (new to 2.0.12)

delsesn

dspactaudit

dspapsbkplane (new to 2.0.13)

dspbecnt

dspbkpl

dspcbclk

dspconfigs

dspconload

dspdbinfo

dsperrs (new to 2.0.10)

dsplnbucketcnt

dsplnload

dsploginmsg

dsplpback

dsppatterns

dsppnni-dbg (new to 2.0.12)

dsppnni-election (new to 2.0.12)

dspportload

dsppswdreset or dsppasswdreset

dsprevs

dspsesn

dspsscopstats (new to 2.0)

dspsvcparm (new to 2.0)

mkfs

smgrDataShow

softswitch

switchback

telnet (new to 2.0.12)

uplmi

users

Changed Commands

The commands that changed in this release by being executed on a different board, by requiring different parameters, or by having different keywords are not listed here. See individual commands in the Command Reference manual for details.

Some commands have been renamed. In Release 2.1.00:

dspspvclog was renamed dspcons-dbg

passwd was renamed cnfpasswd

dsppwd was renamed dsppasswdreset

cnfspvclog was renamed dbgcon

Removed Commands

The following commands were removed from version 2.1.00:

addln—removed from AXSM

addmaster (obsolete)

addslave (obsolete)

clrxbaralms (removed from Releases 2.0 and 2.1)

cnfifip (obsolete)

cnfxbaradmin (obsolete)

delln—removed from AXSM

dspifip (obsolete)

dspnddebug

dspshelfalm (obsolete)—pre-empted by dspenvalms

dspslotalms

dspxbaralms (removed from 2.0)—the singular command, dspxbaralm, remains

formatdisk

hmkfs

offdiagcstat

shutdisk

syncdisk

Upgrading to a New Software Release

This section contains installation and upgrade instructions. For complete details, refer to the MGX 8850 Switch Software Configuration Guide that shipped with your system. Also see the "Related Documentation" section of these notes for a list of the new documentation that supports Release 2.1.00.

Upgrade Procedure Overview

When upgrading your node, upgrade the software in the following order:

1. PXM45 boot software

2. PXM45 runtime software

3. AXSM boot software

4. AXSM runtime software

5. RPM boot software

6. RPM runtime software


Note If you are falling back from the new revision to the older revision, always fall back on the service modules first, then fall back on the processor card.


PXM45 Upgrades

Upgrading the Boot Software for a Redundant PXM45 Pair


Step 1 Type sh to go to the shellconn on Standby PXM45 card.

Step 2 Issue the sysBackupBoot command. This will cause the standby PXM card to reset and come up with the backup prompt.

Step 3 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().The sysPxmRemove() command will prevent the active PXM card from resetting the PXM that is in backupboot mode.

Step 4 Issue the sysFlashBootBurn "filename" command where the filename includes the full path.

sysFlashBootBurn "C:FW/pxm45_002.001.000.000_bt.fw"

Enter y to confirm to burn new boot. Wait for the new back up boot to be burnt onto the card and the pxm45backup prompt to re-appear.


Step 5 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the Standby state.

Step 6 Perform a switchcc. When the formerly Active card comes up in the Standby state, upgrade its boot code by following steps 1-5 above.


Note It is a valid configuration to be running the old runtime software with the new boot software.


Upgrading the Runtime Software for a Redundant PXM45 Pair


Step 1 Use the loadrev command to load the 2.1.00 software on the standby card.

loadrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: loadrev 7 2.1(0.0)

This will cause the standby PXM card to reset and come upin the Standby state with the new software version. Both the active and the standby PXM cards will indicate a U state (for example: Active-U and Standby-U), indicating that the cards are being upgraded.


Note We can abort the revision using the abortrev command. When we use the abortrev command after the loadrev command, only the standby PXM card that has been upgraded will be reset and come back to Standby ready with the Old revision. Abortrev after a loadrev will not reset the node.


Step 2 After the standby card comes back up with the new software in the Standby-U state, use the runrev command to upgrade the node to the new version. This command will cause the standby card upgraded in Step 1 to take over as the active card, and cause the previously active card to reset and come back in the Standby state with the new software version.


Note Once a runrev command has been issued, we can use an abortrev command to fall back, but it will cause a reset of the whole node.


runrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: runrev 7 2.1(0.0)

Step 3 After the redundant card comes up in standby, issue the command commitrev to commit your node to the current software release.


Note Once the revision has been committed, there are only two ways to fall back to the older revision in a non-graceful manner. The first is to use the setrev command to set the revision of the node to the older version. The second is to use a restorallcnf command to restore the configuration to the older revision.


commitrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion)

For example: commitrev 7 2.1(0.0)

Upgrading the Boot Software for a Non-Redundant PXM45 Card

The upgrade with a single PXM card will be non-graceful and affect service, because there is no processor redundancy.


Step 1 Type sh to go to the shellconn.

Step 2 Issue the sysBackupBoot command.

Step 3 Hit Return when prompted to do so to stop auto-boot.

Step 4 Issue the sysFlashBootBurn "filename" command, where filename includes the full path.

sysFlashBootBurn "C:FW/pxm45_002.001.000.000_bt.fw"

Enter y to confirm to burn new boot.

Wait for the new back up boot to be burnt oton the card and the pxm45backup prompt to re-appear.

Step 5 Reboot the card by issuing the reboot command. Wait till the card goes to the Active state.


Upgrading the Runtime Software for a Non-Redundant PXM45 Card


Step 1 Use the loadrev command to prepare for 2.1.00 upgrade.

loadrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: loadrev 7 2.1(0.0)

Loadrev will not reboot the card. It will cause Revision Change markers and the card state to be reported as Active-U.


Note The revision change can be aborted using the abortrev command. An abortev after a loadrev will not cause a reset of the single PXM card.


Step 2 Use the runrev command to upgrade the card to new version.

runrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: runrev 7 2.1(0.0)

Runrev will reboot the card. It will cause the node to run the new software version.


Note It will cause the node to be reset and come up with the new software version. The version change can be aborted after a runrev using an abortrev command. This will cause a reset of the node, and the node will come up running the older software version.


Step 3 Use the commitrev command to commit the card to the current release.

commitrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: commitrev 7 2.1(0.0)


Note After the version has been committed, there are only two ways to fall back to the older version in a non-graceful manner. The first is to use a setrev command to set the revision of the node to the older version. The second is to use a restorallcnf command to restore the configuration to the older revision.



AXSM Upgrades

Upgrading the Boot Software for a Redundant AXSM Pair

Issue all commands from the active PXM card.


Step 1 Use the burnboot command to burn the new 2.1.00 boot code onto the standby AXSM card.

burnboot <slot> <version>

The slot number is the physical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion)

For example: burnboot 1 2.1(0.0)

This will cause the standby AXSM card to reset and come back in Standby state with the new boot code.

Step 2 After the standby AXSM card comes back up with the new boot software in the Standby state, use switchredcd to switch over the AXSM cards.

Step 3 After the standby card comes up as Standby, use the burnboot command to burn the new 2.1.00 boot code onto the new standby card.

burnboot <slot> <version>

For example: burnboot 2 2.1(0.0)

This will cause the standby AXSM card to reset and come back in Standby state with the new boot code.


Upgrading the Runtime Software for a Redundant AXSM Pair

Issue all commands from the active PXM card.


Step 1 Use the loadrev command to load the 2.1.00 runtime software on the standby card.

loadrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion)

For example: loadrev 1 2.1(0.0)

This will cause the standby AXSM to reset and come up in the Standby ready state with the new software version. The AXSM pair will indicate a U against their states in the dspcds command to indicate that they are being upgraded.


Note You can abort the new version using abortrev command. If you use the abortrev command after the loadrev command, only the standby AXSM card that has been upgraded will be reset and come back in the Standby state with the current version.


Step 2 After the standby card comes back up with the new software in the Standby-U state, use the runrev command to switchover to the 2.1 release. This command will bring your original standby card to the Active state and cause the formerly active AXSM card to reset and come back up as Standby with the new version.


Note After a runrev command has been issued, we can use an abortrev command to fall back, but it will cause a reset of both the AXSM cards in the redundant pair.


runrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion)

For example: runrev 1 2.1(0.0)

Step 3 After the redundant card comes up in the Standby state, issue the command commitrev to commit your AXSM card pair to the new release.


Note After the new release has been committed for an AXSM card pair, there is only one way to fall back to the older version in a non-graceful manner. Use the setrev command for the AXSM card to set the revision of the card to the older version. A setrev on the card will reset the AXSM pair.


commitrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: commitrev 1 2.1(0.0).

Upgrading Software on a Non-Redundant AXSM Card

These procedures will affect service, because there is no redundancy for the AXSM card.

Upgrading Boot Software for a Non-Redundant AXSM Card


Step 1 Use the burnboot command to burn the new 2.1 boot software onto the AXSM card.

burnboot <slot> <version>

The slot number is the physical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion)

This will cause the single AXSM card to reset and burn the new boot software. The card will come up Active after a reset with the new boot and current runtime software.

For example: burnboot 1 2.1(0.0)

Upgrading Runtime Software for a Non-Redundant AXSM Card


Step 1 Use the loadrev command to load the new 2.1 version on the single AXSM card.

loadrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: loadrev 1 2.1(0.0)

This will cause the revision marker change on the single AXSM card, and the card state will indicate that it is being Upgraded. (You will see Active-U against that card in the dspcds command.)


Note The revision change may be aborted using the abortrev command. An abortev after a loadrev will not cause a reset of the single AXSM card.


Step 2 Use the runrev command to upgrade the single AXSM card to the new version.

runrev <slot> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: runrev 1 2.1(0.0)

This will cause the single AXSM card to reset and come up with the new software version.


Note The software version change can be aborted after a runrev. This will cause a reset of the single AXSM card, and the card will come up running the older version.


Step 3 Use the commitrev command to commit the version change.

commitrev <slot number> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: commitrev 1 2.1(0.0)


Note After the revision has been committed for a single AXSM card, there is only one way to fall back to the older version in a non-graceful manner. Use a setrev command for the AXSM card to set the revision of the card to the older version. A setrev on the card will only reset the AXSM card.


Aborting the Revisions for Both the PXM Cards and AXSM Cards

The abortrev command can be used to abort the revision that the card has been upgraded to.


Note Abortrev can be used only after a loadrev and a runrev command. Abortrev cannot be used after a commitrev.


abortrev <slot> <version>

The slot number is the logical slot.

The version is MajorVersion.MinorVersion(MaintVersion.PatchVersion).

For example: abortrev 1 2.1(0.0)


Note Read the note in each section about the effect of the abortrev command.


RPM Upgrades

Upgrading with 1:N Redundancy

The procedure assumes all RPM cards on the node need to be upgraded.

This is the Primary Upgrade:


Step 1 Execute addred on the PXM card.

Step 2 Execute WR MEM on the RPM card.

Step 3 Modify the active configuration to boot from the new upgrade software.

Step 4 Execute WR MEM again.

Step 5 Execute softswitch, and make the secondary card active.


Note You can make the secondary ready for the upgrade at this moment (see option 1 of the Secondary Upgrade.)


Step 6 Softswitch back to the primary when the primary goes into the standby state.

Step 7 Continue this procedure from step 2 for all remaining primary cards.


To upgrade the secondary card, there are two options. To upgrade with redundancy, proceed. To upgrade without redundancy, skip to "Upgrading Without Redundancy."


Step 1 Execute WR MEM when the secondary is active (after step 6 in above sequence). This will cause the secondary to boot from the new upgrade software when it gets reset in future.

Step 2 After step 7, softswitch from any primary to secondary, execute WR MEM, and softswitch back to the original active card.

Upgrading Without Redundancy


Step 1 Configure the RPM card to store its configuration on the PXM hard disk by <boot config e:auto_config_slot# >.


Note If you do not use this method, you can store the configuration (config) in NVRAM also. If the configuration is too big to store in NVRAM, you will have to compress the configuration before saving it


Step 2 Modify the active configuration to boot from the new upgrade software.

Step 3 Execute WR MEM.

Step 4 Reset the RPM card.


Installation Notes

Upgrade Path

Starting with Release 2.1.00, MGX 8850 supports graceful upgrades from Release 2.0.13 to 2.1.00.

Limitations and Restrictions

RPM-PR can only be function as either an Edge LSR or as an LSC, but not both functions on the same RPM-PR.

Total of (OC12 minus T3) Mbps intrashelf traffic for Cell bus based modules are supported.

Controller ID 2 is reserved for PNNI controller; 3-20 are available or LSC controller.

Support for 3 controllers only (1 for PNNI and 2 for LSC).

Partition ID 1 is reserved for PNNI.

CWM 10.4 support for these features will be supported at a future date.

addred is not allowed between RPM/B and RPM-PR.

To configure redundancy, the Primary and Secondary RPM cards need to be in the Active state.

Removal of the Primary RPM back card does not cause switchover to the Secondary RPM.

The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in Release 2.0 baseline (2.0.10-2.0.13) with PXM45 and PXM45/B is 99.

The Administrator needs to execute "write memory" on the Primary cards after executing addred on the PXM card.

If the Secondary card is redundant to Primary cards "x" and "y", the Administrator cannot delete redundancy for "x" only.

switchcc immediately after executing softswitch can cause problems. We recommend you wait at least 5 seconds after softswitch to initiate a switchcc.

IOS software images on Primary and Secondary cards do not have to be compatible.

If any AXSM cards remain in the INIT state and the PXM45 standby card is reset, the PXM45 standby card will not transit back to the Standby state. This is a DB server limitation.

If the destination address is reachable for both a 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.

SCT can be changed with connections present in this release. However, if service-affecting, the connections will be rerouted.

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

When CWM is connecting to the network, the IP address 10.0.x.x cannot be used for MGX 8850 PXM45 as lnPci address.

For users who would like to add MPLS partition on a port where other partitions have already been added and have set the min-vci value to be 32, there are two options:

After the MPLS controller is added, explicitly add the TDP sig vc using a vpi/vci pair within its partition's resource range.

Do a dnport and cnfpart to move the min-vci to 35 for all partitions on the port.

(CSCdr15911) Changing or reseating the back card several times on the AXSM OC48 card may sometimes cause the front card to reset and cause a loss of service. The PhyTask also gets suspended. To avoid this problem, try not to reseat at the back card too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system up.

If using PXM45B, make sure that "Expanded Memory on PXM45B Enabled" option on the dspndparms screen is disabled. If it is enabled, please follow the procedure in the release notes of the bug CSCdt66970 to disable it.

APS Status Information

(CSCdt17735) If you remove the active back card of an AXSM card with APS configured, in some cases the active line does not switch properly.

(CSCdt45715) In some instances, we have seen swichaps give a wrong or false error saying it failed, but it has actually succeeded. Display shows Warning: Switch Unsuccessful on Line: Due to Some Unknown Reason.

(CSCdt56312) APS switching fails intermittently when executed back-to-back by a script.

Please ensure the APS connector is correctly installed. Refer to the "APS Backplane" section in Chapter 4 of the Cisco MGX 8850 Hardware Installation Guide. This guide shipped with the switch. (See "Related Documentation" for more information.) After you install the assembly, verify that the APS connector is properly installed by using the new CLI command dspapsbkplane.

The current APS design has the APS mux (through the mini-backplane) between the framer and the line. Hence, the processor monitors status of the line after the APS mux. As a result, it also reports and displays the APS status of the line that feeds to it. The following CLIs as well as line LEDs are affected:

dsplns

dspbercnt

LEDs

The lines could be mapped "straight" (i.e., the line of Back Card X, fed to Front Card X and the line of Back Card Y fed to Front Card Y) or "crossed" (i.e., the line of Back Card X fed to Front Card Y and the line of Back Card Y fed to Front Card X.). Typically, when one executes command dspapslns on Card X, one expects Front Card X to show the status of the lines of Back Card X. However, in the current design, one must note that this is true only with the "straight" situation. In the "crossed" situation, dspapslns on Card X will show the status of the lines fed to it (i.e., of the Peer Card Y). As long as one is aware of how to interpret the above CLI commands and LEDs in this situation, everything should be clear.

Q: How does one determine if lines are in a "straight" situation or a "crossed" situation?

A: In card redundancy, initially the Primary card is Active and the Secondary card is Standby, the Working line is from the Primary card and the Protection line is from the Secondary card and the Active Line is the Working Line. If the Primary card is Active and the Active Line is Protection or if the Secondary card is Active and the Active line is Working, we are in a "crossed" situation; if not, we are in a "straight" situation. The dspapslns command shows which line is Active.

Recommendations

The RPM subinterface ID range is 1 - 32767.

We recommend applying the default values for PCR, SCR, and so on to the Control VC. If the values are decreased to a low value, there is a chance that the protocol on the interface (SSCOP or PNNI) will not come up.

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

Important Notes

(CSCdt55154) RPM back card status may be incorrect.

For RPM SPVC dax connections, the slave end must be deleted before the master endpoint.

Changed IOS Commands

PXM1
PXM45

addcon

switch connection

rpmrscprtn

switch partition

atm pvc

pvc


To remove AXSM redundancy (delred), you must remove the Y-red cables before issuing the delred command.

On feeder trunks, confoamseg is required for tstdelay to work. The steps are as follows on PNNI:


Step 1 dpnport <portid>

Step 2 cnfpnportsig <portid> -cntlvc ip

Step 3 cnfoamsegep <portid> no

Step 4 uppnport <portid>


(CSCdt09949) Currently the CLI command "addchanloop" does not store the connection loop state as persistent data. As a result, this loop (ingress and egress) state of a connection will be lost after the following operations:

resetcd

resetsys

dncon followed by upcon

controller resync (dnport followed by upport)

switchredcd

reroute (dnport)

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. MiniVDI is not negotiated by ILMI, so the user should set this parameter same on both nodes.

By default, 900 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.

The database stores the backplane serial number and back card serial numbers. Therefore if cards are moved from one node to other, the console will display "SHM Alert!! Alert!!." In this situation, use the following steps:


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

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

Step 3 Enter shmRecoverIgRbldDisk.


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, thus minimal bandwidth is available for new SPVC connections, there is a condition which 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.

To replace one type of AXSM front card with another type, you must delete all connections, partitions, ports and down lines. If an AXSM card fails, the same type of AXSM card must be installed in its slot.

(CSCdt32198) The dsperr command currently provides proper information only when it is executed on PXM slot. When it is executed on the AXSM slot, the information is incorrect.

Caveats

Open Caveats for MPLS

Table 4 lists known bugs for MPLS in Release 2.1.00.

Table 4 MPLS Bugs in Release 2.1.00

Bug ID
Description
S1Bugs

None

S2 Bugs

None

S3 Bugs
 

CSCds31381

Redistributing external routes from bgp into ospf for a vrf will generate an ospf process. This process will stay active even if redistribution is removed.

S4Bugs
 

CSCdr50215

Symptom: When redistributing VPNV4 BGP routes containing OSPF RT extended community attribute into OSPF, the router may display alignment errors.

Condition: This problem is fixed in 12.1(4) and 12.1(4)E releases. This fix is not included in 12.1(3) and 12.1(3)E releases.

Workaround: No workaround is necessary.

CSCdt27105

Symptom: RPM CPU Utilization Goes High.

Condition: When there more than 1500 connection and There is incoming AIS for all the connection.

Workaround or fix: None


Open Caveats for MGX 8850

Table 5 lists known anomalies in this MGX 8850 software delivery. Included with each is a brief discussion of the problem. A more in depth discussion is available in the release note enclosure of the problem record in Bug Navigator.

Table 5 Open Caveats for MGX 8850 

Bug ID
Description
S1 Bugs
 

CSCdt17735

Symptom: AXSM/B APS; removed the active back card would cause the active front card to reset. Some case the active line did not switch properly.

Condition: AXSM/B OC3 and OC12; 1+1 APS; Bi-Dir; Revert/NonRev.

Removal of the active back card.

Workaround: None

CSCdt45715

Symptom: The APS switches will fail in OC12 caused by spurious interrupts

Condition: None.

Workaround: None.

CSCdt57525

Symptom:APS protection channel stuck in signal fail

Condition: Remove/insert BC caused protection channel stuck in "signal fail"

Workaround: resetcd to active AXSM.

CSCdt59098

Symptom: PXM45A and PXM45B firmware directory syncup times out. Condition:

Occurs when the standby PXM card does not have a copy of the runtime software and tries to download the software from the Active PXM.

Workaround: None

CSCdt61113

Symptom: Data Cell loss when PXM45B becomes active.

Condition: Switchcc to make PXM45B active

Workaround: None

CSCdt61175

Symptom: PXM45B unable to come up in Standby state. SAR errors reported

Condition: Replace a PXM45A standby with PXM45B to bring it up in standby ready state.

Workaround: None

CSCdt62832

Symptom:Connections fail and links go to oneway inside with swithcc followed by resetsys

Condition: switchcc followed by resetsys without standby transitioning to Standby Ready

WorkAround: None

CSCdt63620

Symptom: PXM was dropping 83% of cells when pumped oc12 - T3

Condition: PXM was dropping 83% of cells when pumped oc12 - T3

Workaround: None

CSCdt65453

Symptom: None.

Condition: The ports are stuck in building vc and down in progress after resetsys on peer node.

Workaround: None

S2 BUGS
 

CSCdr91301

Symptom: Upon AXSM reset, ILMI on some ports on the said AXSM may go into 'disabled' state.

Condition: This is a very rare situation and has been observed twice in the past six months of testing.

Workaround: Down the port and re-up the port.

CSCds64781

Symptom: After delred of RPM redundant cards, the previous secondary RPM card comes up with the same configuration of the primary card which it was covering. If the auto_config_slot file for the secondary is present, this problem is not seen.

Conditions: One must do a wr mem when the secondary RPM was active. auto_config_slot# for secondary wasn't present on PXM before an addred.

Workaround: None.

CSCds74565

Symptoms: PNNI node name displayed in dsppnni-node is not the same as command prompt node name.

Conditions: When the newly configured node name is a matching prefix of the old stored node name, the new node name was not written to the disk. So the PNNI node name won't show the correct node name.

Workaround: Clear the old node name by typing a completely different node name and then try the new node name.

CSCds78530

Symptom: Unable to configure the interface policy to any thing other than default values on legacy ports

Condition: Currently there is no support to reprogram the min guaranteed bw, booking factor etc on legacy ports. As a result the qbins cannot be programmed to give some guaranteed bandwidth to specific service types like UBR, TAG etc.

Workaround: None

CSCds86986

Symptoms: AXSM switchover cause all PNNI links on this AXSM go to attempt.

Condition: This problem occurred after resetting an AXSM non-redundant card and followed by several (some times up to 10) consecutive AXSM switchovers on redundant AXSM pairs on other slots of the same node.

Workaround: Do not do consecutive AXSM swichovers. If the problem occurs, the periodic resync between PNNI controller and AXSM will recover the failure.

CSCdt05371

Symptom: Traps were not generated for HD failure during fault insertion testing.

Condition: Hard disk failure was simulated on modified PXMs.

Workaround: None

CSCdt05378

Symptom: Switchover to faulty standby PXM allowed during fault insertion testing

Condition: HD failure was simulated on the standby PXM

Workaround: None

CSCdt05383

Symptom: PXM switchover did not occur when HD failure simulated on active PXM during fault insertion testing

Condition: HD failure was simulated on active PXM

Workaround: None

CSCdt05385

Symptom: No alarms reported when HD failure on active PXM

Condition: HD failure was simulated on active PXM

Workaround: None

CSCdt05387

Symptom: Hexadecimal characters appeared on telnet session and access to system via telnet and console port access was then lost

Condition: HD failure was simulated on active PXM

Workaround: None.

CSCdt06424

Symptom: OC12 AXSM card does not implement REI-L (M1) byte for generation of near-end error counts to far-end system.

Condition:

Workaround: None.

CSCdt11342

Symptom: CLI command (dspcds) in PXM will show RPM is in boot state. But in RPM Console we will be able to see RPM is UP and Running.

Condition: This problem happens when you do switchcc for 40 times. So the RPM lifetime is 40 switchovers. After switchcc, RPM cards show up 'Boot/Active' although they are actually 'Active'.

Workaround: Reset the RPM cards when this happen.

CSCdt11521

Symptom: vsiProcessVxlCommitRsp: no leg, but has Pep error message keep pop up on PXM

Condition: Reset multiple AXSM cards

Workaround: It'll stop generate error message after AXSM comes up

CSCdt16733

Symptom:

1. Failed to switchapsln W->P on OC12 AXSM/A and AXSM/B.

2. Error "ApsDisable()" displayed repetitively.

3. Same failure occurred on OC3 also, but no "ApsDisable()" error.

Condition:

1. Start with AXSM/A and AXSM/A as APS 1+1.

2. Replace the Standby AXSM/A with AXSM/B. (Both FC and BC)

3. Switchred; then replace the 2nd Standby AXSM/A with AXSM/B.

Workaround: Perform delapsln and addapsln to clear the error condition.

CSCdt17313

Symptoms: Switchapsln seems to not be functioning properly.

Condition: After a switchredcd, switchapsln fails for OC-3.

Workaround: None

CSCdt19936

Symptom: Port stuck in building vc

Condition: Power off/on or reset node

Workaround: Issue dnpnport portID then uppnport portID command

CSCdt28752

Symptom: One SPVC went down.

Condition: When PXM switch over took place.

Workaround: Resetsys will bring back the SPVC.

CSCdt28970

Symptom: Allowing addred

Condition: Primary card in mismatch state

Workaround: None.

CSCdt31059

Symptom: Sub-interface addition without specifying link-type results in anomalies.

Condition: Sub-interface should be added without specifying link-type

Workaround: While adding sub-interface always specify subinterface linktype.

CSCdt33717

Symptom: When line is upped with no cable attached, "dspalm" command does not indicate LOS.

Condition: When Model B STM-1 and T3/E3 back cards are used.

Workaround: None

CSCdt38260

Symptom: pnport went into vc failure state

Condition: setrev was executed on AXSM

Workaround: None

CSCdt38628

Symptom: dspbecnt shows wrong info.

Condition: Always.

Workaround: None.

CSCdt43629

Symptom: Sev 4 'Nodal data in disk mismatch with RAM data' message appears in event log

Condition: Clock sources were deleted or re-added and switchcc executed

Workaround: None

CSCdt44668

Symptom: Loading and running new revision and adding a PXM45B card causes ATMIZER errors.

Condition:

Workaround: Unknown.

CSCdt45544

Symptom: issued a switchcc, display log shows error, scmproccardinsertremovemsg unknown slot 23.

Condition: Customer did a switchcc, dsplog shows this error. 08-00137 02/06/2001-18:09:43 SCM-5-UNKNOWN_VALUE tSCM 0x8022442c <scmProcCardInsertRemoveMsg> unknown slot 23 - 24 dropped

Workaround: None

CSCdt45643

Symptom: Route Op Start/Stop messages are dropped incorrectly.

Condition: Unknown

Workaround: None

CSCdt46311

Symptom: AXSM-OC12 stopped working.

Condition: Redundancy was there between two AXSM cards. When it has been attempted to fall back to previous version of firmware by using setrev and burnboot commands. One card stopped working and other card came up active.

Workaround: Reset the card which was not working and then reset the active card in the redundant pair.

CSCdt48260

Symptoms:

1. RPM CPU Utilization might go high.

2. "cc" to RPM might take time.

3. Sub-interface will go up/down.

4. console access to RPM will be slow.

Condition:

If we add more than 300 PVC, with all OAM Managed. Since all the OAM Cells are Process Switched, having more PVCs with OAM-Managed, will increase no. of cells to be handled in process level, which will degrade the performance.

Workaround:

If we need more PVC with OAM Managed, then we have to reduce the OAM Loopback freq. and OAM Retry Freq. If we can make the Loopback Freq. as 60 sec and retry freq as 10 sec, this might solve the problem.

CSCdt49900

Symptom: Active PXM45 got reset.

Condition: When switchredcd was given between to AXSM-OC48s.

Workaround: Unknown.

CSCdt51884

Symptom: Multiple Upgrades can take place at the same time

Condition: Issue loadrev on a set of cards and then do it on the other set

Workaround: None

CSCdt53257

Symptom: Executed testdelay on a connection for multiple times.

Condition: On SPVC connection execute tstdelay multiple times.

Workaround: For successful tstdelay we need to try few times.

CSCdt53959

Symptoms: OC3/MMF 1+1 APS; switchapsln w/Clear failed with "Unknown Reason" after the Back Card was replaced.

Condition: OC3/MMF with 1+1APS setup; Active on Secondary card and Protection line. Remove and replace the active Back Card. Then switchapsln function will fail.

Workaround: First, make sure the Back Card is seated properly and screwed in tightly. Delapsln then Addapsln will clear the error condition most of the time.

CSCdt55154

Symptom: dspcds shows RPM back card as empty.

Condition: When RPM back cards are plugged into the RPM, when RPM is UP and Running.

Workaround: Resetcd will make the back card active.

CSCdt56312

Symptom: APS switching fails intermittently. Sometimes APS won't switch back from P-W, sometimes APS switched okay but false alarm message was display "Warning: Switch Unsuccessful on Line: Due To Some Unknown Reason."

Condition: switchapsln manual(W-P) then Force(P-W)

Workaround: None.

CSCdt56854

Symptoms: OC12 1+1 APS SETUP; switchapsln w/Manual from WLine to PLine failed with "Priority" error. After the Error condition was cleared; switchapsln failed on the local end, but switched from WLine to PLine at the remote end.

Condition: OC12 1+1 APS with Bi-direction configured; Active on Secondary card and WLine. After the WLine Back Card was replaced, and the APS error was cleared.

Workaround: None

CSCdt59174

Symptom: AXSM-OC3 went into Active-F state.

Condition: After switchcc was done on the node.

Workaround: Unknown.

CSCdt60239

Symptom: Switchred on the other side of 1+1 APS produces an ALM on the working line which is presently active line

Condition: Switchred on the far end

Workaround: None.

CSCdt60336

Symptom:

1. You will see drops in Main Interface.

2. Communication between RPM and PXM will be slow, like cc to card will timeout.

3. Console access will be locked.

Condition:

When you send traffic to RPM with smaller PDU size, like 64 byte packets.

Workaround:

There is a limitation on RPM with respect to the number of packets it can handle per sec. Please read the below release notes.

For RPM/B its 150,000 pps

For RPM-PR its 350,000 pps

So if your Packet size is small, so it fits into one ATM cell, then RPM needs handle 365,566 pps. So if you want to increase usage of bandwidth you have increase the PDU size. This will prevent drops.

1.1.32 Version Software Release Notes Cisco WAN MGX 8850, 8230, and 8250 Software With MGX Release 1.1.32, two Route Processor Modules (RPMs) are supported; the RPM/B and the RPM-PR. The RPM/B is a NPE-150 based router card capable of sustaining 150,000 pps. The RPM-PR is an NPE-400 based router capable of sustaining over 350,000 pps.

CSCdt61077

Symptom:

1. You will see drops in Main Interface.

2. Communication between RPM and PXM will be slow, like cc to card will timeout.

3. Console access will be locked.

Condition: When you send traffic to RPM with smaller PDU size, like 64 byte packets.

Workaround:

There is a limitation on RPM with respect to the number of packets it can handle per sec. Please read the below release notes. For RPM/B its 150,000 pps For RPM-PR its 350,000 pps. So if your Packet size is small, so it fits into one ATM cell, then RPM needs handle 365,566 pps. So if you want to increase usage of bandwidth you have increase the PDU size. This will prevent drops.1.1.32 Version Software Release Notes Cisco WAN MGX 8850, 8230, and 8250 Software With MGX Release 1.1.32, two Route Processor Modules (RPMs) are supported; the RPM/B and the RPM-PR. The RPM/B is a NPE-150 based router card capable of sustaining 150,000 pps. The RPM-PR is an NPE-400 based router capable of sustaining over 350,000 pps. The RPM-PR will only operate with IOS 12.1(5.3)T_XT or later. For the following section "RPM" will refer to both the RPM/B and the RPM-PR, (unless specifically called out) even though some software versions and limitations are not applicable to the RPM-PR because it doesn't support IOS versions before 12.1(5.3)T_XT.

CSCdt61925

Symptom: AXSM-OC3 went into Active-F state.

Condition: When the node was upgraded from one build to another build.

Workaround: None

CSCdt64272

Symptom: PXM45B did not come up as standby.

Condition: When PXM45B was inserted in standby slot.

Workaround: None.

CSCdt64482

Symptom: There is a switch failure at times.
Condition: This is a known problem
Work around: 1+1 uni directional mode seems to work for inter and intra card APS. problems are seen in 1+1 bi directional case.Revertive or non -drevertive should not matter.

CSCdt65669

Symptom: Cannot configure the IOS "set" command within the policy-map command.

Condition: None

Workaround: None.

CSCdt66184

Symptom: addcon, dspcons, dspcon, delcon, cnfcon are only available at the CISCO_GP access level.

Condition: Commands are available on AXSMS.

Workaround: You must log in as cisco to access these commands.

CSCdt67969

Symptom: PXM45A resets from init state.

Condition: When resetsys was given on the node.

Workaround: None.

CSCdt70494

Symptom:

1) Dspred shows secondary RPM slot as empty even though Standby - after a switchcc/resetsys/shelf power up.

2) The secondary RPM slots take a long time to come up when the secondary card is coming up after aswitchcc or a resetsys/shelf power up.

Conditions: If for any reason the secondary card is trying to come up (following a reset) after a switchcc/resetsys or a shelf power up.

Workaround: None.

Under such scenario, the RPM card takes a long time to come up. And the calculation is that it waits for 3 minutes X the number of RPM cards present in the node before it comes up as standby/Active.

S3 BUGS
 

CSCdr28284

Symptoms: The CLI required the user to specify whether the connection is PVC or not. This was removed in the bug fix.

Condition: None

Workaround: None

CSCds14722

Symptom: There is no way to display Hmm Error counters from the CLI.

Condition: No command available.

Workaround: None.

CSCds26663

Symptom: Log not complete for path trace due to dropped messages.

Conditions: When path trace is carried out.

WorkAround: None

CSCds38696

Symptom: CLI dspxbaralm and dspxbaralms redundant. dspxbaralm needs to show more information

Condition: dspxbaralm has been removed. Only dspxbaralms command remains.

Workaround: Use other xbar CLIs such as dspxbarstatus,dspxbarmgmt to see the status.

CSCds42187

Symptom: During build of axsmsim-rt, the build displays error related to the APS files.

Condition: This problem happens only for build in the simulation target.

Workaround: None

CSCds42201

Symptom: Standby PXM45 card is in continuous reset loop, all AXSM cards in the shelf are either in Failed state or in reset loop.

Condition: Injecting a hardware failure on SRAM component of Active PXM45 card manually.

Workaround: None

CSCds42505

Symptom: No Major alarm is displayed against AXSM card in card alarms when the card is in Failed state.

Condition: Injecting a hardware failure on SRAM component of Active PXM45 card manually.

Workaround: None

CSCds43093

Symptom: switchcc allowed to be executed when the standby PXM45 card has a hardware failure.

Condition: Injecting a hardware failure on SRAM component of Standby PXM45 card manually.

Workaround: Do not execute switchcc.

CSCds43124

Symptom: Standby PXM45 card hardware failure is not reported correctly.

Condition: Injecting a hardware failure on SRAM component of Standby PXM45 card manually.

Workaround: None

CSCds43165

Symptom: Active and Standby PXM45 card hardware failure is not reported in the event log.

Condition: Injecting a hardware failure on SRAM component of either Active or Standby PXM45 card manually.

Workaround: None

CSCds43560

Symptom: PXM45 card status LED is green, when the card is continuous reset loop.

Condition: Injecting a hardware failure on BRAM component of Active PXM45 card manually.

Workaround: None

CSCds44434

Symptom: An error log is observed in the event log after using the command cnfdiag to attempt to configure online path test diagnostic. This indicates that the attempt to configure the diagnostic was unsuccessful.

Condition: This symptom can occur when an attempt is made to configure the online path test diagnostic on a MGX 8850 switch

Workaround: None.

CSCds46509

Symptom: CLI dspcd <slot #> from PXM shows slightly different version than CLI dspcd done on the AXSM card. The only thing missing is the 'D' at AXSM card version name.

Condition: This problem is seen always if dspcd is done from AXSM. This is not a customer impacting defect.

Workaround: Check the version from PXM. It will show the correct version.

CSCds49422

Symptom: Contrace will not function.

Condition: None.

Workaround: None

CSCds50108

Symptoms: dspcon shows incorrect RIF/RDF values (shifted by +1).

Conditions: When you add or modify abr connection parameters on RPM.

Workaround: None.

CSCds66602

Symptom: Dax Vcc connection fails

Condition: An unrelated VPC partition is deleted

Workaround: None

CSCds66375

Symptom: Dspcd, dspcds, dspbkpl, readid bkpl, recordid bkpl show inaccurate headings.

Condition: Always.

Workaround: None.

CSCds67426

Symptoms: Two PXM45 nodes with one end has primary and secondary clock configured (first node) another end has clocking sources (second node) have been reset. The first node is up before the second node. The PXM45 resync clocks will get NAK from AXSM card. This will cause clock configuration status in not configurable.

A4A.7.PXM.a > dspclksrc

Primary clock type: generic

Primary clock source: 6:1.1:1

Primary clock status: not configured

Primary clock reason: no clock signal

Secondary clock type: generic

Secondary clock source: 6:1.2:2

Secondary clock status: not configured

Secondary clock reason: no clock signal

Active clock: internal clock source switchover mode: non-revertive

Conditions: Anomaly has only occurred when performing resetsys on two nodes at the same time.

Workaround: Reconfigure the clocks with cnfclksrc commands.

CSCds68568

Symptom: AXSM does not go Active after initiating burning of new software

Condition: New software is being downloaded to AXSM. Download takes a very long time.

Workaround: None

CSCds68651

Symptom: It takes 10 minutes to reset AXSM card after QE48 is disabled.

Condition: QE48 is disabled.

Workaround: None.

CSCds70494

Symptom: No error filtering mechanisms.

Condition: Too many errors reported to HMM. The only way to stop this is to disable HMM reporting.

Workaround: None

CSCds73435

Symptom: Residual database information causes AXSM card state to be interpreted incorrectly. An AXSM card inserted into this slot with the residual database may not successfully come up.

Condition: Residual database on the disk can be introduced if the active Pxm card or disk is replaced with an older card or disk that has old data on it.

Workaround: Before replacing an active PXM front card or disk, make sure that there is a saved configuration for that node. After replacing the active PXM front card or disk, restored the saved configuration. Or to verify if there are residual data on the disk, after the node comes up, perform a list file command (eg. ll) on the D:/DB2 directory. For every slot that is reserved, there should be a corresponding subdirectory for that reserved slot (eg. SL7), if there are extra subdirectories for non-reserved slot, these are residual old databases.

CSCds87038

Symptom: dspdiagcnf, dspdiagerr and dspdiagstatus commands do not break after 24 lines.

Condition: Normal Operation

Workaround: None

CSCds87859

Symptom: PNNI links are in attempt, dspsarcnts shows about 50% of PDU's getting CRC and or length errors on any one connection. (can only occur when there is a standby PXM)

Condition: Problem seen after an Upgrade from 2.0 to 2.1 firmware.

Workaround: After the upgrade, use the cnfxbarmgmt command to disable load sharing and then re-enable.

CSCds88784

Symptom: The dspcdalms and dspcds commands show minor and major alarms for AXSM cards. These alarms are for HUMVEE errors that were reported to the CAM, but can not be cleared.

Conditions: In versions 2.0(X) and 2.1(X), there is no way to clear individual card alarms. These alarms are maintained as a summary of all minor and major alarms in the system.

Workaround: Use the resetcd -f command, in order to clear the alarm summary counters. Note: This command will NOT physically reset the card - only the alarm summary counters will be cleared.

CSCds91665

Symptom: Switch partition deletion request is accepted randomly on RPM.

Condition: Multiple Subsequent execution of "no sw par <vpc/vcc> <same-partId> <same-cntrl Id>" cause "%incomplete command" out-put to be displayed.

Workaround: User should be executing deletion request only once and in proper form at i.e., "no switch part <VPC/VCC> <partId> <cntrlId> "

CSCdt04197

Symptom: Service switch does not switch all aps lines

Condition: APS service switch

Workaround: Multiple service switches.

CSCdt05372

Symptom:

Popup messages appeared on CLI

Condition: HD failure was simulated during fault insertion testing

Workaround: None.

CSCdt11986

Symptom: switchapsln allows a user to do a P->W switch option even if the Active line is working.

Condition: Always

Workaround: None.

CSCdt13184

Symptom: In bidirectional APS, if the remote end has done a Lockout of Protection, W->P switch at the local end will fail with "Unknown" Reason

Condition: See above.

Workaround: None.

CSCdt14348

Symptom: Should not have a hard-coded enable password on the standby RPM.

Condition: Only on standby RPM

Workaround: Unknown.

CSCdt16719

Symptom: Pop up message is shown on newly active PXM card

Condition: This problem is found while PXM switch over

Workaround: None

CSCdt19134

Symptom: SPVC connections rerouting fluctuates.

Condition: Execution of resetsys or switchredcd commands on via nodes.

Workaround: None.

CSCdt20890

Symptom: APS configuration allowed in a STM back card in AXSM-OC3 card

Condition: None

Workaround: None

CSCdt23235

Symptom: Pushing the 2 buttons on the front of the PXM45B board does not generate a CORE dump when the card resets.

Workaround: No workaround.

CSCdt26078

Symptom: When executing a cc to a AXSM card, the event log logs a message 'Non-existing CommEp 0xc01b077 has invalid tag 0x????; Expected tag is 0x????.'

Condition: The deletion of an internal communication endpoint is incorrectly issuing the message. It is an annoying but harmless message. There is no other side effect.

Workaround: None

CSCdt26997

Symptom: PNNI link problems, loss of connections

Condition: resetsys caused one of PNNI link went to attempt state one side and OneWayInside in other. Intermittent failure.

Workaround: None

CSCdt27229

Symptom: User tries to delete a virtual port using snmp- wrong error value is seen.

Condition: User tries to delete a virtual port using snmp

Workaround: None

CSCdt27561

Symptom: OC-48 Model/B currently is not supported in Release 2.0 or 2.1.

Condition: Nothing caused this problem. Hardware simply is not backward compatible with the software therefore, the software needs to be enhanced.

Workaround: None

CSCdt30141

Symptom: Logs on console of the standby AXSM card shows "Multi-party conns are not handled .....".

Condition: This was caused by an accidental enabling of trace message level in a devtest software image.

Workaround: None

CSCdt32121

Symptom: Presence of APS mini-backplane installed in MGX node cannot be found with runtime CLI.

Condition: Customer cannot find APS mini-backplane by execution of CLI commands. MGX switch must be physically inspected to determine presence of mini-backplane.

Workaround

None:

CSCdt34859

Symptom: Problems routing connections.

Condition: Problem may be seen after an AXSM switch over.

Workaround: Reset the AXSM card.

CSCdt42209

Symptom: CUT: (cuts) failed to schedule time in cutsProcessAckRecv event log message was recorded

Condition: None

Workaround: None

CSCdt42337

Symptom: After issuing switchredcd, debug output appears as follows: "Error in emUpdateLineAlarmState() call for tca alarms, errCode=-1"

Condition: APS 1+1, AXSM model B.

Workaround: None.

CSCdt43383

Symptom: The setrev on a redundant service module pair with the Primary card missing fails.

Condition: None

Workaround: None

CSCdt43407

Symptom: :Display of the Error message needs to be modified.

Condition: None

Workaround: None

CSCdt43625

Symptom: Allowed to configure redundancy between upper bay and lower bay.

Condition: None

Workaround: None.

CSCdt44579

Symptom: Currently, no customer-friendly tool to display OAM cell count per channel on the AXSM

Condition: None

Workaround: On the AXSM card, set "cnfchandbg" to level=3 and use "dspchandbgcnt" to see the count #8. These counts will not indicate OAM anywhere.

CSCdt45961

Symptom: APS Active in Pline, after switchapsln w/Clear; Active remains on Pline.

Condition: The APS line is configured as Non-revertible.

Workaround: May configure the APS line as Revertible, then the Clear option will switch Pline to Wline.

CSCdt46552

Symptom: When do "dsppnportsig portId", it shows "aini" as the version. Then do "dsppnport portId", it shows port status is "up" and ILMI status is "UpAndNormal".

Condition: For PNNI port with ILMI enabled, if "cnfpnportsig" to "aini" version, then port is still up and ILMI UpAndNormal.

Workaround: None

CSCdt46926

Symptom: dspcd on an AXSM/B card does not show lower back card

Condition: When performed from the controller card.

Workaround: None

CSCdt53778

Symptom: Lockout command on line X will also cause APS switch to Working on lines Y and Z

Condition: AXSM/B APS 1+1. All active lines have APS configured for bidirectional mode. All lines have existing user requests -- the X line has a successful request from W->P, while the Y and Z lines have failed requests from P->W. Once the lockout command is initiated on line X, the Working line becomes the active line (which is correct). However, the two other lines are also affected and go to Working (not correct).

Workaround: None.

CSCdt55215

Symptom: "Vsi_avl_tree_add did not function" message generated.

Condition: When the node was upgraded using setrev.

Workaround: Unknown.

CSCdt55955

Symptom: Currently all the Xtag are interfaces are displayed in the format of RPM Slot.Port

Condition: None

Work-around: None.

CSCdt58554

Symptom: Aps Event log is not clear enough to debug

Condition: Aps events

Workaround: Look at existing APS event log.

CSCdt59893

Symptom: Sessions on AXSM were not being deleted. Type "who" or "users" on the AXSM to see the sessions. Sessions remained even after timeout. Attempt to cc resulted in the error:

Err: cliSmEptWrite(): ssiIpcComEpNameResolve("cli.07.0700911B"): failed

Condition: IPC call to lookup an epid was failing, causing code to free sessions to fail.

Workaround: None

CSCdt59932

Symptom: Runrev for an SM is not prevented even though there were updates to the primary version after loadrev was completed successfully.

Condition: If a Standby PXM rebuilds when upgrade of an SM is in progress and a loadrev is completed followed by a PXM switchover, the new Active PXM (old Standby PXM) wouldn't have kept track of DB updates to primary version. This results in not blocking the runrev when SM's DBs were updated during the upgrades.

Workaround: Avoid PXM switchovers during upgrade of an SM. If there was a PXM switchover and there is a likely chance of SM's DBs were updated after a loadrev is completed, abort the SM's upgrade and restart.

CSCdt60187

Symptom: Switchred on a redundant APS pair takes the working line to Invld state

Condition: Switchred on a redundant APS pair

Workaround: Requires few switchovers.

CSCdt60635

Symptom: UniVersion for self-supporting is displayed as "none" instead of "self".

Condition: When configure the uni port to self-supporting, the command dsppnport output shows "none".

Workaround: To verify the configuration, dsppnportsig can be used to display the configured signalling version


Related Documentation

Table 6 lists the documentation that supports the installation and operation of the MGX 8850 Release 2.1 switch.

Table 6 Related Documentation for the MGX 8850 Switch, Release 2.1

Documentation
Description

Cisco MGX 8850 Routing Switch Hardware Installation Guide, Release 2.1

DOC-7812561=

Provides a detailed description for installing the MGX 8850 switch in a restricted access location.

Cisco MGX 8850 Routing Switch Command Reference, Release 2.1

DOC-7812563=

Describes and lists the user-accessible command line interface (CLI) for the MGX 8850 switch.

Cisco MGX 8850 Routing Switch Software Configuration Guide, Release 2.1

DOC-7812551=

Describes how to configure the MGX 8850 switch.

Cisco MGX 8850 SNMP Reference, Release 2.1

DOC-7812562=

Provides information on all supported Management Information Base (MIB) objects, support restrictions, traps, and alarms for the AXSM, PXM45, PNNI, and RPM Modules.

Cisco MGX Route Processor Module Installation and Configuration, Release 2.1

DOC-7812510

Provides information on initial site preparation, installation, and configuration of the Cisco MGX 8850 Route Processor Module (RPM-PR). Troubleshooting, maintenance procedures, and cable specifications are also provided.


Documentation Corrections

None to report with this release.

Obtaining Documentation

The following sections provide sources for obtaining documentation from Cisco Systems.

Ordering Documentation

Cisco documentation is available in the following ways:

Registered Cisco Direct Customers can order Cisco Product documentation from the Networking Products MarketPlace:

http://www.cisco.com/cgi-bin/order/order_root.pl

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

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

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

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.

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.

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 the following website:

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.

To register for Cisco.com, go to the following website:

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 the following website:

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.