Table Of Contents
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1), Software Version 1.2.13
Features Introduced in Release 1.2.13
Additional PXM1 Stats and NBSM Stats for AUSM and FRSM
Command to Terminate a Telnet Session
Features Not Supported in This Release
MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware
Service Module Redundancy Support
Loopback Plug on a HSSI:DTE Interface
ForeSight and Standard ABR Coexistence Guidelines
CLI Modifications in 1.2.x Baseline
CWM Recognition of RPM-PR and MGX-RPM-128M/B Back Cards
Problems Fixed in Release 1.2.13
Known Anomalies for Platform Software Release 1.2.13 and Service Module Firmware
MGX 8230/8250/8850 Software Interoperability with Other Products
MGX 8250/8850 Firmware Compatibility
MGX 8230 Firmware Compatibility
MGX 8850, MGX 8250, and MGX 8230 Release 1.2.13 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
Service Module Boot/Firmware Download Procedure
Manual Configuration of Chassis Identification
Chassis Identification During a Firmware Upgrade
Interoperability of Service Module on MGX 8220 and MGX 8250 Switches
Historical Information from the 1.2.x Baseline
Features Introduced in Release 1.2.11
RPM Automatic Cellbus Double Clocking
Features Introduced in Release 1.2.10
AUSM-8T1E1 Egress Channel Counters
PXM-UI-S3 Secondary BITS Clocking
Features Introduced in Release 1.2.02
Configuring the Cellbus Clock (CBC) Rate
Features Introduced in Release 1.2.01
Standard ABR on FRSM-VHS Modules
Features Introduced in Release 1.2.00
ITU APS Annex-A, All Configurations Supported on PXM1
Problems Fixed in Release 1.2.11
Problems Fixed in Release 1.2.10
Problems Fixed in Release 1.2.02
Problems Fixed in Release 1.2.01
Problems Fixed in Release 1.2.00
Obtaining Technical Assistance
Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1), Software Version 1.2.13
Contents
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.
Note that for Release 1.2.13, the user documentation (command reference, overview, and installation and configuration guides) were not updated. Use the Release 1.1.3 and 1.2.10 documents in addition to this release note.
Product documentation for MGX 8850 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850Product documentation for MGX 8250 is available at the following URL:http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850
Product documentation for MGX 8230 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850Product documentation for VISM 3.1(0) is available at the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/Product documentation for RPM 1.1 and 1.2.10 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.htmIf 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.2.13
In addition to the following new features, Release 1.2.13 supports all new features introduced in the Release 1.2.x baseline. (See "Historical Information from the 1.2.x Baseline" section.)
Additional PXM1 Stats and NBSM Stats for AUSM and FRSM
Statistics Collection is used to monitor the traffic conditions on the MGX 8250 and MGX 8230 nodes, Statisitics are collected from every Servce Module card at the user specified interval. The Statistical Collection Manager is a CWM feature. For this release, we are adding statistics for the FRSM and AUSM service modules, specifically, the statistics on the MGX-FRSM-VHS, MGX-FRSM-8T1E1 and MGX-AUSM-8 T1E1 service modules, as well as the PXM1.
For more information, refer to the latest CWM release notes.
Command to Terminate a Telnet Session
The delsesn command lets you terminate one or more user-sessions. To see the number of the each active session, use the dspsesn command. Termination takes place immediately upon command execution. Before it proceeds, the CLI warns you that the command is destructive. If you proceed with the deletion, the user whose session is being deleted receives the message, "Forced Logout By <userid> !!!!!!!!!!!," where userid is the user running the delsesn command. Note that you can delete any user-session command with this command. The command syntax is the following.
delsesn <sesn no> [sesn no>] [sesn no>] ...
where
sesn no designates the number of the session in the range 0-15. At least one session number is mandatory, and all others up to a total of 15 are optional. The dspsesn command can provide the user-session numbers.
For example, use the dspsesn command to determine the existing user-sessions. Delete session 2 (user "david9"), then repeat the dspsesn command. Note that the dspsesn output provides a form of the user-session number that delsesn requires: "Session 2."
M8850_NY.7.PXM.a > M8850_NY.7.PXM.a > dspsesnPort Slot Idle UserId From-------------------------------------------------------------telnet.01 * 7 0:00:00 david 10.19.238.35telnet.02 7 0:00:18 david9 10.19.238.35M8850_NY.7.PXM.a > M8850_NY.7.PXM.a > dspsesn-----------------------------------------> Session 0 (console):Waiting for login...-----------------------------------------*> Session 1 (telnet):Executing command: dspsesnuser name: davidaccess level: SERVICE_GPslot: 7slotFallback: 1From: 10.19.238.35-----------------------------------------> Session 2 (telnet):Waiting for user input...user name: david9access level: GROUP1slot: 7slotFallback: 7From: 10.19.238.35M8850_NY.7.PXM.a > delsesn 2WARNING! delsesn is a destructive command it willnon-gracefully delete sessions selected by youDo you wish to proceed ? [y/n] yM8850_NY.7.PXM.a > dspsesn-----------------------------------------> Session 0 (console):Waiting for login...-----------------------------------------*> Session 1 (telnet):Executing command: dspsesnuser name: davidaccess level: SERVICE_GPslot: 7slotFallback: 1From: 10.19.238.35Features Not Supported in This Release
•
Layer 2 support as an AutoRoute routing node
•
MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware
The following MGX 8220 hardware has been superseded by MGX 8850 hardware.
•
•
Service Module Redundancy Support
MGX 8850 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 1 Service Module Redundancy Support
MGX-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
1 Bulk Distribution is supported for T1 lines only on SRM-3T3 cards.
2 Bulk Distribution is supported for T1 and E1 lines using the SRM-E card.
Network Management Features
Network management features are detailed in the CWM Release 11 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 2 for detailed connection information.
For the MGX8230 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 MGX 1 MIB naming convention has been changed as of this release. The new_mibFormat. will now be named mgx1rel1211mib.tar.
The MIBs are bundled in the firmware bundle posted to CCO.
Note
Notes and Cautions
The following notes and cautions should be reviewed before using this release.
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.
•
•
•
•
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.
1.
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.2.
3.
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.
CLI Modifications in 1.2.x Baseline
Table 3 lists the new and modified commands in Release 1.2.x baseline.
Table 3 New/Modified CLI Commands in 1.2.x Baseline
addapsln
The parameter archmode sets the APS architect mode to be used on the working/protection line pairs. The new value "5" is added to specify 5: 1+1 Annex A.
ITU APS Annex-A
SRM-E1addcon
Two new values have been introduced for cesCas type to configure a channel with the multiframe option enabled. The values are ds1SfCasMF and ds1EsfCasMF.
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type, and so on.
CESM2
adddiagtest
Diagnostics.The diagnostic commands are modified for test number 8-SRM M13 Access. This command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot. Refer to the Release Notes for Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Software Version 1.1.40 at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/14/rnotes/rn1140.htm
SRM-E
addlink
Bulk redundancy/distribution. The existing command addlink is modified to link a certain number of T1/E1 channels from a bulk interface on SRM-E to a service module's T1/E1 lines. This command checks the card type of the service module in the target slot. The service module must be a T1/E1 type, depending upon the tributary type configured for the SRM-E line using the cnfln command. A service module will switch all its lines to bulk mode even if only one line is mapped to a tributary from SRM-E.
Note
SRM-E
addln
Existing addln command is modified to support per line interface type configuration (used only with the 12IN1-8S). If the user doesn't specify <interface_type>, the default type V.35 is used.
FRSM-HS2/B
SRM-E
addlnloop
Physical interface. Existing command addlnloop is modified to add a logical loopback on a line on the new card. (SRM-E)
SRM-E
addred
Redundancy activities. The existing command addred is modified to configure redundancy on the new card.
SRM-E
clralldiagtests
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
SRM-E
clralm
Managing alarms. Existing command clralm is modified to clear alarms on a line on the new card.
SRM-E
clralmcnt
Managing alarms. The existing command clralmcnt is modified to clear alarm counts on a line on the new card.
SRM-E
cnfbert
BERT activities. The existing command cnfbert is modified to configure a line or port for BERT and start the test on the new card.
SRM-E
cnfclktype
Existing cnfclktype command is added to FRSM-HS2B to configure line clock type for V.35/X.21 interfaces. This command is valid on the FRSM-HS2B-12IN1 card.
FRSM-HS2/B
cnfdiagparams
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
SRM-E
clrdiagresults
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
SRM-E
cnfclklevel
Permits the user to set the STRATUM level desired. (S-3 Clocking)
PXM-UI-S3
cnfdiagtest
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
SRM-E
cnflink
Bulk redundancy/distribution. The existing command cnflink is modified to configure the link for T1 byte-sync mapping on the new card. For byte-sync mapping on sonet interfaces, the T1 framing format should be configured.
The framing format can be specified at line level for all links using the cnfln command. It can be then overridden on a per link basis using the cnflink command.
Note
SRM-E
cnfln
Existing cnfln command is modified on FRSM-HS2/B to support new MIB objects.
Note
For SRM-E, cnfln command is modified to support new MIB objects and new enumerations for line rate.
For tributary type, option VT2 (carries E1 signals in Sonet) is not supported in this release.
For tributary mapping type, only option, 2 byte-synchronous mapping, is supported for T1.
FRSM-HS2/B
SRM-E
cnfsrmcklsrc
Managing clock sources. Existing command cnfsrmclksrc is modified to support the new SRM-E card.
SRM-E
clrsrmcnf
Managing configuration. The existing command clrsrmcnf is modified to clear all card configuration including distribution links. The configuration cannot be cleared if redundancy is enabled.
SRM-E
delbert
BERT activities. The existing command delbert is modified to delete/terminate the operation in progress on the new card.
SRM-E
deldiagtest
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
SRM-E
dellink, delslotlink
Bulk redundancy/distribution. The existing commands dellink/delslotlink are modified to delete distribution links on the new card. After the last distribution link to a service module is deleted, the service module switches all its lines to non-bulk mode (to its back card).
SRM-E
delln
Physical interface. Existing command delln is modified to disable a line on the new card.
Note
SRM-E
dellnloop
Physical interface. Existing command dellnloop is modified to delete a logical loopback on a line on the new card.
SRM-E
delred
Redundancy activities. The existing command delred is modified to delete the redundancy configuration on the new card.
SRM-E
delsesn
Use this command to terminate a UNIX-based telnet session.
delsesn <sesn no> [sesn no>] [sesn no>] ...
where sesn no is the number of the session in the range 0-15.
PXM3
dspalmcnt
Managing alarms.The existing command dspalmcnt is modified to display alarm counts on a line on the new card.
SRM-E
dspalm
Managing alarms. Existing command dspalm is modified to display alarms on a line on the new card.
SRM-E
dspalmcnf
Managing alarms. Display alarm configuration for a line.
SRM-E
dspalms
Managing alarms. Existing command dspalms is modified to display alarms on all lines of a slot on the new card.
SRM-E
dspapsln
ITU APS Annex-A
SRM-E1dspbert
BERT activities. The existing command dspbert is modified to display the parameters and the results of an ongoing operation on the new card.
SRM-E
dspcd
The dspcd command on the CESM model B card is modified to display "CESM8T1B" next to the Fab number. This can be used to differentiate between CESM model A and B cards.
CLI changes
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type and so on.
CESM2
dspclkinfo
Displays some extra information about second external BITS clock, as shown in the following screen example:
NOEXTCLK2 = OFFextClock2Present = NoLast External Clock2 Present = 1PXM-UI-S34
dspparifs
Displays the existence of interface 7.36 alongwith interface 7.35.
PXM-UI-S34
dspdiagresults.
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
SRM-E
dspdiagtests
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
SRM-E
dsplink, dspslotlink
Bulk redundancy/distribution. The existing commands dsplink/dspslotlink are modified to display distribution links.
SRM-E
dspln
Existing dspln command is modified on FRSM-HS2 B and SRM-E to display new objects.
FRSM-HS2/B
SRM-Edsplns
Existing dsplns command is modified to display interface type.
FRSM-HS2/B
SRM-Edsplog
The command dsplog will include SRME online diagnostics failure if it happens.
SRM-E
dspred
Redundancy activities. The existing command dspred is modified to display the redundancy configuration on the new card.
SRM-E
dspsrmclksrc
Managing clock sources. Existing command dspsrmclksrc is modified to display the card types of the current and previous SRM card.
SRM-E
dspsrmcnf
Managing configuration. The existing command dspsrmcnf is modified to display the current card configuration on the new card.
SRM-E
modbert
BERT activities. The existing command modbert is used to modify BERT parameters.
SRM-E
pausediag
resumediagCommand is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
SRM-E
rundiagtest
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
SRM-E
showdiagtests
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
SRM-E
softswitch
Redundancy activities. The existing command softswitch is modified to manually switch to the redundant module for the SRM-E.
SRM-E
switchapsln
The command is modified to include the following options:
3 = forced working-> protection
4 = forced protection->working
5 = manual working->protection
6 = manual protection-> working
ITU APS Annex-A
SRM-E1
switchback
Redundancy activities. The existing command switchback is modified to switch back to the primary module from the redundant module for the SRM-E.
SRM-E
xcnfalm
Managing alarms.The existing command xcnfalm is modified to configure alarms for a line on the new card. The xcnfalm command allows only DS3 and E3 alarm thresholds to be configured.
SRM-E
xcnfcon
Two new values have been introduced for cesCas type to configure a channel with the multiframe option enabled. The values are ds1SfCasMF and ds1EsfCasMF.
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type, and so on.
CESM2
1 Added in Release 1.2.01.
2 Modified in Release 1.2.01.
3 Added in Release 1,2,13
4 Modified in Release 1.2.10
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, 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 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.
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 publication on the documentation CD.
Step 1
Step 2
Step 3
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
cc <slot #>Step 2
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 shelf.
Caution
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 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
Caution
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 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.
•
•
•
•
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:
•
•
•
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).
Limitations
CWM Recognition of RPM-PR and MGX-RPM-128M/B Back Cards
CWM does not distinguish between the Ethernet back card versions installed with the MGX-RPM-128M/B or RPM-PR. There is no functionality difference.
clrsmcnf
As a speedy way to wipe out all configuration on an SM, you can use clrsmcnf. This command works in the following scenarios:
•
•
•
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. MGX 8250, and MGX 8230:
•
•
Note
Problems Fixed in Release 1.2.13
The following is the list of problems fixed in the service module firmware and the Release 1.2.13 software. 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.
Known Anomalies for Platform Software Release 1.2.13 and Service Module Firmware
The following is the list of known anomalies in the service module firmware and the Release 1.2.13 software. 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.
Guest
