Table Of Contents
Release Notes for Cisco MGX 8950, Software Release 3.0.10
Contents
About Release 3.0.10
Type of Release
Locating Software Updates
Release Note Document Changes
New Features and Enhancements in Release 3.0.10
MGX-RPM-XF-512 Card
Hardware Features
Software Features
Alarm Filtering
Enhancements
Service Class Template File Information
System Requirements
Software/Firmware Compatibility Matrix
MGX and RPM Software Version Compatibility Matrix
Additional Notes
Hardware Supported
New Hardware in Release 3.0.10
New and Modified Commands
Limitations, Restrictions, and Notes
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
RPM-PR and RPM-XF Limitations
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.10
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.10
Status of MGX 8950 Caveats Found in Previous Releases
MGX 8950 Resolved Caveats in Release 3.0.10
Known Route Processor Module or MPLS Caveats
MGX-RPM-XF-512 Caveats
Acronyms
Documentation
Related Documentation
Cisco WAN Manager Release 11.0.10
Cisco MGX 8850 (PXM45) Multiservice Switch Release 3.0.10
Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3.0.10
Cisco MGX 8950 Multiservice Switch Release 3.0.10
Service Expansion Shelf PNNI Controller Release 3.0.10
Cisco MGX 8830 Multiservice Switch Release 3.0.10
Cisco WAN Switching Software Release 9.3.42
MGX 8850 (PXM1) Multiservice Switch Release 1.2.11
MGX 8250 Edge Concentrator Release 1.2.11
MGX 8230 Edge Concentrator Release 1.2.11
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.10
Contents
About Release 3.0.10
These release notes describe the system requirements, new features, and limitations that apply to Release 3.0.10 of the MGX 8950 multiservice switch. These notes also contain Cisco support information.
Following the improvements to PNNI scaling for the MGX 8950 with Release 3.0.00, Release 3.0.10 enhances the MGX 8950 switch's IP/MPLS abilities by supporting both Label Switch Controller (LSC) and Label Edge Router (LER) functions with the high-performance MGX-RPM-XF-512.
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.10, see the Release Notes for Cisco MGX 8850 (PXM45/B and PXM1E) and MGX 8830, Software Version 3.0.10.
Type of Release
Release 3.0.10 is a hardware and software release for the MGX 8950 switch.
Locating Software Updates
Please contact your account representative to obtain Release 3.0.10 for the MGX 8950.
Release Note Document Changes
These changes have been made to this document since the Rev. B0, October 24, 2002 revision.
•
Fixed typographical errors.
•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.10
Release 3.0.10 contains these new features:
•MGX-RPM-XF-512 Card
•Alarm Filtering
MGX-RPM-XF-512 Card
MGX-RPM-XF-512 is the next generation RPM card based on Cisco Patented Parallel Express forwarding (PXF) technology. Service Provider customers can use MGX-RPM-XF-512 to IP enable their FR/ATM infrastructure to provide high touch services like IP VPNs using MPLS with line rate quality of service (QoS). The MGX-RPM-XF-512 Gigabit Ethernet module can play a key role in service provider networks providing Metro Ethernet services in conjunction with Cisco ONS 15454.
Hardware Features
The MGX-RPM-XF-512 card has the following hardware features:
•Full height serial line based router module.
•Dual OC-24 ATM SAR.
•1-port Gigabit Ethernet back card support per MGX-RPM-XF-512 front card.
•1-port OC-12 POS back card support per MGX-RPM-XF-512 front card.
•One MGX-RPM-XF-512 front card can only support either the Gigabit Ethernet (GE) or Packet over SONET (POS) back card but not both at the same time in the initial release.
•High-speed back card is supported in the upper half of the shelf.
•Console back card with two FE ports for management traffic is supported only in the lower half of the chassis.
Software Features
The MGX-RPM-XF-512 card has the following software features:
•Edge LSR functions.
•Label Switch Controller.
•1:N Redundancy.
Note Only RPMs of the same card type are supported in a redundancy group.
•MPLS Class of Service. (Low Latency queueing, Diffserv support, WFQ/CBWFQ, Modular QoS CLI)
•Frame-based MPLS and cell-based MPLS support.
•PNNI SPVC/SPVP connection management.
•ATM COS such as VBR-nrt, VBR-rt, and UBR.
•Full IP Routing suite - RIPv2/OSPF/ISIS/BGP.
•Support for IP multicast.
•PPP services. PPPoA
•VLAN-802.1Q support with 802.1Q to MPLS VPN mapping.
The MGX-RPM-XF-512 card is supported on the MGX 8950 switch.
Alarm Filtering
The Alarm Filtering feature works in conjunction with Cisco WAN Manager (CWM) 11.0.10 to display a filtered integrated shelf alarm. The filtered integrated shelf alarm ignores all lines, ports, connections and feeder alarms reported by a given node. When the CWM GUI displays a group of nodes in group mode, the group's integrated alarm is the aggregation of all filtered alarms reported by the nodes in the group, and all trunk/line alarms reported by these nodes.
Enhancements
The product enhancement requests (PERs) in Table 1 were introduced in Release 3.0.10.
Table 1 List of Product Enhancement Requests in MGX Release 3.0.10
Enhancement Number
|
Purpose
|
2291
|
The persistent topology feature provides CWM with a persistent view of the network, regardless of the current operational status of the nodes in the network. Topology information (IP address, node ID, feeder port ID, etc.) is stored in the persistent topology database for each node in the network. If a node is disconnected from the network due to some error scenario (the link went down, the node rebooted, etc.), CWM would still be able to retrieve information about this node from the persistent topology database. Starting with this release, the persistent topology database contains information on the routing and feeder nodes in the network.
|
Service Class Template File Information
There are no new SCT files for Release 3.0.10.
System Requirements
This section describes software compatible with this release, and lists the hardware supported in this release.
Software/Firmware Compatibility Matrix
Table 2 lists Cisco WAN or Cisco IOS products that are interoperable with Release 3.0.10.
Table 2 MGX 3.0.10 Compatibility Matrix
Product
|
N
|
N-1
|
N-2
|
Other Releases
|
CWM
|
11.0.10
|
11.0.00
|
10.5.10 patch 1
|
10.5.10 patch 2, 10.4.10 patch 3
|
MGX 8230, 8250, and MGX 8850 (1.x only)
|
1.2.11
|
1.2.10
|
1.1.42
|
1.1.34
|
MGX 8850, PXM45
|
3.0.10
|
3.0.00
|
2.1.80
|
2.1.76, 2.0.15
|
MGX 8850, PXM1E
|
3.0.10
|
3.0.00
|
—
|
—
|
MGX 8830
|
3.0.10
|
3.0.00
|
—
|
—
|
MGX 8950
|
3.0.10
|
3.0.00
|
2.1.80
|
2.1.76
|
BPX/IGX
|
9.3.42
|
9.3.36
|
9.2.42
|
—
|
BXM FW
|
MFW
|
MFV
|
MFR
|
—
|
UXM FW
|
ACH
|
ACH
|
ABT
|
—
|
URM FW
|
XBB
|
XBB
|
XBA
|
—
|
MGX 8220
|
5.0.18
|
4.1.12
|
—
|
—
|
SES
|
3.0.10
|
3.0.00
|
1.1.75
|
1.0.14
|
MGX-RPM-PR-256/512
|
12.2(13)T
|
12.2(11)T1
|
12.2(8)T4
|
—
|
MGX-RPM-XF-512
|
12.2(11)YP
|
12.2(8)YP
|
—
|
—
|
MGX and RPM Software Version Compatibility Matrix
Table 3 lists the software that is compatible for use in a switch running Release 3.0.10 software.
Table 3 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.010.001_bt.fw
|
3.0.10
|
pxm45_003.000.010.001_mgx.fw
|
3.0.10
|
3.0.10
|
AXSM-1-2488/B
|
axsm_003.000.010.001_bt.fw
|
3.0.10
|
axsm_003.000.010.001.fw
|
3.0.10
|
3.0.10
|
AXSM-16-155/B
|
AXSM-4-622/B
|
AXSM-16-T3E3/B
|
MGX-RPM-PR-256
|
rpm-boot-mz.122-11.T1
|
12.2(11)T1
|
rpm-js-mz.122-11.T1
|
12.2(11)T1
|
12.2(11)T1
|
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.10 is mgxmibs3010.tar.
Table 4 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 4 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.
New Hardware in Release 3.0.10
•MGX-RPM-XF-512 front card, MGX-XF-UI back card, MGX-1GE back card, MGX-1OC12POS-IR back card
MGX 8950 Product IDs and Card Types
Table 8 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
|
—
|
New and Modified Commands
Commands are described in detail in the "Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and MGX 8950 Command Reference, Release 3" located at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/release3/cmdref/mgx3.pdf
Table 9 lists the new commands for Release 3.0.10.
Table 9 New Commands for Release 3.0.10
Command
|
Description
|
clrspvcnonpers
|
Deletes one or more non-persistent SPVC endpoints from a port.
|
cnfsvcoverride
|
Specifies three node-level settings that relate to overriding an SVC's or SVP's ownership of a VPI and VCI (in the case of an SVC).
|
cnftrftolerance
|
Specifies a node-level setting to permit the addition of connections whose traffic parameters may have a slight, unintentional mismatch between the master and slave endpoints.
|
cnfuplinkbert
|
Sets up a BERT for a line on the PXM1E UNI/NNI back card.
|
dspsvcoverride
|
Displays up to three node-level settings that relate to overriding an SVC's or SVP's ownership of a VPI and VCI (in the case of an SVC).
|
dsptrftolerance
|
Displays a node-level setting to permit the addition of connections whose traffic parameters may have a slight, unintentional mismatch between the master and slave endpoints.
|
dspuplinkbert
|
Displays the configuration and current status for BERT on a line on the PXM1E UNI/NNI back card.
|
startuplinkbert
|
Starts a BERT on one of the lines on the PXM1E UNI/NNI back card.
|
stopuplinkbert
|
Stops the BERT that is running on one of the lines on the PXM1E UNI/NNI back card.
|
Table 10 lists the changed commands for Release 3.0.10.
Table 10 Modified Commands for Release 3.0.10
Command
|
Description
|
addcon
|
Add a connection on the PXM1E.
|
cnfpnportcc
|
Configures certain call control parameters for a specific port.
|
cnfstatsmgr
|
Lets you configure multiple statistics managers. Index options 1 through 3 are currently not used (or ignored) by CWM. Index option 4 (Master statistics manager) was added in release 3.0.10. Use Index option 4 to specify the IP address of the statistics master for the switch, which defines the IP address of the workstation authorized to enable or disable statistics on the switch.
|
dspcon
|
Displays priority routing for a nonpersistent endpoint.
|
dspcons
|
Displays priority routing for nonpersistent endpoints.
|
dsppnport
|
Displays priority routing.
|
dsppnportcc
|
Displays certain call control parameters for a specific port.
|
Limitations, Restrictions, and Notes
This section includes information about limitations, restrictions, and notes pertaining to Release 3.0.10.
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.
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 PXM45B 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 PXM45B cards and not for the PXM45A 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 to 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
•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 nonauto configuration files in the E:RPM directory. These nonauto 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
•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.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.
•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 PXM45B 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 the dnpnport command), connections are rerouted right away but Node A has not had that information updated in the routing tables yet.
SPVC on Node A will have routing cost = 2*500 + 2*1000 = 3000, but since link 2 is down, Node B will choose link 3. The routing cost on Node A SPVC is still 3000 as it did the calculation during the route search.
If link 2 is up, if you use a rteopt command on Node A to obtain the new route, and the new path selected has a cost of 3000.
Because SPVC has 3000, it does not reroute through link 2.
Scenario 2: Instead of link 2 being down, if there is a crankback on link 2, the same result stated above occurs.
Scenario 3 (for CBR and VBR): Link selection is set as maxavcr, maxcr, or random on Node B (by using the cnfpnni -selection command) If link 2 has less bandwidth than link 3, and the link selection criteria at Node B is set to maxavcr, Node A will still put the cost as 3000 with least aw calculation, but Node B will choose link 3 (even though it is costlier) because it has more bandwidth.
Scenario 4 (for ABR and UBR): Link selection does not apply to ABR and UBR (by using the cnfpnni -selection command). This is exactly the same as Scenario 3 because ABR and UBR follow load balancing on parallel links instead of choosing the minaw link.
Scenario 5 (for all types of service categories): After call setup, if the admin weight is increased on the link on which the call is routed, the routing cost calculated during the call setup will not get changed. So if a rteopt is done after increasing admin weights on the existing links on the connection path, the connections will not get optimized to take the newer path.
Workaround
If you use the dnpnport command on link 2 (connections will be routed via link 3), after using the uppnport command on link 2, then use the cnfpnni-intf command to change the existing administrative weight on link 2 to a lesser value, for example, 800 (from 1000).
When the optrte command is used at Node A, routing cost will be = 2*500 + 800(fwd) + 1000 (bwd) = 2800 for the new route of link 2.
Because all SPVC connections have 3000 as the routing cost, connections will be rerouted on link 2.
Important Notes
This section provides general notes that apply to this release, and covers some procedures that are not yet in the manuals.
•You must use the SCT files released with Version 2.1.80 (number 2 and 3, which were included in Version 2.0.13 are similar to number 2 and 3 for 2.1.80) for the Control VC feature. If you are using the MPLS feature, then you will need to change to SCT 4 or 5, which were released with Version 2.1.00.
•By default, 2000 cps and 543 cps will be reserved for SSCOP and PNNI Signalling VC respectively, even when you disable SSCOP and PNNI. These values are configurable by the cnfpnctlvc command.
•Do not execute the delcontroller command when connections/ports still exist. The impact of executing delcontroller with connections is that the connections cannot be recovered until the controller is re-added using addcontroller and the AXSM cards or the entire node has to be reset (otherwise ports remain in the provisioning state). There is now a warning to the user of the impact of the command when there are existing connections/ports.
•Analysis of the code has identified a situation which has a low probability of occurring and in fact has not been encountered in any test scenarios to date. This caution and associated workaround is provided as a precautionary measure. When the link bandwidth for SPVC connections is reaching full capacity, making minimal bandwidth available for new SPVC connections, a condition can be encountered where the initial software check believes there is sufficient bandwidth for the new SPVC connection. However, the final software confirmation for available bandwidth may be rejected because there is no bandwidth available. If this problem occurs, the system will recover when the PNNI updates are refreshed. (This will happen at the default time of 30 minutes.) The user can recover from this problem by making the Administrative weight of that link very high to avoid that link from being used.
•When the switch cannot automatically resolve nativity check conflicts, you can force a configuration rebuild from a specific hard disk by establishing a console port session through the corresponding PXM-UI-S3 card and issuing the shmRecoverIgRbldDisk command. This command ignores the nativity check and configures the entire switch according to the configuration on the hard disk.
•PNNI default minimum VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes (for example, 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. Minimum VPI is not negotiated by ILMI, so the user should set this parameter the same on both nodes.
APS Management Information
The following tips apply to the use of the dspapsbkplane command and the APS connector, which is sometimes called a backplane. The APS connector must be installed to enable intercard APS.
The APS dspapsln, dspapslns, switchapsln, and dspapsbkplane commands were modified in release 2.1.70.
Note The dspadjlnalm and dspadjlnalmcnt commands are new to Release 3.0.00. The dspadjlnalmcnt command is supported on AXSM/B.
The APS dspadjlnalm command was new to release 2.1.70. Refer to the Release Notes for MGX 8850 Command Reference for Release 2.1 at the following location for further details about the commands mentioned in these release notes:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r21/index.htm
Note The issues in this section are seen only in Operational mode 1+1, bidirectional, Rev/non-Rev. If at least one side is configured as 1+1 unidirectional, these problems do not occur.
The following are some open issues in this release:
•Reset of active AXSM/A or AXSM/B, removal of active AXSM/A or AXSM/B, or AXSM/A or AXSM/B card switchover may cause the lines behind that card to be in an LOS status for 20ms to 30ms. If these lines were active at the time, some additional APS switch will occur; and the corresponding lines at the far-end will be in SF alarms before the standby AXSM card comes up. The momentary loss of signal is due to the hardware limitation; no other workaround is available. (Refer to caveat CSCdu41763—P-comment and CSCdv01058—Eng-Note for more details.)
Preparing for Intercard APS
The following components are required for intercard APS:
•Two front cards.
•Two back cards for every bay hosting APS lines. All lines on cards used for intercard APS must operate in APS pairs or use Y cables.
•An APS connector installed between the two back cards for every bay hosting APS lines.
Use the dspapsbkplane command on both the standby and active card to verify that the APS connector is plugged in properly. The following example shows the results displayed by the dspapsbkplane command when the APS connector is in place:
M8xx0_NY.1.AXSM.a > dspapsbkplane
Line-ID Primary Card Signal Status Secondary Card Signal Status
Remote Front Card : PRESENT
Bottom Back Card : ENGAGED
The following example shows the results displayed by the dspapsbkplane command when the APS connector is not place:
M8xx0_LA.1.AXSM.a > dspapsbkplane
Line-ID Primary Card Signal Status Secondary Card Signal Status
Remote Front Card : ABSENT
Bottom Back Card : NOT-ENGAGED
Note The dspapsbkplane command should be used only when the standby card is in the Ready state. When the standby card is booting or fails, intercard APS cannot work properly and this command displays NOT ENGAGED.
If the dspapsbkplane command displays the APS Line Pair does not exist message, suspect that the APS is not configured on a line.
If the dspapsbkplane command shows different values for each of the two cards, suspect that the APS connector is seated properly on one card but not on the other.
The APS connector status is the same for all lines in a single bay because the APS connector interconnects two back cards within the same bay. You need to enter the dspapsbkplane command only once to display the APS connector status for both upper and lower bays.
Enter the dspapslns command to verify APS configuration. If the working and protection lines show OK, both lines are receiving signals from the remote note.
Managing Intercard APS Lines
In AXSM/B intercard APS, either front card can be active, and can be connected to either APS line through the APS connector joining the two back cards. The following process describes how intercard APS communication works:
1. The signal leaves the front card at the remote end of the line. (See Figure 2 and Figure 3.)
2. The signal passes through the APS connector and both back card transmit ports at the remote end of the line. (See Figure 2 and Figure 3.)
3. The signal travels through both communication lines to the receive ports on both back cards at the local end. (See Figure 2 and Figure 3.)
4. The active front card processes the signal that is received on the active line. (See Figure 2 and Figure 3.)
5. The standby card monitors only the status of the standby line. (See Figure 2 and Figure 3.)
6. If necessary, the signal passes through the APS connector to the front card. (See Figure 3.)
Note For AXSM/B, the front card monitors both the receive lines.
Figure 2 shows an example of how this process operates in a standard APS configuration, where the primary card monitors the working line and the secondary card monitors the protection line.
Figure 2 Standard APS Configuration
Figure 3 shows an example of how the APS communication process operates in a crossed APS configuration, where the secondary card monitors the working line that is attached to the primary card, and the primary card monitors the protection line that is connected to the secondary card.
Figure 3 Crossed APS Configuration
Line failures are always detected at the receive end of the line. This is where a switchover occurs when a failure is detected. Two different types of switchovers can occur, depending on whether the APS was configured as unidirectional or bidirectional in the cnfapsln command:
•When a failure occurs on a line configured for unidirectional switching, the switch changes lines at the receive end only. A switchover is not necessary at the transmit end because the transmitting back cards send signals on both lines in the 1 +1 APS configuration.
•When a failure occurs on a line configured for bidirectional switching, a switchover occurs at both ends of the line.
If the status of the standby line is good, a switchover from the failed active line to the standby is automatic.
Enter the cnfapsln command to enable an automatic switchover back to the working line after it recovers from a failure, as shown in the following example:
M8xx0_LA.1.AXSM.a > cnfapsln -w 1.1.1 -rv 2
Table 11 describes the configurable parameters for the cnfapsln command.
Table 11 The cnfapsln Command Parameters
Parameter
|
Description
|
-w <working line>
|
Slot number, bay number, and line number of the active line to configure, in the format:
Example: -w 1.1.1
|
-sf <signal fault ber>
|
A number between 3 and 5 indicating the Signal Fault Bit Error Rate (BER), in powers of 10:
•3 = 10-3
•4 = 10-4
•5 = 10-5
Example: -sf 3
|
-sd <SignalDegradeBER>
|
A power if 10 in the range 5 to 9 that indicates the Signal Degrade Bit Error Rate (BER):
•5 = 10-5
•6 = 10-6
•7 = 10-7
•8 = 10-8
•9 = 10-9
Example: -sd 5
|
-wtr <Wait To Restore>
|
The number of minutes to wait after the failed working line has recovered, before switching back to the working line. The range is 5 to 12.
Example: -wtr 5
|
-dr <direction>
|
Determines whether the line is unidirectional or bidirectional.
•1 = Unidirectional. The line switch occurs at the receive end of the line.
•2 = Bidirectional. The line switch occurs at both ends of the line.
Note This optional parameter is not shown in the above example because you do not need to set it for a revertive line.
Example: -dr 2
|
-rv <revertive>
|
Determines whether the line is revertive or non-revertive.
•1 = Non-revertive. You must manually switch back to a recovered working line.
•2 = Revertive. APS automatically switches back to a recovered working line after the number of minutes set in the -wtr parameter.
Example: -rv 1
|
If you want to manually switch from one line to another, enter the switchapsln <bay> <line> <switchOption> <service switch> command, as shown in the following example:
M8xx0_LA.1.AXSM.a > switchapsln 1 1 6
Manual line switch from protection to working succeeded on line 1.1.1
Table 12 describes the configurable parameters for the cnfapsln command.
Table 12 The switchapsln Command Parameters
Parameter
|
Description
|
bay
|
The working bay number to switch.
|
line
|
The working line number to switch.
|
switchOption
|
The method of performing the switchover.
•1 = Clear previous user switchover requests. Return to working line only if the mode is revertive.
•2 = Lockout of protection. Prevents specified APS pair from being switched over to the protection line. If the protection line is already active, the switchover is made back to the working line.
•3 = Forced working to protection line switchover. If the working line is active, the switchover is made to the protection line unless the protection line is locked out or in the SF condition, or if a forced switchover is already in effect.
•4 = Forced protection to working line switchover. If the protection line is active, the switch is made to the working line unless a request of equal or higher priority is in effect. This option has the same priority as option 3 (forced working to protection line switchover). Therefore, if a forced working to protection line switchover is in effect, it must be cleared before this option (forced protection to working line switchover) can succeed.
•5 = Manual switchover from working to protection line unless a request of equal or higher priority is in effect.
•6 = Manual switchover from protection to working line. This option is only available in the 1+1 APS architecture.
|
service switch
|
This is an optional parameter. When set to 1, this field causes all APS lines to switch to their protected lines.
|
Enter the dspapslns command to verify that the active line switched over from the protection line to the working line, as shown in the following example:
M8xx0_LA.1.AXSM.a > dspapslns
Working Prot. Conf Oper Active WLine PLine WTR Revt Conf Oper LastUser
Index Index Arch Arch Line State State (min) Dir Dir SwitchReq
------- ----- ---- ----- ------ ----- ----- ----- ---- ---- ---- ----------
1.1.1 2.1.1 1+1 1+1 working OK OK 5 Yes bi bi ManualP->W
Troubleshooting APS Lines
This section describes the port light behavior changed in Release 3.0.00 as follows:
•Port lights on AXSM /B front cards indicate the receive status of APS lines.
•The active front card always displays the status of the active line.
•The standby card always displays the status of the inactive line. If only one APS line fails, the line failure LED is always displayed on the standby front card.
•Port lights on AXSMB front cards indicate the receive status of the physical line connected to it. For example, when APS is configured for working line as 5.1.3 and protection line as 6.1.3, regardless of which card is active, the port LED on card 5 will show the receive status of 5.1.3 and card 6 will show the receive status of 6.1.3.
Note The remainder of this section is the same as for Release 2.1.80 unless otherwise noted as updated for Release 3.0.10.
Caution When the active front card and the active line are in different slots and the inactive line has failed, it is easy to incorrectly identify the failed line as the line in the standby slot. To avoid disrupting traffic through the active line, verify which physical line is at fault before disconnecting the suspect line.
If the active line fails and the standby line is not available, the switch reports a critical alarm.
If the active line fails and the standby line takes over, the former standby line becomes the new active line, and the switch reports a major alarm.
If an AXSM/A front card fails, APS communication between the redundant front cards fails. This can result in one of the following situations:
•If both APS lines were working before the failure, an APS line failure causes a switchover to the protection line.
•If either APS line failed prior to a front card failure, a failure on the active line does not cause a switchover to the other line. Because the standby front card failed, it cannot monitor the standby line and report when the line has recovered. This means that the active card cannot use the standby line until the standby front card is replaced and the line problem corrected.
Use the following procedure to troubleshoot APS lines:
Step 1 Enter the dsplns command to determine if the line in alarm is an APS line. The dsplns command shows which lines are enabled for APS:
M8xx0_LA.1.AXSM.a > dsplns
Sonet Line Line Line Frame Line Line Alarm APS
Line State Type Lpbk Scramble Coding Type State Enabled
----- ----- ------------ ------ -------- ------ ------- ----- --------
1.1 Up sonetSts12c NoLoop Enable Other ShortSMF Clear Enable
1.2 Up sonetSts12c NoLoop Enable Other ShortSMF Clear Disable
2.1 Up sonetSts12c NoLoop Enable Other ShortSMF Clear Disable
2.2 Up sonetSts12c NoLoop Enable Other ShortSMF Clear Disable
If the line in alarm is an APS line, and has always functioned properly as an APS line, proceed to Step 2.
If the line in alarm has never functioned properly as an APS line, verify that the following are true:
•Redundant front and back cards are in the appropriate bays and are installed at both ends of the line.
•Cable is properly connected to both ends of the line.
•Enter the dspapsbkplane command to verify that the APS connector is installed properly at both ends of the line.
Step 2 Enter the dspapslns command at both ends of the communication line to determine whether one or both lines in an APS pair are bad. Use Table 13 to help you determine which APS line is not functioning properly.
Note Table 13 is updated for Release 3.0.00.
Table 13 Troubleshooting APS Line Problems Using the dspaps Command
Active Line
|
Working Line
|
Protection Line
|
Working Line LED
|
Protection Line LED
|
Description
|
Working
|
OK
|
OK
|
Green
|
Green
|
Active card is receiving a signal on working and protection lines. This does not guarantee that transmit lines are functioning properly. You must view the status on a remote switch.
|
Protection
|
SF
|
OK
|
Green for AXSM/A
Red for AXSM/A
Green for AXSM/B
|
Red
|
Active card is receiving a signal on the protection line. No signal is received on the working line.
|
Working
|
OK
|
SF
|
Green
|
Red
|
Active card is receiving a signal on the working line. No signal is received on the protection line.
|
Working
|
SF
|
SF
|
Red
|
Red
|
Active card is not receiving a signal from either line. The working line was the last line to work.
|
Protection
|
SF
|
SF
|
Red
|
Red
|
Active card is not receiving a signal from either line. The protection line was the last line to work.
|
Working
|
UNAVAIL
|
UNAVAIL
|
—
|
—
|
The card set is not complete. One or more cards have failed or been removed. See Table 14 to troubleshoot card errors.
|
If one or both lines appear to be bad, determine whether the working or protection line is in alarm. Troubleshoot and correct the standby line first. Replace the components along the signal path until the problem is resolved.
•If the dspapslns command at either end of the line indicates a front or back card problem, resolve that problem first. (See Table 14 to troubleshoot card problems).
•If the dspapslns command shows a signal failure on the standby line, replace that line.
•If the standby line is still down, replace the cards along the signal path.
Table 14 Troubleshooting Card Problems
APS Line Failure
|
Possible Cause
|
All lines in upper and lower bays
|
Suspect a bad or removed front card. If both front cards are good, both back cards may be bad.
|
All lines in upper bay only. Lower bay APS lines OK.
|
Suspect bad upper bay back card.
|
All lines in lower bay only. Upper bay APS lines OK.
|
Suspect bad lower bay back card.
|
Installing and Upgrading to Release 3.0.10
For upgrades, the term graceful means the process does not interrupt switch traffic or change the switch configuration.
The MGX 8950 switch can be upgraded to Release 3.0.10 from Release 2.1.76, 2.1.80 or 3.0.00.
Note Starting with Release 3.0.10, CLI commands and shellconn commands can be used to burn the boot images.
Important Upgrade Notes
AXSM/B Cards Running APS
•On upgrading to 3.0.10, the cnfxbarmgmt command has to be issued in the following cases to enable the loadsharing and auto shutdown when it is not enabled by default during the upgrade:
–A nongraceful upgrade from 2.0.x to 3.0.10.
–Upgrading from 2.1.76 or later when load sharing or auto shutdown is manually disabled.
AXSM Cards in Op B Mode and APS Lines
•If the firmware is being upgraded using loadrev/runrev to Release 3.0.10 from Release 3.0.00, the APS lines must be deleted prior to the upgrade if all of the following conditions are met (refer to caveat CSCdy09317).
–APS is operating in the Operating Mode B. This can be verified from the output of the dspcd command on the AXSM card.
–APS lines have been added and none of the APS lines are configured with ITU-T protocol (that is, Annex-B protocol).
•When upgrading from 2.1.80 to 3.0.10 and higher, check that the working and protection lines are free of any line failures prior to issuing the enableaxsmbaps command. Otherwise, the ports can go down. If this problem is encountered, take out the receive part of the line that doesn't have the alarm and re-insert it (refer to caveat CSCdz50925).
NNI Ports
Signaling must be configured on NNI ports prior to upgrading to Release 3.0.00 and higher. Otherwise, for an NNI port with no signaling and ILMI enabled, after upgrading to Release 3.0.00 and higher, the PNNI link will go down.
Manual Clocking
Manual clocking may latch twice when upgrading the PXM45 controller cards from Release 2.1.x to Release 3.0.00 and higher.
Installation and Upgrade Procedures
The procedures to upgrade to Release 3.0.10 appear in "Appendix A, Downloading and Installing Software Upgrades" in:
•Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3 (DOC-7814577=)
•Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3 (DOC-7814248=)
Note For MGX-RPM-XF-512 upgrade information, refer to the Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3.
You can order manuals (see the "Obtaining Documentation" section) or download them from the main Multiservice Switch Documentation site as follows:
Step 1 Go to http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm.
Step 2 Click on the link that matches your product name or configuration, for example:
•MGX 8950
Step 3 Click on Release 3.
Step 4 Click on the Software Configuration Guide or RPM Installation manual.
Caveats
This section provides information about caveats associated with Release 3.0.10 software.
MGX 8950 Caveats
Severity level 1, 2, and 3 caveats are organized in this section as follows:
•"MGX 8950 Open Caveats in Release 3.0.10"
•"Status of MGX 8950 Caveats Found in Previous Releases"
•"MGX 8950 Resolved Caveats in Release 3.0.10"
MGX 8950 Open Caveats in Release 3.0.10
Table 18 lists the Severity 1 open caveats for the MGX 8950 Release 3.0.10 software.
Table 18 Severity 1 Open Caveats for MGX 8950 3.0.10 Software
DDTs Issue
|
Description
|
CSCdt54958
|
Hardware: axsm1
Symptom: OC12 p-p jitter amplitude exceeded the 0.10 UI pp.
Conditions: Unknown.
Workaround: None.
|
CSCdw27075
|
Hardware: pxm45
Symptom: Unable to switchcc to a AXSM card in Y-redundancy configuration. The reason for that is that QE VI threshold has been exceeded and QE is discarding the incoming AAL5 frames. This situation may be met in PXM45A, where SAR overflow may occur (very rare). Note: customer should not let QE SAR overflow occur in PXM45A
Conditions: After a switchredcd on an AXSM card pair in redundant mode.
Workaround: None.
|
CSCdx33812
|
Hardware: pxm45b
Symptom: Xbar planes being shut done on the PXM45B.
Conditions: Xbar errors being reported between slots 3, 7, and 8.
Workaround: None.
|
CSCdx54945
|
Hardware: axsm1b_oc12
Symptom: All external xtags are down. Attempts to switchcc to slot 5 (containing xtag interfaces) failed.
Conditions: Standby PXM in slot 8 in empty reserve state. There are some P1SarErrors reported to the active PXM log.
Workaround: None.
|
CSCdy11654
|
Hardware: pxm45b
Symptom: User can neither "cc" nor "ccc" (high primary) to any slot with an RPM seated in it. "cc" to any other slot containing any other card type succeeds.
Condition: IOS IPC memory buffer leaked for 21 days, zero resource were available for IPC, when this situation occurred. The MGX shelf is operating in simplex mode.
Workaround: "switchcc" with duplex shelf "resetcd" with simplex shelf.
|
CSCdy65077
|
Hardware: axsm1b_oc3
Symptom: Standby AXSM hung for approximately one minute - caused data loss.
Conditions: Upon the execution of the switchredcd on slot #11 to #12.
Workaround: None.
|
CSCdy81906
|
Hardware: pxm45b
Symptom: Slots 1 and 2 rebooted and failed.
Condition: After a burnboot slot #8 and switchcc was executed on the shelf.
Workaround: None.
|
CSCdy81930
|
Hardware: axsm1b_oc12
Symptom: Port failed for over 9 minutes.
Condition: Unknown.
Workaround: None.
|
CSCdy82098
|
Hardware: pxm45
Symptom: Node failed to establish connections, and ports go to building state etc.
Conditions: Heavily populated node with PXM45A cards.
Workaround: Do resetsys.
|
Table 19 lists the Severity 2 open caveats for the MGX 8950 Release 3.0.10 software.
Table 19 Severity 2 Open Caveats for MGX 8950 3.0.10 Software
DDTs Issue
|
Description
|
CSCdt61581
|
Hardware: pxm45
Symptom: Faulty card did not go into continuous reset during Utopia bus parity error failure
Conditions: Utopia bus parity error fault insertion was being undertaken
Workaround: Unknown.
|
CSCdv53825
|
Hardware: pxm45
Symptom: sframetick lock config is lost.
Conditions: When a switchcc is executed on the shelf.
Workaround: None.
|
CSCdx17118
|
Hardware: pxm45
Symptom: Slower and partial reroutes for connections routed over trunks with errors or delay.
Conditions: Introducing delay and bit errors on trunks between peer groups causes connection reroute delays.
Workaround: Unknown.
|
CSCdx57346
|
Hardware: pxm45b
Symptom: Intercard communication is lost between PXM and AXSM cards.
Conditions: User cannot access (CC) other cards in MGX2 chassis. Redundant PXM remains in init state.
Workaround: None.
|
CSCdx89271
|
Hardware: pxm45b
Symptom: The RPM in slot 13 failed to load the primary config file. The RPM recovered in a standby state, with the default config as the running config.
Conditions: The RPM at slot 13 has a 1.3 MB config file. The RPM are configured for 1:n redundancy, with slot 4 covering each slot. The redundant slot (4) did not have a card inserted during the node recovery from the rebuild caused by dip in voltage from the power source.
Workaround: Unknown.
|
CSCdy09052
|
Hardware: pxm45
Symptom: dsphotstandby runs into infinity loop.
Conditions: Do PXM switchover while dsphotstandby is in progress.
Workaround: None.
|
CSCdy22633
|
Hardware: axsm1b_oc3
Symptom: Only on a specific node, and only on a specific slot pair, does the dspcons and dspcons -filt 4 command give syntax error usage information even though the command was correctly entered. Commands provide expected output on other slots in the node, and in the same slots in different nodes, the problem is not seen. Also there is also an error message logged for slot 11 every time the command "dspcons -filt 4" is issued, "cliCallXfunc: xFunc() Parameter validation failed non MIB-based command:".
Conditions: The dspcons command with the filter option had failed due to the presence of connections on a port that did not exist. This could have been caused by two possible scenario: a) the port had disappeared off the port database, b) the connections were "dangling" connections that did not get cleaned up as part of a delete operation. Most of the clues found in the logs point to the latter.
Workaround: The problem is not malignant and does not impact the normal functioning of the switch, a) It does not impact traffic, b) provisioning operation on the node should be possible, c) the port can be re-added if necessary and connections can be provisioned on the port. The only connections that cannot be re-added are those which are dangling in the database. d) The only impact of the dangling connections is that it reduces the number of connections that can be provisioned in the card. The problem can be rectified by deleting the dangling connections on the card.
|
CSCdy24461
|
Hardware: axsm1b_oc3
Symptom: Spurious alarms being reported on AXSM line interface.
Conditions: Unknown.
Workaround: Unknown.
|
CSCdy31818
|
Hardware: pxm45b
Symptom: Getting error message on RPM "% Transmit to PXM Timed out" while executing a few commands on the RPM. Show log in the RPM displays the following message: 00:01:46: rpmrscprtn: Partition VCC:part(0):cntlr(0) Out-Of-Synch (OnlyOnPXM) RPM [(slot=0 ifnum=0 part=0 cntlr=0 status=6): ingr:0 0 egr:0 0 vpi:0 0 vci:0 0 chans:0 0] PXM [(slot=0 ifnum=1 part=0 cntlr=0 status=0): ingr:0 0 egr:0 0 vpi:0 0 vci:0 0 chans:0 0]
Conditions: An AXSM was inserted in place of an RPM. When the RPM was inserted back, some commands were timing out on the RPM with the error message "% Transmit to PXM Timed out"
Workaround: None.
|
CSCdy36366
|
Hardware: pxm45b
Symptom: MPG SPVC cost should include cost of traversing via peer groups.
Conditions: Only includes cost of higher level Hlinks, and source PG cost. Since the via peer group costs are not included, it's possible that we might not take a more optimized route during route optimization.
Workaround: None.
|
CSCdy39198
|
Hardware: axsm1
Symptom: Doesn't set up additional parameter (other than mandatory parameters) during APS Line addition.
Conditions: During APS Line addition through SNMP, send additional parameters (like APS direction).
Workaround: None.
|
CSCdy40247
|
Hardware: axsm2b_oc48
Symptom: OC48B is in Active-F.
Conditions: Unknown.
Workaround: None.
|
CSCdy44965
|
Hardware: pxm45b
Symptom: All AXSMEs failed in the shelf due to Max Card Reset reached.
Conditions: Due to PXM45B resetting in slot #7 for no known reason.
Workaround: None.
|
CSCdy50998
|
Hardware: axsm1b_oc3
Symptom: By doing setrev/resetcd for both the cards, active card on the remote gets reset.
Conditions: Having all the lines configured for APS. This is applicable only for OC3. Description. This is fixed, however after doing the testing of our fix we have found that, if all the lines are unidirectional then problem does not exist. If the lines have bidirectional APS and in particular if the last line i.e. 2.8 is configured for APS then the problem persists. If we have 15 APS lines irrespective of Uni/Bi then our fix works. Only problem we have with the last line with bidirectional APS on other lines.
Workaround: Unknown.
|
CSCdy51734
|
Hardware: pxm45b
Symptom: Standby PXM went to empty state as seen in dspcds or dspcd.
Conditions: None.
Workaround: Issue resetcd on the standby PXM.
|
CSCdy53083
|
Hardware: axsm1b_oc12
Symptom: Core dump on slot #14, AXSM OC12
Conditions: Following a switchcc script running for about 3 days.
Workaround: None.
|
CSCdy53476
|
Hardware: pxm45b
Symptom: All service modules and standby PXM in the node reset/boot continuously.
Conditions: Unknown failure of the standby PXM.
Workaround: Remove the standby PXM and reset the active PXM.
|
CSCdy54351
|
Hardware: pxm45b
Symptom: Slave end persistent SPVC mismatch on frame_discard field between ram and disk; i.e., disk shows for this connection frame_discard is OFF, but ram shows it is ON.
Conditions: A routed persistent SPVC, where master end has frame_discard turned on. Then slave end persistent SPVC will have frame_discard field mismatch between ram and disk.
Workaround: There are 2 ways to workaround: 1) From line card CLI, do upcon/dncon, or cnfcon for the given connection. 2) Switchcc from controller card. This will only fix the first 10 mismatched SPVC connections.
|
CSCdy55759
|
Hardware: pxm45b
Symptom: Executed command "memshow ?" on PXM45 sw revision 2.1(80.0) and console stopped responding to commands.
Conditions: Command "memshow ?" on active PXM45 sw rev 2.2(80.0) caused the console to hang.
Workaround: No workaround at this time. Do not execute the command.
|
CSCdy58998
|
Hardware: pxm45
Symptom: The AXSME available rate shows only 1.
Conditions: sh control VSI descriptor on LSC controllers
Workaround: None
|
CSCdy59180
|
Hardware: pxm45b
Symptom: Once it was observed that 4 SPVC failed to route. This failure was due to slave state of the connections were in wrong state.
Conditions: When large number (250k) of SPVC rerouted.
Workaround: None.
|
CSCdy60873
|
Hardware: pxm45b
Symptom: After resetting the MGX-RPM-XF card, it went to fail state.
Conditions: It happens mostly in the following condition. a) When the SSI chunk pool free pattern was set. (from shellconn, ssiChunkPoolsFillFreePatternSet 1 will enable this)
Workaround: Reset the ssiChunk Pool Free pattern set (if it is enabled already). Do "ssiChunkPoolsFillFreePatternSet 0" to reset this option.
|
CSCdy60873
|
Hardware: pxm45b
Symptom: After reseting the RPM-XF card, it went to fail state.
Conditions: It happens mostly in the following condition. a) When the ssi chunk pool free pattern was set. (from shellconn, ssiChunkPoolsFillFreePatternSet 1 will enable this) b) run ipcMblkShow to see whether this pattern is set or not: If u see "x" in the first column of "FGESSIX...", then this is the case. pxm45>ipcMblkShow ipcMblkShow IPC buffer memory data: ----------------------- Buffer area start: 0xe500000 Buffer area size: 27197440 Free buffer memory: 3133024 Total buffers: 9600 Total mblks: 10100 Floating mblks: 500 Alloc/Free Statistics: ---------------------- Buffers: AllocOk 266766, AllocErr 0, FreeOk 284099, FreeErr 0 Floating Mblks: AllocOk 17565, AllocErr 0, Lwm 462 data nb nb high nb alloc nb free cr iv rc FGESSIX id size chunk free wtMrk ok/fl ok/fl pt pa ev PSVHCSH name ----- ---- ----- ----- ----- -------- -- -------- -- -- -- -- ------- ---- 10002 32 10100 9868 426 284331 0 284099 0 0 0 0 x.xa.xx IPC:Mblks 10003 376 5000 5000 176 202044 0 202044 0 0 0 0 x.xaxxx IPC:Buf_360 10004 1144 2000 2000 11 28069 0 28069 0 0 0 0 x.xaxxx IPC:Buf_1128 10005 4216 600 600 73 6237 0 6237 0 0 0 0 x.xaxxx IPC:Buf_4200 10006 8568 2000 1768 279 30416 0 30184 0 0 0 0 x.xaxxx IPC:Buf_8552 value = 0 = 0x0
Workaround: Reset the ssiChunk Pool Free pattern set (if it is enabled already). Do "ssiChunkPoolsFillFreePatternSet 0" to reset this option.
|
CSCdy61355
|
Hardware: pxm45b
Symptom: XBAR alarms present on the new PXM45b
Conditions: After running the sysFlashBootBurn command to upgrade the shelf.
Workaround: None.
|
CSCdy61622
|
Hardware: pxm45b
Symptom: 1) All AXSM/AXSM-E cards without redundancy go to Active-F state 2) All AXSM/AXSM-E cards with redundancy switched over The AXSM-E cards will switch back and forth between the redundant pair
Conditions: If the active PXM tries to reset the standby PXM and the reset does not go through and it is put to FAILED state
Workaround: Remove the standby PXM which has been put to failed state
|
CSCdy62916
|
Hardware: pxm45b
Symptom: AXSM card in Active-F state as seen with dspcds or dspcd. The dsplog -sl for the failed slot will have a log signature similar to the following (slot 14 in this example): 14A00478 09/12/2002-23:58:06 SHMA-7-NFATAL_MAJ_ERPT E:00240 tCpro shmLocalCdNonFatalMajor shmLocalCdNonFatalMajorErrReport: AppId 0x10007, tId 0x1003c, tName tCpro , Ref. pslot 14, callerPc 0x80328e44, evtNum 0x3034 14A00477 09/12/2002-23:58:06 CPRO-4-RAMDISK_ERR tCpro cProWriteRamDisk RamDisk error : Fopen with lock failed; errno=133896
Conditions: None
Workaround: None
|
CSCdy65143
|
Hardware: pxm45b
Symptom: Executing a dspcon on the PXM45b with an invalid VCI is displaying a connection with a different VCI and other invalid attributes.
Conditions: Executing dspcon with an invalid VCI to display the connection.
Workaround: None.
|
CSCdy68455
|
Hardware: pxm45
Symptom: Traffic was totally stopped on a XF redundancy setup.
Conditions: A simultaneous switchcc and a XF switchover (physically pulling out the active card) was done on the node.
Workaround: None
|
CSCdy69205
|
Hardware: axsm1b_oc3
Symptom: Clock signals not available after APS switch
Condition: If APS lines are switched from working line to protection line on the primary card, clock source for that line becomes unlockable. Basically in APS setup, if the local line is not available (LOS/LOF), clock signals obtained are of range. Clock signals should always be derived from the active line (Working or Protection).
Workaround: Unknown.
|
CSCdy69719
|
Hardware: pxm45b
Symptom: ATMizer failure not handled in active PXM45B.
Condition: When dip switch for fault insertion is turned on spl active HFIT pxm45B board.
Workaround: The fault is detected by standby PXM45B. On active card, there is no workaround.
|
CSCdy70426
|
Hardware: pxm45b
Symptom: 1. The bypasses are not ordered by AvCR. This means that bypasses with smaller bandwidth can be advertised ahead of ones with more bandwidth. However in most cases, the bypasses are advertised as full-meshed instead of spanning tree, so that the ordering of bypasses wouldn't matter, since all the bypasses are advertised. 2. The routing cost is not calculated correctly for via peer groups that are configured as complex nodes. This could affect finding an optimized route in MPG network.
Conditions: The complex node that is turned on a node with a lot of bypasses
Workaround: None.
|
CSCdy70426
|
Hardware: pxm45b
Symptom: 1. The bypasses are not ordered by AvCR. This means that bypasses with smaller bandwidth can be advertised ahead of ones with more bandwidth. However, in most cases, the bypasses are advertised as full-meshed instead of spanning tree, so that the ordering of bypasses wouldn't matter, since all the bypasses are advertised. 2. The routing cost is not calculated correctly for via peer groups that are configured as complex nodes. This could affect finding an optimized route in MPG network.
Condition: The complex node that is turned on a node with a lot of bypasses.
Workaround: None.
|
CSCdy71223
|
Hardware: pxm1e
Symptom: LOA yields inconsistent active clock state in 2 pxm1e nodes.
Conditions: Create an LOA on 2 pxm1e nodes.
Workaround: Unknown.
|
CSCdy71720
|
Hardware: axsm1b_oc12
Symptom: AXSM card switched to the redundant card then reset.
Conditions: When the modified PXM jumper was pulled to simulate a 3.3V power converter failure.
Workaround: None.
|
CSCdy72593
|
Hardware: pxm45
Symptom:
Conditions:
Workaround:
|
CSCdy72688
|
Hardware: pxm45
Symptom: When 'dspdiagstat', counters not updated on FRSM-12-T3E3.
Conditions: Enable online diagnostics.
Workaround: Unknown.
|
CSCdy72711
|
Hardware: axsm1b_oc12
Symptom: AXSM port (with APS) went down after runrev was executed on AXSM.
Conditions: One of the APS lines was in SF.
Workaround: Unknown.
|
CSCdy73536
|
Hardware: axsm1b_oc12
Symptom: dspapslns did not indicate SF condition for Working line that had been disconnected.
Conditions: Rx of Working line had been pulled out.
Workaround: Unknown.
|
CSCdy73536
|
Hardware: axsm1b_oc12
Symptom: dspapslns did not indicate SF condition for Working line that had been disconnected.
Condition: Rx of Working line had been pulled out.
Workaround: Unknown.
|
CSCdy73577
|
Hardware: pxm1e
Symptom: Oam_conn_upoamerr: failed reading ATLAS for connection status.
Conditions: After multiple switchcc.
Workaround:
|
CSCdy73727
|
Hardware: pxm45
Symptom: Unknown.
Conditions: Unknown.
Workaround: Unknown.
|
CSCdy73728
|
Hardware: axsm1b_oc3
Symptom: Some AXSM cards in a node were running default SCTs.
Conditions: System had gone through a reset
Workaround: Unknown.
|
CSCdy74714
|
Hardware: pxm45b
Symptom: Runaway task logged in dsplog after cntl c was issued.
Condition: The cntl c was issued to halt the dumpconfig command which was part of a script that was running on the shelf.
Workaround: None.
|
CSCdy77458
|
Hardware: pxm45b
Symptom: Interface port information pointermessages seen in the dsplog.
Condition: During an upgrade or after a switchredcd is executed.
Workaround: None.
|
CSCdy79315
|
Hardware: pxm45b
Symptom: Unknown control command in output of command execution.
Condition: When the command dspsesn is executed via the CLI.
Workaround: None.
|
CSCdy80802
|
Hardware: pxm45b
Symptom: SRME E1-distribution is not working in AU-4 trib grouping.
Condition: The user is seeing alarms on VISM-PR E1 lines after adding links from TUG3 #2 and #3 groups. Also RDV-V alarm is received in TUG3 #2, #2 group links. The RDI-V alarm is observed on the external Mux (OPM STM1).
Workaround: None.
|
CSCdy80912
|
Hardware: pxm45b
Symptom: PXM45 card got reset 2+ times.
Conditions: Reset AXSM cards, then standby PXM45, then active PXM.
Workaround: None.
|
CSCdy82093
|
Hardware: axsm1
Symptom: cnfln on ds3 AXSM card cause tlb load exception.
Conditions: Execute the command cnfln.
Workaround: Unknown.
|
CSCdy83276
|
Hardware: pxm45b
Symptom: Owner task tMAhandler did not free the memory(free/alloc caller : SarMgmIpcRxBufRet+0xd8.
Conditions: Unknown.
Workaround: Unknown.
|
CSCin19333
|
Hardware: pxm45
Symptom: SNMP requests time out.
Condition: This happens only when the SNMP request is for a RPM-XF card and usually when the card has just come up.
Workaround: None.
|
Table 20 lists the Severity 3 open caveats for the MGX 8950 Release 3.0.10 software.
Table 20 Severity 3 Open Caveats for MGX 8950 3.0.10 Software
DDTs Issue
|
Description
|
CSCdu26141
|
Hardware: pxm45
Symptom: SHM-4_DB_REQ_FAIL messages are logged at severity 4 in the event log. The log entries will look similar to the following: 08-00323 05/15/2001-00:51:31 SHM_-4-DB_REQ_FAIL shmDiskHdl 0x803276b4 SHM ERR: Database request on slot 8 failed, db = rslot, in
Conditions: Consecutive resetcd were executed on the PXMs in this node. This log can be seen under 2 conditions: 1. Under the normal operation of the PXM if this is logged, it is a problem with the communication between 2 tasks that needs to be investigated. 2. During any form of shelf reset like resetsys, abortrev, setrev etc. If this log is seen at around the time a shelf reset is happening, it is not a problem if this log is seen. This will not have any impact at all on the state of the shelf or the state of the configuration on the shelf.
Workaround: None.
|
CSCdu27030
|
Hardware: axsm1
Symptom: OAM CC Activation Cell correlation tag is incorrectly modified.
Conditions: User notes that an F4-Seg Active-CC OAM cell with a correlation tag of 0x6A is returned to the sending device with a correlation tag of 0x00.
Workaround: None.
|
CSCdv50574
|
Hardware: axsm1
Symptom: Incorrect usage statement generated.
Conditions: When the delapsln CLI command is executed.
Workaround: None.
|
CSCdv69323
|
Hardware: pxm45
Symptom: Shelf sends too many messages to CWM.
Conditions: After the execution of switchredcd on the shelf.
Workaround: None.
|
CSCdx34833
|
Hardware: pxm45b
Symptom: Popup message seen on the CLI display.
Conditions: While the shelf was idle and no CLI command where being executed.
Workaround: None.
|
CSCdx62800
|
Hardware: pxm45b
Symptom: MGX45 CLI Reference Manual needs updated.
Conditions: 4 new commands missing out of the manual.
Workaround: None.
|
CSCdx67417
|
Hardware: all
Symptom:
Conditions:
Workaround:
|
CSCdx81165
|
Hardware: axsm1b_oc3
Symptom: Slot 11 does not send out AIS for DAX or Non-DAX SPVCs.
Conditions: When slot #11 is the active slot
Workaround: None.
|
CSCdy10115
|
Hardware: pxm45
Symptom: Spurious event log messages for environmental alarms for DC supply are logged.
Conditions: Unknown.
Workaround: None.
|
CSCdy10480
|
Hardware: pxm45
Symptom: Default 0 SCT is not shown for FRSM-12-T3E3.
Conditions: Execute dspscts/
Workaround: The system will allow the user to configure port and card level SCTs even though the display does not show it.
|
CSCdy23797
|
Hardware: pxm45b
Symptom: pntrace commands not completely documented.
Conditions: MGX CLI Manual versus the troubleshooting guide.
Workaround: None.
|
CSCdy24232
|
Hardware: pxm45b
Symptom: dsplog indicates that a card does not exist. The log will look similar to the following (card 1 in this example): 01460 07/31/2002-18:32:10 SCM-4-NODEST tSCM scmProcDataMsg Card 1 doesn't exist, 105 21
Conditions: After a switchcc is executed.
Workaround: None. Not service impacting.
|
CSCdy25518
|
Hardware: pxm45
Symptom: Switchapsln command can be executed on PXM-45 even though command has no relevance to hardware configuration. No error message is given.
Conditions: Switchapsln can be executed from PXM-45 without user feedback indicating that command is not applicable to hardware configuration.
Workaround:
|
CSCdy29344
|
Hardware: pxm45b
Symptom: The back card removal trap does not contain the back card number. User can not make out which back card is removed.
Conditions: When a back card is removed, trap 60059 will be sent.
Workaround: Look at the dspcd output to find which back card is removed (depending upon the back card status)
|
CSCdy37182
|
Hardware: all
Symptom: dspcd shows lower back card empty for a full height back card.
Conditions: None
Workaround: None. Not service impacting. Display issue.
|
CSCdy53146
|
Hardware: axsm1b_oc12
Symptom: S1 byte for Synchronization Status Messaging not implemented properly.
Conditions: On the AXSMB/OC12, and the AXSMB/STM1
Workaround: None.
|
CSCdy54607
|
Hardware: pxm45
Symptom: PXM command line interface paused indefinitely and would no longer accept commands
Conditions: Occurred after executing the memshow<noCmdBold) command from the command line interface
Workaround: None.
|
CSCdy55782
|
Hardware: pxm45b
Symptom: No consistency in the warning message for invalid login attempts.
Conditions: When attempting to login to the shelf with incorrect User ID and password.
Workaround: None.
|
CSCdy59858
|
Hardware: pxm45b
Symptom: Using inband management, not able to ping pxm1 feeders atm0 address when the PXM45's lnPci0 and atm0 subnet masks are different. The trigger is the deletion of the internal SVC between the AXSM and the PXM. Can be reproduced by doing a dnport/upport on the AXSM port which connects to the management router in the setup shown below: CWM station---ethernet---Router with ATM oc3 interface-----AXSM------PXM45-----AXSM-----PXM1
Conditions: Observed on MGX8850 PXM45 running 2.1.75
Workaround: The problem is in the VxWorks routing table on the PXM45. The IP data to pxm1 first has to traverse PXM45 where it is switched to the AXSM connecting to the pxm1. 1. Switchcc on the PXM45 clears this condition. 2. Making PXM45 re-learn the route to pxm1 clears this issue. This can be done by initiating a telnet from PXM45 CLI to pxm1
|
CSCdy59923
|
Hardware: pxm45b
Symptom: Mounting nfs is not necessary, takes time and resources and can cause conflicts when nfs host is the same as another device.
Conditions: Nfs host is mounted when coming up.
Workaround: None.
|
CSCdy59933
|
Hardware: pxm45
Symptom: Attempt to low level format with diskFormat and ataFormat fails on PXM-HD with the following error: pxm45bkup>diskFormat "C:" IDE: format in progress. This takes a while .........Device abort error .... status is 51 error is 10 Couldn't format "C:". value = -1 = 0xffffffff pxm45bkup>
Conditions: This condition is observed in 2.1 Release when the PXM-HD model is IC25N020ATCS04-0 or IBM-DJSA-205. The HDD model name can be viewed with the command ataShow. cmdBold>More Information: A low level format is not required in the field as these drives come preformatted from manufacturing. Using sysClrallcnf and recreating the file system with sysDiskCfgCreate will help to reinitialize a PXM-HD in the field.
Workaround: None.
|
CSCdy62765
|
Hardware: pxm45
Symptom: Standby PXM reset. The dsplog will look similar to the following example (slot 8 is active, 7 is standby in this example): 08A98502 09/05/2002-16:48:56 SHMA-7-FATAL_ERR_RPT E:00317 pnRedman shmRamSyncFatalErrRepor shmRamSyncFatalErrReport: AppId 0x1000c, tId 0x10054, tName pnRedman, Ref. pslot 7, callerPc 0x807c68e8, evtNum 0x1000 08A98509 09/05/2002-16:48:56 REDM-6-RmRamDbReset pnRedman checkSyncRamResetState Redman receive reset from RAMDB. Reset reason:-2 Note that the AppId, tId, tName could be any application on the node.
Conditions: A RAM sync error triggered the standby PXM reset.
Workaround: None. The standby PXM returned to service following the reset.
|
CSCdy64715
|
Hardware: pxm45
Symptom: ataFormat() fails
Conditions: When using IBM-DJSA-205 disks (Gb)
Workaround: In release 3.0, use ataFormat_20GBversion(). In release 2.1, there is no workaround
|
CSCdy64892
|
Hardware: pxm45
Sometimes: The error message "CPRO-SNMP_ERROR cutW1Task cpro_log_error SNMP error; id = 117; err Connection does not exist in cPro db" appears.
Conditions: MGX45, Version 2.1(80.0)
Workaround: None.
|
CSCdy67817
|
Hardware: axsm1b_oc3
Symptom: PNNI ports went into down in progress state and SPVCs failed during fault insertion testing.
Conditions: Skystone Port 1 secondary in reset (SWC6) and (SWC5) faults were inserted on an active AXSM card.
Workaround: Unknown.
|
CSCdy67817
|
Hardware: axsm1b_oc3
Symptom: PNNI ports went into down in progress state and SPVCs failed during fault insertion testing.
Condition: Skystone Port 1 secondary in reset (SWC6) and (SWC5) faults were inserted on an active AXSM card.
Workaround: Unknown.
|
CSCdy72707
|
Hardware: pxm45
Symptom: 1) All AXSM/AXSM-E cards without redundancy go to Active-F state 2) All AXSM/AXSM-E cards with redundancy switched over. The AXSM-E cards will switch back and forth between the redundant pair.
Condition: If the Active PXM tries to reset the standby PXM and the reset does not go through and it is put to FAILED state.
Workaround: Remove the standby PXM which has been put to failed state.
|
CSCdy73100
|
Hardware: pxm45b
Symptom: Misspelled word in the syntax of the cnfpnni-node output.
Conditions: When viewing the output, the word does is spelled deso.
Workaround: None.
|
CSCdy78372
|
Hardware: axsm1b_oc3
Symptom: Card with Skystone failure came up as active-f and healthy card came up as failed.
Condition: Resetsys was executed with fault present.
Workaround: Unknown.
|
CSCdy78398
|
Hardware: axsm1b_oc3
Symptom: SAR errors not detected by SCM till 3 min.
Condition: Tests consisting of SAR single bit errors were executed on active and standby AXMS cards.
Workaround: Unknown.
|
CSCdy82174
|
Hardware: axsm1b_oc3
Symptom: PNNI ports went into down in progress and SPVCs failed.
Condition: Customer was executing Fault Insertion case "CBC in reset mode" on active AXSM.
Workaround: Unknown.
|
CSCdy82219
|
Hardware: axsm1b_oc3
Symptom: PNNI ports go into provisioning mode and spvcs fail when fault on active card or card switchover allowed to standby card with fault.
Condition: Utopic 2 Bus CBC to ATMIZER bit tx/rx errors inserted on active or standby cards.
Workaround: Unknown.
|
CSCdy82305
|
Hardware: axsm1b_oc3
Symptom: PNNI ports went down in progress and SPVCs failed when fault injected on active or switchredcd allowed to card with fault present.
Condition: Hold ATMizer in reset mode (SWB9) Fault Insertion test case inserted on active or standby card.
Workaround: Unknown.
|
CSCdy82328
|
Hardware: axsm1b_oc3
Symptom: After FS clear K2 was carrying previous channel number for four frames leading to random behavior of other equipment.
Condition: Initial condition: WS2 is primary and active line is WS2 Issue FS Issue FS clear. Active line and Primary section shall be WS1, and mismatch should not occur on either node.
Workaround: None.
|
CSCdy82452
|
Hardware: axsm1
Symptom: QE48 fault not detected in standby state.
Condition: User executed QE48 VC Table and QDB Memory Bank Fault Insertion test cases.
Workaround: Unknown.
|
CSCdy82780
|
Hardware: axsm1
Symptom: Faulty card did not reset and come up as failed.
Condition: Customer executed QE48 Tx UTOPIA3 to Humvee parity error fault insertion test case.
Workaround: Unknown.
|
CSCdy82800
|
Hardware: axsm1
Symptom: Card with fault inserted came up as standby.
Condition: Customer executed HUMVEE to SPEEDUP PLD UTOPIA 3 parity error fault insertion test cases.
Workaround: Unknown.
|
Status of MGX 8950 Caveats Found in Previous Releases
Table 21 describes the status of caveats found in previous releases of MGX 8950 Release 3.0.10 software.
Table 21 Status of Caveats for Previous Releases of MGX 8950 3.0.10 Software
DDTs Issue
|
Status
|
Description
|
CSCdt54958
|
Severity 1; still open.
|
Hardware: AXSM OC-12 cards.
|
CSCdw27075
|
Severity 1; still open.
|
Hardware: PXM45.
|
CSCdx69070
|
Severity 1; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45.
|
CSCdx77614
|
Severity 1; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45B.
|
CSCdu86213
|
Severity 2; closed.
|
Problem was due to an Ethernet chip hardware problem. Hardware: PXM45.
|
CSCdw68448
|
Severity 2; closed.
|
Fixed in Release 3.0.10. Hardware: AXSM.
|
CSCdx12518
|
Severity 2; closed.
|
The customer agreed to close the bug. Hardware: AXSMB OC-3.
|
CSCdx38504
|
Severity 2; closed.
|
Problem was due to faulty hardware. Hardware: RPM-PR.
|
CSCdx44559
|
Severity 2; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45.
|
CSCdx49157
|
Severity 2; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45B.
|
CSCdx64083
|
Severity 2; closed.
|
Problem was due to faulty hardware. Hardware: AXSM OC-48.
|
CSCdx67985
|
Severity 2; closed.
|
Duplicate of CSCdx06370, which was fixed in Release 3.0.00. Hardware: PXM45B.
|
CSCdx68487
|
Severity 2; closed.
|
The bug could not be reproduced with different cards. Hardware: AXSMB OC-3.
|
CSCdx70819
|
Severity 2; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45B.
|
CSCdx71179
|
Severity 2; closed.
|
Problem could not be reproduced. Hardware: PXM45B.
|
CSCdx71196
|
Severity 2; closed.
|
Problem was due to faulty hardware. Hardware: AXSM OC-12.
|
CSCdx71590
|
Severity 2; closed.
|
Fixed in Release 3.0.10. Hardware: AXSM OC-12.
|
CSCdx76852
|
Severity 2; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45B.
|
CSCdx77374
|
Severity 2; closed.
|
Duplicate of CSCdv62811, which is closed with the customer's agreement. Hardware: PXM45B.
|
CSCdx77522
|
Severity 2; closed.
|
Fixed inRelease 3.0.10. Hardware: PXM45B.
|
CSCdx78739
|
Severity 2; closed.
|
Duplicate of CSCdx71590, which is fixed in Release 3.0.10.b. Hardware: PXM45B.
|
CSCdt70323
|
Severity 3; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45.
|
CSCdu71423
|
Severity 3; closed.
|
The problem could not be reproduced. Hardware: AXSM.
|
CSCdu71558
|
Severity 3; closed.
|
The software is working as designed. Hardware: AXSM OC-48.
|
CSCdv22540
|
Severity 3; closed.
|
Duplicate of CSCdw29928, which was closed due to faulty hardware. Hardware: AXSMB OC-12.
|
CSCdv48058
|
Severity 3; closed.
|
The customer agreed to close this bug. Hardware: AXSMB OC-12.
|
CSCdv49510
|
Severity 3; closed.
|
The customer agreed to close this bug. Hardware: AXSMB.
|
CSCdv62811
|
Severity 3; closed.
|
The customer agreed to close this bug. Hardware: AXSM.
|
CSCdw08931
|
Severity 3; closed.
|
Fixed documentation error. Hardware: PXM45.
|
CSCdw10207
|
Severity 3; still open.
|
Hardware: AXSM.
|
CSCdx04460
|
Severity 3; closed.
|
The customer agreed to close this bug. Hardware: PXM45.
|
CSCdx31466
|
Severity 3; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45.
|
CSCdx41607
|
Severity 3; closed.
|
The feature was disabled starting with Release 3.0.00. Hardware: PXM45B.
|
CSCdx43364
|
Severity 3; closed.
|
This bug was discovered to be an RPM bug, and was fixed in 12.2(11.05)GLD and 12.2(11.05)T. Hardware: RPM.
|
CSCdx45501
|
Severity 3; closed.
|
Fixed in Release 3.0.10. Hardware: PXM45B.
|
MGX 8950 Resolved Caveats in Release 3.0.10
Table 22 lists the resolved caveats for the MGX 8950 Release 3.0.10 software.
Table 22 Resolved Caveats for MGX 8950 3.0.10 Software
DDTs Issue
|
Description
|
CSCdx02135
|
PLFM:boot flash corrupted after burnboot 3.0(0.225
|
CSCdx19404
|
Z-CDS: newly re-worked maker B cards didn't come up
|
CSCdx69070
|
Memory Allocation Errors - dsplog leaking memory a
|
CSCdx77614
|
Multiple node PXMs failed and other PXM in active f
|
CSCdy11654
|
Cannot CC nor CCC to slot with RPM card: IOS ipc b
|
CSCdy13722
|
(S)PXM cannot sync with primary rpm-xf slot after
|
CSCdw36064
|
AXSM core dump during switchredcd stress testing
|
CSCdw66847
|
Signalling COSB thresholds not programmed for ingr
|
CSCdw68448
|
Low accuracy problem on MBS policing.
|
CSCdw69483
|
Z-RED:switchredcd failed while wr mem is in proces
|
CSCdw71199
|
Error message from RPM-PR: RPM failed
|
CSCdw94593
|
cross commit / discrepancy in trunk bandwidth
|
CSCdx07885
|
EMEA axsmB fails intermittently with UnkAPS alarm
|
CSCdx15478
|
No RDI-L and RDI-P is sent by the W and P Lines wh
|
CSCdx21895
|
Z-REGS: after clrallcnf node bring up, RPM-XF came
|
CSCdx29956
|
lost cell bus clock config after power cycle
|
CSCdx30231
|
AXSM dspvsicon not showing correct lVci
|
CSCdx30496
|
RGS:One new GIG backcard can not be detected if ds
|
CSCdx44119
|
APS:dsplog did not show the second APS switching.
|
CSCdx49157
|
Unable to change SSCOP PCR after changing from def
|
CSCdx50255
|
bnPathHoldDown and PTSE holddown timers have no ef
|
CSCdx55010
|
AXSM conn receiving AIS from switch receive side
|
CSCdx57101
|
SNTP does not work efficiently when configured thr
|
CSCdx57591
|
SLT: Need to be able to configure > 50K conns afte
|
CSCdx63688
|
dbIO tlb exception when setrev before commitrev is
|
CSCdx65353
|
SPVC: Cross Commit failed on some connections.
|
CSCdx66220
|
aps needs to reset rmi connection in case its unhe
|
CSCdx66979
|
Core Dumps created during DBsync between Act&Stby
|
CSCdx69115
|
RPM Card Going into Failed State for a while after
|
CSCdx70242
|
Active BC removal/insertion caused SF, and oneWayI
|
CSCdx70819
|
Core Dumps created during DBsync between Act&Stby
|
CSCdx76697
|
Master is ok while slave is in failed state.
|
CSCdx76852
|
RGS:active RPM-PR backcards changed to empty after
|
CSCdx77522
|
APS: When 1 backcard missing, MGX send sd clear t
|
CSCdx81842
|
SLT:RPM-PR redundancy is lost after upgrade from 3
|
CSCdx82275
|
Cannot create SPVCs up to the partition limits.
|
CSCdx84262
|
The tail end of the connection reroute to be impro
|
CSCdx85661
|
popup message appears on second telnet using cnfnd
|
CSCdx89214
|
Both (A)&(S)PXM had rebuild trigger by unexpected
|
CSCdy10136
|
Call rate improvement to get to 160 calls/sec
|
CSCdy24425
|
AXSM/B port did not come up after LOS cleared
|
CSCdy24836
|
<switchcc> Ram Sync Failed, eventlog message
|
CSCdy24873
|
<switchcc> Failed to send event to ctc state machi
|
CSCdy26150
|
PTSE gets regenerated even with path down timer as
|
CSCdy33523
|
ENVMON: Support for integrating alarms
|
CSCdy35413
|
AXSM/A/B does not transmit NULL for E3 tail trace
|
CSCdt70323
|
3Change PXM burnboot process to not require console
|
CSCdv43250
|
DLS: no maximum login attempts to node
|
CSCdv82967
|
VUNI: misleading error msg while adding partition
|
CSCdw08931
|
clrallcnf, restoreallcnf not overwriting node LAN
|
CSCdw16078
|
REG21: unknown BC reported for stby axsme after px
|
CSCdw79627
|
Info shown by dspconinfo on PXM and dsptotals on A
|
CSCdw84026
|
k_smRedMapEntry_set() calling cliAddred()
|
CSCdw87384
|
PRI: dspconinfo -detail false giving the wrong spv
|
CSCdx04867
|
JANPN:Allow pathtrace on control port for svcc-rcc
|
CSCdx06836
|
APS-B: Inter, AXSM/B in OpB mode after upgrade fro
|
CSCdx27983
|
AUTO:Same clock source as primary and secondary by
|
CSCdx31466
|
CLI command delcons needs special privilege usage
|
CSCdx36523
|
error messages are recorded in log regarding NCDP
|
CSCdx39344
|
RGS:dspcd shows NO inserted BACKCARD but with acti
|
CSCdx43364
|
The snmp query on ifName responds five time for sw
|
CSCdx44453
|
couldnot delete an svcif when route is configured
|
CSCdx45501
|
dsppnni-routing-policy should match the display of
|
CSCdx48469
|
Feature for providing shelf filtered alarm status
|
CSCdx53295
|
REG3.0: ilmiPassup task freeing a mem - MBLKINVALI
|
CSCdx57455
|
Setrev should not be allowed after Runrev complete
|
CSCdx59149
|
RFS: Trying to free NULL pointer
|
CSCdx59223
|
UPG:all NCDP ports shut down when NNI link out of
|
CSCdx72300
|
REG3.0: cnfcon allows MCR > PCR on stdABR conn
|
CSCdx73996
|
preserving sw/fw vers result addred failure for AX
|
CSCdx77738
|
SCT chksum dont match between sw distributed and C
|
CSCdx84039
|
PXM45 Multi-cast feature checkin
|
CSCdy18274
|
dspconinfo needs to separate out persistent and no
|
CSCdy18792
|
3.0(10): unnecessary messages displayed on remote
|
CSCdy59240
|
SwitchCC caused due to mainProc1 getting killed unexpectedly
|
CSCdy59372
|
CPU utilization hit 0% IDLE due to pnCcb, when connections r
|
CSCdy61503
|
Failed connections on pop-2
|
Known Route Processor Module or MPLS Caveats
For information about caveats with the RPM-PR or RPM/B card, refer to Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for MGX Release 1.2.11 and MGX Release 3.
For information about caveats with the RPM-XF card, refer to Release Notes for Cisco MGX Route Processor Module (RPM-XF) for MGX 8850 (PXM45) Release 3.0.10 .
MGX-RPM-XF-512 Caveats
The new MGX-RPM-XF-512 card supports MGX 8850 (PXM45), Release 3.0.10.
For information about caveats with the MGX-RPM-XF-512 card, refer to Release Notes for Cisco MGX Route Processor Module (RPM-XF) for Release 3.0.10 of MGX 8850 (PXM45).
Acronyms
Table 23 describes the acronyms used in this document.
Table 23 Acronyms and Their Descriptions
Acronym
|
Description
|
AINI
|
ATM Inter-Network Interface
|
APS
|
automatic protection switching
|
ATM
|
asynchronous transmission mode
|
AXSM
|
ATM Switch Service Module
|
B-ISUP
|
Broadband ISDN User Part
|
BPX
|
an earlier Cisco backbone switch
|
CLI
|
command line interface
|
CWM
|
Cisco Wide Area Network Manager
|
DSLAM
|
digital subscriber line access module
|
IETF
|
Internet Engineering Task Force
|
LDP
|
label distribution protocol
|
LSC
|
label switch controller
|
LSP
|
label switched paths
|
LSR
|
label switch router
|
MIB
|
management information base
|
MPG
|
multiple peer group
|
MPLS
|
multiple protocol label switching
|
NCDP
|
network clock distribution protocol
|
PNNI
|
private network-to-network interface
|
PXM
|
processor switch module
|
RPM
|
route processor module
|
RPM-PR
|
route processor module - Premium
|
RPM-XF
|
route processor module - Express Forwarding
|
SCT
|
service class template
|
SLA
|
service level agreement
|
SM
|
service module (a card)
|
SNMP
|
simple network management protocol
|
SPVC
|
soft permanent virtual connection
|
SVC
|
switched virtual circuit
|
UNI
|
User-Network Interface
|
VCI
|
virtual channel identifier
|
VPI
|
virtual path identifier
|
Documentation
The documents listed in this section are for the releases that are compatible with Release 3.0.10.
Note The technical documentation that supports this release may include descriptions of features not implemented as of this printing.
Related Documentation
The following Cisco publications contain additional information related to the operation of this product and associated equipment in a Cisco WAN switching network.
Cisco WAN Manager Release 11.0.10
The product documentation for the Cisco WAN Manager (CWM) network management system for Release 11.0.10 is listed in Table 24.
Table 24 Cisco WAN Manager Release 11.0.10 Documentation
Title
|
Description
|
Cisco WAN Manager Installation Guide for Solaris 8, Release 11
|
Provides procedures for installing Release 11 of the CWM network management system and Release 5.4 of CiscoView.
|
Cisco WAN Manager User's Guide, Release 11
|
Describes how to use the CWM Release 11 software, which consists of user applications and tools for network management, connection management, network configuration, statistics collection, and security management.
|
Cisco WAN Manager SNMP Service Agent, Release 11
|
Provides information about the CWM Simple Network Management Protocol Service Agent, an optional adjunct to CWM that is used for managing Cisco WAN switches using SNMP.
|
Cisco WAN Manager Database Interface Guide, Release 11
|
Provides information about accessing the CWM Informix OnLine database that is used to store information about the network elements.
|
Cisco MGX 8850 (PXM45) Multiservice Switch Release 3.0.10
The product documentation for the installation and operation of the MGX 8850 Multiservice Switch for Release 3.0.10 is listed in Table 25.
Table 25 Cisco MGX 8850 (PXM45) Multiservice Switch Release 3.0.10 Documentation
Title
|
Description
|
Cisco MGX 8850 (PXM45 and PXM1E) Hardware Installation Guide, Release 3
|
Describes how to install the MGX 8850 multiservice switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8850 switch uses either a PXM45 or a PXM1E controller card and provides support for both broadband and narrow band service modules.
|
Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E) and MGX 8950 Command Reference, Release 3
|
Describes how to use the PXM and AXSM commands that are available for the MGX 8850, MGX 8950, and MGX 8830 switches.
|
Cisco Frame Relay Software Configuration Guide and Command Reference for the MGX 8850 FRSM12 Card, Release 3.0.10
|
Describes how to use the high-speed Frame Relay (FRSM12) commands that are available for the MGX 8850 switch.
|
Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3.0.10
|
Describes how to configure MGX 8850 and MGX 8950 switches with PXM45 controller cards to operate as ATM edge or core switches. This guide also provides some operation and maintenance procedures.
|
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3.0.10 and SES Release 3.0.10
|
Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
|
Cisco VISM Installation and Configuration Guide, Release 3
|
Describes how to install and configure VISM1 in several MGX 8000 Series switches. This guide is available online only.
|
Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3.0.10
|
Describes how to install and configure the MGX Route Processor Module (RPM-XF) in the MGX 8850 Release 3 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
|
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1
|
Describes how to install and configure the MGX Route Processor Module (RPM-PR) in the MGX 8850 Release 2.1 and later switches. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
|
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.11 and Release 3.0.10
|
Provides the latest feature, upgrade, and compatibility information, as well as known and resolved caveats for RPM-PR.
|
Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3.0.10
The product documentation for the installation and operation of the Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3.0.10 is listed in Table 26.
Table 26 Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3 Documentation
Title
|
Description
|
Cisco MGX 8850 Hardware Installation Guide (PXM45/B and PXM1E), Release 3.0.10
|
Describes how to install the MGX 8850 multiservice switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8850 switch uses either a PXM45 or a PXM1E controller card and provides support for both broadband and narrow band service modules.
|
Cisco MGX 8850, MGX 8950, and MGX 8830 Command Reference (PXM45/B and PXM1E), Release 3.0.10
|
Describes how to use the PXM and AXSM commands that are for the the MGX 8850, MGX 8950, and MGX 8830 switches.
|
Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3.0.10
|
Describes how to configure MGX 8850 and MGX 8830 switches with PXM1E controller cards to operate as ATM edge switches. This guide also provides some operation and maintenance procedures.
|
Cisco Frame Relay Software Configuration Guide and Command Reference for MGX Switches (PXM1E)
|
Provides software configuration procedures for provisioning connections and managing the FRSM cards supported in this release. Also provides command descriptions for all FRSM commands.
|
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3.0.10 and SES Release 3.0.10
|
Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
|
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1
|
Describes how to install and configure the MGX Route Processor Module (RPM-PR) in the MGX 8850 Release 3 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
|
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.11 and Release 3.0.10
|
Provides the latest compatibility information, as well as known and resolved caveats for RPM-PR.
|
Cisco MGX 8950 Multiservice Switch Release 3.0.10
The product documentation for the installation and operation of the MGX 8950 Multiservice Switch for Release 3.0.00 is listed in Table 27.
Table 27 Cisco MGX 8950 Multiservice Switch Release 3 Documentation
Title
|
Description
|
Cisco MGX 8950 Hardware Installation Guide, Release 3.0.10
|
Describes how to install the MGX 8950 core switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8950 switch uses a PXM45/B controller card and provides support for broadband service modules.
|
Cisco MGX 8850, MGX 8950, and MGX 8830 Command Reference (PXM45/B and PXM1E), Release 3.0.10
|
Describes how to use the PXM and AXSM commands that are available for the MGX 8850, MGX 8950, and MGX 8830 switches.
|
Cisco MGX 8850 (PXM45) and MGX 8950 Software Configuration Guide, Release 3.0.10
|
Describes how to configure MGX 8850 and MGX 8950 switches with PXM45 controller cards to operate as ATM edge or core switches. This guide also provides some operation and maintenance procedures.
|
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3.0.10 and SES Release 3.0.10
|
Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
|
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1
|
Describes how to install and configure the MGX Route Processor Module (RPM-PR) in the MGX 8950. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
|
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.11 and Release 3.0.10
|
Provides the latest feature, upgrade, and compatibility information, as well as known and resolved caveats for RPM-PR.
|
Service Expansion Shelf PNNI Controller Release 3.0.10
The product documentation for the installation and operation of the Service Expansion Shelf (SES) PNNI Controller is listed in Table 28.
Table 28 SES PNNI Controller Release 3 Documentation
Title
|
Description
|
Cisco SES PNNI Controller Software Configuration Guide, Release 3.0.10
|
Describes how to configure, operate, and maintain the SES PNNI Controller.
|
Cisco SES PNNI Controller Command Reference, Release 3.0.10
|
Provides a description of the commands used to configure and operate the SES PNNI Controller.
|
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3.0.10 and SES Release 3.0.10
|
Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
|
Cisco MGX 8830 Multiservice Switch Release 3.0.10
The product documentation for the installation and operation of the MGX 8830 Multiservice Switch Release 3.0.00 is listed in Table 29.
Table 29 Cisco MGX 8830 Multiservice Switch Release 3 Documentation
Title
|
Description
|
Cisco MGX 8830 Hardware Installation Guide, Release 3.0.10
|
Describes how to install the MGX 8830 edge switch. This guide explains what the switch does and covers site preparation, grounding, safety, card installation, and cabling. The MGX 8830 switch uses a PXM1E controller card and provides PNNI support for narrow band service modules.
|
Cisco MGX 8850 (PXM1E) and MGX 8830 Software Configuration Guide, Release 3.0.10
|
Describes how to configure MGX 8850 and MGX 8830 switches with PXM1E controller cards to operate as ATM edge switches. This guide also provides some operation and maintenance procedures.
|
Cisco MGX 8850, MGX 8950, and MGX 8830 Command Reference (PXM45/B and PXM1E), Release 3.0.10
|
Describes how to use the PXM and AXSM commands that are available in the CLI of the MGX 8850, MGX 8950, and MGX 8830 switches.
|
Cisco Frame Relay Software Configuration Guide and Command Reference for MGX Switches (PXM1E)
|
Provides software configuration procedures for provisioning connections and managing the FRSM cards supported in this release. Also provides command descriptions for all FRSM commands.
|
Cisco MGX and SES PNNI Network Planning Guide for MGX Release 3.0.10 and SES Release 3.0.10
|
Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a SES for PNNI route processing.
|
Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide, Release 2.1
|
Describes how to configure the MGX Route Processor Module (RPM-PR) in the MGX 8830 Release 3 switch. Also provides troubleshooting, maintenance, and basic Cisco IOS configuration information. (For RPM-PR software configuration information only.)
|
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1
|
Describes how to install the MGX Route Processor Module (RPM-PR) in the MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting and maintenance information, cable and connector specifications, and basic RPM-PR slot and redundancy limitations and constraints. (For RPM-PR hardware installation information only.)
|
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.11 and Release 3.0.10
|
Provides compatibility information, as well as known and resolved caveats for RPM-PR.
|
Cisco WAN Switching Software Release 9.3.42
The product documentation for the installation and operation of the Cisco WAN Switching Software Release 9.3.40 is listed in Table 30.
Table 30 Cisco WAN Switching Software Release 9.3.40 Documentation
Title
|
Description
|
Cisco BPX 8600 Series Installation and Configuration, Release 9.3.30
|
Provides a general description and technical details of the BPX broadband switch.
|
Cisco WAN Switching Command Reference, Release 9.3.30
|
Provides detailed information on the general command line interface commands.
|
Cisco IGX 8400 Series Installation Guide
|
Provides hardware installation and basic configuration information for IGX 8400 Series switches that are running Switch Software Release 9.3.30 or earlier.
|
Cisco IGX 8400 Series Provisioning Guide
|
Provides information for configuration and provisioning of selected services for the IGX 8400 Series switches that are running Switch Software Release 9.3.40 or earlier.
|
Cisco IGX 8400 Series Regulatory Compliance and Safety Information
|
Provides regulatory compliance, product warnings, and safety recommendations for the IGX 8400 Series switch.
|
9.3.40 Version Software Release Notes for Cisco WAN Switching System Software
|
Provides new feature, upgrade, and compatibility information, as well as known and resolved caveats.
|
MGX 8850 (PXM1) Multiservice Switch Release 1.2.11
The product documentation for the installation and operation of the MGX 8850 (PXM1) Multiservice Switch is listed in Table 31.
Table 31 MGX 8850 (PXM1) Multiservice Switch Release 1.2.11 Documentation
Title
|
Description
|
Cisco MGX 8850 Multiservice Switch Installation and Configuration, Release 1.1.3
|
Provides installation instructions for the MGX 8850 multiservice switch.
|
Cisco MGX 8800 Series Switch Command Reference, Release 1.1.3
|
Provides detailed information on the general command line for the MGX 8850 switch.
|
Cisco MGX 8800 Series Switch System Error Messages, Release 1.1.3
|
Provides error message descriptions and recovery procedures.
|
Cisco MGX 8850 Multiservice Switch Overview, Release 1.1.3
|
Provides a technical description of the system components and functionality of the MGX 8850 multiservice switch from a technical perspective.
|
Cisco VISM Installation and Configuration Guide, Release 3
|
Describes how to install and configure VISM in several MGX 8000 Series switches. This guide is available online only.
|
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1
|
Describes how to install and configure the MGX Route Processor Module (RPM/B and RPM-PR) in the MGX 8850, MGX 8250, and MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
|
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (Release 1), Software Version 1.2.11 (PXM1)
|
Provides new feature, upgrade, and compatibility information, as well as known and resolved caveats.
|
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.11 and Release 3.0.10
|
Provides new feature, upgrade, and compatibility information, as well as known and resolved caveats.
|
MGX 8250 Edge Concentrator Release 1.2.11
The documentation for the installation and operation of the MGX 8250 Edge Concentrator is listed in Table 32.
Table 32 MGX 8250 Edge Concentrator Release 1.2.11 Documentation
Title
|
Description
|
Cisco MGX 8250 Edge Concentrator Installation and Configuration, Release 1.1.3
|
Provides installation instructions for the MGX 8250 Edge Concentrator.
|
Cisco MGX 8250 Multiservice Gateway Command Reference, Release 1.1.3
|
Provides detailed information on the general command line interface commands.
|
Cisco MGX 8250 Multiservice Gateway Error Messages, Release 1.1.3
|
Provides error message descriptions and recovery procedures.
|
Cisco MGX 8250 Edge Concentrator Overview, Release 1.1.3
|
Describes the system components and functionality of the MGX 8250 Edge Concentrator from a technical perspective.
|
Cisco VISM Installation and Configuration Guide, Release 3
|
Describes how to install and configure VISM in several MGX 8000 Series switches. This guide is available online only.
|
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1
|
Describes how to install and configure the MGX Route Processor Module (RPM/B and RPM-PR) in the MGX 8850, MGX 8250, and MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
|
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (Release 1), Software Version 1.2.11 (PXM1)
|
Provides new feature, upgrade, and compatibility information, as well as known and resolved caveats.
|
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.11 and Release 3.0.10
|
Provides new feature, upgrade, and compatibility information, as well as known and resolved caveats.
|
MGX 8230 Edge Concentrator Release 1.2.11
The documentation for the installation and operation of the MGX 8230 Edge Concentrator is listed in Table 33.
Table 33 MGX 8230 Edge Concentrator Documentation
Title
|
Description
|
Cisco MGX 8230 Edge Concentrator Installation and Configuration, Release 1.1.3
|
Provides installation instructions for the MGX 8230 Edge Concentrator.
|
Cisco MGX 8230 Multiservice Gateway Command Reference, Release 1.1.3
|
Provides detailed information on the general command line interface commands.
|
Cisco MGX 8230 Multiservice Gateway Error Messages, Release 1.1.3
|
Provides error message descriptions and recovery procedures.
|
Cisco MGX 8230 Edge Concentrator Overview, Release 1.1.3
|
Provides a technical description of the system components and functionality of the MGX 8250 Edge Concentrator from a technical perspective.
|
Cisco VISM Installation and Configuration Guide, Release 3
|
Describes how to install and configure VISM in several MGX 8000 Series switches. This guide is available online only.
|
Cisco MGX Route Processor Module Installation and Configuration Guide, Release 1.1
|
Describes how to install and configure the MGX Route Processor Module (RPM/B and RPM-PR) in the MGX 8850, MGX 8250, and MGX 8230 Release 1 switch. Also provides site preparation, troubleshooting, maintenance, cable and connector specifications, and basic Cisco IOS configuration information.
|
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (Release 1), Software Version 1.2.11 (PXM1)
|
Provides new feature, upgrade, and compatibility information, as well as known and resolved caveats.
|
Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for Release 1.2.11 and Release 3.0.10
|
Provides new feature, upgrade, and compatibility information, as well as known and resolved caveats.
|
Obtaining Documentation
These sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at this URL:
http://www.cisco.com
Translated documentation is available at this URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped 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 through an annual subscription.
Ordering Documentation
You can order Cisco documentation in these ways:
•Registered Cisco.com users (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 Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
You can submit comments electronically on Cisco.com. In the Cisco Documentation home page, click the Fax or Email option in the "Leave Feedback" section at the bottom of the page.
You can e-mail your comments to bug-doc@cisco.com.
You can submit your comments by mail by using the response card behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you with these tasks:
•Streamline business processes and improve productivity
•Resolve technical issues with online support
•Download and test software packages
•Order Cisco learning materials and merchandise
•Register for online skill assessment, training, and certification programs
If you want to obtain customized information and service, you can self-register on Cisco.com. To access Cisco.com, go to this URL:
http://www.cisco.com
Technical Assistance Center
The Cisco Technical Assistance Center (TAC) is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two levels of support are available: the Cisco TAC Web Site and the Cisco TAC Escalation Center.
Cisco TAC inquiries are categorized according to the urgency of the issue:
•Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.
•Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
•Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
•Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
The Cisco TAC resource that you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
You can use the Cisco TAC Web Site to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to this URL:
http://www.cisco.com/tac
All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to this URL to register:
http://www.cisco.com/register/
If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC Web Site, you can open a case online by using the TAC Case Open tool at this URL:
http://www.cisco.com/tac/caseopen
If you have Internet access, we recommend that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. These classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer automatically opens a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled: for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). When you call the center, please have available your service agreement number and your product serial number.
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other 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. (0304R)
Copyright © 2003, Cisco Systems, Inc.
All rights reserved.
Feedback
