Table Of Contents
Release Notes for Cisco WAN MGX 8850 Switch Software Release 2.0.13
Contents
Introduction
System Requirements
Hardware Supported
AXSM Cards
PXM-45 Cards
PNNI
Software Compatibility
Compatibility Matrix
Release 2.0.13 System Content
Additional Deliverables for Release 2.0.13
Upgrading to a New Software Release
Upgrade Procedure
New and Changed Information
New CLI Commands
Changed CLI Commands
New Features in Release 2.0.13
Obsoleted Features in Release 2.0.13:
Installation Notes and Cautions
Limitations and Restrictions
Important Notes
APS Status Information
Recommendations
Caveats
Known Anomolies in Release 2.0.13
Problems Fixed in Release 2.0.13
Known Anomalies from Previous Releases
Problems Fixed in Release 2.0.12
Problems Fixed in Release 2.0.11
Problems Fixed in Release 2.0.10
Problems Fixed in Release 2.0.02
Related Documentation
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco.com
Technical Assistance Center
Contacting TAC by Using the Cisco TAC Website
Contacting TAC by Telephone
Service and Support
Release Notes for Cisco WAN MGX 8850 Switch Software Release 2.0.13
Contents
Introduction
These release notes describe the upgrade procedures for version 2.0.13, software upgrade procedures, hardware supported by the release, network support, and software limitations. The notes also contain Cisco support information. Follow-on releases are planned to add new features, and can be found in the Marketing Road Map.
System Requirements
Hardware Supported
The following table lists support hardware for Release 2.0.13:
Model
|
800 Part Number
|
Revision
|
PXM-45
|
800-06147-07
|
B0
|
PXM-UI-S3
|
800-05787-02
|
A0
|
PXM-HD
|
800-05052-03
|
A0
|
AXSM-1-2488
|
800-05795-05
|
A0
|
SMFSR-1-2488-FC
|
800-05490-05
|
A0
|
SMFXLR-1-2488-FC
|
800-05793-05
|
A0
|
SMFLR-1-2488-FC
|
800-06635-04
|
A0
|
AXSM-16-155
|
800-05776-06
|
A0
|
AXSM-4-622
|
800-05774-09
|
B0
|
AXSM-16-T3/E3
|
800-05778-08
|
A0
|
SMFIR-2-622
|
800-05383-01
|
A1
|
SMFLR-2-622
|
800-05385-01
|
A1
|
SMB-8-T3-BC
|
800-05029-02
|
A0
|
SMB-8-E3-BC
|
800-04093-02
|
A0
|
MMF-8-155
|
800-04819-01
|
A1
|
SMFIR-8-155
|
800-05342-01
|
B0
|
SMFLR-8-155
|
800-05343-01
|
A1
|
APS RDNT CON
|
800-05307-01
|
A0
|
AXSM Cards
The AXSM card is a double height ATM service module that is compatible with release 2.0 and later PXM-45 based versions of the MGX switch. The AXSM card uses the serial line traces on the MGX chassis to access the 45Gbps crosspoint fabric of the PXM-45 card and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.
The AXSM card provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM card on the IGX, and AUSM card of the release 1 MGX 8850. Other Cisco ATM platforms and other ATM manufacturers' equipment have proven to be compatible.
Line Interfaces for the AXSM Cards
•
T3/E3
8 ports per back card, 2 back cards per dual height slot
G.703/Accunet Conformance
•OC3c/STM1
G.703/GR-253 Conformance
8 ports optical per back card, 2 back cards per dual height slot
MMF, SMF intermediate and long reach
4 port Electrical back card
•OC12c/STM4
G.703/GR-253 Conformance
2 Ports per back card, 2 back cards per dual height slot
SMF intermediate and long reach
•OC48c/STM16
G.703/GR-253 Conformance
Single port back card, one back card per slot
SMF Short, long and extra-long reach
ATM Layer Information
•Usage policing supported on all interfaces except OC48c/STM16
•T3 interfaces support both PLCP and direct cell mapping
•64 Logical interfaces — ports, trunks, or virtual trunks (future)
•16 Class of Service queues for each class of service
•Supports independent queues for each ATM class of service
Network Management Features
•OAM functionality per ITU-T I.610
•Fault management — AIS/RDI at F4 and F5 flow
•User selectable continuity checking at connection endpoints
•Loopback diagnostics
•Automatic alarm generation and propagation for interface failures
The AXSM card offers a complete ATM feature set and allows the MGX 8850 to scale to the core of service provider networks from the T3/E3 edge to the OC48c core. Full line rate is achieved through the use of the serial line traces on the MGX 8850 platform. The entirely standards-based design and connection protocols enable installation into any existing network, as well as building new ATM infrastructures.
PXM-45 Cards
The PXM-45 card is a 45-Gbps processor switch module. The architecture of the PXM-45 card contains the CellBus fabric that is used in the current PXM-1 card, but adds the functionality of a 45-Gbps crosspoint switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX 8850. The PXM-45 card provides a Stratum3 central clocking circuit conforming to GR-1244 and G.813 specifications. This is an improvement over the Stratum4-based PXM-1 design.
Reliability, Availability and Serviceability Features
The PXM-45 card is designed to be fully redundant: There are two dedicated slots in the MGX 8850 (dual height slots 7 and 8) that house the PXM-45 card. Highlights of the reliability, availability and serviceability (RAS) features are listed below:
•Switchover from active to standby is designed to result in no cell loss with the exception of cells that are physically on the fabric at the time of the swap.
•In-band arbitration/grant mechanism ensures that service module failure does not stop traffic flow
•Hardware design ensures that if one or both hard disks fail, the cards will still pass traffic with no interruption, although provisioning could be suspended.
•MTBF Goal is calculated using a 99.9999% availability model which assumes two PXM-45 cards in a system. This was calculated at greater than 100,000 hours.
PXM-45 Card Information
The PXM-45 card supports PNNI software. There are two other components that complete the card set:
•PXM-UI-S3
•PXM-HD
The PXM-UI-S3 supports the following interfaces:
•Two RJ45 10Mbps 802.3 Ethernet ports
•Two RJ45 RS-232 Data Termination Equipment (DTE) ports that can be Y cabled. Pinouts are as follows:
Pin
|
Signal
|
Direction
|
Description
|
1
|
RTS
|
OUTPUT
|
Request to Send
|
2
|
DTR
|
OUTPUT
|
Data Terminal Ready
|
3
|
TX
|
OUTPUT
|
Transmit Data
|
4
|
SG
|
|
Signal Ground
|
5
|
SG
|
|
Signal Ground
|
6
|
RX
|
Input
|
Receive Data
|
7
|
DSR
|
Input
|
Data Set Ready
|
8
|
CTS
|
Input
|
Clear to Send
|
•Two DB9 T1/E1 BITS input, with converted cables that can be Y cabled. The following connections are supported:
–RJ48. Pinout conforms to Accunet1.5 Specification
–Wire wrap
–BNC
–DB15
•One DB15 Alarm interface. Contacts are normally open. This interface can be Y cabled.
–PXM-HD
This contains the hard disk for the processor.
PNNI
Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and scales to very large networks.
PNNI includes two categories of protocols. PNNI defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI topology and routing are based on the well-known link-state routing technique.
PNNI also defines a second protocol for signaling, that is, message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI 4.0 signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure. Whereas the UNI signaling protocol distinguishes between the user and network sides of a connection, PNNI is a symmetrical protocol.
PNNI provides dynamic ATM routing with quality of service (QoS) support as defined by the ATM Forum. PNNI uses link-state and source-state route technology, supports aggregation for private ATM addresses and links between switches, and can scale the network and its performance by means of configuring PNNI peer groups and hierarchical levels. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology.
The functions of the PNNI routing protocol include:
•Hello protocol (allows adjacent switches to exchange topology information)
•PTSE (PNNI Topology State Elements) database synchronization and management
•PTSE flooding
•Address summarization and advertisement
•Link and nodal aggregation
•Pre-computation of routing tables
•Quality of Service (QoS) based routing
•Multiple Routing Metrics
•Discovery of neighbors and link status
•Synchronization of topology databases
•Load balancing on equal cost paths
•Load balancing on parallel links
•Load balancing with redundant addresses
•Alternate paths
These PNNI features are supported in Release 2.0 of the MGX:
•UNI 3.0/3.1
•PNNI 1.0 Single Peer Group
•ILMI 4.0
•Point to point ATM SVCC and SVPC
•Support for ABR, CBR, VBR, rt-VBR, and UBR
•Alternate call routing (see separate feature description)
•On demand call routing (see separate feature description)
•Native E.164 and AESA (E.164, ICD, DCC) [formerly NSAP] address format
•Enhanced CAC with per service class policy parameter (see separate feature description)
•Per Class of service overbooking
•Congestion control (see separate feature description)
•PNNI connection and path trace
•OAM fault management
•Address filtering (see separate feature description)
•Intelligent CAC (see separate feature description)
•Call processor redundancy
PNNI networks are highly resilient due to their ability to quickly reroute connections around failed network elements, and to update routes and network topology based upon availability of network resources. Connections will generally route quickly using pre-computed routing tables, but in the case of congestion or during a network failure, on-demand routes will be calculated for connections.
Software Compatibility
Compatibility Matrix
Board Pair
|
Latest Boot Code Version
|
Minimum
Boot Code
Version
|
Firmware
|
Latest
Firmware
Version
|
Minimum
Firmware
Version
|
PXM-45
|
pxm45_002.000.013.000_bt.fw
|
2.0.13.0
|
pxm45_002.000.013.002_mgx.fw
|
2.0.13.2
|
2.0.13.2
|
AXSM-1-2488
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.013.002.fw
|
2.0.13.2
|
2.0.13.2
|
AXSM-16-155
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.013.002.fw
|
2.0.13.2
|
2.0.13.2
|
AXSM-4-622
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.013.002.fw
|
2.0.13.2
|
2.0.13.2
|
AXSM-16-T3/E3
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.013.002.fw
|
2.0.13.2
|
2.0.13.2
|
MGX 2.0.13 interoperates with CWM 10.4
MGX 2.0.13 operates with MGX 1.1.31 and MGX 1.1.32 as a feeder. Please see 1.1.311/1.1.32 release notes for bugs related to the feeder features.
MGX 2.0.13 operates with CiscoView 5.2 (package 3.3x).
Release 2.0.13 System Content
Switch Software and Boot Codes
The following four images apply to the 2.0.13 release:
•Boot Images
–axsm_002.000.012.000_bt.fw
–pxm45_002.000.013.000_bt.fw
•Runtime Images
–axsm_002.000.013.0002.fw
–pxm45_002.000.013.002_mgx.fw
Additional Deliverables for Release 2.0.13
SNMP MIB
The MIB release for this 2.0.13 is mibs2012.
Upgrading to a New Software Release
This section contains installation and upgrade instructions. For complete details, refer to the MGX 8850 Switch Software Configuration Guide, part 78-12629-01, which supports installation of software version 2.0.12 and higher.
Upgrade Procedure
When upgrading your node, upgrade the software in the following order:
Step 1 PXM45 backup boot
Step 2 PXM45 runtime
Step 3 AXSM backup boot—only needed if upgrading from a release earlier than 2.0.12
Step 4 AXSM runtime
The following does not apply if you are upgrading from version 2.0.12:
•If the active AXSM has some non-default interface policy configured with the cnfpnportcac command, then the standby AXSM card might not be in sync with the active card. This affects the upgrade of the cards to the new version. The user will have to follow the procedure for a non-graceful upgrade to the new version.
If the default interface policy is being used, graceful upgrades are supported.
Graceful upgrades are also possible if the interface policy is configured for 3 or fewer ports, because the interface policy for 4 or more ports do not get synced to standby.
Note The PXM-45 upgrade is still graceful; only the AXSM redundancy will be ungraceful if there have been interface policy changes.
•If you are currently using 3 IP addresses to telnet to your node, read the first section in "Changed CLI Commands" on reconfiguring your IP addresses on your node. The Disk IP address must be configured.
Upgrading the Boot and Runtime Images from 2.0.12 to 2.0.13 (Redundant Systems)
The following procedure is for redundant systems.
Step 1 Copy files to the switch.
Step 2 Type sh to go to the shellconn.
Step 3 Issue the sysBackupBoot command.
Step 4 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().
Step 5 Issue the sysFlashBootBurn <"filename"> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
Step 6 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the Active state.
Step 7 Enter the switchcc command. When the former active card comes up standby, upgrade its boot code by following steps 2 - 6 above.
Step 8 Use the loadrev command to load the 2.0.13 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(13.2)
Step 9 After the standby card comes back up with the new image in the Active state, use the runrev command to load the 2.0.13 release on the active card. This command will bring your original standby card to active state.
runrev <slot number> <version>
For example: runrev 8 2.0(13.2)
Step 10 After the redundant card comes up in the standby/Active state, issue the command commitrev to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(13.2)
Step 11 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev, runrev and commitrev command for each AXSM card.
For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2)
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.
Step 12 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <version>
For example: loadrev <AXSM slot> 2.0(13.2)
Step 13 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <version>
For example: runrev <AXSM slot> 2.0(13.2)
Step 14 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)
Repeat steps 12-14 for all redundant AXSM cards.
Upgrading the Boot and Runtime Images from 2.0.12 to 2.0.13 (Non-Redundant Systems)
The following procedure is for non-redundant (PXM-45) systems.
Step 1 Upgrade the PXM-45 boot code.
Step 2 Type sh to go to the shellconn.
Step 3 Issue the sysBackupBoot command.
Step 4 Hit return when prompted to do so to stop auto-boot.
Step 5 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
Step 6 Use the loadrev, runrev, and commitrev commands to load the 2.0.13 release:
Step 7 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev command for each AXSM card. For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2)
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.
Step 8 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <primary version>
For example: loadrev <AXSM slot> 2.0(13.2)
Step 9 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <primary version>
For example: runrev <AXSM slot> 2.0(13.2)
Step 10 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)
Repeat steps 9-10 for all redundant AXSM cards.
Upgrading the Boot and Runtime Images from 2.0.11 to 2.0.13 (with No Interface Policy Changes) [Redundant Systems]
The following procedure is for redundant systems.
Step 1 Type sh to go to the shellconn.
Step 2 Issue the sysBackupBoot command.
Step 3 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().
Step 4 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
Step 5 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the ready state.
Step 6 Enter the switchcc command. When the formerly active card comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the loadrev command to load the 2.0.13 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(13.2)
Step 8 After the standby card comes back up with the new image in the ready state, use the runrev command to load the 2.0.13 release on the active card. This command will bring your original standby card to Active state.
runrev <slot number> <version>
For example: runrev 8 2.0(13.2)
Step 9 After the redundant card comes up in standby ready, issue the command commitrev to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(13.2)
Step 10 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 11 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev, runrev and commitrev command for each AXSM card.
For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2)
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.
Step 12 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <version>
For example: loadrev <AXSM slot> 2.0(13.2)
Step 13 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <version>
For example: runrev <AXSM slot> 2.0(13.2)
Step 14 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)
Repeat steps 12-14 for all redundant AXSM cards.
Upgrade Procedure for Non-Redundant (PXM-45) Systems
The following procedure is for non-redundant (PXM-45) systems.
Step 1 Upgrade the PXM-45 boot code.
Step 2 Type sh to go to the shellconn.
Step 3 Issue the sysBackupBoot command.
Step 4 Hit return when prompted to do so to stop auto-boot.
Step 5 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
Step 6 Use the loadrev, runrev, and commitrev commands to load the 2.0.13 release:
Step 7 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 8 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev command for each AXSM card.
For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2)
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.
Step 9 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <primary version>
For example: loadrev <AXSM slot> 2.0(13.2)
Step 10 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <primary version>
For example: runrev <AXSM slot> 2.0(13.2)
Step 11 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)
Repeat steps 10-11 for all redundant AXSM cards.
Upgrading theBoot and Runtime Images from 2.0.11 to 2.0.13 (with Interface Policy Changes)
The following procedure is for redundant systems.
Step 1 Type sh to go to the shellconn.
Step 2 Issue the sysBackupBoot command.
Step 3 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().
Step 4 Issue the sysFlashBootBurn <filename> command, where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
Step 5 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the ready state.
Step 6 Enter the switchcc command. When the formerly active card comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the loadrev command to load the 2.0.13 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(13.2)
Step 8 After the standby card comes back up with the new image in the ready state, use the runrev command to load the 2.0.13 release on the active card. This command will bring your original standby card to active state.
runrev <slot number> <version>
For example: runrev 8 2.0(13.2)
Step 9 After the redundant card comes up in standby ready, issue the command commitrev to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(13.2)
Step 10 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 11 To upgrade non-redundant/redundant AXSM cards with the new runtime image, issue the setrev command for each AXSM card. For example:
setrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant/redundant AXSM cards.
The following procedure is for non-redundant systems.
Step 1 Upgrade the PXM-45 boot code.
Step 2 Type sh to go to the shellconn.
Step 3 Issue the sysBackupBoot command.
Step 4 Hit return when prompted to do so to stop auto-boot.
Step 5 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
Step 6 Use the setrev command to load the 2.0.13 release:
Step 7 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 8 To upgrade the AXSM runtime, issue the setrev command for the AXSM card.
setrev <AXSM slot> 2.0(13.2)
New and Changed Information
This section describes new and changed commands in release 2.0.13.
New CLI Commands
The new command dspapsbkplane displays the APS connector status. For example:
U3.6.AXSM.a > dspapsbkplane 6.1.3
BackPlane: ENGAGED
Golden.3.AXSM.a > dspapsbkplane 3.1.1
Changed CLI Commands
No CLI commands are changed in this release.
New Features in Release 2.0.13
There are no new features in this release.
The following features are committed, but not supported in this release:
•AXSM cards with STM1 electrical interface.
•Inter operability with LS1010 and BPX-SES (BPX-SES is in beta phase).
•Connection density: 50K connections per node. 40K connections are supported in this release.
Obsoleted Features in Release 2.0.13:
No features are obsoleted in this release.
Installation Notes and Cautions
•(CSCdt05425) If the active AXSM has some non-default interface policy configured, then standby card might not be in sync with the active card. This will also affect the upgrade of the cards to the new version. The user will have to follow the procedure for a non-graceful upgrade for the new version.
If the default interface policy is being used, then the redundancy/graceful upgrade is possible.
The redundancy/upgrade will also work if the interface policy is configured for 3 or fewer ports (as the interface policy for 4 or more ports does not get synced to standby).
Note that AXSM Redundancy works after the customer has upgraded to 2.0.12. The AXSM Redundancy problem only exists in versions 2.010 and 2.0.11.
•When removing AXSM redundancy (delred), you must remove the Y-red cables before issuing the delred command.
•On feeder trunks, confoamseg is required for tstdelay to work. The steps are as follows on PNNI:
Step 1 dpnport <portid>
Step 2 cnfpnportsig <portid> -cntlvc ip
Step 3 cnfoamsegep <portid> no
Step 4 uppnport <portid>
•(CSCdt09608) To prevent database sync problems on CWM, when setting these MIB variables or using corresponding CLI command addcon, the user should always follow these rules:
–from SNMP, cwaChanCDV and cwaChanRemoteCDV should always be set to the same value.
–from SNMP, cwaChanCTD and cwaChanRemoteCTD should always be set to the same value.
–from CLI, the parameters 'lcdv' and 'rcdv' of the addcon command should always be set to the same value.
–from CLI, the parameters 'lctd' and 'rctd' of the addcon command should always be set to the same value.
–do not set above variables on a slave endpoint either from CLI or SNMP.
•(CSCdt09949) Currently the CLI command addchanloop does not store the connection loop state as persistent data. As a result, this loop (ingress and egress) state of a connection will be lost after the following operations:
–resetcd
–resetsys
–dncon followed by upcon
–controller resync (dnport followed by upport)
–switchredcd
–reroute (dnport)
•PNNI default min VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes (e.g., MPLS and NCDP). For users who would like to add MPLS controller in future releases of MGX 8850, it is highly recommend to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be established automatically on 0/32.
•By default, 900 cps and 543 cps will be reserved for SSCOP and PNNI Signalling VC respectively, even when you disable SSCOP and PNNI. These values are configurable by the cnfpnctlvc command.
•The database stores the backplane serial number and back card serial numbers. Therefore if cards are moved from one node to another, the console will display "SHM Alert!! Alert!!." In this situation follow these steps:
Step 1 Enter shmFailDisplay. A display table will show that BRAM is not native.
Step 2 Enter shmFailRecoveryHelp. This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is shmRecoverIgRblDisk.
Step 3 Enter shmRecoverIgRbldDisk.
•Do not execute delcontroller when connections/ports still exists. The impact of executing delcontroller with connections is that the connections cannot be recovered until the controller is re-added via addcontroller and the AXSM cards or the entire node has to be reset (otherwise ports remain in provisioning state). There is now a warning about the impact of the command when there are existing connections/ports.
•(CSCds70478) Currently, Humvee error reporting is turned off for the AXSM cards. They are however logged.
•Analysis of the code has identified a situation which has a low probability of occurring and in fact has not been encountered in any test scenarios to date. This caution and associated workaround is provided as a precautionary measure. When the link bandwidth for SPVC connections is reaching full capacity, thus minimal bandwidth is available for new SPVC connections, there is a condition which can be encountered where, the initial software check believes there is sufficient bandwidth for the new SPVC connection; however, the final software confirmation for available bandwidth may be rejected because there is no bandwidth available. If this problem occurs, the system will recover when the PNNI updates are refreshed. (This will happen at the default time of 30 minutes.) The user can recover from this problem by making the Administrative weight of that link very high to avoid that link from being used.
•To replace one type of AXSM front card with another type, all connections, partitions, ports and down lines must be deleted. In case of AXSM card failure, the same type of AXSM card must be installed in that slot.
•(CSCds11868) If a user is using CWM with their node, the user should use CWM to configure the node name since the restriction on the switch is different than CWM. CWM only supports 11 characters whereas the switch CLI command allows up to 32 characters.
•(CSCdt32198) The dsperr command currently provides proper information only when it is executed on PXM slot. When it is executed on the AXSM slot, the information is incorrect.
Limitations and Restrictions
•If any AXSM cards remain in INIT state and the PXM-45 standby card is reset, the PXM-45 standby card will not transit back to standby. This is a DB server limitation.
•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in Rel 2.0 baseline (2.0.10-2.0.13) with PXM-45 and PXM-45/B is 99.
In future releases of MGX 8850 with PXM-45/B, the maximum number of logical interfaces supported will be 3199. The PXM-45 module will always support a maximum of 99 logical interfaces.
The maximum number of signalling interfaces in Rel 2.0 and future releases of MGX 8850 is 99. Signalling interfaces are those running a protocol such as PNNI, IISP, AINI or supporting SVC/SVP.
Interfaces on standby or redundant cards are not counted.
•(CSCdt32565) APS working line must be 1 line lower than the protection line. For example, 1 is the working link and 2 is the protection line. Having 1 as the protection and 2 as the working line is not allowed.
•If the destination address is reachable for both a IISP and a PNNI link from the same node, ABR connections will not route. The current routing algorithm will always choose IISP links over PNNI links because it is local. Since IISP does not support ABR connections, the connection setup will fail.
•SCT can be changed with connections present in this release. However, if service affecting the connections will be rerouted.
•(CSCds41609) Connection statistics at CLI and Bucket level is not available in AXSM-1-2488 cards. However, connection debug statistics are available in all types of cards.
•When CWM is connecting to the network, the IP address 10.0.x.x cannot be used for MGX 8850 PXM-45 as lnPci address.
•For users who would like to add MPLS partition on a port where other partitions have already been added and have set the min-vci value to be 32, then the user has two options:
–After the MPLS controller is added, explicitly add the TDP sig vc using a vpi/vci pair within its partition's resource range.
–Do a dnport and cnfpart to move the min-vci to 35 for all partitions on the port.
•(CSCdr15911) Changing or reseeding the back card several times on the AXSM OC48 card may sometimes cause the front card to reset and cause loss of service. The PhyTask also gets suspended. To avoid this problem, try not to reseat the back card too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring up the system.
Important Notes
APS Status Information
Caution Please ensure the APS connector is correctly installed. Refer to the "APS Backplane" section in Chapter 4 of the "Cisco MGX 8850 Hardware Installation Guide". This guide is part number 78-10351-04, and can be ordered from Cisco Marketplace or downloaded from
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/20x/hig/index.htm. After you install the assembly, verify that the APS connector is properly installed by using the new CLI command
dspapsbkplane.
The current APS design has the APS mux (through the mini-backplane) between the framer and the line. Hence, the processor monitors status of the line after the APS mux. As a result, it also reports and displays the APS status of the line that feeds to it. The following CLIs as well as line LEDs are affected:
•dsplns
•dspapsalms
•dspapslns
•dspbercnt
•LEDs
The lines could be mapped "straight" (the line of Back Card X, fed to Front Card X and the line of Back Card Y fed to Front Card Y) or "crossed" (the line of Back Card X fed to Front Card Y and the line of Back Card Y fed to Front Card X). Typically, when one does say dspapslns on Card X, one expects Front Card X to show the status of the Lines of Back Card X. However, in the current design one must note that this is true only the "straight" situation. In the "crossed" situation, dspapslns on Card X will show the status of the lines fed to it, that is, of the Peer Card Y. As long as one is aware of how to interpret the above CLI commands and LEDs in this situatio, everything should be clear.
So how does one determine if the configuration is "straight" or "crossed"?
In card redundancy, initially the Primary card is Active and the Secondary card is Standby, the Working line is from the Primary card and the Protection line is from the Secondary card and the Active Line is the Working Line. If the Primary card is Active and the Active Line is Protection or if the Secondary card is Active and the Active line is Working we are in a "crossed" situation; otherwise we are in a "straight" situation.The dspapslns command shows which line is Active.
Recommendations
We recommend you apply the default values for PCR, SCR, etc. to the Control VC. If the values are decreased to a low value, there is a chance that the Control VC (SSCOP or PNNI) will not come up. Note that you must use the SCT files released with 2.0.11 (number 2 and 3, which are included in the 2.0.13 release) for the Control VC feature.
Caveats
Known Anomolies in Release 2.0.13
The following is the list of known anomalies in this MGX 8850 software delivery. Included with each is a brief discussion of the problem. A more in depth discussion is available in the release note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
S1 Bugs
|
|
CSCdr15911
|
Symptom:
Changing the back card may sometimes cause the front card to reset and cause loss of service. It may occasionally be difficult to bring up the AXSM card.
Conditions:
This problem happens occasionally when someone reseats the back card several times, the front card is reset.
It is also observed that during power on/off testing, sometime the PhyTask got suspended.
Workaround:
Try not to reseat the back card too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.
|
CSCds86986
|
Symptoms:
AXSM switchover cause all pnni links on this AXSM go to attempt.
Condition:
This problem occurred after resetting an AXSM non-redundant card and followed by several (some times up to 10) consecutive AXSM switchovers on redundant AXSM pairs on other slots of the same node.
Work around:
Do not do consecutive AXSM switchovers. If the problem occurs, the periodic resync between PNNI controller and AXSM will recover the failure.
|
CSCdt11867
|
Symptom:
Ports go to ilmi query after PXM switch over
Condition:
Upgrades the network, then do switchcc
Work around:
None
Recovery:
Down port then up port by using dnpnport/uppnport command
|
CSCdt12043
|
Symptom :
After multiple switchcc failed to telnet to a node.
Condition :
Disk IP address not configured for LAN (lnPci0). During switchover, no ARP broadcast sent to declare new IP address <--> MAC address mapping.
Workaround:
Make sure the Disk IP address (lnPci0) of this node is configured.
|
CSCdt27029
|
Symptom:
AXSM switchover and PXM switchover when AXSM cards inserted
Condition:
AXSM cards were reseated
Workaround:
UNKNOWN
|
CSCdt28974
|
Symptom:
Manual switch from active protection line to working line does not follow aps protocol.
Condition:
Protection line was active.
Workaround:
UNKNOWN
|
CSCdt28983
|
Symptom:
aps switching does not meet Signal Degrade Threshold requirements for switching
Condition:
Errors were injected at the threshold levels specified for Signal Degrade conditions to be reported.
Workaround:
UNKNOWN
|
CSCdt29648
|
Symptom:
BPX reported no ingress data from MGX
Condition:
aps switch had been performed on BPX
Workaround:
UNKNOWN
|
CSCdt29711
|
Symptom:
Adding and deleting APS line on a NNI port caused it to go to building VC state. Condition:
The port is stuck in building VC state and the signalling type is changed from NNi to UNI.
Workaround:
Unknown
|
CSCdt32565
|
Symptom:
Failed to add redundancy between AXSM cards. Further summary. This occured during software upgrade to 2.0(13). This only causes a failure for an Intracard APS case.
Condition:
If we have APS line configured with protection line greater than working line we get into this problem.
In the original APS software, the CLI command, "addapsln", did not have any check to prevent adding APS line where the protection line is less than the working line. This will go through even though it is not acceptable. The APS database will not accept this. However, the process called "CEMA" allows it.
Therefore, Intercard APS was not working in the previous release. The bug ID CSCdt08530, that resolved most of the APS problem correct this mistake as well.
However, by fixing what was wrong in the first place, it caused the configurations in the system to be unable to be recognized.
Workaround:
The only solution is that prior to upgrading the runtime image to 2.0(13), the administrator needs to verify that on a stand alone card, there are no Intracard APS configured such that the working line is greater than the protection line.
If there is, then the Intracard APS has to be deleted, along with its ports, partitions and connections. If they prefer to leave the connections, they will have to use another line for APS configuration later on.
Once the Intracard APS is deleted, they can then upgrade the runtime image and then add APS later on. Or they could add it correctly in the old image prior to upgrading to the new image 2.0(13).
If an upgrade is already done prior to deleting the Intracard APS, this would definitely cause the AXSM card to not function properly. Therefore, to fix this problem, they need to downgrade back to the previous image and delete the Intracard APS with the protection line less than the working line. Once that is accomplished, then they could do the upgrade.
|
S2 BUGS
|
|
CSCdr89521
|
Symptom:
dspcon shows routing cost = 0
Condition:
This will happen after swithcc on connections that are not rerouted
Workaround:
Do a dncon or rrtcon
|
CSCds24362
|
Symptoms:
Occasionally, when downing a UNI port (dnport) on AXSM followed by upport, some VSIErr are displayed on the AXSM console.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnport on the UNI on NODE_EP1.
(4) upport on the UNI on NODE_EP1. At this time, some vsierr might be displayed on the AXSM console.
Workaround:
None.
|
CSCds74175
|
Symptom:
When bit error are injected on a protection line and if the protection line were to be active (in case of intra card APS), "dspbecnt" would show those errors on the working line stats instead of the protection line stats.
Condition:
This happens only for an intra-card APS case. The problem is still under investigation.
Workaround:
If the working line is active, then the display shown on dspbecnt is correct. If the protection line is active, then use the stats shown on the working line as the protection line bit error stats and vice versa.
|
CSCds74268
|
Symptom:
Active AXSM card in a redundant pair spontaneously resets
Condition:
Previous to the reset, a spontaneous switchover from the previously active AXSM card had taken place. The previously active AXSM card did not come into standby mode after the switchover, but stayed in boot state.
Workaround:
UNKNOWN
|
CSCds74316
|
Symptoms
The dsplog command displays 0.0.0 for protection line id when the APS pair is deleted.
Conditions
Not all of the APS events show proper protection line index. Some are printed with 0.0.0 as index.
Workaround:
None
|
CSCds89730
|
Symptom:
Upon trap verification, cwCardIngSctFileAlarm (60358) does not provide correct value for cmIngressFileId varbind.
Conditions:
User generated trap by configuring the card SCT with an invalid/missing ID using the command (cnfcdsct 56, where 56 is the invalid SCT ID) User then checked CWM GUI OV Event Browser window for traps and expanded varbinds.
Workaround:
UNKNOWN
|
CSCds89759
|
Symptom:
Upon trap verification, cwaChanMultipleChanInAlarms (60306) appears to be generated too many times with respect to CLI actions.
Conditions:
User was downing ports and associated multiple channels from CLI. dnport <port #> User then checked CWM GUI OV Event Browser window for traps and expanded varbinds.
Workaround:
UNKNOWN
|
CSCds89819
|
Symptom:
Customer reports excessive and varied traffic restore time with redundant AXSM card resets.
Condition:
Excessive and varied traffic restore is observed when a redundant APS connected nni link experiences card switchovers. Traffic restore over the link is ranging from 25 Milliseconds all the way up to one (1) second.
Workaround:
None
|
CSCds90463
|
CSCds90463
Symptom:
EM database consistency error during AXSM resync
Condition:
This problem is found in MGX 8850 shelf, after runrev on redundant AXSM card, standby AXSM card try to come up and sync the database with the active AXSM card.
Workaround:
unknown
|
CSCds92690
|
Symptom:
Slave conns were in E-Ais/RDI for no apparent reason.
Condition:
aps miniplane connectors and back cards were installed prior to connections going into alarm
Workaround:
UNKNOWN
|
CSCdt02295
|
Symptoms:
The J0/Z0 bytes are incorrect when the mode is SONET.
Condition:
None
Work around:
None.
|
CSCdt02323
|
Symptoms:
The J0/Z0 bytes in the recd. SONET frame are not correct.
Condition:
None
Workaround:
None.
|
CSCdt05371
|
Symptom:
Traps were not generated for HD failure during fault insertion testing.
Condition:
Hard disk failure was simulated on modified PXMs.
Workaround:
UNKNOWN
|
CSCdt05378
|
Symptom:
Switchover to faulty standby PXM allowed during fault insertion testing
Condition:
HD failure was simulated on the standby PXM
Workaround:
UNKNOWN
|
CSCdt05383
|
Symptom:
PXM switchover did not occur when HD failure simulated on active PXM during fault insertion testing
Condition:
HD failure was simulated on active PXM
Workaround:
UNKNOWN
|
CSCdt05385
|
Symptom:
No alarms reported when HD failure on active PXM
|
