Feedback
|
Table Of Contents
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1), Software Version 1.3.10
Features Introduced in Release 1.3.10
MPSM 8-port T1/E1 Service Module and License Manager Support
Standard Available Bit Rate (ABR) Mapping Changes
Features Introduced in Release 1.3.00
Features Not Supported in This Release
Service Module Redundancy Support
New Boot Image for FRSM 8T1/E1
Using the restoresmcnf Command
Loopback Plug on a HSSI:DTE Interface
ForeSight and Standard ABR Coexistence Guidelines
Reaction to Feedback Messages - Rate Up
Reaction to feedback messages - Rate Down
Known Anomalies for Platform Software Release 1.3.10 and Service Module Firmware
Resolved Anomalies for Platform Software Release 1.3.10 and Service Module Firmware
Resolved Anomalies for Platform Software Release 1.3.00 and Service Module Firmware
MGX 8230, MGX 8250, and MGX 8850 (PXM1) Software Certification with Other Products
MGX 8250 and MGX 8850 (PXM1) Firmware Compatibility
MGX 8230 Firmware Compatibility
MGX 8850 (PXM1), MGX 8250, and MGX 8230 Release 1.3.10 Hardware
Special Installation and Upgrade Requirements
Special Instructions for Networks Containing FRSM-2-CT3
Upgrade Procedure for Non-Redundant PXM
Upgrade Procedure for Redundant PXMs
Instructions to Abort PXM Upgrade
Aborting an Upgrade from Release 1.1.3x and Above
Aborting an Upgrade from Release 1.1.2x
Service Module Boot/Firmware Download Procedure
Manual Configuration of Chassis Identification
Chassis Identification During a Firmware Upgrade
Interoperability of Service Modules on MGX 8220 and MGX 8250 Switches
MPSM 8-port T1/E1 Licensing Overview
Finding Documentation for Cisco MGX, BPX, SES, and CWM Products
Obtaining Technical Assistance
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1), Software Version 1.3.10
Contents
About These Release Notes
Note that for Release 1.3.10, the user documentation (command reference, overview, and installation and configuration guides) were not updated. Use the existing documents in addition to this release note.
Product documentation for MGX 8850 (PXM1) is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/index.htmProduct documentation for MGX 8250 is available at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/index.htm
Product documentation for MGX 8230 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/index.htmProduct documentation for VISM is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/Product documentation for RPM is available at the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/rpm/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/rpm/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/rpm/index.htmProduct documentation for AUSM (and ATM services on MPSM 8-port T1/E1) is available at the following URL
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/ausm/index.htm
Product documentation for CESM (and circuit emulation services on MPSM 8-port T1/E1) is available at the following URL
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/cesm/index.htm
Product documentation for FRSM (and Frame Relay services on MPSM 8-port T1/E1) is available at the following URL
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/frsm/index.htm
Product documentation for MPSM 8T1/E1 hardware is available at the following URL
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/hwdoc/hig/index.htm
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.
Features Introduced in Release 1.3.10
Release 1.3.10 supports all features introduced in prior releases. (Refer to the 1.2.21 release notes for features introduced in the 1.2 baseline)
MPSM 8-port T1/E1 Service Module and License Manager Support
Release 1.3.10 introduces support for the MPSM-8-T1E1. The MPSM-8-T1E1 (Multiprotocol Service Module) is a single-height replacement card for the AUSM-8T1/E1, FRSM-8T1/E1, and CESM-8T1/E1 narrowband service modules, and supports the back cards each of these service modules supports. The MPSM-8-T1E1 card has any service, any card (ASAC) capability. For more information on MPSM 8T1/E1 hardware, refer to the following URL
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/hwdoc/hig/index.htm
Release 1.3.10 also introduces support for the MPSM-8-T1E1 License Manager which is required to turn on special licensed features of the MPSM card. The MPSM card can be licensed to provide the services of either a FRSM, AUSM or CESM service module on one MPSM-8-T1E1 card.
For information specific to License Manager configuration on the MPSM-8-T1E1 card in PXM1-based MGX switches, refer to the "MPSM 8-port T1/E1 Licensing Overview" section.
Standard Available Bit Rate (ABR) Mapping Changes
According to ATM forum's TM4.0, ABR connections should have zero in the CLP and EFCI bits in the ATM cell. To follow this recommendation all Frame Relay cards reset the CLP and EFCI bits of all outgoing ATM cells to zero irrespective of the value of the DE and FECN bits of the incoming frames.
Release 1.3.10 introduces support for enabling or disabling StdABR options at the port level, instead of card level by using the CLI command cnfportstdabrctrl or xcnfport.
The RM (Resource Management) cell generation options will remain the same for the port level as they were for the card level. These options are:
1.
No RM cell generation, no mapping
2.
No RM cell generation, mapping
3.
RM cell generation, no mapping
4.
RM cell generation, mapping
In releases prior to 1.3.10, RM cell generation and DE --> CLP, FECN --> EFCI mapping control was available as a FRSM-8T1E1 card level feature for StdABR connections. Users enabled or disabled RM cell generation and mapping through the command cnfstdabrctrl. Once this command was enabled, all of the StdABR connections on the card behaved in the same way. With release 1.3.10 and the introduction of port-based RM cell generation and DE --> CLP, FECN --> EFCI mapping control configuration, the CLI command cnfstdabrctrl has been made obsolete.
Unique Device Identifier
With Release 1.3.10 Cisco Multi Protocol Service Module products have an electronically retrievable identifier. This identifier is called the Unique Device Identifier (UDI) and consists of the Product Identifier (PID), the Version Identifier (VID), and the hardware Serial Number (SN). The UDI is programmed at the factory and is stored in non-volatile memory.
The UDI is used to identify specific equipment for inventory management, asset management, entitlement, business operations management, network implementation, and network management.
In network management, the UDI enables network administrators to easily track specific components in their network.
You can display the UDI by issuing the show inventory command from the command line interface (CLI). The show inventory command displays the information shown in Table 0-1.
The following example shows the show inventory command and its output:
MGX8850.8.PXM.a > show inventoryNAME: "1" , DESCR: "Cisco MGX8850 Backplane"PID: MGX8850 , VID: 000, SN: SN1234567890NAME: "1" , DESCR: "Double-height ATM SM, 8 T1/E1"PID: MPSM-8-T1E1 , VID: 000, SN: SN1234567890MGX8850.8.PXM.a >Features Introduced in Release 1.3.00
Release 1.3.00 supports all features introduced in prior releases. (Refer to the 1.2.21 release notes for features introduced in the 1.2 baseline)
SRME/B Service Module
Release 1.3.00 introduces the SRME/B. The SRME/B adds T3/E3 interfaces to the current SRME which already supported OC-3 and STM-1 Electrical interfaces. This new SRME/B service module supports T3/E3, OC-3 and STM-1 Electrical interfaces with the same front card. Bulk distribution to all 24 slots is now possible for the 8230/8250/8850 PXM1-based platforms.
SRME/B hardware information is found here:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/hwdoc/hig/index.htm
SRME/B configuration information is found here:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/scg/index.htm
SRME/B command information is found here:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/cmdref/index.htm
SNTP Support
In prior releases, SNTP support was only for the PXM45-based nodes. This feature allows all PXM1-based nodes to use SNTP or Simple Network Time Protocol to synchronize clocks within an internetwork of PXM1-based nodes. SNTP provides a comprehensive mechanism to access national time sources and adjust each nodes's clock to that time source. CWM support for SNTP on PXM1-based nodes is the same mechanism as supported by CWM on the MGX8800 PXM45-based switches in prior releases.
SNTP configuration material can be found here:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/scg/index.htm
SNTP command information is found here:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/cmdref/index.htm
SSH Support
Release 1.3.00 introduces a Secure Remote Terminal Interface feature. This feature provides an SSH session whenever someone accesses into the PXM1-based node via the LAN port using telnet.
You configure this feature using the cnftelnetenbl CLI command. This command allows you to configure telnet access to the PXM1-based node. By default, telnet server access is enabled. When you disable telnet access remote users must use the SSH protocol to login to the PXM1-based node.
MIB Changes in Release 1.3.00
Release 1.3.00 introduces support for the entity MIB. The entity MIB allows a single agent to represent multiple logical entities. The entity MIB can be used to represent physical entities in a system (node, switch etc.). These physical entities include chassis, slots, modules, backplanes, power supplies, fans, sensors etc.
Features Not Supported in This Release
•
Layer 2 support as an AutoRoute routing node
•
Interworking with Cisco 3810
Service Module Redundancy Support
MGX 8850 (PXM1) provides high-speed native ATM interfaces, which can be configured as ATM UNI ports or trunks. The following table contains redundancy support information for service modules.
Table 2 Service Module Redundancy Support
Front Card Model # Redundancy SupportedMGX-AUSM-8E1/B
1:N redundancy
MGX-AUSM-8T1/B
1:N redundancy
AX-CESM-8E1
1:N redundancy
AX-CESM-8T1
1:N redundancy
MGX-CESM-8T1/B
1:N redundancy
MGX-CESM-2T3E3
1:1 redundancy
AX-FRSM-8E1
1:N redundancy
AX-FRSM-8E1-C
1:N redundancy
AX-FRSM-8T1
1:N redundancy
AX-FRSM-8T1-C
1:N redundancy
MGX-FRSM-HS2
1:1 redundancy
MGX-FRSM-HS2/B
with HSSI back card, 1:1 redundancy
with 12IN1-8S back card, no redundancyMGX-FRSM-2CT3
1:1 redundancy
MGX-FRSM-2T3E3
1:1 redundancy
MGX-FRSM-HS1/B
No redundancy
MGX-RPM-128M/B
1:N redundancy
MGX-RPM-PR-256
1:N redundancy
MGX-RPM-PR-512
1:N redundancy
MGX-VISM-8T1
1:N redundancy
MGX-VISM-8E1
1:N redundancy
MGX-VISM-PR-8T1
1:N redundancy
MGX-VISM-PR-8E1
1:N redundancy
Note
Support for 1:N redundancy is provided in conjunction with an MGX-SRM-3T31 card, an MGX-SRME2 or an MGX-SRME/B3 card.
1 SRM-3T3 cards only support bulk Distribution for T1 lines.
2 Bulk Distribution is supported for T1 and E1 lines using the SRME card.
3 The SRME/B card supports Bulk Distribution for T1 and E1 lines on the same backcards as.the SRME card supports and adds support for Bulk Distribution for T3 lines on the MGX-BNC-3T3-M backcard.
Network Management Features
Network management features are detailed in the CWM Release 15 Release Notes at: http://cisco.com/univercd/cc/td/doc/product/wanbu/svplus/index.htm
Port/Connection Limits
Connection limits can vary. The table below shows total connections per card, but also shows the number of connections per port with LMI enabled. For example, the new FRSM-HS2/B card using a HSSI back card can support a total of 2000 connections on the card. However, if LMI is enabled on both ports, the total number of connections goes down. If StrataLMI is enabled for one ports, that port supports 560 connections. The other port not configured for LMI can support 1000 connections, for a total of 1560 connections.
Overall, there is a limit of 16,000 connections per shelf.
Refer to Table 3 for detailed connection information.
For the MGX 8230 and MGX 8250 Edge Concentrators, 16,000 connections (PVC) on the PXM1 based PAR Controller. If the MGX is a feeder to a BPX, only 15,729 feeder connections are available—271 connections are reserved for communication between the BPX and MGX. Maximum number of PXM UNI connections supported is still 4000 (as in prior releases).
SNMP MIB
The MIBs provided with Release 1.3.10 are named mgx1rel1310mib.tar.
The MIBs are bundled in the firmware bundle posted to CCO.
Note
The old_mib_Format has been discontinued as of the 1.2.10 release As of the 1.2.10 release the new_mibFormat will be named mgx1rel<releasenumber>mib.tar
Notes and Cautions
The following notes and cautions should be reviewed before using this release.
New Boot Image for FRSM 8T1/E1
There is a new FRSM Boot image for the FRSM-8 cards. The image is only required for the fix for CSCdz18745.
To upgrade the boot image, please follow the procedure in Service Module Upgrades.
Using the restoresmcnf Command
Before using the restoresmcnf command, you must issue a clrsmcnf to make sure that there are no dangling connections after the restoresmcnf command.
Loopback Plug on a HSSI:DTE Interface
Using a loopback plug on a HSSI:DTE interface is not supported and can bring the node down.
UPC Connection Parameters
In Release 1.1.40 and higher, the default PCR is 50 cps, and the default for policing is "enabled." These settings are insufficient for running RPM ISIS protocol over the connection, and with such settings, the ISIS protocol will fail. The PCR value needs to be increased, depending upon the number of interfaces configured for ISIS on the RPM. CLI modification and changes in this release.
Depending upon your connection type, you can use the following CLIs to modify the PCR parameter.
•
cnfupccbr
•
cnfupcvbr
•
cnfupcabr
•
cnfupcubr
ForeSight and Standard ABR Coexistence Guidelines
ForeSight is similar to the rate-based ABR control system in TM 4.0 in that they both use Rate up and Rate down messages sent to the source of the connection to control the rate a connection runs at, based on congestion within the switches along that connections path. Both systems use Resource Management (RM) cells to pass these messages. There are differences between the two systems that need to be considered.
RM Cell Generation
ForeSight is a destination-driven congestion notification mechanism. The destination switch is responsible for generating the RM cells, which defaults to every 100 ms. This means that any rate modifications at the source end happen approximately every 100 ms, and the time delay between the actual congestion at the destination and the source getting to know about it could be 100 ms.
In standard ABR a source generates FRM cells every (nRM) cell intervals, where n is configurable. These are used to pass congestion information along to the destination switch, which then uses this information to generate BRM (Backward RM cells) back to the source A further consideration is that the actual user data flow will be lower for an equivalent rate due to the additional RM cells. Therefore, the more traffic being generated on a connection at any one time, the faster the feedback will be to the source.
There is also a TRM parameter which states that if no RM cells have been generated after this time has passed then one will automatically be sent. Depending upon the speed it is running at, an ABR connection may therefore react faster or slower to congestion than the equivalent ForeSight connection. (for example, if an ABR connection runs at 100 cells per second, and nRM is 32, then approximately three RM cells will be generated per second, or once every 300 msecs. If it runs at 1000 cps then an RM cell would be generated approximately every 30 msecs. In both cases, the equivalent ForeSight connection would generate an RM cell every 100 msec.)
Reaction to Feedback Messages - Rate Up
In ForeSight, in response to a Rate Up cell from the destination, the source increases its rate by a percentage of the MIR for that connection. If we call this percentage the rate increase percentage (RIP), then RIP is configurable at the card level (the default is 10 percent). In the case where MIR is low, the ForeSight rate increase will be slow as it has to increase as a percentage of MIR (rather than CIR).
On a standard ABR connection, in the event of available bandwidth (no congestion) the source increases its rate by a factor of (RIF*PCR). This means the rate increase step sizes are much bigger than for ForeSight for larger values of RIF (RIF has a range of 1/2, 1/4,....,1/32768). If RIF is not configured properly then standard ABR will ramp up its rate much faster and to a higher value. This is aided by the fact that the step sizes are bigger and the step frequency is higher in comparison with ForeSight.
Reaction to feedback messages - Rate Down
In ForeSight on receiving a Rate Down cell from the remote end, the source reduces its current rate (actual cell rate) by 13 percent. The rate decrease percentage (RDP). RDP is configurable at the card level.
In standard ABR, rate decrease is by an amount (RDF*ACR). Currently, the default value of RDF is 1/16 (6.25 percent). This means when this connection co-exists with ForeSight connections, in the event of congestion ForeSight connection reduces its rate by 13 percent whereas standard ABR connection reduces its rate by only 6.25 percent. Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types, then RDF should be changed to 1/8, so that both connections ramp down by the same amount (13 percent).
Fast-Down
In ForeSight if the destination egress port drops any data due to congestion then the destination sends a Fast Rate Down cell. Also, if a frame cannot be reassembled at the egress due to a lost cell somewhere in the network, a Fast-down will be generated. On reception of Fast Rate Down the source reduces its current rate by 50 percent (this is again a card-level configurable parameter).
Standard ABR does not distinguish between drops and the ECN/EFCI threshold being exceeded. This means that, in case of drops in the egress port queue, a standard ABR connection rate reduces by only (RDF*ACR) but the ForeSight connection rate reduces by (ACR*0.5). Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types then Fast Down could be effectively disabled by configuring the reaction to be 13 percent rate down instead of 50 percent.
Guidelines
The two systems will work together within the network, but as the above description suggests, if the differences between the two systems are not taken into consideration, then a ForeSight connection and an ABR connection with the same configuration parameters will not behave the same way within the network.
ABR and ForeSight provide a mechanism for distributing excess bandwidth between connections over and above the minimum rate, therefore if these guidelines are not taken into consideration then the allocation of this excess bandwidth may be biased toward connections running one of these algorithms over connections running the other.
If this is a requirement, the following guidelines may be useful, assuming ForeSight is set to defaults except for Fast Rate Down which is set for 13 percent.
•
Nrm: Nrm needs to be set at a value whereby the approximate RM cell generation is
100 milliseconds, to match that of ForeSight. This calculation is based on the expected average, or sustained, cell rate of the connection. However, if the (potential) fast-down messages from ForeSight are left to equate to 50 percent rate down, then an estimate of how often this may occur needs to be made and factored into the equation. If the connection receives Fast-down messages, then this would make the ForeSight connection react faster than the equivalent ABR connection to congestion. To compensate for this, Nrm needs to be set at a value of less than 100 msecs, a suggested value to aim for is between 60-70 msecs (this would be approximate as n is configurable in steps of 2**n). This would mean that, in the event of congestion, the ABR connection would start to react faster.•
RIF: Rate increase factor is a factor of PCR in ABR and MCR in ForeSight. The default RIF for ForeSight is MCR*.10. Therefore, RIF should be configured so that (PCR*RIF) approximates MCR*0.1. If Fast-Down is still effectively enabled, then PCR*RIF should approximate MCR*0.62 to compensate.
•
RDF: (Rate Decrease Factor) RDF should be 1/8. This approximates to 13 percent that ForeSight uses.
The following worked examples may help explain this further
Assume a network is currently running ForeSight with default parameters, and supports the following four connection type, where CIR = MIR, PIR = port speed, and QIR = PIR:
T1 Port Speed 64K CIR
Example:
CIR = MIR = 64K
PIR = QIR = port speed = 1544
Fastdown = 13%(The calculation used to convert between frame based parameters (CIR, PIR, and so on.) and their equivalent cell-based parameters is FR_param *3/800. This allows for cell overheads, and so on. based on frame sizes of 100 octets.)
CIR = MIR = (64000*3/800) = 240 cps
PIR = QIR = (1544 *3/800) = 5790 cpsForeSight ABR
Rate-up equals (240*.1) = 24 cps RIF equals x where (1590/x) = 24 cps
X needs to be approx 200
RIF equals 256 (nearest factor of 2)RDF equals 13% RDF = 1/8
Nrm equals 100 msecs Nrm equals 32RM cells will be generated somewhere between 6 (5790 cps approx equal to 32 cells per 6 msecs) and 133 msecs (240 cps approx equal to 32 cells every 133 msecs) depending on ACR.
Node Related
•
A maximum of one BERT test can be performed per bay at any point in time. The command addln should be issued before executing the addapsln command.
•
If you are moving service modules from an existing MGX 8220 platform to the MGX 8850 (PXM1), MGX 8250, or MGX 8230, the MGX 8220 service modules (AX-FRSM-8T1/E1, and AX-CESM-8T1/E1) need to have the boot flash upgraded to MGX 8220 Release 5.0.00 common boot code (1.0.01 version) before they can be plugged in to the MGX 8850 (PXM1), MGX 8250, or MGX 8230 chassis. All MGX 8220 service module versions that use Release 4.0.xx of boot code and earlier are not supported in the MGX 8850 (PXM1), MGX 8250, or MGX 8230.
If loading of the correct common boot code image is required then it will have to be performed on an MGX 8220 chassis, and cannot be performed on an MGX 8850 (PXM1), MGX 8250, or MGX 8230 chassis. Please refer to the procedure below, which is also outlined in the Cisco MGX 8850 (or MGX 8250 /MGX 8230) Installation and Configuration publication on the documentation CD.
Step 1
Use ftp to port the MGX 8220 Release 5 common boot image for the service module to a workstation.
Step 2
Plug in the card into the MGX 8220 shelf.
Step 3
Download the proper MGX 8220 shelf Release 5.0 boot image using the following commands from the workstation:
tftp <ip address of the MGX 8220 shelf >binput <boot filename> AXIS_SM_1_<slot#>.BOOTTo insure that TFTP downloaded the appropriate boot code, perform the following procedure to verify the flash checksums.
Step 1
Log into the shelf.
cc <slot #>Step 2
Verify that the two checksums are the same.
chkflashIf not, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 (PXM1) shelf.
CautionIf the checksums are not the same when you remove the service module, then the service module will not boot when it is plugged in and the service module will have to be returned using the Cisco Returned Material Authorization process.
•
Whenever an MGX 8850 is added as a feeder to a BPX 8600, SWSW automatically programs a channel with a VPI.VCI of 3.8 for use as the IP Relay channel. IP Relay is used to send IP data between nodes via the network handler, allowing every node in the domain to be directly addressable via IP addressing and CWM workstations to communicate with every node (especially feeders) using TELNET, SNMP and CWM protocols. If the user tries to add a channel with a VPI.VCI of 3.8, the BPX 8600 does not prevent the user channel from being added, but the MGX 8850 rejects it. To delete the added channel on the BPX 8600, and to get IP relay working you need to reset the BXM card.
•
In addition to clearing the entire configuration, clrallcnf command clears the network IP addresses. IP addresses and netmasks stay the same (dspifip). However, Cisco recommends entering the cnfifip command to reconfigure the network IP addresses. Network IP is gone (dspnwip), and must be re-configured using the cnfifip command. Refer to the entry on cnfifip in the Cisco MGX 8850 Command Reference for syntax.
•
Service module upgrades error handling is not provided. If the user skips any of the steps during upgrade or if a power failure happens in the middle of the upgrade, results will be unpredictable. See the Special Installation and Upgrade requirements section for service module upgrades. To recover from procedural errors contact your TAC support personnel.
•
The MGX 8850 (PXM1) supports 15 simultaneous Telnet sessions and up to 10 TFTP sessions per shelf.
•
You must use the following Y-cables for FRSM-HS2 and FRSM-CT3 redundancy as specified in the Product Orderability Matrix (Straight Cable: 72-0710-01, Crossover Cable: 72-1265-01, Straight Y-cable: FRSM-HS2: CAB-SCSI2-Y, FRSM-CT3: CAB-T3E3-Y). Other cables are not supported.
Y-cable redundancy for FRSM-HS2, FRSM-2CT3, FRSM-2T3, FRSM-2E3 is supported only for adjacent slots.
•
There is no need to issue the syncdisk and shutdisk commands before removing the PXMs. The system quiesces the disk by detecting the removal of the PXM board and flushes the write buffers to the disk and puts the PXM in sleep mode. This disables any further hard disk access by locking the actuator.
Note
When the card is reinserted the PXM automatically comes out of sleep mode.
CautionCooling and Power limitations: Be aware of the need for extra power supplies and fans beyond certain limitations. A single fan tray will support all configurations that draw between 1200 and 1400 watts. For power requirements, the MGX 8850 (PXM1) requires a minimum of one power supply per line cord to support the power requirement for five cards (see Table 4).
Table 4 Number of Power Supplies Per Line Cord Based on Cards Supported
0-5 Cards 6-10 Cards 11 and AboveSingle Line Cord (N+1):
2
3
4
Dual Line Cord (2N):
2
4
6
This is based on an estimated worst-case power requirement of 190W plus margin per card slot.
Connection Management Related
•
The name of the node cannot be changed if there are PVCs. The node name must be changed from the default value before adding connections, since it cannot be changed later. Use the cnfname command to change the node name.
•
Only one feeder trunk can be configured. No BNI trunk to MGX 8850 (PXM1) as a feeder is supported.
•
The slave end of a connection must be added first.
The slave end cannot be deleted and re-added back by itself. If you delete the slave end, the entire connection must be completely torn down and re-added back. If the slave end of the connection is deleted and re-added back by itself, then unpredictable results will happen.
•
For user connections, VCI 3 and VCI 4 on every VPI are reserved for VPC OAMs.
•
The actual number of feeder connections you can provision on the PXM is always two less than you have configured. The dsprscprtns command shows max connections as 32767, but you can only use 32767 - 2 = 32765. One connection is used for LMI and another one for IP relay.
•
There is no error handling detection while provisioning through the CLI. Invalid endpoints and unsupported connection types (such as connections between FRSM-CESM ports or connections between structured and unstructured connections) are permitted using the CLI. The user should not configure these connections.
•
The sum of CIR of all channels of a port can be greater than port speed as long as CAC is disabled. However, it is not acceptable for one channel's CIR to be greater then port speed even if CAC is disabled. Two channels added up can exceed port speed. This means you cannot oversubscribe a port if only one channel is configured.
•
When trying to add a port on DS0 slot 32 of a CESM-8E1 line using an SNMP set or the CiscoView Equipment Manager, the SNMP agent in CESM will time out, without adding the port. The SNMP libraries treat the 32 bit DS0 slotmap (cesPortDs0ConfigBitMap) as an integer. The value for the last DS0 is treated as the sign value. This causes a corruption in the packet coming to the agent. As the agent does not receive a complete SNMP packet, it does not respond and times out. Use the command line interface to add a port on DS0 slot 32 of a CESM-8E1 line.
•
The cnfport command does not allow VPI ranges to be reduced. The cnfport command only allows the VPI range to expand. The correct sequence is to delete all connections on the partitions, delete the partitions, delete the port, and add the port with new VPI range.
•
On an FRSM-2CT3, one can add 128 ports on a group of 14 T1 lines as indicated below.
–
lines 1 to 14: 128 ports (A)
–
lines 15 to 28: 128 ports (B)
–
lines 29 to 42: 128 ports (C)
–
lines 43 to 56: 128 ports (D)
So, to add 256 ports on one T3: add 128 ports on the first 14 T1 lines and the remaining 128 on the next 14 T1 lines.
•
Note that (A) and (D) are connected to first FREEDM and (B) and (C) are connected to the second FREEDM. Each FREEDM supports only 128 ports. If 128 ports are added on one T3 as in (A), then there cannot be any more ports as in (D). The 129th port should be on lines 15 to 42 (as in B or C).
•
If the user adds a connection between an RPM and a PXM and then deletes the connection, the RPM shows no connection but the PXM still has the connection. The MGX was designed and implemented in such a way that only the connections that have the master end show up on PXM (by dspcons command). Consider these three connections:
•
c1: has only slave end
•
c2: has only master end
•
c3: has both master and slave end
When using the dspcons command, c2 and c3 will be displayed, not c1. The connection will not show up once the master end (PXM) is deleted. Recommendation: When adding a connection, if one end of the connection is PXM, always configure the PXM side to be the slave. Thus when deleting the RPM side, which is the master, the connection will not show up on the PXM. However, keep in mind that the slave end (PXM) still exists. This also provides a side benefit. When a connection exists with only the slave side, no bandwidth is occupied. The bandwidth is reserved only if the master end exists (with or without the slave).
Documentation Corrections
The documentation for the PXM1-based MGX switches incorrectly describes the cellbus to slot assignments.
For example, the MGX 8250 with a PXM1 has 8 cellbuses. The distribution of these 8 cellbuses to the appropriate slot numbers can be found executing the CLI command dspcbclk.
m8250-4a.1.8.PXM.a > dspcbclkCellBus Rate (MHz) Slot AutoClkMode--------------------------------------------------CB1 21 1, 2 disableCB2 21 3, 4 disableCB3 21 5, 6 disableCB4 21 17 - 22 disableCB5 21 9, 10 disableCB6 21 11, 12 disableCB7 21 13, 14 disableCB8 21 25 - 30 disableLimitations
clrsmcnf
As a speedy way to wipe out all configuration on an SM, you can use clrsmcnf. This command works in the following scenarios:
•
SM not in slot
•
SM in slot and in active (good) state
•
SM in slot but in failed state, boot state or another state.
To be able to use an SM of a different type from the current one in a slot you can also use clrsmcnf for example, if there is a FRSM8T1/E1 in the slot with some configuration and the customer wants to use this slot for an AUSM8T1/E1 card.
The following are NOT supported on the MGX 8850 (PXM1), MGX 8250, and MGX 8230:
•
Saving a configuration of an SM from one shelf and restoring it to the same slot on another shelf.
•
Saving a configuration of an SM in a slot and restoring it to another slot of the same card type.
Note
As designed, if RPM-PR is configured as a Label Switch Controller (LSC), execution of the clrsmcnf command on those LSC slots will be rejected.
Problems after Power Cycle
This limitation pertains to configurations on MGX 8250 and MGX 8230 nodes with RPM-PR cards.
Following a power cycle, some configurations of MGX 8230 or MGX 8250 may display problems. (The booting of some service modules, RPM-PR cards and/or the standby PXM1 card are impacted.) The following must be true for this problem to occur:
1) RPM-PR cards must have configuration on the PXM HD.
2) There have to be RPM-PR cards on the shelf.
3) There have to be SRM cards on the shelf.
4) There has to be core card redundancy
The workaround is to reset the impacted card(s) to clear the problem (see CSCeb02400).
Known Anomalies for Platform Software Release 1.3.10 and Service Module Firmware
Table 5 lists known anomalies in the service module firmware and the Release 1.3.10 software as of 08/23/04. 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.
Resolved Anomalies for Platform Software Release 1.3.10 and Service Module Firmware
Table 6 lists resolved anomalies in the service module firmware and the Release 1.3.10 software as of 08/23/04. Included with each is the headline tied to the particular problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Resolved Anomalies for Platform Software Release 1.3.00 and Service Module Firmware
Table 7 lists resolved anomalies in the service module firmware and the Release 1.3.00 software as of 04/14/04. Included with each is the headline tied to the particular problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Compatibility Notes
MGX 8230, MGX 8250, and MGX 8850 (PXM1) Software Certification with Other Products
Table 8 lists how MGX software version 1.3.10 interoperates with other products.
Boot File Names and Sizes
Table 9 displays the boot file names and sizes for this release.
MGX 8250 and MGX 8850 (PXM1) Firmware Compatibility
The firmware compatibility matrix for this release is presented in Table 10.
MGX 8230 Firmware Compatibility
The MGX 8230 firmware compatibility matrix for this release is presented in Table 11.
MGX 8850 (PXM1), MGX 8250, and MGX 8230 Release 1.3.10 Hardware
Table 12 shows the front card and back card compatibility for the hardware supported in this release. The table lists the card model/ name, part numbers, the minimum version and the minimum revisions of each card supported in Release 1.3.10. Note that there may be more than one 800 level part numbers for the same front cards. The minimum version is identified by the last 2 digits of the 800 level numbers.
]
Special Installation and Upgrade Requirements
Existing customers should use the upgrade procedure Service Module Upgrades to upgrade. A graceful upgrade from any release previous to the current release is supported. For new customers, the image will be pre-installed and should use the PXM installation procedure to upgrade to future maintenance releases.
A graceful upgrade from any release previous to the current release is supported (for example, MGX 1.1.3x, 1.1.4x or 1.2.2x to MGX 1.3.10), but a graceful downgrade is not supported. Abort or fallback to the previous release is supported at any stage during the upgrade. For abort instructions, refer to Instructions to Abort PXM Upgrade.
Special Instructions for Networks Containing FRSM-2-CT3
When upgrading from any release prior to Release 1.1.32, under certain conditions with the FRSM 2 CT3, a script must be ran in order to properly upgrade the software. The script resolves the FREEDM buffer issue described in anomaly CSCds66176; namely, that ports are lost sometimes after softswitch or resetcd. The algorithm to allocate FREEDM buffers was changed in order to fix this anomaly. Because of the algorithm change, ports might be lost when upgrading from a release (FRSM version < 10.0.22) with the older algorithm. The script identifies cards which will lose ports if the card is upgraded to Release 1.1.32 or greater.
A README file contained in the Release bundle TAR file located on CCO describes how to run the script and shows an example of the script output.
Executing the Script
Execute the script:
•
On all shelves with FRSM-2CT3 prior to an upgrade from any version to Release 1.1.32 (FRSM VHS version 10.0.22) or higher.
•
For upgrades from releases prior to Release 1.1.32 for the MGX 8250, MGX 8230, or MGX 8850. To fix this issue, an algorithm change was made in Release 1.1.32 (10.0.22 version of FRSM 2 CT3).
Script Functionality
The script applies the new algorithm for buffer allocation to existing ports to determine if all the ports will remain intact during the upgrade process. After application of the new algorithm, a log file is created for each FREEDM chip on all the FRSM 2CT3 cards on the shelf. The log file contains confirmation that the buffer allocations are OK or NOTOK. If the log file contains NOTOK for a card, then upgrading the card to the new release will cause the card to lose ports. Therefore, ports must be moved to another card before upgrading this card.
Upgrade Procedure for Non-Redundant PXM
Upgrading a switch with non-redundant PXMs is an ungraceful upgrade. An ungraceful upgrade from any release previous to the current release is supported (for example, MGX 1.1.3x, 1.1.4x or 1.2.2x to MGX 1.3.10).
Step 1
Save your current configuration.
saveallcnfStep 2
Get the filename by listing the CNF directory:
node-prompt> ll "C:/CNF"size date time name-------- ------ ------ --------512 APR-08-1999 08:16:18 . <DIR>512 APR-08-1999 08:16:18 .. <DIR>512 APR-09-1999 05:26:42 TMP <DIR>45433 APR-09-1999 05:28:42 NODENAME_0409990528.zip45433 APR-09-1999 05:28:42 NODENAME.zipIn the file system :total space : 819200 K bytesfree space : 787787 K bytesStep 3
On the workstation, upload the saved configuration to the workstation:
unix-prompt> tftp <shelf.ip.address>tftp> bintftp> get CNF/NODENAME_0409990528.zipReceived 45433 bytes in 0.4 secondsStep 4
Download the release to upgrade PXM Backup boot image to the PXM. For example:
unix-prompt> tftp <node_name or IP address>tftp> bintftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BTtftp> quitStep 5
Download the release to upgrade PXM runtime image to the PXM. For example:
tftp> <node_name or IP address>tftp> bintftp> put pxm_<new_rel>.fw POPEYE@PXM.FWtftp> quitStep 6
Download the ComMat.dat file to the C:/FW directory of the Active PXM. Enter the TFTP put command:
tftp <node_name or IP address>tftp> bintftp> put ComMat.dattftp> quitStep 7
On the PXM type the following when the transfer is done:
PXM.a> copy ComMat.dat /FW/ComMat.datStep 8
Enter install bt <new_rel>.
Step 9
Enter install <new_rel>. At the end of the display, enter yes.
PXM.a> install <new_rel>redundancy is not availablethe other card is not availableyou are not in redundant mode,do you want to try an ungraceful upgrade(yes or no)?yes
Upgrade Procedure for Redundant PXMs
This section applies to upgrades from 1.1.34 and all later releases.
CautionDo not remove old firmware until the upgrade is done.
Note
First you must ensure that the shelf IP address and the PXM IP address are set. The PXM must have its own unique IP address and there must be a another unique IP address for the shelf.
Step 1
Save your current configuration.
saveallcnfStep 2
Get the filename by listing the CNF directory:
node-prompt> ll "C:/CNF"size date time name-------- ------ ------ --------512 APR-08-1999 08:16:18 . <DIR>512 APR-08-1999 08:16:18 .. <DIR>512 APR-09-1999 05:26:42 TMP <DIR>45433 APR-09-1999 05:28:42 NODENAME_0409990528.zip45433 APR-09-1999 05:28:42 NODENAME.zipIn the file system :total space : 819200 K bytesfree space : 787787 K bytesStep 3
On the workstation, upload the saved configuration to the workstation:
unix-prompt> tftp <shelf.ip.address>tftp> bintftp> get CNF/NODENAME_0409990528.zipReceived 45433 bytes in 0.4 secondsStep 4
Verify that one PXM is Active and the other Standby.
Step 5
From the workstation, download the PXM Backup boot image.
unix-prompt> tftp <pxm.ip.address>tftp> bintftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BTtftp> quitStep 6
From the workstation, download the PXM FW.
unix-prompt> tftp <pxm.ip.address>tftp> bintftp> put pxm_<new_rel>.fw POPEYE@PXM.FWSent 1982672 bytes in 18.3 secondsMake sure that the transfer is successful by looking at the message displayed on the PXM console after the transfer:
Program length = 1982672Calculated checksum = 0xd9779bc6 stored checksum = 0xd9779bc6Fw checksum passed
Note
Bytes sent, program length, and receive time vary per release. Also, see the Compatibility Matrixes for current file sizes and file names.
Step 7
Download the ComMat.dat file to the C:/FW directory of the Active PXM. Enter the TFTP put command:
unix-prompt> tftp <node_name or IP address>tftp> bintftp> put ComMat.dattftp> quitStep 8
After the transfer is done, type the following on the PXM:
PXM.a> copy ComMat.dat /FW/ComMat.datStep 9
Enter the command install bt <new_rel>.
Step 10
Enter the command install <new_rel>.
Step 11
After the Standby card is reset and successfully enters the hold state, on the Active PXM, enter the command newrev <new_rel>.
The Active card will be reset and go to hold state.
After the newrev, enter the command dspcd to show the firmware revision on the new, active PXM.
CautionIf at this stage (after newrev) the upgrade needs to be aborted, follow the instructions under "Instructions to Abort PXM Upgrade."
During the graceful upgrade procedure, if after the newrev command the non-active card enters the "MISMATCH" state, do the normal commit command. You will get a warning message:
other card not found,
do you still want to complete the commit operation
Answer yes and then reset the non-active card.
If you get the MISMATCH during the upgrade process, after you finish, you will still have the MISMATCH. To correct the mismatch, you must check your back cards; they must be identical.
Step 12
After the Active PXM is reset and successfully enters the hold state, on the new Active PXM, enter commit <new_rel>.
Instructions to Abort PXM Upgrade
A graceful downgrade is not supported. However, abort or fallback to the previous release is supported at any stage during the upgrade. The following procedure should be used to abort to a previous release.
Aborting an Upgrade from Release 1.1.3x and Above
If the upgrade needs to be aborted for any reason during the upgrade process from release 1.1.3x and above, follow these instructions.
Step 1
Execute abort <release no>
PXM.a> abort <release no>
Aborting an Upgrade from Release 1.1.2x
If the upgrade needs to be aborted for any reason during the upgrade process from release 1.1.2x, follow these instructions.
Step 1
If the abort is required before the newrev command is entered, skip to Step 8.
Step 2
Enter the following commands if the upgrade process is past the newrev stage.
Step 3
On the Active PXM, enter shellConn
Step 4
Enter smCardMibVer = 21
Step 5
Enter saveDBToArchive <PXM SlotNo>, 0
Step 6
Enter uploadBram <PXM SlotNo>, <PXM SlotNo>
The <PXM SlotNo> should be 7 for the MGX 8850 (PXM1) switch and for the MGX 8250 switch (even if the Active PXM is in slot 8, use slot 7).
The <PXM SlotNo> should be 1 for the MGX 8230 switch (even if the Active PXM is in slot 2 use slot 1).
The example that follows is for the MGX 8850.
PXM.a > shellConn-> smCardMibVer=21-> saveDBToArchive 7, 0-> uploadBram 7, 7Step 7
If RPM cards also are on this node, perform the following for each RPM card:
Inside shellConn on Active PXM, enter:
saveDBToArchive <RPM_slot#>, 1
d &arcMem+<RPM_slot#>*4
Copy down the 4 byte address that is displayed after executing the d&arcMem+<RPM_slot#>*4 command and enter it in the following command.rmSlotArchFileSave <RPM_slot#>, <4 byte address>
For example, for an RPM in slot 9, the result is:-> d &arcMem+36d &arcMem+368051cb90: 8702 bad8 0000 0000 0000 0000 * ..........*8051cba0: 0000 0000 0000 0000 0000 0000 0000 0000-> rmSlotArchFileSave 9,0x8702bad8Step 8
Execute abort <release no>.
PXM.a> abort <release no>
Service Module Boot/Firmware Download Procedure
The following procedure describes how to download the boot and the service module firmware for slot-independent and slot-dependent images.
Step 1
Download the boot image for the service module onto the PXM hard disk.
unix-prompt> tftp <node_name or IP address>tftp> bintftp> put <backup boot> POPEYE@SM_1_0.BTtftp> quitStep 2
Download the boot image onto the respective service module using the command:
install bt sm <slot #> <version>
Repeat for each of the service modules on the node.
Step 3
Now, choose instruction for slot-independent or slot-dependent firmware. See below.
For slot-independent image:
Download the selected revision of service module firmware onto the PXM hard disk.
unix-prompt>tftp <node_name or IP address>tftp> bintftp> put <FW file> POPEYE@SM_1_0.FWtftp> quitYou cannot do two puts in the same TFTP session.
Repeat for each service module type and for each slot-independent firmware.
For slot-dependent image:
For a slot-specific image (in this example the service module is tied to slot 1),
unix-prompt> tftp <ip address of the MGX 8850 shelf>tftp> bintftp> put <sm FW file name> POPEYE@SM_1_1.fw
Note
If the checksums are not the same when you remove the service module then the service module will not boot when it is plugged in and the service module will have to be RMA'ed.
Note
Please consult your Support Representative before performing any software upgrade.
Manual Configuration of Chassis Identification
MGX as a Standalone Node
If any MGX box is to be used as a standalone node for testing, the intended model number from the PXM firmware configuration should be matched MANUALLY by running the "runConfigurator" utility.
Example: node1 was running 1.1.24 as a 8850 node:
If the node's model number is set to 8250 by default after a 1.1.32 firmware upgrade, but the node1 is still configured as a 8850 standalone node on the CWM side, then CWM will reject the node on discovery, and the node will remain undiscovered.
Solution: On every standalone node, manually verify that the runConfigurator settings match the switch.
Chassis Identification During a Firmware Upgrade
On the CWM side, the emd.conf must be modified to a one second wait time so it can help clean up the emc process's internal cache and CWM database (regarding any slot that has sent the functional removal trap). This ensures that CWM will sync up whatever is current with the switch after the upgrade.
Before a firmware upgrade is begun, complete the following steps:
Step 1
Change the following line in emd.conf:
"Hold for 300 secs before deleting the card after a func module trap is received".
to
"Hold for 1 secs before deleting the card after a func module trap is received".
Note
This prevents race conditions in updating the database table from the firmware version upgrade.
Step 2
After emd.conf is changed, send HUP signals to all EMC processes.
Step 3
After the firmware upgrade is complete, reset the hold time back to 300 seconds.
Step 4
Send HUP signals to EMC processes to confirm the changeback.
Interoperability of Service Modules on MGX 8220 and MGX 8250 Switches
CautionGraceful downgrade for the Service Module is not supported.
If you are moving service modules from an existing MGX 8220 platform to the MGX 8850, the MGX 8220 service modules (AX-FRSM-8T1/E1, and AX-CESM-8T1/E1) need to have the boot flash upgraded to MGX 8220 Release 5.0.00 common boot code (1.0.01 version) before they can be plugged in the MGX 8850 chassis. All MGX 8220 service module versions that use Release 4.0.xx of boot code and earlier are not supported in the MGX 8850.
SPARE DEPOT: Customers receiving a replacement service module via the TAC (through the RMA process) will have the common boot code image that works for MGX 8220 Release 4.x, 5,x, and MGX 8850 installed on legacy service modules. (Spare service modules received directly from manufacturing through the normal ordering process will have the correct boot code image already loaded.)
If loading of the correct common boot code image is required then it will have to be performed on an MGX 8220 chassis, and cannot be performed on an MGX 8850 chassis. Please refer to the procedure below, which is also outlined in the Cisco MGX 8850 Installation and Configuration Guide on the documentation CD.
Use ftp to port the Axis 5 common boot image for the service module to a workstation.
Plug in the card into the MGX 8220 shelf.
Download the proper MGX 8220 shelf Release 5.0 boot image using the following commands from the workstation:
unix-prompt> tftp <ip address of the MGX 8220 shelf >tftp> bin1tftp> put <boot filename> AXIS_SM_1_<slot#>.BOOTkjNow you must insure that TFTP downloaded the appropriate boot code by verifying the flash checksums.
Login to the shelf.
unix-prompt> tftp cc <slot #>tftp> chkflashVerify that the two checksums are the same.
If NOT, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.
Service Module Upgrades
The following steps need to be followed for service module upgrades. Service module firmware images cannot be downloaded as specific versions, because only 1 slot independent image can be present on the disk. Hence, the user cannot revert back during the installation process.
Step 1
Download the service module firmware to the shelf. Refer to Service Module Boot/Firmware Download Procedure.
Note
To upgrade all the service modules, load all the firmware files and boot files to the node. Then execute the command resetsys. Make sure that the configuration is saved.
Step 2
For non-graceful upgrades, just reset the card and the service module will come up with the new image.
Step 3
Enter the following command to install the service module boot file:
install bt sm <slot> <version>where <slot> is the service module that is being upgraded
and <version> is the service module image on the disk.
Step 4
For graceful upgrades, a secondary card should be backing up the service module that needs to be upgraded. Configure the redundancy and enter the following command:
install sm <slot> <version>where <slot> is the service module that is being upgraded
and <version> is the service module image on the disk.
Note
The concept of version is redundant here, since there is only one service module image on the disk. However we do check that the version given by the user matches the image on the disk to make it consistent with PXM upgrade/downgrade.
newrev sm <slot> <version>where <slot> is the service module that is being upgraded
and <version> is the service module image on the disk.
commit sm <slot> <version>where <slot> is the service module that is being upgraded
and <version> is the service module image on the disk.
Note
There is no abort command for service module upgrade.
MPSM 8-port T1/E1 Licensing Overview
A description of the MPSM 8-port T1/E1 hardware is available in the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, Cisco MGX 8830, and Cisco MGX 8880 Hardware Installation Guide, Releases 2 Through 5 online. For general information on configuration of the MPSM 8-port T1/E1 in general, and general information on configuration of the licensing feature, refer to Chapter 9 in the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, Cisco MGX 8830, and Cisco MGX 8880 Configuration Guide, Release 5 online.
Refer to the following section for licensing alarm information specific to PXM1-based MGX switches.
MPSM License Alarms
MPSM feature license alarms can occur at the node level or the slot level of the switch. The following sections describe these alarms:
Node License Alarm
Node license alarms are raised when the count of the feature licenses in the PXM license pool database on the switch is considered invalid.
Node license alarms can happen under the following conditions:
•
A switch configuration that was saved before licenses were added or transferred to and from the PXM license pool has been restored. Any mismatch between the actual license count and the restored license count generates a minor license alarm. To prevent this type of alarm, always save the switch configuration after you move, transfer, or add licenses.
•
The switch configuration is restored on a different node, or the Cisco MGX chassis is replaced with another chassis. Because licenses are authorized for a specific backplane serial number, such conditions will cause a mismatch between the physical backplane serial number and serial number recorded in the database.
When a node license alarm is raised, all cards that are using feature licenses go into the slot license alarm state. If no licenses are in use by the cards, no slot license alarms will be raised.
On PXM1 platforms, use the PXM dspcd command to troubleshoot the node license alarm. As shown in the following example, if the switch is in the node license alarm state, the cardIntegratedAlarm will be minor and the cardMinorAlarmBitMap will indicate License Alarm:
M8850_R1.1.7.PXM.a > dspcdModuleSlotNumber: 7FunctionModuleState: ActiveFunctionModuleType: PXM1-OC3FunctionModuleSerialNum: SAG05304YHHFunctionModuleHWRev: D0FunctionModuleFWRev: 1.3.10.065FunctionModuleResetReason: RestoreallcnfLineModuleType: PXM-UILineModuleState: PresentSecondaryLineModuleType: SMFIR-4-155SecondaryLineModuleState: PresentmibVersionNumber: 1.2.20configChangeTypeBitMap: No changescardIntegratedAlarm: MinorcardMajorAlarmBitMap: ClearcardMinorAlarmBitMap: License AlarmBkCardSerialNum: SBK042501CNTrunkBkCardSerialNum: SBK05070188FrontCardPCBNumber: 800-06229-04TrunkBkCardPCBNumber: 800-05351-01UIBkCardPCBNumber: 800-03688-01SrmBackCardPCBNumber: Not ApplicableM8850_R1.1.7.PXM.a >Node license alarms are cleared by validating licenses in the license pool. This is done by applying the special Rekey feature license to the node using the cnflic command. When the pool licenses are validated, any existing slot license alarms are also cleared and normal operation is restored. For the procedure to rekey feature licenses, see the "Rekeying Feature Licenses" section in Chapter 9 of the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, Cisco MGX 8830, and Cisco MGX 8880 Configuration Guide, Release 5 online.
Note
If the switch is in node license alarm, you must rekey the PXM license pool before proceeding with any other license management tasks. Failure to resolve node license alarms can lead to the invalidation of previously generated license keys due to sequence number mismatches.
Slot License Alarms
Slot license alarms are raised under the following conditions:
•
The node license alarm has been raised indicating an invalid count of licenses in the PXM license pool database. When a node license alarm is raised, all cards that are using feature licenses go into the slot license alarm state. Slot license alarms raised under this condition can be cleared by rekeying the PXM license pool. For the procedure to rekey feature licenses, see the "Rekeying Feature Licenses" section in Chapter 9 of the Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, Cisco MGX 8830, and Cisco MGX 8880 Configuration Guide, Release 5 online.
•
The slot in alarm has acquired or oversubscribed one or more licenses while these licenses were not available in the license pool. For example, on the PXM1 platform this situation might occur when a card is configured to use licenses, the card slot configuration is removed with the clrsmcnf command, the licenses are assigned to another card, and then the card slot configuration is restored. Slot license alarms raised under this condition are cleared by adding the required number of licenses to the PXM license pool or by releasing corresponding licenses from other slots so that they become available to the slot in alarm. If slots in alarm have redundancy, you must add licenses to cover both the primary and secondary slots to clear the alarms.
On PXM1 platforms, use the PXM dsplicalms command to troubleshoot slot license alarms. The output of this command will indicate which MPSM cards are in the slot license alarm state. The following example shows the output of the PXM dsplicalms command on the PXM1 platform. In this example, the MPSM card in slot 22 is in slot license alarm:
M8850_R1.1.7.PXM.a > dsplicalmsSlot Critical Major Minor || Slot Critical Major Minor---- -------- ------- ------- || ---- -------- ------- -------1 0 0 0 || 17 0 0 02 0 0 0 || 18 0 0 03 0 0 0 || 19 0 0 04 0 0 0 || 20 0 0 05 0 0 0 || 21 0 0 06 0 0 0 || 22 0 0 17 0 0 0 || 23 0 0 08 0 0 0 || 24 0 0 09 0 0 0 || 25 0 0 010 0 0 0 || 26 0 0 011 0 0 0 || 27 0 0 012 0 0 0 || 28 0 0 013 0 0 0 || 29 0 0 014 0 0 0 || 30 0 0 015 0 0 0 || 31 0 0 016 0 0 0 || 32 0 0 0M8850_R1.1.7.PXM.a >On PXM1-based platforms, the output of the PXM dspliccd <slot> command also shows if a card is in slot license alarm and displays how much time is left in the alarm grace period and if provisioning is allowed with the addcon command. The following example shows the output of the PXM dspliccd <slot> command of an MPSM-8T1-FRM card in a PXM1 platform in the slot license alarm state:
M8850_R1.1.7.PXM.a > dspliccd 22Card License Alarm: MinorService Module Type: MPSM-8T1E1Service Module Serial Number: SAD073103HHProvisioning Allowed: YesGrace-Period Remaining: 4 Days, 23 Hrs=========================================================Allocated License Type Quantity-------------------- --------RateControl 1=========================================================Programmed License Type Quantity-------------------- --------=========================================================Programmed Licenses Registered: N/ALicense Registration Node: --License Registration Chassis Serial No: --M8850_R1.1.7.PXM.a >On PXM1-based platforms, the MPSM dspcd command will indicate if a card is in slot license alarm. If the card is in the slot license alarm state, the cardIntegratedAlarm will be minor and the cardMinorAlarmBitMap will indicate License Alarm. The following example shows the output of the dspcd command on an MPSM-8T1-FRM card in a PXM1 platform in the slot license alarm state:
M8850_R1.1.22.MPSM8T1.FRM.a > dspcdModuleSlotNumber: 22FunctionModuleState: ActiveFunctionModuleType: MPSM-8T1-FRMFunctionModuleSerialNum: SAD073103HHFunctionModuleHWRev: 02FunctionModuleFWRev: 030.000.004.016-P2FunctionModuleResetReason: Reset by PXMLineModuleType: LM-RJ48-8T1LineModuleState: PresentmibVersionNumber: 102configChangeTypeBitMap: No changescardIntegratedAlarm: MinorcardMinorAlarmBitMap: LICENSE ALARMFront Card InfoPCB PART NO-(800 LEVEL): 800-24473-01PCB PART_NO-(73 LEVEL): 73-9197-01PCB REVISION (800 LEVEL):PCB SERIAL NO: SAD073103HHCLEI CODE: 0MANUFACTURING ENG: 0x0RMA TEST HISTORY: 0x0Back Card InfoPCB PART NO-(800 LEVEL): 000-00000-00PCB PART NO-(73 LEVEL): 00-00000-00PCB REVISION (800 LEVEL): ACFAB PART NO-(28 LEVEL): 28-02011-01PCB SERIAL NO: B75816MANUFACTURING ENG: 0x1CRMA HISTORY: 0x0M8850_R1.1.22.MPSM8T1.FRM.a >On PXM1-based platforms, the output of the MPSM dspliccd command also shows if a card is in slot license alarm. The following example shows the output of the dspliccd command of an MPSM-8T1-FRM card in a PXM1-based platform in the slot license alarm state:
M8850_R1.1.22.MPSM8T1.FRM.a > dspliccdCard License Alarm: MinorService Module Type: MPSM8T1E1Service Module Serial Number: SAD073103HHProvisioning (addcon) Allowed: YES=========================================================Needed License Type Needed Licenses------------------- ---------------RateControl 1=========================================================Allocated License Type Allocated licenses---------------------- ------------------RateControl 1=========================================================Programmed License Type Programmed licenses------------------------ -------------------=========================================================Programmed License Registered: NOLicense registration node: NONELicense registration chassis: NONE=========================================================M8850_R1.1.22.MPSM8T1.FRM.a >
Note
If the switch is in node license alarm, you must rekey the PXM license pool before proceeding with any other license management tasks. Failure to resolve node license alarms can lead to the invalidation of previously generated license keys, due to sequence number mismatches.
When the switch is in slot license alarm, you have a grace period of 5 days (120 hours) to resolve the alarm(s). During the first 4 days (96 hours), traps are sent every 24 hours. For the final 24 hours of the grace period, traps are sent every hour of operation. If the alarms do not get cleared, the following actions are taken:
•
An event is logged indicating the expiration of the grace period for a given slot needing license(s).
•
A trap is sent hourly indicating the expiration of the grace period.
•
The addcon command is blocked on the slot in license alarm until the license alarms are cleared.
Once the PXM license pool has been rekeyed or licenses have been added to the PXM license pool, provisioning is restored and the switch exits the alarm state.
Related Documentation
Note that for Release 1.3.10, the product documents (Command Reference, Overview, and Installation and Configuration Guides) were not updated. Use the Release 1.1.3 documents in addition to the Release Notes for Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Software Version 1.3.10.
Product documentation for MGX 8850 (PXM1) is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/index.htmProduct documentation for MGX 8250 is available at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/index.htm
Product documentation for MGX 8230 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/index.htmProduct documentation for VISM is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/Product documentation for RPM is available at the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/rpm/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/rpm/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/rpm/index.htmProduct documentation for AUSM (and ATM services on MPSM 8-port T1/E1) is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/ausm/index.htm
Product documentation for CESM (and circuit emulation services on MPSM 8-port T1/E1) is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/cesm/index.htm
Product documentation for FRSM (and Frame Relay services on MPSM 8-port T1/E1) is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/rel5/frsm/index.htm
Product documentation for MPSM 8T1/E1 hardware is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850px45/hwdoc/hig/index.htm
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.
Obtaining Documentation
Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation on the World Wide Web at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
International Cisco websites can be accessed from this URL:
http://www.cisco.com/public/countries_languages.shtml
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•
Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:
http://www.cisco.com/en/US/partner/ordering/index.shtml
•
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Finding Documentation for Cisco MGX, BPX, SES, and CWM Products
The previous "Ordering Documentation" section applies to other Cisco documentation. Starting in 2003, all documents listed in the "Related Documentation" section are available online only unless stated otherwise.
•
In your browser's URL field, enter www.cisco.com. In the top right search field, enter the complete document part number (for example, enter OL-4538-01, including the -01 suffix). Click on GO.
•
For the Cisco Wide Area Network Manager (CWM) documents, in your browser's URL field, enter http://www.cisco.com/univercd/cc/td/doc/product/wanbu/svplus/index.htm and look for the CWM release number.
•
For all other documents, in your browser's URL field, enter http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm. Look for the switch name and release number. For example, look for MGX 8850 (PXM1E), then Release 5.
Documentation Feedback
You can submit e-mail comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools 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 to
•
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
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.
Inquiries to Cisco TAC 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.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
The Cisco TAC Web Site allows you 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 the following URL:
All customers, partners, and resellers who have a valid Cisco services 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 the following URL to register:
http://www.cisco.com/register/
If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:
http://www.cisco.com/tac/caseopen
If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; 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 will automatically open a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following 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). In addition, please have available your service agreement number and your product serial number.
This document is to be used in conjunction with the Cisco WAN Switching MGX 8850 Release 1, MGX 8250, and MGX 8230 publications.
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. (0404R)
Copyright © 2004, Cisco Systems, Inc.
All rights reserved.
Feedback
