|
Table Of Contents
Release Notes for Cisco MGX 8850 Software Version 2.1.00
New Features in Release 2.1.00
MPLS LSC/LER Support on RPM-PR for MGX 8850-PXM45
Label Switch Controller Redundancy for MPLS Control Plane
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
Upgrading to a New Software Release
Upgrading Software on a Non-Redundant AXSM Card
Aborting the Revisions for Both the PXM Cards and AXSM Cards
Contacting TAC by Using the Cisco TAC Website
Release Notes for Cisco MGX 8850 Software Version 2.1.00
Contents
This document contains the following sections:
•"Software Compatibility" section
•"New and Changed Information" section
•"New Features in Release 2.1.00" section
•"Upgrading to a New Software Release" section
•"Limitations and Restrictions" 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
Software Compatibility
Table 2 lists software and firmware compatibilities.
Table 2 Software Compatibility Matrix
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 TOSAvailable
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
•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
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.
Related Documentation
Table 6 lists the documentation that supports the installation and operation of the MGX 8850 Release 2.1 switch.
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-9883We 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.
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, PIX, 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, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. 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. (0102R)
Copyright © 2001, Cisco Systems, Inc.
All rights reserved.