Table Of Contents
Release Notes for Cisco MGX 8950, Software Release 3.0.20
Contents
About Release 3.0.20
Type of Release
Locating Software Updates
Release Note Document Changes
New Features and Enhancements in Release 3.0.20
SPVC Connection Statistics
CLI Configurable Access
Controller Card Mastership Sanity Verification
Serial Bus Path Fault Isolation
Cell Bus Path Fault Isolation and Recovery
Enhancements
Service Class Template File Information
New Commands
System Requirements
Software/Firmware Compatibility Matrix
MGX and RPM Software Version Compatibility Matrix
Additional Notes
Hardware Supported
MGX 8950 Product IDs and Card Types
Limitations, Restrictions, and Notes
Release 3.0.20 Limitations
CLI Configurable Access
Controller Card Mastership Sanity Verification
Serial Bus Path Fault Isolation
Cell Bus Path Fault Isolation and Recovery
Release 3.0.10 Limitations
AXSM Cards
PNNI Limitation
SCT Files
Persistent Topology
Reroute Call Performance Changes
Clocking Limitations
Additional Limitations
Release 3.0.00 Limitations
Maximum Threshold Accuracy for PXM45
Disk Space Maintenance
Non-native Controller Front Card and HDD Card
clrsmcnf Command
APS
Path and Connection Trace
SNTP
Priority Routing
SPVC Interop
Preferred Route
Persistent Topology
AXSM Cards
RPM-PR and RPM-XF Limitations
Restrictions for Release 3.0.20
Restrictions for Release 3.0.10
Restrictions for Release 3.0.00
AXSM Model B Restrictions
Formatting Disks
Saving Configurations
Other Limitations and Restrictions
Clearing the Configuration on Redundant PXM45 Cards
Limitations and Restrictions for 2.1.x
General Limitations, Restrictions, and Notes
Limitations for rteopt via Parallel Links
Important Notes
APS Management Information
Preparing for Intercard APS
Managing Intercard APS Lines
Troubleshooting APS Lines
Installing and Upgrading to Release 3.0.20
Important Upgrade Notes
AXSM/B Cards Running APS
AXSM Cards in Op B Mode and APS Lines
NNI Ports
Manual Clocking
Installation and Upgrade Procedures
Caveats
MGX 8950 Caveats
MGX 8950 Open Caveats in Release 3.0.20
Status of MGX 8950 Caveats Found in Previous Releases
MGX 8950 Resolved Caveats in Release 3.0.20
Known Route Processor Module or MPLS Caveats
MGX-RPM-XF-512 Caveats
Acronyms
Documentation
Related Documentation
Cisco WAN Manager Release 11
Cisco MGX 8850 (PXM45) Multiservice Switch Release 3
Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3
Cisco MGX 8950 Multiservice Switch Release 3
SES PNNI Controller Release 3
Cisco MGX 8830 Multiservice Switch Release 3
Cisco WAN Switching Software Release 9.3
Cisco MGX 8850 (PXM1) Edge Concentrator Switch Release 1
Cisco MGX 8250 Edge Concentrator Switch Release 1
Cisco MGX 8230 Edge Concentrator Switch Release 1
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco.com
Technical Assistance Center
Cisco TAC Web Site
Cisco TAC Escalation Center
Release Notes for Cisco MGX 8950, Software Release 3.0.20
Contents
About Release 3.0.20
These release notes describe the system requirements, new features, and limitations that apply to Release 3.0.20 of the MGX 8950 multiservice switch. These notes also contain Cisco support information.
Release 3.0.20 improves upon the previous 3.0.00 and 3.0.10 Releases for the MGX 8950 by providing enhancements to existing features and capabilities.
These release notes accompany the technical manuals listed in the "Related Documentation" section.
For information about the MGX 8850 (PXM45), MGX 8850 (PXM1E), or MGX 8830 Release 3.0.20, see the Release Notes for Cisco MGX 8850 (PXM45/B and PXM1E) and MGX 8830, Software Version 3.0.20.
Type of Release
Release 3.0.20 is a software release for the MGX 8950 switch.
Locating Software Updates
Please contact your account representative to obtain Release 3.0.20 for the MGX 8950.
Release Note Document Changes
These changes have been made to this document since the Rev. A0, December 11, 2002 revision.
•
Replaced reference to MGX 8830, MGX 8850 (PXM1E and PXM45), and MGX 8950 Command Reference, Release 3, at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/axsm/index.htm with AXSM Software Configuration Guide and Command Reference for MGX 8850 (PXM45) and MGX 8950, Release 3, at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/axsm/index.htm.
•Added syntax for enableaxsmbaps command to clarify usage.
•Added limitation about when configuring virtual interfaces on AXSM cards, that the physical interface must be of the same ATM header type.
New Features and Enhancements in Release 3.0.20
Release 3.0.20 contains these new features:
•SPVC Connection Statistics
•CLI Configurable Access
•Controller Card Mastership Sanity Verification Enhancement
•Serial Bus Path Fault Isolation Enhancement
•Cell Bus Path Fault Isolation and Recovery Enhancement
SPVC Connection Statistics
SPVC connection statistics display the statistics generated for the originator node, and for an MPG node, it displays the statistics for the border nodes. It will show the number of SPVC connections that are successfully routed, number of connections that are failed, and the number of crankbacks initiated and received.
CLI Configurable Access
A new command, cnfcli, has been created to allow administrators to customize the CLI command access levels. An ASCII file with the command names and the corresponding new command access levels is created by an administrator. This file is FTP'ed to the node. This file contains commands for the whole node, irrespective of the card types (one file per system). Then cnfcli is invoked to parse and install the new command access levels.
Controller Card Mastership Sanity Verification
This feature provides checks to validate the hardware mastership states on the active and standby PXM cards. The scope of this enhancement in this release is to detect invalid mastership states, send a trap, and log more information. This feature does not provide any new auto-corrective action when a mastership problem is detected.
Serial Bus Path Fault Isolation
The MGX 8850/8950 currently uses the serial bus for its data path transport. The switching ASICs and Humvee chips on the PXM and Switch Module cards are designed to detect data integrity and chip errors.
When an error is detected on the switching fabric path by either the Service Module cards, or the Switching Fabric card (e.g., PXM45, or XM60) and if the error count exceeds its error threshold, the error is reported to the PXM, and the PXM will take one or more of the following corrective actions:
•shutdown the humvee/switch fabric link that is reporting errors
•switch to a standby switching module
•switch to a standby PXM module
•reset the active switch module (SM)
Table 1 summarizes the enhancements made in this firmware release in isolation and recovery procedures:
Table 1 Enhancements to Isolation and Recovery Procedures
Failure Detection
|
Isolation
|
Recovery
|
Humvee Errors on SM
|
Isolate local Humvee errors before reporting failure to the PXM. Speed up detection/isolation of Humvee SFRAME errors to be less than 10msec versus the current (2+ seconds).
|
Follow current recovery procedure when such an error is detected.
1) Shutdown the link that reported the errors
2) If all links going toward an SM card fails, move the SM slot to degraded mode, and if redundancy is available on that SM, switch the standby SM to be active.
3) If all links reported error on a card, leave the last failed link up.
|
Humvee Errors Reported on the PXM
|
Isolate local Humvee errors before reporting failure to the PXM. Speed up detection/isolation of Humvee SFRAME errors to be less than 10msec versus the current (2+ seconds).
|
Follow current recovery procedure when such an error is detected.
1) Shutdown the link that reported the errors
2) If all Humvee links on the PXM report errors, raise a non-fatal error against the PXM. If PXM redundancy is available, switch to the standby PXM card.
|
Switch Fabric errors
|
Isolate local Switching Fabric errors before reporting failure to the PXM. Speed up detection/isolation of Switching Fabric SFRAME errors to be less than 10msec versus the current (2+ seconds).
|
Follow current recovery procedure when such an error is detected.
1) Shutdown the link that reported the errors
2) If all links going toward an SM card fails, move the SM slot to degraded mode, and if redundancy is available on that SM, switch the standby SM to be active.
3) If all links reported error on a card, leave the last failed link up. (new)
|
Cell Bus Path Fault Isolation and Recovery
The service modules and the controller cards use the Cell Bus for almost all the inter-card communication. One aspect of inter-card communication involves the active controller card periodically polling the service modules to detect service module failures. So, any failure to use the Cell Bus results in major failure in the system. In Release 3.0.20, the firmware has been enhanced to offer better procedures for detection, isolation and limited recovery from the failure of the hardware components that are specific to using the Cell Bus path.
The Cell Bus Path fault is isolated to the PXM if its polling of all Service Modules and the standby controller card in the node fails. Once the fault is isolated to the active PXM, the Active PXM is reset to initiate a switchover and recover from the failure.
Enhancements
The product enhancement requests (PERs) in Table 2 were introduced in Release 3.0.20.
Table 2 List of Product Enhancement Requests in MGX Release 3.0.20
Enhancement Number
|
Purpose
|
2834
|
A dsphotstandby command which, when entered on the AXSM, would check for the readiness of the standby AXSM. This would ensure that a switchover to the standby AXSM would be safe.
|
7419
|
Two new CLI commands, dspportrtcnt and clrportrtcnt, are being added as a way to display the real-time statistics in both ingress and egress directions and to clear these statistics, respectively.
|
Service Class Template File Information
There are no new SCT files for Release 3.0.20.
New Commands
The following commands are new:
•clrimadelay
•clrnodalconstats
•clrportconstats
•clrportrtcnt
•cnfchanstdabr
•cnfcli
•cnfportconstats
•dspadjlnalm
•dspadjlnalmcnt
•dspcdhealth
•dsphotstandby
•dspnodalconstats
•dspportrtcnt
•dsptech
•forcecdnative
•smclrscrn
Please refer to the following manuals for details about commands:
•The MGX 8830, MGX 8850 (PXM1E and PXM45), and MGX 8950 Command Reference, Release 3, available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/cmdref/index.htm
•The AXSM Software Configuration Guide and Command References for MGX 8850 (PXM45) and MGX 8950, Release 3, available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/axsm/index.htm
System Requirements
This section describes software compatible with this release, and lists the hardware supported in this release.
Software/Firmware Compatibility Matrix
Table 3 lists Cisco WAN or Cisco IOS products that are interoperable with Release 3.0.20.
Table 3 MGX 3.0.20 Compatibility Matrix
Product
|
N
|
N-1
|
N-2
|
CWM
|
11.0.10P1
|
11.0.10
|
N/A
|
MGX 8230, 8250, and MGX 8850 (1.x only)
|
1.2.13
|
1.2.02
|
1.1.34/1.1.42
|
MGX 8850, PXM45
|
3.0.20
|
3.0.10
|
2.1.80
|
MGX 8850, PXM1E
|
3.0.20
|
3.0.10
|
3.0.00
|
MGX 8830
|
3.0.20
|
3.0.10
|
3.0.00
|
MGX 8950
|
3.0.20
|
3.0.10
|
2.1.80
|
BPX/IGX
|
9.3.45
|
9.3.42/9.3.36
|
9.2.41
|
BXM FW
|
MFW
|
MFV
|
MFR
|
UXM FW
|
ACJ
|
ACH
|
ABT
|
URM FW
|
XBB
|
XBB
|
XBA
|
MGX 8220
|
5.0.19
|
4.1.12
|
—
|
SES
|
3.0.20
|
3.0.10
|
1.1.79
|
MGX-RPM-PR-256/512
|
12.2(11)T2
|
12.2(11)T1
|
12.2(8)T4
|
MGX-RPM-XF-512
|
12.2(11)YP
|
12.2(8)YP
|
—
|
VISM
|
3.1.00
|
2.2.1
|
—
|
MGX and RPM Software Version Compatibility Matrix
Table 4 lists the software that is compatible for use in a switch running Release 3.0.20 software.
Table 4 MGX 8950 and RPM Software Compatibility Matrix
Board Pair
|
Boot Software
|
Minimum Boot Code Version
|
Runtime Software
|
Latest Firmware Version
|
Minimum Firmware Version
|
PXM45/B
|
pxm45_003.000.020.000_bt.fw
|
3.0.20
|
pxm45_003.000.020.000_mgx.fw
|
3.0.20
|
3.0.20
|
AXSM-1-2488/B
|
axsm_003.000.020.000_bt.fw
|
3.0.20
|
axsm_003.000.020.000.fw
|
3.0.20
|
3.0.20
|
AXSM-16-155/B
|
AXSM-4-622/B
|
AXSM-16-T3E3/B
|
MGX-RPM-PR-256
|
rpm-boot-mz.122-11.T2
|
12.2(11)T2
|
rpm-js-mz.122-11.T2
|
12.2(11)T2
|
12.2(11)T2
|
MGX-RPM-PR-512
|
MGX-RPM-XF-512
|
rpmxf-boot-mz.122-11.YP
|
12.2(11)YP
|
rpmxf-p12-mz.122-11.YP
|
12.2(11)YP
|
12.2(11)YP
|
Additional Notes
The SNMP MIB release for 3.0.20 is mgxmibs3020.tar.
Table 5 shows the various types of APS protocols that are supported on the AXSM/A and AXSM/B cards, and the MGX release that provides the support.
Table 5 APS Protocol Support
Op Mode (APS Protocol)
|
Card Types
|
AXSM/A
|
AXSM/B
|
Op_A mode (GR253)
|
Release 2.1.x and higher
|
Release 2.1.x and higher
|
Op_B mode (GR253, ITU-T Annex A/B)
|
—
|
Release 3.0.00 and higher
|
Hardware Supported
This section lists Product IDs, 800 part numbers, and revision levels for MGX 8950 cards. It also lists MGX 8950 front and back card types, and whether APS connectors are supported.
MGX 8950 Product IDs and Card Types
Table 6 MGX 8950 Front and Back Card Types and Supported APS Connectors
Front Card Type
|
Back Card Types
|
Supports APS Connector (MGX-APS-CON-8950)
|
PXM45/B
|
PXM-HD
|
—
|
PXM-UI-S3
|
—
|
AXSM-1-2488/B
|
SMFSR-1-2488/B
|
Yes
|
SMFLR-1-2488/B
|
Yes
|
SMFXLR-1-2488/B
|
Yes
|
AXSM-4-622/B
|
SMFIR-2-622/B
|
Yes
|
SMFLR-2-622/B
|
Yes
|
AXSM-16-155/B
|
SMB-4-155
|
Yes
|
MMF-8-155-MT/B
|
Yes
|
SMFIR-8-155-LC/B
|
Yes
|
SMFLR-8-155-LC/B
|
Yes
|
AXSM-16-T3E3/B
|
SMB-8-T3
|
—
|
SMB-8-E3
|
—
|
MGX-RPM-PR-256
MGX-RPM-PR-512
|
MGX-MMF-FE
|
—
|
MGX-RJ45-4E/B
|
—
|
MGX-RJ45-FE
|
—
|
MGX-RPM-XF-512
|
MGX-XF-UI
|
—
|
MGX-1GE
|
—
|
MGX-1OC12POS-IR
|
—
|
MGX-GE-LHLX1
|
—
|
MGX-GE-SX1
|
—
|
MGX-GE-ZX1
|
—
|
Limitations, Restrictions, and Notes
This section includes information about limitations, restrictions, and notes pertaining to Release 3.0.20.
Release 3.0.20 Limitations
CLI Configurable Access
•Not all CLI commands are allowed to be changed and a command cannot be changed to CISCO_GP group access level.
•Only the switch software is allowed to generate the binary file. This file has an authentication signature which has to be validated before the file can be used. Any manual changes to the file would make the file void.
•If the binary file becomes corrupted, then the command access levels revert back to the default values during the card bring-up. To recover, repeat the installation process or retain a copy of the binary file and do cnfcli accesslevel install on that service module.
•Currently, command names are verified, but an invalid command name may be parsed and be added to the binary file. However, this invalid name would be ignored later.
•If replication to standby failed, the installation process failed.
•cnfcli accesslevel default restores all command access levels to default for the service module that this command is executed on. It does not remove the binary file and this change is not persistent. If it is executed on the active card of a redundancy pair, the standby card is not affected. When the card is reset and the binary file exists, it will configure from the binary file when it is brought up.
Controller Card Mastership Sanity Verification
•Because the solution provided in this release can only detect and log invalid mastership state transitions, an outage may still occur.
Serial Bus Path Fault Isolation
•The Serial Bus Fault Isolation feature only addresses isolating errors on the local cards. However, when a common error occurs on the switching fabric card, this solution does not address this. As a result, if there is a problem on the PXM card or the XM60, the fault is going to be reported against all cards that detected the symptoms of this problem.
Cell Bus Path Fault Isolation and Recovery
•The isolation procedures can isolate the Cell Bus path involving the QE SAR that is used for polling the Serial Bus based Service Modules (e.g., AXSM, AXSM/B, AXSM-E,) and all the communication with the standby controller card and the Cell Bus Based Service Modules (e.g., FRSM, CESM). These procedures can't isolate the Cell Bus path failures involving ATMizer SAR that is used for the inter-card communication except polling, between the active controller card and the Serial Bus based Service Modules (e.g., AXSM, AXSM/B, AXSM-E).
•The isolation procedures isolate the Cell Bus path failures to the active controller card only. This means, it is determined whether the active controller card has the fault for the inter-card communication over the Cell Bus from the active controller card to the Service Modules and the standby controller card or not. It does not isolate the fault if the active controller card fails to communicate with some cards and successfully communicates with the rest on the Cell Bus.
•There should be at least 2 cards (2 Service Modules or 1 Service Module and 1 standby PXM) for the isolation procedures to be able to isolate the Cell Bus path failures to the active controller card.
•Only the failures detected by periodic polling triggers the isolation procedures. Failures reported from other sources in the system against a Service Module or the standby controller card due to the Cell Bus path failures don't initiate the isolation procedures, and which results in resetting that card against which the failure is reported, even while the active controller card is in the process of isolating the Cell Bus path failures triggered by the polling failures.
•There is no separate trap/alarm generated against the active controller card Cell Bus path when the fault is isolated to the active controller card. Only the event logs will be available that can be used during the manual investigation triggered by the card reset and/or switchover traps.
•If there is no controller card redundancy available, isolating the Cell Bus path failure to active controller card results in outage as the active controller card will be reset.
Release 3.0.10 Limitations
AXSM Cards
•APS is supported on AXSM-1-2488/B after upgrading the card to Release 3.0.00 and up, and enabling the card to operate in the Op B mode.
•When running in the APS Op B mode on an AXSM/B card, EM database corruption messages may be reported on line interfaces. If this situation occurs, use the following shellcon command to refresh the alarm structure (refer to caveat CSCdy24461):
–emRefreshLineState <1-based bay number> <1-based line number>
PNNI Limitation
There is a limitation in the ATM Forum PNNI specification on how the crankbacks are handled by the entry border nodes. If the entry border of a peer group cannot route a call to the destination node and if the cause of blocking was within the peer group, then the entry cranks back to the next higher level (page 246, point b.1.2 in the ATMF PNNI specification). This higher level crankback is translated to a blocked node of the logical group node and so the source node processing this crankback would treat the whole peer group to be blocked. If this entry border node crankback happens on the destination peer group or if it happens on the transit peer group that is the only route to reach the destination node, then the calls will not get routed.
SCT Files
•With the changes for CSCdw80282, you must FTP the SCT files for all the service modules back to the PXM45 controller cards after a clrallcnf command is issued. These files are removed because they are considered to be nodal configuration files and are deleted from the C:/SCT and the F:/SCT directories.
•With the changes for CSCdw80303, the SCT files for all the service modules are saved. The valid SCT files in C:/SCT and F:/SCT and their subdirectories are saved in a zip file along with the other configuration information. When the configuration is restored, the saved SCT files will be copied into the C:/SCT and the F:/SCT directories, and will overwrite any files in those directories.
•Users should not use AXSM SCT files with an SCT ID greater than 255. If a value greater than 255 is used, CWM will not be able to syncup those SCT files.
Persistent Topology
•If the node ID is changed on a remote node, then the new node ID value is automatically saved into the entry corresponding to that remote node on the gateway node. There is no longer a need to manually delete the old node ID value from the gateway node. Note that this behavior is different from Release 3.0.00.
However, if a remote node is downed, the gateway node is reset, the node ID of the remote node is changed, and the remote node is connected to the network again, the gateway node will store the new node ID as a new entry instead of overwriting the old entry with the new node ID. In this situation, the procedure for node ID change stated in the Release Notes for 3.0.00 should be used.
Reroute Call Performance Changes
For better call performance on PXM45/B cards, the following commands need to be issued after the upgrading to Release 3.0.10:
1. cnfnodalcongth -connpendlo 750 -connpendhi 1000
2. cnfnodal congth -setuphi 1000
Then perform the following commands at both ends of the NNI links:
3. confintcongth <physical port> -setuphi 500
4. cnfpnctlvc <physical port> sscop -scr 3000
Note These parameters are recommended only for the PXM45/B cards and not for the PXM45A or the PXM1E cards.
Clocking Limitations
•The clock sources will be requalified when auto-revertive mode is changed using the cnfclksrc command.
•The dspclksrcs command may display status as configuring on the new Active controller card just after a switchover even though the clock sources are configured and latched to one of the clock sources. However, this inconsistency in the display is transient and the display is corrected after few seconds.
•The standby controller card doesn't monitor the uplink clock sources. As a result, the standby controller card doesn't generate alarm if an uplink clock source becomes unlockable. The information showed by the dspstbyclksrcs command may be incorrect for the uplink clock sources on the standby controller card.
•There is no action initiated either on the Active controller card or on the Standby controller card if none of the configured clock sources is good, the time period for the hold-over mode has expired (more then 24 hours since neither primary nor secondary clock source became unlockable) and the local oscillator used for free running is not functional. However, alarms are raised and events are logged under these conditions.
•Once the secondary clock source becomes the active clock source when the primary clock source became unlockable, the primary clock source is not monitored or qualified. As a result, it is not reverted to primary clock source when the primary clock source becomes stable even though auto-revertive mode is enabled. The workaround to get the primary clock source get monitored and relatched is to reconfigure the primary clock source. This will force the primary clock source to be requalified and relatched.
•The controller card attempts to reprogram a clock source on the Service Module(s) if the clock source is configured to be taken from a port on a Service Module when one of the following occurs:
–A Narrow Band Service Module switchover and a clock source is configured to be taken from a port on that Service Module
–A Broadband Service Module switchover
–A port on any Broadband Service Module is administratively upped
–An active Broadband Service Module rebuild is completed
–A Narrowband Service Module has rebuilt and a clock source is configured to be taken from a port on that Service Module. If the controller card fails to reprogram the clock source on the Service Module under the above circumstances, the network clocking hardware on the controller card is deprogrammed to not take the clock source from that Service Module. Under these circumstances, the clock source needs to be reconfigured to reattempt to program the clock source on the Service Module.
Additional Limitations
•Starting with Release 3.0.10, when a hardware card is newly supported in a release, the core clear command should be invoked once because of a CLI limitation. On executing the core command, the display shows the current core as 2 or 3, and the core clear command needs to be executed (refer to caveat CSCdz31938).
•For the MGX 8950, at least two XM60s are needed. One of the XM60s has to be on top, and has to be in slot 9 or 10.
•Currently, an error message is displayed when the primary card is in the standby state and the secondary card is in the active state for 1:1 redundancy. The issue is a design limitation, and the error message "Primary card is not Active" is displayed (refer to caveat CSCdy41074).
•The switchcc command results in requalification of the primary or secondary clock sources if on the newly active card the primary or secondary clock sources were not qualified before switchcc. On the active card, the nonactive clock source is requalified upon executing the switchcc, resetcd, or dnport commands (refer to caveat CSCdx30282).
Release 3.0.00 Limitations
Maximum Threshold Accuracy for PXM45
•There is a limitation regarding the maximum threshold accuracy for the PXM45. The Qbin threshold and VI rate are stored in the form of exponent and mantissa, and some accuracy is lost in expressing the real rate. In testing the thresholds, the lack of accuracy is compounded with both of the Qbin and VI rate (draining rate) and therefore we cannot calculate a exact 100% correct discard rate.
To ensure that the user gets the rate that they have specified, the software configures Qbin depth at the next larger rate which the hardware can support. As a result, ICG and RSD are truncated. In this example, we have the following scenario:
Refer to caveats CSCdw89558, CSCdw85738, CSCdw89101, or CSCdw89123 for more information.
Disk Space Maintenance
•As the firmware does not audit the disk space usage and remove unused files, the disk space in C: and E: drives should be manually monitored. Any unused saved configuration files, core files and firmware files, and the configuration files of the MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards should be promptly deleted manually. Following this procedure allows you to avoid shortage of disk space to successfully store event logs, configuration upload files in the C: drive and the configuration of MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards in the E: drive.
Non-native Controller Front Card and HDD Card
•When a nonnative HDD back card is inserted in the standby controller slot, the firmware does not clean up the drives which have free disk space below 30 percent. When the standby controller card comes up, it needs to be verified whether the contents have been cleaned up.
•When a nonnative HDD back card is inserted in the standby controller slot, the firmware does not clean up the non-auto configuration files in the E:RPM directory. These non-auto configuration files in the E:RPM directory have to be manually cleaned up after the standby controller card becomes ready.
•Due to the checks for nonnative cards, when the controller front or HDD cards are swapped in the same node, the controller card that attempts to come up as active may get reset twice.
•When a nonnative HDD card is inserted into the standby controller slot, verify that after the card becomes ready in the standby controller slot, its hard disk contents are deleted and synchronized the relevant files from the Active card.
clrsmcnf Command
•For the clear service module configuration feature, if there is a controller card switchover before the clear service module configuration operation is complete, the clrsmcnf command needs to be reissued to ensure that the configuration is completely cleared to avoid any incomplete cleanup.
•For the clear service module configuration feature, using the clrsmcnf command may result in discrepancy in the PNNI configuration. For example, some connections may be in the mismatch state.
•If the clrsmcnf command is given with the option to clear the software version for the slot as well, then the card will go into the failed state after the operation is complete.
•While using the clrsmcnf command, the card in the specified slot is not usable until the operation has successfully completed.
•The clrsmcnf command will not work for redundant service modules.
•The clrsmcnf command will not work if an upgrade is in progress.
•If MGX-RPM-PR-256/512 or MGX-RPM-XF-512 is configured as an LSC (Label Switch Controller), execution of clrsmcnf command on those LSC slots will be rejected, as designed.
•The clrsmcnf command does not work if the controller exists for the slot.
APS
•For AXSM-B APS, the back card of the active card must be present for APS to function.
•The new commands dspadjlnalm and dspadjlnalmcnt are now supported on AXSMB.
Path and Connection Trace
•Path trace is not supported on the control port.
•Path trace will not have the accurate information when there is a crankback on the connect path.
•Path and connection trace feature in Release 3.0.00 and higher is not compatible with the path and connection trace available with previous releases.
SNTP
•The CWM MIB is not supported in Release 3.0.00 and higher.
Priority Routing
•Prioritized reroute of SPVCs is not guaranteed, if the SPVCs originate on a signaling port. We might see SPVCs getting routed out-of-order. In-order routing of SPVCs is guaranteed on nonsignaling ports.
•The MGX-RPM-PR-256/512 does not support configuration of routing priority. All RPM mastered SPVCs will be assigned a routing priority of 8 by the PXM.
•Changing the routing priority for DAX connections will not change the priority of the associated pn-cons (SVCs). This is because the SPVCs will not be derouted and rerouted if just the endpoint parameters are changed, and routing priority is an endpoint parameter. Also, because DAX connections are never derouted, even when the UNI port goes down and the rrtcon command is not supported for DAX connections, the routing priority change will never get reflected. The only way for this to get reflected is to use the dncon and upcon commands. Because DAX connections are never derouted, the effect of this limitation is voided.
•Priority routing operates in a best effort manner. This is because of the following reasons:
–Two in-order RELEASEs can still arrive out-of-order at the Master node, if they take two different paths.
–Under congestion scenarios we can expect RELEASEs to be transmitted out-of-order. This is because we do not want to hold up the release of other calls if we are not able to send RELEASEs on one of the interfaces, as it is congested. The calls that we are unable to release could be higher priority calls.
•Lower priority SPVCs can be routed ahead of higher priority SPVCs. This can happen if we have attempted several times to route higher priority SPVCs, but failed. To prevent starvation of lower priority SPVCs, we will start to route lower priority SPVCs and we will get to the higher priority SPVCs at a later point in time.
SPVC Interop
•NNI SPVC Addendum Version 1.0 is not supported.
•PNNI 1.0 Addendum (Soft PVC MIB) is not supported.
•Origination of single-ended spvcs (with -slavepersflag) from RPMs is not supported.
•CC (Continuity Check) is not be available at the slave end of a single-ended SPVC.
•Reporting AIS detection to CWM is not be available at the slave end of a single-ended SPVC.
•The tstdelay command is not be available at the slave end of a single-ended SPVC on a switch.
•The slave end of a single-ended SPVC is not be visible to CWM.
•If single-ended SPVCs are originated from switches, they can only be configured via CLI and not from CWM in the current release.
•Single-end provisioning will not be supported for DAX connections, because no value addition is seen for interoperability.
•SPVC statistics are not available for the slave endpoint of a single-ended SPVC because this endpoint is non-persistent.
•When the persistent slave endpoint of an existing SPVC connection is deleted and the master endpoint is allowed to remain, the connection may get established as a single-ended spvc connection. In this case, CWM will show the connection as Incomplete.
•Override of SVC connections on a VPI due to an incoming SPVP request for that VPI is not supported. The following override options are alone supported:
–spvcoverridesvc
–spvcoverridesvp
–spvpoverridesvp.
Preferred Route
•Upgrading a preferred routing configured connection from any Release 3.0.x will be nongraceful. In a future release, the configuration of the preferred route identifier information for each connection will be supported on the Service Module cards instead of on the PXM controller. During the upgrade, the preferred route identifier information for each connection will be lost and the preferred route identifier needs to be reprovisioned on the Service Module cards. Also, the preferred route table at the PXM controller will be lost. Connections that have already been routed with preferred routing will remain, and there will be no alarms for these connections.
•The preferred routes can be specified only within a PNNI single peer group meaning all the nodes in the preferred route lie within the same peer group.
•All the nodes in the network should be running Release 3.0.00 software to use the preferred route feature.
•All the links specified in the preferred route should be PNNI links.
•If a node in the PNNI network changes its PNNI node ID, the old entry in the persistent topology database in all the nodes in the network need to be deleted. If any of the preferred routes in any nodes in the network contains the changed node as one of the hops, the preferred route(s) must be modified using the new table index (in the persistent topology database) allocated for the changed node.
•If a node in the PNNI network is deleted via configuration commands from the persistent topology database, if any of the preferred routes configured at that node (where the delete command is executed) contains the deleted node as one of the hops, the preferred route(s) must be deleted/modified manually.
•If a node in the PNNI network is removed via physical decommissioning, and if any nodes in the network had some preferred routes that contain the removed node as one of the hops, the preferred route(s) must be deleted/modified manually.
•Due to differences in physical port numbering, non-Cisco nodes can only be the terminating nodes in a preferred route.
•When a connection is routed on a route other than its preferred route and if the preferred route becomes available, the connection would not be automatically derouted to route back to its preferred route. The user has to deroute/reroute by using configuration commands (optrte, rrtcon, dncon/upcon etc.).
•The preferred route configuration is available using only the CLI at the PXM controller. The configuration of the preferred route will be available with the CWM proxy service agent in a future CWM release.
Persistent Topology
•In a mixed network of pre-Release 3.0.00 and 3.0.00 or later nodes, only the node name and the node ID will be shown for a pre-Release 3.0.00 node in the topology database. This is because the feature is not present in pre-Release 3.0.00 nodes.
•If a peer group is made up of physical nodes with pre-Release 3.0.00 release logical nodes, then the information for the logical node will be stored in the topology database, because there is no way to distinguish between physical nodes and pre-Release 3.0.00 release logical nodes. Logical nodes with Release 3.0.00 or later will not be stored in the topology database.
•To delete a node information entry from the topology database, first remove the node itself from the network, either by disconnecting the cables, or downing all the links between that node and the network. Wait for an hour. Then, delete that node from the topology database. This is done because, even if a node is removed from the topology database of all nodes in the peer group, its PTSEs will still be stored in the other nodes until they are flushed from those nodes. This would happen within an hour's time, but it is configurable as a PNNI timer value. If the node is deleted from the topology database within that hour's time, and the node does switchcc/reboot, then it is possible that the node info for that deleted node will be added back into the topology database.
•When the node ID of a node is changed, the old node ID is added back into the topology database as a new node entry. In addition, the old node ID will still be stored in the topology database of all the other nodes in the peer group. In order to delete this entry, wait for an hour so that the PTSEs with the old node ID is flushed from the topology database of all the nodes in the peer group, and then delete the information of the old node ID from the topology database.
•It is possible that the gateway nodes are not in synchronicity in a peer group, and this could happen in many situations. For example, a gateway node is added in a peer group, then a node is deleted from the peer group, and another gateway node is configured, then the information for the deleted node would not be in the second gateway node. Another example is that a node is deleted from one gateway node, but not in another gateway node.
•When you delete a node from the peer group, the node information must be deleted from all the nodes in that PG, even the non-gateway-node nodes. Otherwise, the node information for that deleted node will still be in the non-gateway-node nodes. This could cause inconsistencies later if this node is configured to be a gateway node.
AXSM Cards
•If ER stamping is used, the rate interval does not provide sufficient accuracy to be completely effective. As a result, when an AXSM card is supporting a PNNI link which is congested with mixed CBR/ABR traffic, cells will be dropped. This condition only occurs when ER stamping is enabled and CI is disabled on an AXSM PNNI link, along with CBR/ABR traffic running so as cause congestion on the link.
•It is recommended that the CI/EFCI mechanism be used for rate feedback rather than the ER stamping mechanism, especially if CBR/ABR traffic is expected (refer to caveat CSCdw63829).
RPM-PR and RPM-XF Limitations
Starting with Release 3.0.00, Route Processor Module (RPM) cards have their own release notes. For details on the MGX-RPM-PR-256/512 cards, refer to the Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for MGX Release 1.2.11 and MGX Release 3.0.10 or the Release Notes for Cisco MGX Route Processor Module (MGX-RPM-XF-512) for MGX 8850 (PXM45) Release 3.0.10. These release notes are available online at the following location:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm
The release notes are identified by switch name (for example, MGX 8850 (PXM45), Release 3, Route Processor Module, Release Notes.
Restrictions for Release 3.0.20
No restrictions have been identified.
Restrictions for Release 3.0.10
No restrictions have been identified.
Restrictions for Release 3.0.00
AXSM Model B Restrictions
The enableaxsmbaps command is a PXM CLI command required to turn on additional APS features on AXSM/B cards in Releases 3.0.x and up. By issuing this command, the card operating mode becomes AXSM Op B. This command is required only while upgrading configured cards with Release 3.0.x images. If the AXSM/B cards do not have any configuration and are upgraded with Release 3.0.x, then the card operating mode would be made as AXSM Op B and it is not required to issued the enableaxsmbaps command.
The command has the following syntax:
enableaxsmbaps <primary | secondary slot>
The enableaxsmbaps command should be given after the completion of upgrading to Release 3.0.x. The following requirements are needed to change the card operating mode to AXSM Op B:
•For redundant cards, both the cards should be AXSM/B cards and the image on both cards should be Release 3.0.x and up.
•For non-redundant cards, the card should be an AXSM/B and the image should be Release 3.0.x and up.
Formatting Disks
•The hard disks should not be formatted with the Release 3.0.00 backup boot or runtime firmware. The Release 3.0.00 firmware initializes the disks with DOS File System Version 2.0 where as the earlier 2.x releases use DOS File System Version 1.0. As a result, if the hard disks are formatted with Release 3.0.00 firmware, those disks will become unusable in nodes running Release 2.x firmware. Because Release 3.0.00 firmware is backward compatible, it can use hard disks with DOS File System Version 1.0.
Saving Configurations
•The C disk drive should not be used for saving multiple older configurations, images, and core dumps. The disk space on this drive is needed to save event logs and configurations, and the logs and configurations will not be correctly saved if there is inadequate disk space.
Other Limitations and Restrictions
•PXM disk sync verification will not work if an upgrade is in progress.
•The maximum number of connections supported in Release 3.0.00 is 250K connections with the PXM45/B controller cards.
•Load sharing will not be enabled automatically if upgrading from a lower revision that has load sharing disabled.
•Path and connection trace are not supported between different peer groups.
•On AXSM cards, when configuring virtual interfaces (i.e. VUNI, VNNI, EVUNI, EVNNI), the physical interface must be of all one ATM header type, either UNI or NNI. Keep in mind that the signaling that is applied to a virtual port is independent of the actual virtual port ATM header. The only limit will be that the VPI value must be within the UNI ATM header limitations (0-255).
Clearing the Configuration on Redundant PXM45 Cards
•Due to checks to prevent an inserted card from affecting the system, an additional step may be required when inserting two nonnative PXM45 cards in a shelf. Insert the first PXM45, use the clrallcnf command, and allow this to become active before inserting the second PXM45.
•After using the clrallcnf command, you must clean up old SCT files (refer to caveat CSCdw80282).
Limitations and Restrictions for 2.1.x
This section is extracted from the MGX 2.1.79 release notes. It describes the following issues for Releases 2.1.60 through 2.1.80:
•General limitations, restrictions, and notes
•APS management information and open issues
•Clearing the configuration on redundant PXM45/B cards
General Limitations, Restrictions, and Notes
The following limitations and restrictions apply to this release.
Note For the MGX 8950, references to "AXSM" refer to the AXSM/B cards.
•The 8 port MMF back cards for the AXSM and AXSM/B front cards do not support Y-cable redundancy.
•Presently, the PXM CLI allows for provisioning of a PNNI controller (controller id 2) on any slot in the chassis, but for this release, such provisioning should be restricted to slot 7 only.
•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in this release with the PXM45 card is 99, and for PXM45/B cards it is 192. Of the 192 PNNI interfaces, up to 100 interfaces can be signaling ports. The other 92 interfaces should be non-signaling ports, such as non self-supporting ports.
•AXSM-1-2488/B cards do not have a policing function enabled.
•In Multiple Peer Group (MPG) mode, when one switches over to the standby on a PGL node with three levels, it can take several minutes on the standby card for this PGL to come up and the SVC based RCC to setup. This is normal behavior, because PNNI does not support hot redundancy. For a switchover, the entire PNNI database must be rebuilt. (It is like a reboot for PNNI, even though the active calls are not affected.)
•Trace information captured in the error logs of non-PXM slots (seen with the dsperr -sl <slotnum> command) will not translate addresses in the trace to correct symbolic names. Such files with trace data need to be moved off the system using FTP and forwarded to TAC and engineering.
•Support for three controllers only (one for PNNI and two for LSC). Controller ID 2 is reserved for a PNNI controller; IDs 3 to 20 are available for LSC controllers.
•Partition ID 1 is reserved for PNNI.
•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in this release with PXM45 cards is 99 and PXM45/B cards is 192.
•If an active AXSM card is stuck in the active INIT state, the standby PXM will not go to the standby ready state until the active AXSM goes to a steady state. The steady states are: active ready, failed, mismatch, empty, empty reserved, and standby ready. With redundancy configured, if a standby AXSM card is stuck in a standby init state, with an active AXSM already in a active ready state, the standby PXM will go to the standby ready state without delay. If both AXSMs in the redundancy pair are not in a steady state, then the standby PXM will not go to the standby ready state until one or both of the two AXSM cards are in the active ready state.
•If the destination address is reachable for both an IISP and a PNNI link from the same node, ABR connections will not route. The current routing algorithm will always choose IISP links over PNNI links because it is local. Because IISP does not support ABR connections, the connection setup will fail.
•In this release, a Service Class Template (SCT) can be changed with connections present. However, if the change affects services in use, the connections will be rerouted.
•When CWM is used to manage the network, the IP address 10.0.x.x cannot be used as the LAN address (lnPci) for the switch.
•Caveat CSCdx29956 information—the release note enclosure contains these fields:
–Symptom: Cellbus clock configuration defaults after a power cycle.
–Condition: Set one of the cell bus clock speeds to 42 MHz and power cycle the node.
–Workaround: Re-configure cell bus clock after a node rebuild.
•If there are MGX-RPM-PR-256/512 card(s) in the node, after clrallcnf, the standby controller card takes longer to come up. The more MGX-RPM-PR-256/512 cards in the node, the longer the standby controller takes to come up. This also happens when the standby controller card is coming up, and MGX-RPM-PR-256/512 cards are inserted into slots that were not previously used for MGX-RPM-PR-256/512 cards.
Limitations for rteopt via Parallel Links
This section lists limitations for rteopt via parallel link. Use Figure 1 as you work through the scenarios in this section.
Figure 1 Configuration Example for rteopt via Parallel Link
The configuration for Figure 1 and the scenarios in this section are as follows:
•Link 1 has forward and backward admin weight set to 500 (via cnfpnni-intf).
•Link 2 has forward and backward admin weight set to 1000.
•Link 3 has forward and backward admin weight set to 2000.
•SPVC connection is routed from Node A to Node C (Master endpoint is at Node A) via link 1 and link 2.
Scenario 1: Link 2 is down (for example, by using
