Table Of Contents
2.0.12 Version Software Release Notes
Cisco WAN MGX 8850 Software
About These Release Notes
About the 2.0.12 Release
Phased Release Strategy:
Software Release 2.0.12 and related hardware:
AXSM Cards
PXM 45 Cards
PNNI
Special Installation/Upgrade Requirements
Upgrade Procedure
Loading the runtime images from 2.0.10/2.0.11 to 2.0.12 (with no interface policy changes)
Loading the runtime images from 2.0.10/2.0.11 to 2.0.12 (with interface policy changes)
New CLI Commands
Changed CLI Commands
Features Not Supported
Committed (but not delivered in this release)
Obsoleted:
Additional Features:
Notes & Cautions
Limitations
APS Status Information:
Recommendations:
Compatibility Notes
Compatibility Matrix
Release 2.0.12 System Content
Switch Software and Boot Codes
Hardware Products
Known Anomalies
Problems Fixed in Release 2.0.12
Known Anomalies from Previous Releases
Problems Fixed in Release 2.0.11
Problems Fixed in Release 2.0.10
Problems Fixed in Release 2.0.02
Additional Deliverables
SNMP MIB
Obtaining Service and Support
Cisco Connection On-line
2.0.12 Version Software Release Notes
Cisco WAN MGX 8850 Software
About These Release Notes
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
About the 2.0.12 Release
Phased Release Strategy:
Follow on releases are planned to add new feature contents and can be found in Marketing Road Map
Software Release 2.0.12 and related hardware:
AXSM Cards
The AXSM is a double height ATM service module that is compatible with release 2.0 and later PXM45 based versions of the MGX. The AXSM uses the serial line traces on MGX chassis to access the 45Gbp crosspoint fabric of the PXM45 and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.
The AXSM provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM on the IGX, and AUSM of the release 1 MGX8850. 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 offers a complete ATM feature set and allows the MGX8850 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 MGX8850 platform. The entirely standards based design and connection protocols enables the installation into any existing network, as well as building new ATM infrastructures.
PXM 45 Cards
The PXM-45 is a 45Gbps processor switch module. The architecture of the PXM-45 contains the CellBus fabric that is used in the current PXM-1, but adds the functionality of a 45Gbps cross point switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX8850. The PXM-45 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 (RAS) Features
The PXM-45 is designed to be fully redundant, there are two dedicated slots in the 8850 (dual height slots 7 and 8) that will house the PXM-45. Highlight of the 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 to ensure that if one or both hard disk fails, 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 PXMs in a system. This was calculated at greater than 100,000 hours.
PXM45 Card Information
The PXM-45 will support PNNI software. There are two other components that make the complete card set these are:
•PXM-UI-S3
•PXM-HD
The PXM-UI-S3 supports the following interfaces:
•One RJ45 10Mbps 802.3 Ethernet port
•Two RJ45 RS232 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. Pin Out 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 will scale 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 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 has the ability to 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 the following:
•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
The following 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.
Special Installation/Upgrade Requirements
Upgrade Procedure
•When upgrading your node, upgrade in the following order
–pxm45 backup boot
–pxm45 runtime image
–axsm backup boot
–axsm runtime image
•In addition, if the active axsm has some non-default interface policy configured (cnfpnportcac), then standby card might not be in sync with the active card. This will also affect the upgrade of the cards to new version. The user will have to follow the procedure for non-graceful upgrade for the new version.
If the default interface policy is being used then upgrade (graceful) will not be affected.
The upgrade will also work if the interface policy is configured for port numbers <= 3 (as the interface policy for other ports (>=4/5) is not getting synced to standby).
Note The pxm45 upgrade is still graceful, only the AXSM redundancy will be ungraceful if there has 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.
Loading the runtime images from 2.0.10/2.0.11 to 2.0.12 (with no interface policy changes)
For Redundant Systems
Step 1 - type "sh" to go to the shellconn
Step 2 - issue "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.012.000_bt.fw"
Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.
Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the "LOADREV" command to load the 2.0.12 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(12.0)
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.12 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(12.0)
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(12.0)
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(12.0)
runrev <axsm slot> 2.0(12.0)
commitrev <axsm slot> 2.0(12.0)
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 on for the standby card.
loadrev <slot number> <version>
For example: loadrev <axsm slot> 2.0(12.0)
Step 13 After the standby AXSM card comes backup in standby mode, issue the "RUNREV" command for the active card.
runrev <slot number> <version>
For example: runrev <axsm slot> 2.0(12.0)
Step 14 After the AXSM card comes backup in standby mode, issue the "COMMITREV" command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <axsm slot> 2.0(12.0)
Repeat this step 12-14 for all redundant AXSM cards.
For non-redundant (PXM45) systems, please follow these steps
Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn
a. - issue "sysBackupBoot" command
b. - hit return when prompted to do so to stop auto-boot
c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.012.000_bt.fw"
d. - enter "y" to confirm
Step 2 Use the "LOADREV, RUNREV, COMMITREV" commands to load the 2.0.12 release:
Step 3 To upgrade the AXSM boot code, issue the "burnboot" command:
For example: burnboot <axsm slot> 2.0(12)
Step 4 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(12.0)
runrev <axsm slot> 2.0(12.9)
commitrev <axsm slot> 2.0(12.0)
Repeat these steps for all non-redundant AXSM cards.
Step 5 To upgrade redundant AXSM cards with the new runtime image, issue the "LOADREV" command on for the standby card.
loadrev <slot number> <primary version>
For example: loadrev <axsm slot> 2.0(12.0)
Step 6 After the standby AXSM card comes backup in standby mode, issue the "RUNREV" command for the active card.
runrev <slot number> <primary version>
For example: runrev <axsm slot> 2.0(12.0)
Step 7 After the AXSM card comes backup in standby mode, issue the "COMMITREV" command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <axsm slot> 2.0(12.0).
Repeat steps 6-7 for all redundant AXSM cards.
Loading the runtime images from 2.0.10/2.0.11 to 2.0.12 (with interface policy changes)
For Redundant System
Step 1 - type "sh" to go to the shellconn
Step 2 - issue "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.012.000_bt.fw"
Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.
Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the "LOADREV" command to load the 2.0.12 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(12.0)
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.12 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(12.0)
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(12.0)
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(12.0).
Repeat these steps for all non-redundant/redundant AXSM cards.
For non-redundant systems, please follow these steps
Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn
a. - issue "sysBackupBoot" command
b. - hit return when prompted to do so to stop auto-boot
c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.012.000_bt.fw"
d. - enter "y" to confirm
Step 2 Use the "SETREV" command to load the 2.0.12 release:
Step 3 To upgrade the AXSM boot code, issue the "burnboot" command:
For example: burnboot <axsm slot> 2.0(12)
Step 4 To upgrade the AXSM runtime, issue the "setrev" command for the AXSM.
setrev <axsm slot> 2.0(12.0)
Repeat this step for all AXSMs on the card.
New CLI Commands
1. The new CLI command `telnet' allows an user to telnet to another node.
a. Syntax:
•telnet [-E<escape character>] [-R<traceroute character>] <ipdest> [<port dest>]
- the sequence ESC <escape character> closes all telnet sessions in the chain and falls back to the first telnet session in the chain.
- the sequence ESC <traceroute character> initiate traceroute: this feature will print all telnet hops in the telnet session
- ipdest is the IP address of the destination
- portdest is the TCP destination port. Its defaulted to the Telnet port.
- the default value for <escape character> is `Q' and the default value for <traceroute character> is `g'
b. Additional Information:
•When opening a new telnet session, i.e. telneting node to node one step further, all telnet options previously negotiated by the users are reset.
•How to fall back to the previous session:
- The CLI command `bye' or `exit' is normally used to fall back to the preceeding node from a telnet connection.
- A failure of the TCP connection between a telneting node and its remote telnet server will cause CLI to fall back
- The escape sequence, ESC <escape character> , provided, in case the remote node is not able to initiate the fall back (for instance if it is down or running in a loop) and the IP stack is not able to detect that the TCP connection is down. This will cause the connection to fall back to the first CLI session in the chain.
•There is no limit on the number of successive telnet hops, although there is a limit of 15 CLI telnet sessions per node.
2. Two new commands (dsprevs and dsprevs -status) have been added that show the revision for each card as well as the internal flag for upgrades. The `dsprevs' command allows users to check the revision of each card without having to do `dspcd' for each one. The dsprevs -s option allows users to check the status of the upgrade for each of these cards from a single place.
Changed CLI Commands
1. The following has information Boot IP and Disk IP setup for LAN IP Connectivity changes:
The Disk IP (lnPci0) is set using the ipifconfig & Boot IP is set with command bootchange.
The Disk IP is the IP address of the ACTIVE PXM.
The Boot IP is the IP address of the Standby PXM.
The line specifying "Internet Address" is the current IP address in use. It may be different than the "Disk IP Address" if the card is the standby PXM and the Disk IP address is different than the Boot IP address (Option 2).
There are three options to set the Boot and Disk IP.
Option 1:
Only one IP is assigned for disk and boot IP for simplex as well as for redundant PXM.
In this case for redundant system the standby interface is down and could be access through cc command or through console port.
Option 2:
Two different IPs are assigned:
This scenario can be applied to redundant system only.
IP # 1 assign to boot IP
IP # 2 assign to disk IP
The boot IP can be assigned manually to both active and standby PXM's.
The disk IP could be assigned by ipifconfig command on active card.
In this case after switchcc the active card has the Disk IP and standby has the BootIP therefore, both controllers (active and standby) can be access through telnet session simultaneously.
This is recommended mode of operation if user can have two IP assignment.
Option 3: NO LONGER SUPPORTED:
Three IPs are set for redundant system:
IP # 1 assign to disk IP of the Active PXM
IP # 2 assign to boot IP of the Active PXM
IP # 3 assign to boot IP of the standby PXM
In this case user has access both active and standby controller as well as boot access.Cisco does not recommend this because this option will not be supported in future releases of the software.
Option 3 is no longer supported. If system is running option 3 configuration, user will note that access to standby PXM is lost. To re-enable standby PXM access, use Option 2.
Regarding the CWM user needs to assign an IP to amt0 interface for SNMP communication.
2. The card state in the cli commands dspcds, dspcd and dspred now indicate upgrades/downgrades. The states are identical to the old ones with the addition of -U or -D at the end indicating upgrade or downgrade respectively.
3. The `dsperr' command has been change to display "Error number xxxxx not found" when no match has been found instead of displaying that wrong error number.
4. The `dsperr' command has been changed to make -sl option mandatory. If no slot number is specified, the command will now display "No slot specified".
5. The `dspchancnt' has been changed to reflect the port status. For example, if an user downs the port (dnport) and then issues the dspchancnt command, the following is displayed:
ERR: Connection does not exist as port is admin down
6. The `clrchancnts' command has been changed to clear the residual (hardware) connections counts.
7. The `addfdr' command will be blocked if there are existing connections on the interface.
8. The optional parameters lcdv, rcdv, lctd, rctd and mc (routing parameters) will be blocked to configure for slave endpoints in both the `addcon' and `cnfcon' commands. In addition:
a. from SNMP, cwaChanCDV and cwaChanRemoteCDV should always be set to the same value.
b. from SNMP, cwaChanCTD and cwaChanRemoteCTD should always be set to the same value.
c. from CLI, the parameters 'lcdv' and 'rcdv' of the 'addcon' command should always be set to the same value.
d. from CLI, the parameters 'lctd' and 'rctd' of the 'addcon' command should always be set to the same value.
e. do not set above variables on a slave endpoint either from CLI or SNMP.
9. The "sysBackupBoot" command has been changed to bring the user to the boot prompt without user intervention.
10. The `dspcon' display has been modified for "Tx CDV, Rx CDV, Tx CTD, and Rx CTD" values. If CDV and CTD are not configured for any connection and it is a valid connection then the display will be -1. For any connection that has invalid values for CDV or CTD, then N/A will be displayed. Since the routing parameters (CDV and CTD) are not allowed to be configure on the slave side, the display for a slave endpoint will be N/A.
11. When a user enters 0xffffffff as netmask in bootChange CLI, it will not be saved to NVRAM. This applies to PXM45 and AXSM.
12. The `cnfxbaradmin' command has been removed. The user will not be able to enable/disable the planes from the CLI.
13. The `tstdelay' command now returns information after the command is issued. For example:
svcswp6.2.PXM.a > tstdelay 10.4 1 101
Test started; Use dspcon to see test results
14. The cnfndparm and dspndparm commands have been modified with additional parameters. The following gives information about how the two new node parameters are implemented and supported in cnfndparms and dspndparms.
cnfndparm command is used to centrally locate node parameter configuration. It is a general command that can be used to specify configuration information about a specific node parameter.
Two new parameters have been added for this release.
1. Required Power Supply Module Bitmap: In the system there exists up to a maximum of six power supply modules. Only one module is required to exist for proper node operation. This command allows the customer to declare which combination of power supplies must exist. Should any of those power supplies be removed, a node alarm will be generated.
Bitmap configuration is stored in BRAM and synched to the standby, so it will survive a system reboot and a processor switchover.
For those not familiar with bitmap configuration, it is a simple way to allow combinations of configurations to be added using one command.
For this command, the bitmap looks as follows:
NODE CONFIGURATION OPTIONS
Opt# Value Type Description
---- ----- ---- -----------
5 0x0 8bit Hex Required Power Supply Module Bitmap
Set existence requirements for Power Supply Modules. If option set to:
0x00: No power supply module existence requirement.
0x01: PSU A1 is required to exist.
0x02: PSU A2 is required to exist.
0x04: PSU A3 is required to exist.
0x10: PSU B1 is required to exist.
0x20: PSU B2 is required to exist.
0x40: PSU B3 is required to exist.
Remaining bits can be entered but will be ignored.
Bits may be combined for multiple Power Supply Module configuration. (e.g. a value of 0x74 sets PSU A3, PSU B1, PSU B2 and PSU B3)
By combining (or adding) the various values together, combinations of PSU can be configured.
For example, if an operator wanted to require that PSU A1 and
PSU B1 always existed:
PSU A1 = 0x01
PSU B1 = 0x10
PSU A1 + PSU B1 = 0x01 + 0x10 = 0x11
so the value the operator would specify is 0x11.
Another example, if an operator want to require that PSU A1, PSU A2, PSU A3 and PSU B1 always existed:
PSU A1 = 0x01
PSU A2 = 0x02
PSU A3 = 0x04
PSU B1 = 0x10
PSU A1 + PSU A2 + PSU A3 + PSU B1 =
0x01 + 0x02 + 0x04 + 0x10 = 0x17
so the value the operator would specify is 0x17.
2. Required Fan Tray Unit Bitmap: In the system there exists up to a maximum of two fan tray units. Only one unit is required to exist for proper node operation. This command allows the customer to declare which combination of fan trays must exist. Should any of those fan tray units be removed, a node alarm will be generated.
Bitmap configuration is stored in BRAM and synched to the standby, so it will survive a system reboot and a processor switchover.
For those not familiar with bitmap configuration, it is a simple way to allow combinations of configurations to be added using one command.
For this command, the bitmap looks as follows:
NODE CONFIGURATION OPTIONS
Opt# Value Type Description
---- ----- ---- -----------
6 0x0 8bit Hex Required Fan Tray Unit Bitmap
Set existence requirements for Fan Tray Units. If option set to:
0x00: No fan tray unit existence requirement.
0x01: Bottom Fan Tray is required to exist.
0x02: Top Fan Tray is required to exist.
Remaining bits can be entered but will be ignored.
Bits may be combined for multiple Fan Tray Unit configuration. (e.g. a value of 0x3 sets both Bottom and Top Fan Trays)
By combining (or adding) the various values together, combinations of Fan Tray can be configured.
For example, if an operator wanted to require that Top Fan Tray always existed:
The value the operator would specify is 0x2.
Another example, if an operator want to require that all Fan Tray existed:
Bottom Fan Tray + Top Fan Tray =
0x01 + 0x02 = 0x03
so the value the operator would specify is 0x3.
15. The dspconinfo has been changed to reflect a new column #Down. This new column will show how many of the connections are down.
Features Not Supported
Committed (but not delivered in this release)
1. AXSM cards with STM1 electrical interface.
2. Inter operability with LS1010 and BPX-SES (BPX-SES is in beta phase).
3. Connection density: 50K connection per node. 40K connections is supported in this release.
Obsoleted:
none
Additional Features:
Auto disk check is a feature that provides automatic disk health checks for all hard disk drives for pxm45. Important disk health information, as a result of auto disk check, is printed out on standard output as well as written to BRAM.
The information written on BRAM is meant to be used by SHM arbitrator later, which is not part of auto disk check. A set of APIs are provided therefore for access of these information.
Currently, during the backup boot of pxm1 or pxm45 shelves, if the fwResetReason is not one of the following, R_RESET_FRM_PXM, R_RESET_SYS, R_SWITCHCC, R_UPGRADE_RESET, autoDiskCheck() is executed. If disk errors are detected, they are printed on standard output and written to BRAM.
autoDiskCheck() and its access API's can also be used in shellcon. autoDiskcheck can also be disabled via the shellcon. The following four commands can may be used from shellcon
•autoDiskCheck
•sysBramDiskErrShow
•sysIsAutoDiskChkEnable
•sysAutoDiskChkToggle
Since BRAM space is prime, currently only one error is written in detail on BRAM for each disk slice, although we do have an error count for each slice with a max of 64K. The error written is normally the first one involving a file name on a slice. If no error involves a file name, then the first error detected is the one written in detail on BRAM for the disk slice.
Notes & Cautions
1. 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 new version. The user will have to follow the procedure for non-graceful upgrade for the new version.
If the default interface policy is being used then the redundancy/upgrade (graceful) will not be affected.
The redundancy/upgrade will also work if the interface policy is configured for port numbers <= 3 (as the interface policy for other ports (>=4/5) is not getting synced to standby).
Note: AXSM Redundancy will work once the customer has upgraded to 2.0.12. The AXSM Redundancy problem only exists in 2.010 and 2.0.11.
2. When removing AXSM redundancy (delred), you must remove the Y-red cables before issuing the delred command.
3. On feeder trunks, confoamseg is required for tstdelay to work. The steps are as follows on PNNI:
• dpnport <portid>
•cnfpnportsig <portid> -cntlvc ip
•cnfoamsegep <portid> no
•uppnport <portid>
4. 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:
a. a) from SNMP, cwaChanCDV and cwaChanRemoteCDV should always be set to the same value.
b. b) from SNMP, cwaChanCTD and cwaChanRemoteCTD should always be set to the same value.
c. c) from CLI, the parameters 'lcdv' and 'rcdv' of the 'addcon' command should always be set to the same value.
d. d) from CLI, the parameters 'lctd' and 'rctd' of the 'addcon' command should always be set to the same value.
e. e) do not set above variables on a slave endpoint either from CLI or SNMP.
5. 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)
6. 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 release 2.1, 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.
7. 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.
8. The database stores the backplane serial number and backcard serial numbers. Therefore if cards are moved from one node to other, console will display "SHM Alert!! Alert!!." In this situation follow the steps below:
a. enter "shmFailDisplay." Display table will show that BRAM is not native.
b. enter "shmFailRecoveryHelp". This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is "shmRecoverIgRblDisk".
c. enter "shmRecoverIgRbldDisk".
9. Do not execute the "delcontroller" CLI when connections/ports still exists. The impact of executing delcontroller with connections is that the connections can not be recovered until the controller is readded 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 to the user of the impact of the command when there are existing connections/ports.
10. Currently, Humvee error reporting is turned off for the AXSM cards. They are however logged.
11. Analysis of the code has identified a situation which has a low probability of occurring and in fast 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.
12. To replace one type of AXSM front card with other type, it is required to delete all connections, partitions, ports and down lines. In case of AXSM card failure, same type of AXSM card must be installed in that slot.
13. If a user has upgraded already to 2.0.12 and then decides to fall back to 2.0.10 he/she should run the following command on the active PXM after falling back to 2.0.10 - gShmRebuildFlagSet(2).
Limitations
1. If any AXSM cards remain in INIT state and the PXM45 standby card is reset, the PXM45 standby card will not transit back to standby. This is a DB server limitation.
2. 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.
3. SCT can be changed with connections present in this release. However, if service affecting the connections will be rerouted.
4. 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.
5. When CWM is connecting to the network, the IP address 10.0.x.x cannot be used for MGX-8850 PXM45 as lnPci address.
6. For users who would like to add MPLS controller in release 2.1, it is highly recommended 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 automatically established on 0/32.
7. For users who would like to add MPLS partition on a port where other partitions has already been added and have set the min-vci value to be 32, then the users has two options:
a. After the MPLS controller is added, explicitly add the TDP sig vc using a vpi/vci pair within its partition's resource range.
b. Do a dnport and cnfpart to move the min-vci to 35 for all partitions on the port.
8. If 50 users (the maximum is 50) is added and the pxm card is reset, the card does not come back up.
9. Changing or reseeding the backcard 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 backcard too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.
APS Status Information:
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" i.e. the line of Back Card X, fed to Front Card X and the line of Back Card Y fed to Front Card Y or "crossed" i.e. the line of Back Card X fed to Front Card Y and the line of Back Card Y fed to Front Card X. Typically, when one 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: i.e. of the Peer Card Y. So long as one is aware of how to interpret the above CLI commands and LEDs in this situation everything should be clear.
Q: How to determine if are in a "straight" situation or a "crossed" situation?
A: In card redundancy, initially the Primary card is Active and the Secondary card is Standby, the Working line is from the Primary card and the Protection line is from the Secondary card and the Active Line is the Working Line. If the Primary card is Active and the Active Line is Protection or if the Secondary card is Active and the Active line is Working we are in a "crossed" situation; else we are in a "straight" situation. dspapslns command shows which line is Active.
Recommendations:
•It is recommended to 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, you must use the SCT files released with 2.0.12 (number 2 and 3) for the Control VC feature.
Compatibility Notes
Compatibility Matrix
Board Pair
|
Latest Boot Code Version
|
Minimum
Boot Code
Version
|
Firmware
|
Latest
Firmware
Version
|
Minimum
Firmware
Version
|
PXM45
|
pxm45_002.000.012.000_bt.fw
|
2.0.12.0
|
pxm45_002.000.012.000_mgx.fw
|
2.0.12.0
|
2.0.12.0
|
AXSM-1-2488
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.012.000.fw
|
2.0.12.0
|
2.0.12.0
|
AXSM-16-155
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.012.000.fw
|
2.0.12.0
|
2.0.12.0
|
AXSM-4-622
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.012.000.fw
|
2.0.12.0
|
2.0.12.0
|
AXSM-16-T3/E3
|
axsm_002.000.012.000_bt.fw
|
2.0.12.0
|
axsm_002.000.012.000.fw
|
2.0.12.0
|
2.0.12.0
|
MGX 2.0.12 interoperates with CWM 10.3 and 10.4
MGX 2.0.12 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.12 operates with Cisco View 5.1x (package 3.3x) and Cisco View 5.2 (package 3.3x).
Release 2.0.12 System Content
Switch Software and Boot Codes
The following four images are applicable to the 2.0.12 release:
•Boot Images
–axsm_002.000.012.000_bt.fw
–pxm45_002.000.012.000_bt.fw
Runtime Images
–axsm_002.000.012.000.fw
–pxm45_002.000.012.000_mgx.fw
Hardware Products
Support hardware for Release 2.0.12:
Model
|
800 Part Number
|
Revision
|
PXM45
|
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
|
Known Anomalies
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 backcard may sometimes cause the front card to reset and cause loss of service. It may occasionally be difficult to bring up the AXSM.
Conditions:
This problem happens occasionally when someone reseats the backcard 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 backcard too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.
|
CSCds20527
|
Symptom:
The CWM Software(ConnProxy module) will notice timeouts while creating connections continuously.
Condition:
SNMP Agent currently support only 16 outstanding requests. Any requests received after it has 16 requests outstanding will be dropped(timeout for NMS Application: Dropped meaning no responses sent back to the NMS application).
Workaround:
Timeouts do not cause any harm except that Users or the CWM modules might log multiple events mentioning that Agent timed out.
Additional Information from CWM:
If client tries to add more than 100 connections through Connection Proxy (Service Agent) Script, they will start getting Time Out's even though the time out frequency is less. Client then needs to find out from the Log file which all connections could not be added. If provisioning is a one time action, Client may bear this, but if they do provisioning very often, it will be a serious concern.
|
CSCds84734
|
Symptom:
Standby PXM45B resets several times after a resetsys. The reset reason points to a hardware watchdog timeout.
Condition:
This problem is found in a shelf with redundant PXM45B cards. After a resetsys, the standby PXM45B continued to reset several times before coming up as a standby card. This problem was only seen once.
Workaround:
None
|
CSCds86986
|
Symptoms:
AXSM switchover cause all pnni links on this AXSM go to attempt.
Condition:
This problem occurred after resetting an AXSM non-redundant card and followed by several (some times up to 10) consecutive AXSM switchovers on redundant AXSM pairs on other slots of the same node.
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
|
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
|
CSCds20527
|
Symptom:
The CWM Software(ConnProxy module) will notice timeouts while creating Connections continuously.
Condition:
SNMP Agent currently support only 16 outstanding requests. Any requests received after it has 16 requests outstanding will be dropped(timeout for NMS Application: Dropped meaning no responses sent back to the NMS application).
Workaround:
None.
Additional Information:
Timeouts do not cause any harm except that Users or the CWM modules might log multiple events mentioning that Agent timed out.
|
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.
|
CSCds32464
|
Symptom:
Sometimes, operator cannot connect to the PXM console port from a PC. This problem is not seen from UNIX based terminals.
Condition:
This problem is experience only on the modem which is connected using V42.bis compression mode.
Workaround:
1) Disable the V42.bis mode on the local modem prior to start the dialing to the remote MGX node. Consult modem manual of how to disable such mode.
2) Execute PXM switchover.
|
CSCds63745
|
Symptom:
The tstconseg fails on BPX when it is connected to AXSM.
On AXSM it results in large delay.
Condition:
Interworking issue between BPX and MGX. It only happens in the interworking scenario and not when they are connected to same equipment.
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 in a redundant pair spontaneously reset
Condition:
Previous to the reset, a spontaneous switchover from the previously active AXSM had taken place. The previously active AXSM 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.
Workarounds:
None
|
CSCds80370
|
Symptom:
CBR SPVC was consistently discarding 50% of its traffic
Condition:
UNKNOWN
Workaround:
UNKNOWN
|
CSCds80406
|
Symptom:
AXSM OC3 spontaneously reset
Condition:
Data transfer tests were being conducted - one of the CBR SPVCs was experiencing discards on 50% of its traffic
Workaround:
Not known
|
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 Popeye2 shelf, after runrev on redundant AXSM card, standby AXSM try to come up and sync the database with the active AXSM.
Workaround:
unknown
|
CSCds92690
|
Symptom:
Slave conns were in E-Ais/RDI for no apparent reason.
Condition:
|
