Switch MIB changes of Release 9.3.11, 9.3.20 and 9.3.24 101
Switch MIB changes of Release 9.3.10 101
Switch MIB Changes to Release 9.3.05 104
Switch MIB changes to Release 9.3 105
Default Values 108
Cisco BPX 8600 Nodes 108
BNI-T3 112
BNI-E3 113
BNI-155/155E 114
BXM-T3 115
BXM-E3 116
BXM-155 117
BXM-622 118
Cisco IGX 8400 Nodes 119
UXM-T3 123
UXM-T1-IMA (1 physical line up) 124
UXM-T1-IMA (4 physical lines up) 125
UXM-E1-IMA (1 physical line up) 126
UXM-E1-IMA (4 physical lines up) 127
UXM-E3 128
UXM-OC3 129
NTM-T1 130
NTM-E1 131
NTM-SR 132
Appendix A—BXM Firmware MFX Release Notes 133
About the Firmware MFX 133
Front Cards 133
Front Card for APS Compatibility 134
Back Cards 134
New Features supported in BXM Firmware MFX 135
Special Installation/Upgrade Requirements 135
APS Issues 135
Channel Statistics Issues 136
Features Obsoleted 136
Notes, Cautions, and Clarifications 137
Known Anomalies in MFX 138
Anomalies Fixed in MFX 139
Anomalies Fixed in MFW 141
Appendix B—UXM Model C ACJ Firmware Release Notes 144
Introduction 144
New Features 144
Obsolete Features 144
Compatibility 144
Bugs Resolved in ACJ 144
Upgrade Instructions 144
Known Anomalies in UXM Model C ACH 145
Anomalies Fixed in ACH 146
Boot Code Requirements 146
Unsupported Configurations or Applications. 147
Notes and Cautions 147
Firmware Filenames and File Sizes 149
Appendix C—UXM Model B Firmware ABU Release 151
Introduction 151
New Features 151
RCMP Parity Policing 151
Obsolete Features 151
Compatibility 151
Anomalies Resolved in ABU 151
Upgrade Instructions 152
Boot Code Requirements 152
Unsupported Configuration or Applications 152
Firmware Filenames and Sizes 152
Notes and Cautions 152
Appendix D—URM Model B Firmware XBC Release Notes 153
Introduction 153
New Features 153
RCMP Parity Policing 153
URM IOS CLI 153
Obsolete Features 153
Compatibility 153
Anomalies Resolved in XBC 153
Upgrade Instructions 154
Boot Code Requirements 154
Unsupported Configurations or Applications 154
Firmware Filenames and Sizes 154
XBC Firmware Boot Code 154
XAA Firmware Boot Code 155
Notes and Cautions 155
Obtaining Documentation 156
Cisco.com 156
Documentation CD-ROM 156
Ordering Documentation 156
Documentation Feedback 156
Obtaining Technical Assistance 157
Cisco.com 157
Technical Assistance Center 157
Cisco TAC Website 158
Cisco TAC Escalation Center 158
Obtaining Additional Publications and Information 158
About the 9.3.47 Release
The 9.3.47 software release supports the Cisco WAN switching products: Cisco BPX 8600 series and Cisco IGX 8400 series. This release does not support the IPX switch.
Throughout this document, unless otherwise stated, all references to the BXM also include the BXM-E, and references to the UXM also include the UXM-E.
Phased Release Strategy
The rollout plan for the 9.3 release is based upon a series of incremental feature releases. This phased feature release strategy is designed to allow the earliest customer availability of key new features, consistent with maintaining high product quality. For the latest status of each 9.3 feature, see the following information.
Definitions
The following terms are used for this release:
Generally Available (GA)
Feature is ready for wide deployment with no restrictions. Customers deploying GA features are supported by the Technical Assistance Center (TAC).
First Customer Ship (FCS)
Feature is available for controlled introduction to selected customers. To trial an FCS feature, contact your account representative. Customers selected for controlled introduction receive assistance with the test plan review and special support from the New Product Team (NPT) in addition to the normal Technical Assistance Center (TAC) support.
Minimum Release Versions
The minimum release version noted in the table represents the minimum switch software version required for each feature. It is recommended that customers use the most current maintenance releases.
Product
Feature Name
FCS/GAStatus
Minimum Release
BPX
Virtual Trunk Bandwidth Oversubscription
FCS
9.3.40
BPX
Feeder VCI Restriction Removal
FCS
9.3.40
BPX/IGX
Display Connection Counts
FCS
9.3.40
BPX/IGX
VC Merge
FCS
9.3.40
IGX
NTM Subrate Trunk Encryptor Synchronization
FCS
9.3.40
IGX
UXM Trunk and Line Loopback
FCS
9.3.40
BPX/IGX
Single-Ended FCES and Policing
FCS
9.3.40
BPX/IGX
Line and Port Alarm Masking
FCS
9.3.40
BPX/IGX
Trunk VC Shaping
FCS
9.3.40
IGX
URM BC-2FE Back Card
GA
9.3.30
IGX
URM VSI Support
GA
9.3.30
IGX
URM Remote Router Configuration
GA
9.3.30
IGX
CRC-4 Error Detection
GA
9.3.30
BPX/IGX
AIS OAM Recognition
GA
9.3.30
BPX/IGX
800 Part Number Support
GA
9.3.30
BPX
Automatic Routing Management to PNNI Migration
GA
9.3.30
BPX
Network to Endpoint Connectivity Verification
GA
9.3.30
BPX
Deferred Connection Alarm Generation
GA
9.3.30
BPX
Enhanced NNI - End-to-end OAM across BPX-MGX Networks
GA
9.3.30
BPX
Provisioning of end-to-end AR - PNNI PVCs (XPVC) across BPX - MGX Networks
GA
9.3.30
BPX
LMI/ILMI on Virtual Ports
GA
9.3.30
BPX/IGX
TFTP Configuration Save and Restore
GA
9.3.30
BPX
F4 - F5 Mapping
GA
9.3.30
BPX/IGX
Virtual Trunk Clock Source Synchronization
GA
9.3.30
BPX
60K Channel support for VSI
GA
9.3.30
BPX/IGX
Trunk Incremental Cell Delay Variance (CDV)
GA
9.3.30
BPX/IGX
Concurrent Routing
GA
9.3.30
IGX
URM Router Functionality
GA
9.3.20
BPX
Dynamic Partitioning
GA
9.3.10
BPX/IGX
Qbin Statistics
GA
9.3.10
IGX
ILMI 4.0
GA
9.3.10
BPX/IGX
ILMI/ELMI Neighbor Discovery
GA
9.3.10
IGX
ELMI for UFMs
GA
9.3.10
IGX
VSI/MPLS
GA
9.3.10
BPX
Virtual Ports
GA
9.3.05
BPX
Hitless Connection Density Upgrade for BXM
GA
9.3.00
BPX
Support for 3 VSI Partitions
GA
9.3.00
BPX
VSI MIB Support
GA
9.3.00
BPX/IGX
800 Board-Level Revision Number
GA
9.3.00
BPX/IGX
Priority Bumping
GA
9.3.00
BPX/IGX
SCR and PCR Policing at Less Than 50 CPS on BXM/BXM-E and UXM/UXM-E
GA
9.3.00
BPX/IGX
Separate Abort Stack
GA
9.3.00
BPX/IGX
Upgrades Protection
GA
9.3.00
BPX/IGX
Control Traffic Shaping
GA
9.3.00
IGX
2000 VC Bandwidth Parameters
GA
9.3.00
IGX
UXM/UXM-E ATM Forum IMA-Compliant Ports
GA
9.3.00
For information about these features, refer to the corresponding release notes at the following URLs:
Virtual trunking defines multiple trunks within a single physical trunk interface. Virtual trunking allows the user to allocate as much bandwidth as needed instead of the full T3, E3, OC3, or OC12 bandwidths. Virtual trunking bandwidth refers to the service rate.
Prior to Release 9.3.40, the bandwidth of a virtual trunk (VT) is limited by its allocated portion of the total physical bandwidth at the interface. If a VT on a single interface is not utilizing its allocated share of bandwidth, other VTs cannot use this available bandwidth when their traffic exceeds the configured level. Each of the VTs on a physical interface has a fixed bandwidth which leads to inefficient use of the total bandwidth.
In Release 9.3.40 the purpose of oversubscribing is to allow a VT to utilize up to a maximum configured bandwidth on the physical interface. The sum of individual maximum bandwidths of the VTs on a single physical interface can exceedthe actual physical bandwidth available on that interface. If a VT is not utilizing its share of bandwidth, another VT can use the bandwidth.
VT bandwidth oversubscription is applicable to AutoRoute (AR) and PNNI. This feature is available on the BPX switch with the BXM-E card. This feature is not supported on any other BPX card or on the IGX switch.
Functionality
The VTs on a physical interface can be configured with minimum and maximum service rates. The maximum service rate can be oversubscribed. If some connections on one VT burst traffic, they are allowed through on the oversubscribed VT up to the maximum service rate.
By default oversubscription on a VT is disabled, and the minimum and maximum service rates are set to the same value. Whenever the minimum and maximum values are changed by the user to be not equal, oversubscription is implicitly enabled.
By default the minimum and maximum service rates on a VT are set to 3000 cps or to the maximum bandwidth available on the physical interface, whichever is smaller.
VT oversubscription is disabled by making both the minimum and maximum service rates equal.
Configuration Requirements
The trunk on which this feature is to be enabled must be up. The remote end can be a BPX or IGX.
The following restrictions apply to VT oversubscription:
Minimum service rate is less than or equal to the maximum service rate for each VT.
Sum of the minimum service rates of all VTs on a physical interface is less than or equal to the total bandwidth of that physical interface.
Maximum service rate is less than or equal to the total bandwidth of the physical interface for each VT on that physical interface.
The sum of the maximum service rates of all VTs on a physical interface can be greater than the total bandwidth of that physical interface.
AutoRoute Connections
When routing connections over a VT, AutoRoute (AR) searches for the VT which has maximum available bandwidth and routes the connection over that VT. When a connection is routed over an oversubscribed VT, AR uses the minimum service rate to check for available bandwidth.
VSI Partitions
A VSI partition on a VT can be oversubscribed since the VSI partition shares the same virtual interface (VI) as that of the VT on which VSI partition is configured. The VI now has a minimum and a maximum service rate. Thus, connections on a VSI partition can burst up to the maximum VI rate with enough bandwidth on the interface. This maximum VI rate is configured through the cnftrk CLI command.
CLI Additions and Modifications
This section contains the commands that have been modified to support VT bandwidth oversubscription.
cnftrk
The cnftrk command has been modified to allow configuration of minimum and maximum service rates.
The Overall utilization field in the display screen indicates the percent utilization of the trunk. If a trunk is oversubscribed, the percentage utilization might exceed 100% when the bandwidth usage exceeds the minimum configured value.
MIB Addition
This section contains the following addition to the atmTrunks table in the switch MIB to support VT bandwidth oversubscription.
Table 3 atmTrunksTable Addition
MIB Object
Description
Values
atmTrkXmitRateMax
Maximum trunk transmission rate in cells per second.
This object can be SET for virtual trunks. The object is read-only for other types of trunks. The value is the same as the atmTrkXmitRate value.
This object can be SET with all other writable objects in this table except:
atmRteTrkAlmEnable
atmRteTrkBdataBTxQlen
atmRteTrkBdataBTxEfcn
atmRteTrkBdataBTxHiClp
atmRteTrkBdataBTxLoClp
Access: read-write
Default: 3000 cps. (equal to atmTrkRcvRate)
Mismatch Capabilities
The following table shows mismatch conditions.
Table 4 Mismatch
Active Card
Replaced by Card
Result
Without VT oversubscription
With or without VT oversubscription
No mismatch
With VT oversubscription disabled
With or without VT oversubscription
No Mismatch
With VT oversubscription enabled
With VT oversubscription
No mismatch
With VT oversubscription enabled
Without VT oversubscription
Mismatch
VT oversubscription is considered enabled if at least one VT on a active BXM is oversubscribed.
Redundancy
SWSW 9.3.40 uses the following guidelines for Y-cable redundancy (Y-red):
Allow Y-red if only one card supports the feature, and the feature is disabled.
Do not allow Y-red if one card supports the feature, the feature is enabled, and the second card does not support the feature.
Do not enable this feature if Y-red is configured between a card supporting VT bandwidth oversubscription and a card not supporting this feature.
Feeder VCI Restriction Removal
STI cells used by Cisco WAN switches and ATM standard UNI/NNI cells have different header formats. ATM standard cells use a 16-bit VCI address field; whereas, STI cells use a 12-bit VCI field. In STI cells the higher 4 bits of octet 4, which contain the last 4 bits of VCI address in ATM standard cells, contain ForeSight information. Therefore, UNI/NNI cells support 65535 VCI addresses while STI cells can support only 4095 VCI addresses.
Since BNI cards use only STI cells, an ATM network with BNI and non-BNI modules must ensure that VCI address translation occurs whenever a cell moves from an ATM (non-BNI) segment to an STI (BNI) segment and vice-versa. Otherwise, the lower 4 bits of VCI information in the UNI/NNI cell are overwritten with ForeSight information when the cell enters the STI segment. This translation is achieved by shifting the lower twelve VCI bits of an ATM cell left or right when it enters or exits an STI segment.
This feature allows VCI shift to be turned on or off on BXM feeder trunks, enabling them to use the full 65535 VCI UNI/NNI address range. This feature also applies to MPLS which requires a VCI range greater than 4095.
This feature is available on the BPX switch with BXM trunks.
Usage
VCI shift operations perform the following functions:
Shift/no-shift operation is configured using the cnffdr command. The same setting should be chosen at both ends of a connection. When a connection is added, a difference in setting causes a mismatch warning to display.
When the shift option is enabled on a feeder trunk, the VCI value is shifted left by four bits for cells entering the feeder trunk and shifted right by four bits for cells leaving the feeder trunk.
Via nodes get the shift/no-shift configuration from the master and program the trunks accordingly.
If the VCI is less than or equal to 4095 in a VPC, then the connection does not need to be rerouted.
To get the VCI unchanged in a VPC connection, shift must be disabled on all nodes in the path of the connection. The no-shift option must be selected at the master and slave nodes of the connection. Via nodes take on the same shift configuration as the master and must be no-shift if the master node configuration is no-shift.
This feature also works with local connections.
Configuration
By default in Release 9.3.40 BXM feeder trunks have VCI shift disabled. The feeder trunks that exist prior to Release 9.3.40 have the VCI shift enabled by default.
To pass VCI without shift on a connection, the master and slave nodes should be configured as no-shift. The connection should not route over a BNI trunk.
For an existing connection, a change in the shift/no-shift setting is effective after the connection is rerouted. For example, if a node is upgraded from a version of SWSW that does not provide cnffdr support to one that does, any existing connections over BXM feeder trunks shift the VCI for cells passing over the connection.
Use the following guidelines for changing the shift/no-shift setting on a feeder trunk:
All existing connections over this feeder trunk must be manually rerouted for the change to be effective. The shift/no-shift setting should be configured before adding new connections. However, the connection continues to have data continuity if this setting is not configured.
If the feeder at one end is changed to no-shift, then the feeder at other end also should be changed to no-shift.
No configuration is required on via nodes since via nodes follow the configuration of the master node.
For a routing trunk, the cnfport command is used to turn shift on or off. For a feeder trunk, shift has to be configured using the cnffdr command or through SNMP.
When new feeder trunks are added on a node running SWSW software with this feature, the trunks come up with shift turned off.
To ensure that the VCI is not changed on a VPC connection, BNI trunks must not be in the path of the connection since BNI trunks use only 12-bit VCI (STI cells).
Note Since the system does not automatically avoid routing over BNI trunks, configure the VPC connections
in the network with directed preferred routes over BXM-only paths. If these paths are lost, the
connection fails rather than rerouting over a path with a BNI.
CLI Additions and Modifications
This section contains the commands that have been modified to support VCI restriction removal.
cnffdr
The cnffdr command is used to configure shift/no-shift on a BXM feeder trunk. The cnffdr command configures the shift/no-shift setting only under the following conditions:
Trunk must be a BXM trunk.
Trunk must be up.
Trunk must be added as a feeder.
If any of the above conditions are not true, the system displays an error message and prompts for another trunk number.
Syntax:
cnffdr <trunk number> <H|N>
Parameter
Description
<trunk number>
Specifies the slot.port of the feeder trunk.
[H|N]
Enable or disable shift.
H = Shift VCI
N = No-Shift (default)
The following example shows the cnffdr display screen The Feeder trunk field displays the trunk number followed by the type of shelf.
For BNI feeder trunks, the VCI field is copied to an STI cell. The shift/no-shift setting is not applicable. Therefore, for BNI feeders the dspfdrcnf command displays a [-] in the Shift field, shown in the following example.
This section contains the addition to the atmTrkTable in the switch MIB to support VCI restriction removal.
Table 5 atmTrkTable Addition
MIB Object
Description
Values
atmTrkHcfShift
Value to indicate whether VCI shift is enabled on the trunk.
For no-shift of VCI the value of the SET operation should be disable(2) and for shift the value should be enable(1). The default value is no-shift for BXM feeder trunks.
The object is applicable only for BXM feeder trunks. For ATM ports on other cards this object is not applicable, and the value -1 is returned.
This object is not applicable for routing trunks.
If a SET operation is tried without giving a value, the default value is set for BXM feeder trunks. The request is ignored for routing trunks.
If a SET operation with a given value is tried on a routing trunk, an error is returned.
Access: read-write
1 = enable
2 = disable
SNMP Error Messages
The following error messages are generated under the specified conditions:
Error code -1 (There is no such variable name in this MIB) is returned when SNMP GET or SET is tried on an invalid trunk or on a trunk that is not up.
Error code -1 is returned when SNMP GET is tried on a trunk which is not a feeder trunk.
Error code -2 (A general failure occurred) is returned when SNMP SET is tried on a trunk which is not a feeder trunk.
Redundancy
This section contains redundancy requirements of this feature.
Controller Card Redundancy
Standby updates are applicable for the shift/no-shift parameter setting. The same configuration is available after executing a switchCC. If a switchCC (automatic) occurs when the configuration is changed but the connections are not rerouted, the configuration is available in the new active controller card. For the configuration to be to be effective, a manual reroute must be done after the switchCC.
Y-redundancy and APS
The shift/no-shift configuration is available on redundant cards.
Display Connection Counts
In SWSW Release 9.3.40 the CLI command, dspconcnts, is modified to include the following connection counts:
Number of connection endpoints terminated on the cards and lines.
Number of connection endpoints terminating on ports. The display includes the endpoint counts of the CBR, VBR, ABR, UBR, and Frame Relay connection types that terminate on each active port. The number of VPC and VCC connection endpoints on each port are also displayed.
Number of connections passing over trunks for the node.
CLI Addition
This section contains the command that has been added to support connection counts.
dspconcnts
The dspconcnts command shows the number of connection and connection endpoints.
Syntax:
dspconcnts [c|p|t|l|h] [h(elp)]
Parameter
Description
c
(Optional) Displays the number of connection endpoints terminating on each card.
p
(Optional) Lists all active ports on the node. For each active port, the number of CBR, VBR, UBR, ABR, and Frame Relay connection endpoints and terminating VPC and VCC connection endpoints are also listed.
t
(Optional) Displays the number of connections passing over each trunk on the node.
l
(Optional) Displays the number of connection endpoints terminating on each line on the node.
h
(Optional) Displays a help screen.
none
Displays the number of connections mastered to or from this node and the number of via connections passing over the node when no option is specified.
Example 8 shows the active ports with the number of connection endpoints.
Slot Type #ConEndPts Slot Type #ConEndPts Slot Type #ConEndPts
3 UXM 291 13 LDM 21 26 CVM 1
4 FRM 32 17 Empty - 27 UXM 0
5 NTM - 18 FRM 37 28 0
6 NTM - 19 CVM 0 29 0
7 CVM 0 20 CVM 0 30 Empty -
8 Empty - 21 Empty - 31 Empty -
9 Empty - 22 UXM 179 32 ALM 0
10 HDM 8 23 Empty -
11 HDM 0 24 Empty -
12 UXM 0 25 FRM 0
Last Command:dspconcnts c
VC Merge
The VC merge feature is already supported on BPX nodes. For more information on this feature, refer to the BPX Installation and Configuration documentation at the following URL:
On the IGX VC merge feature is supported only on UXM-E cards running firmware ACJ or higher.
This feature allows multiple incoming VCs to be merged in to a single outgoing VC. A UXM enhanced card with the VC merge capability can be configured to allow the merging of frame-based connections into a merged VC. The merged VC is controlled by the VSI controller.
The VC merge feature allows scalability of MPLS networks since one VC is allocated to each destination of each link.
The SWSW allows the configuration of VC merge for an enhanced UXM card through the cnfcdparm command. VC merge can be enabled only if the card supports this feature.
The support of VC merge on a card can be verified using the following commands:
dspcd
dspcdparm
The VC merge feature is supported only for frame-based connections. These connections carry AAL5 frames consisting of multiple cells. The cells from a particular frame must be in an uninterrupted sequence when the frame goes out after merging.
After the node is upgraded to Release 9.3.40, VC merge can be enabled on the UXM-E cards by using the cnfcdparm command. The VC merge configuration parameters are saved in BRAM and are sent to the standby processor card.
Availability of Contiguous LCNs
The UXM card requires 550 contiguous logical channels (LCNs) in the AutoRoute (AR) partition to support this feature. The VC merge configuration request is denied if 550 LCNs are not available on the AR partition. The user is prompted to allocate LCNs on the card if the feature needs to be enabled.
The traffic on the VCs might get affected when this feature is enabled where 550 non-contiguous LCNs are available on the card. A trap is sent to indicate that the card needs to be deactivated and reactivated to enable the feature support. Since deactivation of the card disturbs the traffic, the user is prompted with a Y/N to proceed with the request. After the user enters Y to proceed, the SWSW configures the VC merge feature by sending appropriate commands upon card activation. The user is prompted before the interruption of any data traffic.
Redundancy
The VC merge feature is supported on the Y-cabled UXM-E pair.
Graceful mismatch is supported. A mismatch condition is declared if the VC merge feature is in use,and Y-redundancy is attempted using a card that does not support the feature. In such cases, feature mismatch is declared (see Table 6).
Table 6 Mismatch Scenarios
Scenario
Behavior
Logical Card State
Y-red not configured. Replace N (primary) with S (secondary).
OK
S
Y-red not configured. Replace S with N.
If feature is not in use, no mismatch.
If feature is in use, feature mismatch. Feature usage must be removed and card reset to clear mismatch.
N
addyred: N primary, S secondary
No mismatch - addyred is allowed.
N
addyred: S Primary, N secondary
Blocked if feature is in use.
Allowed if feature is not in use. No mismatch.
S/N
CLI Additions and Modifications
This section contains the commands that have been modified to support VC merge.
cnfcdparm
The cnfcdparm command supports the VC merge configuration on UXM supported cards. A card must have at least one active partition to enable VC merge.
Syntax:
cnfcdparm <slot #> <param # (2) > <E/D>
Parameter
Description
slot #
Slot number.
param #2
Parameter(2) that changes the VC Merge State.
E/D
Value to configure the VC merge.
E = enable
D = disable
Example 10 cnfcdparm Command
node TRM Cisco IGX 8420 9.3.4Q May 23 2002
11:41 PST
Card Parameters
1 Channel Statistics Level
......................................... 1
2 VC Merge State
......................................... D
Last Command:cnfcdparm 10 2 E
dspcd
The dspcd command supports the VC merge capability display.
Syntax:
dspcd <slot #>
Example 11 shows the VC merge capability for the UXM card in slot 10.
Example 11 dspcd Command
node TRM Cisco IGX 8420 9.3.4Q May 23 2002
11:27 PST
Detailed Card Display for UXM in slot 10
Status: Standby (Front Card is UXME)
Revision: CA27 Front Card Supports:
Serial Number: 290617 Vtrunks, OAMLpbk & TrfcGen, ILMI
ver 1,
Top Asm Number: 28274601 Neighbor Discovery, SIW, CGW,
CellFwd,
Backplane Installed Hot Standby, Trfc Shaping, IMA,
Backcard Installed ChnStatLvl 1, NumChans = 8000,
Type: E1-IMA NumRCMP = 16382, VSI ver 2, VSI
Ctrlr,
Revision: AA PCR >= 6 cps, F4 AIS
Recognition,
Serial Number:248402 CRC-4 Config, VC Merge, Cnf ILMI
chg/trap
Top Asm Number:28241202
Ports: 8
Interface: BNC
Last Command:dspcd 10
NTM Subrate Trunk Encryptor Synchronization
This feature toggles the DTR lead on an NTM subrate interface backcard for a preconfigured ON and OFF cycle in the case of a disturbance to the trunk. This toggling continues until the trunk alarms clear.
Functions
This feature provides the following functions:
Enables and disables the toggling of the NTMs DTR lead through the cnftrk command.
Configures ON and OFF durations of the NTMs DTR lead through the cnftrk command. The ON and OFF values are in the range of 1 to 128 seconds.
When this feature is enabled, the NTM firmware detects a loss of synchronization by monitoring the following alarms:
Clock loss
Signal loss
Packet loss
Yellow packet received
The firmware then toggles the DTR lead periodically as specified by the ON and OFF times until all the above alarms are cleared. When the alarms are cleared, the firmware restores the state of the DTR lead.
CLI Modifications
This section contains the commands that have been modified to support NTM subrate trunk encryptor synchronization.
cnftrk
DTR toggling is enabled and disabled using the cnftrk command. A DTR toggle on alarm field is displayed for an NTM subrate trunk. Valid values are Y or N.
Fields for configuring ON and OFF duration are DTR secs ON and DTR secs OFF. Valid values for both fields are in the range of 1-128 seconds. Default for DTR secs ON is 29 seconds. Default for DTR secs OFF is 1 second. See the display screen in Example 12.
dsptrk
The dsptrk command is extended to display state of DTR toggling (enabled or disabled) and the ON/OFF durations.
If the feature is enabled on a trunk, the cnftrkict command displays a warning message whenever DTR settings are changed. This warning indicates that the settings will be overridden by cnftrk settings in case of trunk disturbance.
Warning! DTR lead settings will be overridden by cnftrk during Trk alarms
Enter signal source (on, off, or local):
MIB Additions
This section contains the three additions to the fpRteTrk table in the switch MIB for this feature.
Table 7 fpRteTrkTable Additions
MIB Object
Description
Values
fpRteTrkToggleEnable
Value to enable or disable DTR lead toggling.
This object is applicable only to NTM cards with subrate backcards. A SET on any other type of card is ignored.
A GET on any other type of card returns (-1).
Access: read-write
1 = Yes
2 = No (default)
fpRteTrkDtrOn
The ON time in seconds for DTR lead during toggling.
This object is applicable only to NTM cards with subrate backcards.
A SET on any other type of card is ignored. A GET on any other card returns (-1).
Access: read-write
Range: 1-128
Default: 29
fpRteTrkDtrOff
The OFF time in seconds for DTR lead during toggling.
This object is applicable only to NTM cards with subrate backcards.
A SET on any other type of card is ignored. A GET on any other card returns (-1).
Access: read-write
Range: 1-128
Default: 1
SNMP supports enable/disable toggling and configures the ON/OFF toggling parameters.
SNMP OIDs are partitioned into two sets, legal_fprtetrkcnfg_tbl and legal_fptrkparm_tbl. Each table has a separate access function, corresponding to cnftrk and cnftrkparm CLIs. These OIDs are contained in the fpRoutingTrunks table.
UXM Trunk and Line Loopback
This feature provides the loopback commands on a UXM physical interface that is configured for physical, virtual, or feeder trunk(s) in trunk mode and configured for an UNI or NNI ATM port in line mode.
Note This feature already exists on the BPX.
When a physical loopback is added on a UXM physical interface, all the traffic on the physical interface is looped back.
The physical loopback configuration is stored in BRAM and updated to the standby NPM. The configuration is retained after a rebuild, switchcc, or software upgrade. SWSW does not broadcast the physical loopback information on a UXM physical interface to the other BPX/IGX nodes in the network.
Local Loopback (addlnloclp)
When a UXM port interface is put in local loopback state, the traffic that comes into the cell bus from the local cable is looped back on the cell bus and sent back out the cable. This traffic is passed into the network.
The traffic that comes from the remote end through the network is not sent to this interface. This traffic is dropped and is not mixed with the traffic being looped back.
For local loopback on normal trunks the node which has the trunk-end in local loopback state goes into Comm-Fail state while the remote node goes into loopback state. The traffic from the remote node is looped back by the local node.
The symbol "]" always indicates local loopback for both lines and trunks. The loopback behavior on IMA lines/trunks, IMA virtual trunks, and feeder trunks is similar to that of normal lines/trunks. The user can reduce the number of retained links (to ensure that IMA group status is OK using cnfln or cnftrk commands) and safely put a local loopback on one or more of the individual physical IMA links. The test traffic entering the looped IMA links is looped back while the main user traffic remains unaffected (as long as a sufficient number of retained links remain).
Local Remote loopback (addlnlocrmtlp)
For local remote loopback on normal lines, the node that has its line interface in the local remote loopback state loops back the traffic coming from the cell bus. The traffic is looped back and is not passed to the cable. Traffic from the ports on the local node is not sent on to the network. Traffic is dropped at the local node and is not mixed with the traffic being looped back.
For local remote loopback on normal trunks, the node that has its trunk-end in local remote loopback state loops back the traffic coming from the cell bus. The remote node does not receive this traffic.
The traffic being received from the remote node is dropped and is not passed on to the CPE attached to the local node. This traffic is not mixed with the traffic being looped back.
The symbol "[" always indicates local remote loopback for both lines and trunks. The loopback behavior on IMA lines/trunks, IMA virtual trunks, and feeder trunks is similar to that of normal lines/trunks. Local remote loopback on individual IMA links is not supported.
Delete Local/Local Remote loopback (dellnlp)
The dellnlp command deletes either local or local remote loopback on a line or trunk interface.
The displaying (output) screens of the following existing IGX user commands include the loopback indicators on all the trunks or lines on the UXM physical interface:
dsptrks
dsplns
dspphyslns
Table 8 lists the expected behavior upon using the loopback commands on a single (isolated) node and other nodes in a network. The behavior at both the local and remote nodes is shown. All loopback commands are executed on local nodes.
Table 8 Loopback Behavior
Local Node
Remote Node
addlnloclp
addlnlocrmtlp
addlnloclp
addlnlocrmtlp
Trunks (Physical and Virtual)
Single Node
LOS is not cleared
LOS is cleared
Not applicable
Not applicable
Trunks (Physical and Virtual)
Network
dsptrks on local node shows Comm Failure. No LOS alarms are present.
dsptrks on local node shows Looped Back. No alarms are present.
dsptrks shows Looped Back status.
dsptrks shows Comm-Fail.
Lines/Ports
Single Node not connected to CPE
1. Port state remains failed
2. LOS is not cleared.
1. Port State changes to active
2. LOS is cleared
Not applicable
Not applicable
Lines/Ports
Connected to CPE
LOS remains clear
1. Port state remains active
2. LOS remains clear
Not applicable
Not applicable
IMA trunks
Same as physical trunks
Same as physical trunks
Same as physical trunks
Same as physical trunks
IMA ports/lines
Same as ports
Same as ports
Same as ports
Same as ports
Feeder trunks
Network
1. dsptrks shows clear-Ok.
2. Node goes into Major alarm and dspnode shows remote node is unreachable.
3. dsplog shows comm-fail with remote node.
1. dsptrks shows clear-Ok.
2. Node goes into Major alarm and dspnode shows remote node is unreachable.
3. dsplog shows comm-fail with remote node.
1. dsptrks shows clear-Ok.
2. Node goes into Major alarm and dspnode shows remote node is unreachable.
3. dsplog shows comm-fail with remote node.
1. dsptrks shows LOS.
2. Node goes into Major alarm and dspnode shows remote node is unreachable.
3. dsplog shows comm-fail with remote node.
Limitations
The physical loopback commands on IGX can be executed on the UXM physical interface only, not on an individual virtual interface.
Local remote loopback on individual IMA physical links (either lines/trunks) are not supported. Either all or none of the individual IMA physical links might be put into loopback. This loopback behavior is a firmware limitation. However, for local loopbacks either one or more (including all) of the individual IMA physical links can be put into local loopback.
Traffic loopback behavior on feeder trunks is the same as on normal physical trunks. However, the display is different, as shown in Table 8. Feeder trunks do not have an alarm state called Looped Back. For loopbacks on feeder trunks, both local and remote ends are in major alarm and go into communication-failure state. The states are different because feeder trunks use LMI/ILMI protocol for communication failure tests while normal physical trunks use AutoRoute protocol.
SWSW does not support these loopback commands on the SNMP interface.
CLI Additions and Modifications
addlnloclp
The command addlnloclp performs the following operations:
Programs the target UXM to put the physical interface into line local loopback.
Logs a system event to indicate that the physical loopback is applied on the physical interface.
Displays the following summary screens for lines or trunks:
For the UXM physical interface that has been configured as trunk(s), the dsptrks output screen displays the proper loopback indicator on the affected trunk(s).
For lines, the dsplnsoutput screen displays the proper loopback indicator on the affected line.
For IMA lines/trunks the dspphyslns output screen is displayed with the proper loopback indicator on the affected link(s).
Syntax:
addlnloclp <slot.port> or <slot.port[-port, port]> or <slot.port.vport> or <slot.port-port.vport>
Parameter
Description
slot.port
Format for normal UXM physical interface.
slot.port [-port, port]
Format for IMA interfaces.
slot.port.vport
Format for virtual trunks.
slot.port-port.vport
Format for IMA virtual trunks.
addlnlocrmtlp
The command addlnlocrmtlp performs the following operations:
Programs the target UXM to put the physical interface into line local remote loopback.
Logs a system event to indicate that the physical loopback is applied on the physical interface.
Displays the following summary screens for lines or trunks:
For the UXM physical interface that has been configured for trunk(s), the dsptrks output screen displays the proper loopback indicator on the affected trunk(s).
For lines, the dsplnsoutput screen displays the proper loopback indicator on the affected line.
For IMA lines/trunks the dspphyslns output screen displays the proper loopback indicator on the affected link(s).
Syntax:
addlnlocrmtlp <slot.port> or <slot.port[-port, port]> or <slot.port[.vport]> or <slot.port-port.vport>
Parameter
Description
slot.port
Format for normal UXM physical interface.
slot.port [-port, port]
Format for IMA interfaces.
slot.port.vport
Format for virtual trunks.
slot.port-port.vport
Format for IMA virtual trunks.
dellnlp
The command dellnlp performs the following operations:
Programs the target UXM to remove the physical loopback on the UXM physical interface.
Logs a system event to indicate that the physical loopback is removed on the physical interface.
Displays the following summary screens for lines or trunks:
For the UXM physical interface that has been configured for trunk(s), the dsptrks output screen displays the loopback indicator removed on the affected trunk(s).
For lines the dsplnsoutput screen displays the loopback indicator removed on the affected line.
For IMA lines/trunks the dspphyslns output screen displays the loopback indicator on the affected link(s).
Syntax:
dellnlp <slot.port> or <slot.port[-port, port]> or <slot.port.vport> or <slot.port-port.vport>
Parameter
Description
slot.port
Format for normal UXM physical interface.
slot.port [-port, port]
Format for IMA interfaces.
slot.port.vport
Format for virtual trunks.
slot.port-port.vport
Format for IMA virtual trunks.
dsptrks
The dsptrkscommand includes the following modifications:
UXM interface in local loopback state displays ] as the line local loopback indicator.
UXM interface in local remote loopback state displays [ as the line local remote loopback indicator.
If a UXM physical interface is put in loopback state (either local or remote local), the dsptrkscommand displays a loopback indicator associated with each of the logical trunks (physical or virtual) that are configured on that UXM physical interface.
dsplns
The dsplnscommand displays a loopback indicator for the logical line. Thiscommand includes the following modifications:
UXM interface in local loopback state displays ] as the line local loopback indicator.
UXM interface in local remote loopback state displays [ as the line local remote loopback indicator.
dspphyslns
The changes in dspphyslns are identical to those of the dsplns and dsptrks commands except that the loopback indicator is shown against each individual IMA physical line as appropriate.
If Y-redundancy is configured on a UXM card that supports hot-standby the line loopback configuration on its physical interface, if SET, is also programmed to the standby UXM.
Single-Ended FCES and Policing
Single-ended FCES mechanism is used to provide an end-to-end flow control capability to ABR and FST types of connections consisting of multiple segments. This feature allows the BXM-E and UXM-E to provide congestion information to non-Cisco products using a standard interface. ABR flow control is extended to the external segment.
Policing is the process of monitoring ingress traffic of a connection to determine if the traffic can enter and how that traffic is handled once inside the network.
These features allow single-ended FCES and policing on a connection to be configured on an endpoint basis rather than on a connection basis. The congestion control loop is enabled between only those devices that support this feature.
Similarly, policing is independently configured at each endpoint of the connection. This feature allows maximum traffic throughput to avoid cell discards due to traffic clumping on the NNI interfaces.
Functions
Single-ended FCES and policing provide the following functions:
Allows FCES to be enabled or disabled independently on two endpoints of a connection.
Allows policing to be enabled or disabled independently on two endpoints of a connection.
Supports the configuration from CWM, CLI, and SNMP.
Requirements
These features require the BXM-E and UXM-E cards.
FCES
Independent values for FCES provisioning can be configured for the following reasons:
Connections with type ABRSTD, ABRFST, or ATFST (between two ATM endpoints) are added using addconif both endpoints support FCES (VSVD needs to be enabled for ABRSTD connection).
The above connections are configured using the cnfcon CLI command.
ATM classes are configured using cnfcls or cnfatmcls commands.
The dspcon is used to display the above connections,
The parameter for FCES takes one of the following values:
D/D(or D). FCES is disabled at both endpoints.
E/E (or E).FCES is enabled at both endpoints.
E/D. FCES is enabled at the local endpoint only.
D/E. FCES is enabled at the remote endpoint only.
The default value for FCES is disable.
The following example shows the CLI prompt.
FCES [Disable/Disable]:
In the following cases FCES is specified for only one end of a connection:
A connection with type ATFST, ATFXFST, or ATFTFST is added between ATM and FR endpoints. Enabling or disabling FCES is applicable only to the ATM endpoint. FCES is ignored at the FR endpoint.
If one endpoint is acting as a feeder trunk, FCES is not applicable and displays a [-].
For a local connection which uses one channel, only one endpoint for this connection exists.
In these cases, the parameter for FCES is in the following format:
D. FCES is disabled at the ATM endpoint.
E.FCES is enabled at the ATM endpoint.
The CLI prompt in these cases is
FCES [Disable/-]: or FCES [-/Disable]: or
FCES [Disable]: (for onelcn dax connection)
MIB
To integrate with CWM, the switch MIB atmEndptOeBCM object for FCES is read-write.
Policing
When a connection is added using addcon, configured using cnfcon, or displayed usingdspconCLI commands, the parameter for policing takes one of the following value combinations:
[1-5]/[1-5] or [1-5]
If the endpoint is a feeder trunk, the policing is shown as
[1-5/- or -/[1-5]
For UBR connections, CLP tagging is used and corresponds to the following input values:
D/D (or D when inputting). CLP tagging is disabled at both endpoints.
E/E (or E when inputting).CLP tagging is enabled at both endpoints.
E/D. CLP Tagging is enabled at the local endpoint only.
D/E. CLP Tagging is enabled at the remote endpoint only.
If the endpoint is a feeder trunk, the CLP tagging is shown as
D/-, E/-, -/D or -/E
The policing type has a range from 1 to 5. Table 9 shows how these policing types are defined. The value to the left of [/] is the local endpoint policing type and the value to the right of [/] is the remote endpoint policing type. The two endpoints are provisioned independently using these two input values.
.
Table 9 Policing Types
Type
Cells Tested In First Bucket
First Bucket Noncompliance Result
Cells Tested In Second Bucket
Second Bucket Noncompliance Result
Supported Connection Types
Default
1
All
Discard
CLP = 0 or 1
Discard
VBR, ABR
None
2
All
Discard
CLP = 0 only
Discard
VBR, ABR
None
3
All
Discard
CLP = 0 only
Tag with CLP
VBR, ABR
VBR, ABRSTD with VSVD, ABRFST, ATFST, ATFTFST, ATFXFST
4
All
Discard
None
-
CBR, VBR, ABR
CBR, ABRSTD without VSVD
5
None
-
None
-
CBR, VBR, ABR
None
Note Single-ended policing for VBR connections is not supported.
To configure policing based on endpoints rather than connections, use the addcon and cnfcon CLI commands.
The addcon command allows users to configure policing on the two endpoints differently.
The switch MIB definition for remote endpoint policing allows independent SNMP SET operations on the objects of both endpoints.
Compatibility
These features have the following compatibility capabilities:
Provisioning from existing CWM is supported. If the request has only one endpoint value, copy this value to the other end to keep the new feature compatible with the existing CWM. Do not use the default for the other end.
Because the robust message payload definition has not changed, these features function with the CWM 10.5.
MIB
A new MIB object atmEndptOePolicing supports policing type on the other end.
Redundancy
One-to-one redundancy is preserved since the values for FCES and policing endpoint provisioning are stored in BRAM and are sent to the standby card.
Network Interoperability
When connections are added from a node with this feature to another node without this feature, the endpoint-based provisioning can be achieved. On the node the display without this feature, the dspcon command displays only one local endpoint value.
The dcct, dvc, and dvcparms commands display the values on both endpoints.
When an ATM class is configured from a node with this feature to have two different values for FCES or policing, the CWM Connection Manager (CM) updates this ATM class definition on all the nodes in the network including nodes without this feature. If a connection is added from an old revision node using this updated class, the connection uses the two different values to provision the connection.
With an upgraded CWM and mixed revisions on a switch, single-ended FCES is supported if the master node is an upgraded node.
If the switch is upgraded before CWM, the following results occur:
The format of robust message sent from switch is not changed. Only the values of the connection object are changed.
The FCES and policing values cannot be configured differently on CWM, and the display on the CWM is incorrect.
If CWM is upgraded before the switch, the following results occur:
CWM blocks configuring two values differently from the GUI if the switch does not support this feature.
If mixed revisions exist in the network, configuring two values differently is supported if the master node is an upgraded node.
Line and Port Alarm Masking
Alarms on a line or port can be masked so that they are not propagated to the network. This masking allows the known alarms in the network to be hidden from the new alarms.
Line and port alarms can be masked through CLI and SNMP interfaces. Activation and deactivation of the interface alarms are logged in the local event log.
This feature is supported in both IGX and BPX platforms.
Functions
Line and port alarm masking mirrors the existing trunk alarm masking and provides the following functions:
The cnflnalm and cnfportalm commands mask out the line and port alarm on the specified line or port. However, if any connections exist on those lines or ports, the connections on the affected line or port still fail and cause the node to be in MAJOR alarm. The line and port alarms are enabled by default.
The Port Alarms and Line Alarms entries in the dspalms screen are modified to reflect any active and disabled port alarms.
The existing integrated line alarm related command, cnflnalm, is renamed to cnfintalm to reflect the integrated alarm configuration. The display command dsplnalmcnf is renamed to dspintalmcnf.
Line Alarms
The line alarms on a node are caused by physical line failures which result in failure of all of the connections on the line interface.
Line alarm masking is supported on the following cards:
IGX
FRM-E
UFM-C
CVM
UVM
UXM
BPX
BXM
ASI
BNI
Port Alarms
The port alarms in a node can be caused by a failure on the end device (CPE) connected to it. These alarms can be caused by an LMI/ILMI failure to restrict communication between the interface card and the CPE. This failure results in a port communication failure that causes a minor alarm on the node.
Port alarm masking is supported on the following cards:
IGX
FRM-D
FRM-E
UFM-C
UFM-U
CVM
UVM
UXM
URM
BPX
BXM
ASI
BNI
In addition to port communication failures, the serial port interface card, UFMU, can have port configuration, port over speed, and cable mismatch failures. These failures result in minor alarms on port interfaces.
An IGX Frame Relay NNI port can go in to major alarm only when an NNI failure occurs, and the debug flag is enabled.
MIB Additions
This section describes the objects added as a part of the alarm masking feature.
Table 10 MIB Additions
MIB Table
MIB Object
Description
Values
frLport
frLportPortAlmEnable
Value to enable or disable a port alarm.
Access: read-write
1 = enable
2 = disable
atmPort
atmPortAlmEnable
Value to enable or disable a port alarm.
Access: read-write
1 = enable
2 = disable
ds1Line
ds1LineAlmEnable
Value to enable or disable a line alarm.
Access: read-write
1 = enable
2 = disable
ds3Line
ds3LineAlmEnable
Value to enable or disable a line alarm.
Access: read-write
1 = enable
2 = disable
sonetIf
sonetIfLineAlmEnable
Value to enable or disable a line alarm.
Access: read-write
1 = enable
2 = disable
CLI Additions and Modifications
This section contains the commands that have been modified to support line and port alarm masking.
cnfintalm
The cnfintalm command configures the thresholds for the integrated line/trunk alarm parameters. This command is the renamed version of the existing cnflnalm command.
Syntax:
No change
cnflnalm
The cnflnalm command enables or disables a line alarm. Upon successful completion of this command, the dsplns screen is displayed with the configured line number in highlighted display.
Syntax:
cnflnalm <line #> <E/D>
Parameter
Description
line #
Line number.
E/D
Value to configure the line alarm.
E = enable
D = disable
Example 16 cnflnalm Command
node TRM Cisco IGX 8420 9.3.40 May 23 2002
11:44 PST
Line Type Current Line Alarm Status
4 E1/30 Major - Loss of Sig (RED)
10.1m E1/30 Major - Loss of Sig
Last Command:cnflnalm 10.1 d
cnfportalm
The cnfportalm command configures the port alarm.
Syntax:
cnfportalm <port id> <E/D>
Parameter
Description
port id
Port number.
E/D
Value to configure the port alarm.
E = enable
D = disable
Example 17 cnfportalm Command
node TRM Cisco IGX 8420 9.3.40 May 23 2002
11:45 PST
Port States
Port ID State
13.1m FAILED
Last Command:cnfportalm 13.1 d
dspalms
The dspalms command indicates any disabled port alarms.
The dspintalmcnf command configures the thresholds for the integrated line/trunk alarm parameters.
This command is the renamed version of the existing CLI command dsplnalmcnf to avoid the conflict between the line alarm masking and integrated alarm parameter configuration of lines.
Syntax:
No change
Trunk VC Shaping
This feature provides the capability to enable VC shaping on UXM and BXM trunks, virtual trunks, and feeder trunks per Qbin or QoS.
Compatibility
On the BPX, the BXM card must support the trunk VC shaping feature for VC shaping to be enabled on the trunks.
On the IGX, the UXM card must support traffic shaping for VC shaping to be enabled on the trunks.
This feature is compatible only with firmware releases supporting traffic shaping. Additionally, PCR shaping can be disabled per QBin only if the firmware release supports trunk VC shaping. Otherwise, PCR shaping cannot be disabled.
Limitations
The capability to enable and disable VC shaping is available only on AutoRoute Qbins (1-9). VC shaping cannot be enabled on the high priority Qbin (2) since this Qbin services the CC traffic. VC shaping cannot be enabled on other Qbins (Qbin 0, VSI Qbins 10-15).
The maximum rate at which a VC can transmit is limited by its PCR value if PCR shaping is enabled.
Enabling VC Shaping (or disabling from previous enable state) on a trunk applies only to new connections routed over the trunk. VC shaping can be applied to all the connections belonging to a Qbin by performing a reroute.
Functionality
The feature provides the following functions:
Enables PCR-shaping on BXM trunks, virtual trunks, and feeder trunks on a per-QoS basis.
Enables weighted fair queuing (WFQ) on BXM trunks, virtual trunks, and feeder trunks on a per-QoS basis.
Enables VC shaping (WFQ and PCR shaping) on UXM trunks, virtual trunks, and feeder trunks on a per-QoS basis.
The VC shaping capability can be turned on per QoS on the BXM card by configuring the appropriate Qbin to enable the function. When VC shaping is enabled on a Qbin, egress cells are placed on their respective VC queues before they are scheduled into the Qbin. Cells are scheduled from different VC queues into the Qbin using WFQ to ensure fairness among the different VCs.
On the UXM card, VC shaping can be turned on per trunk. The configuration is then applied to relevant Qbins.
Traffic from a VC queue into the Qbin is limited to the PCR. When VC shaping is enabled, both PCR-shaping and WFQ are in effect. However, PCR-shaping can be removed by programming the PCR of the connection to a large value, leaving only WFQ in effect.
The user can enable VC shaping for a particular Class of Service (CoS) on a trunk or virtual trunk using the cnftrkqparm command, cnftrk command on the IGX, or SNMP.
On the BXM, depending on the CoS, the user is provided with the following options:
D = Disabled (default)
E = Both WFQ and PCR-shaping
W = WFQ only
On the IGX the options are
E = Both WFQ and PCR-shaping
D = Disabled
CLI Modifications and Additions
This section contains the CLI modifications to support the trunk VC shaping feature.
cnftrk
The cnftrk command on the IGX was used to enable VC shaping on a per trunk basis before this feature. Since the feature moves the capability to a per-QoS basis, the VC shaping parameter in the cnftrk command is removed.
cnftrkq
The cnftrkq command enables and disables VC shaping for trunks, virtual trunks, and feeders on a per-Qbin basis.
Note The cnftrkq command is a new command applicable only to BXM cards.
VC shaping can be enabled only on the AutoRoute Qbins using this command. Enabling VC shaping on VSI Qbins is not supported. The default values for all the Qbins is disabled.
VC shaping can be enabled on a QBin only if that card supports VC shaping. If a card does not support VC shaping the following error message displays: VC shaping not supported on the card.
The following example shows the cnftrkq command display.
This feature does not have impact on redundancy. No mismatch is declared if one of the cards in a Y-red pair supports this feature and the other does not. However, the feature is activated only if both cards in Y-red support the feature.
MIB Additions
The atmTrunks MIB table currently contains the atmTrkVcShaping object to enable VC shaping per trunk. This object is not used for the BPX and nine new objects are added to enable VC shaping per Qbin. The existing object, atmTrkVcShaping, is still used on the IGX.
Table 11 describes the new objects that are applicable only on BXM cards.
Table 11 atmTrunks Additions
MIB Object
Description
Values
atmTrkNonTSVcShaping
Value to indicate whether the trunk should do VC shaping on the non-time stamped (NonTS) Qbin.
This object is valid only for routing trunks. An error is returned for a SET request on feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
atmTrkVoVcShaping
Value to indicate whether the trunk should do VC shaping on the rt-VBR/Voice Qbin.
This object is valid for routing and feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
atmTrkBdataAVcShaping
Value to indicate whether the trunk should do VC shaping on the Bursty data A Qbin.
This object is valid only for routing trunks. An error is returned for a SET request on feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
3 = wfq-pcr
atmTrkTsVcShaping
Value to indicate whether the trunk should do VC shaping on the time stamped (TS) Qbin.
This object is valid only for routing trunks. An error is returned for a SET request on feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
3 = wfq-pcr
atmTrkBdataBVcShaping
Value to indicate whether the trunk should do VC shaping on the Bursty Data B Qbin.
This object is valid only for routing trunks. An error is returned for a SET request on feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
3 = wfq-pcr
atmTrkCbrVcShaping
Value to indicate whether the trunk should do VC shaping on the CBR Qbin.
This object is valid for routing and feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
atmTrkVbrVcShaping
Value to indicate whether the trunk should do VC shaping on the nrt-VBR Qbin.
This object is valid for routing and feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
3 = wfq-pcr
atmTrkAbrVcShaping
Value to indicate whether the trunk should do VC shaping on the ABR/UBR Qbin.
This object is valid for routing and feeder trunks.
If the card does not support trunk VC shaping, the configuration is accepted but not enabled.
This object can only be set with other per Qbin trunk VC shaping objects.
Access: read-write
1 = disabled
2 = wfq-only
3 = wfq-pcr
Special Installation/Upgrade Requirements
This section contains the installation procedures and upgrade requirements.
General Upgrade Procedure
Note Consult a Support Representative before performing any software upgrade.
The earliest release supported for a graceful upgrade is 9.2.23.
Before upgrading the switch software, make sure the cards have the minimum firmware revision per the compatibility matrix.
Procedure for Upgrading BXM cards to the 9.3 Firmware Release
See Appendix A for instructions on upgrading the BXM firmware.
See the Compatibility Matrix for the tested/supported versions of other firmware and software that work with this release.
Procedure for Upgrading UXM cards to the 9.3 Firmware Release
Note For the VSI/MPLS feature, upgrade the UXM firmware to revision ACC or later. The upgrade procedure
has changed.
If the switch software version on the node is Release 9.2.x, the following steps are required to upgrade the UXM firmware to revision ACC or later:
Step 1 Execute a graceful upgrade to Release 9.3.30.
Step 2 Upgrade the UXM boot code to boot 8.
Step 3 Upgrade the run-time UXM firmware to revision ABJ or greater.
Step 4 After the card comes up, upgrade the run-time firmware to revision ACC or later.
Warning If these procedures are not followed, the card might enter a state from which it can NOT be recovered. See Appendix B for more information about loading the new firmware.
If a Switch Software Release 9.3.x has already been loaded onto the node, the following steps are required to upgrade the UXM firmware to revision ACC:
Step 1 Execute a graceful upgrade to Release 9.3.30.
Step 2 Upgrade the run-time UXM firmware to revision ACC.
Procedure for Adding New BCC Cards as a Part of Upgrading to Release 9.3
If new BCC cards are to be installed as part of the upgrade to Release 9.3, then the physical card upgrade procedure described below must be completed as a separate activity from the Switch software upgrade.
If upgrading to BCC-4 cards on BPX 8600 nodes, perform the software upgrade, followed by the BCC-4 physical card upgrade.
If BCC-4 is already installed, then upgrade as normal.
If any other type of BCC cards are being physically upgraded, complete the physical upgrade of the cards first, followed by the software upgrade.
Revision Interoperability Supported
The Revision Interoperability feature allows a mixed/ heterogeneous network of 9.2.x and 9.3.x (where "x" equals any GA version of 9.2 and 9.3) nodes to coexist and interoperate. This capability allows users to upgrade their networks from 9.2 to 9.3 in multiple steps.
Note It is not recommended that users operate in this state for extended periods of time.
Normal network maintenance and operations such as provisioning, trunk reroutes, card insertions and removals, and normal network alarming, are supported in the mixed revision network. Normal alarms can be received while upgrading a node to Release 9.3.
In a mixed-revision network, functions that are implemented in 9.3 but not in 9.2 are disabled. For example, features that are supported in both Releases 9.2 and 9.3 function at their 9.2 level. New features developed in 9.3 are automatically enabled when all nodes are upgraded to the 9.3 revision level.
Specifically, connection provisioning, connection rerouting, alarming, and CWM support for these features are supported but function at their 9.2 capabilities, and not at their 9.3 levels until all nodes are upgraded. The dspblkdfuncs command displays blocked (disabled) features.
For 9.3.30 and above, the following features are blocked in a mixed network. These features require that all nodes of the network are running 9.3.30.
URM Remote Router Configuration
TFTP Configuration Save and Restore
Concurrent Routing
Note The URM card cannot be activated in a network with mixed switch software releases.
Version Compatibility Notes
For a complete list of firmware revisions supported, see the Compatibility Matrix document, which is included in this release package.
This release supports:
NTM firmware version NEK and NFK or later. For 2048 kbps support and trunk encryptor synchronization, use NJA and NKA or later.
Any MGX 8220 Release 4.1 and 5.0
Cisco WAN Manager (Cisco StrataView Plus) version 10.5.10 and later
UXM firmware
For MPLS VC merge and trunk loopback features, ACJ or later
For MPLS/VSI feature, UXM model ACB or later
If not using MPLS/VSI feature, UXM model ABH or later
BXM firmware
Model MFN or later
For MPLS VC merge, trunk VC traffic shaping, and VT oversubscription features, MFV or later.
UFM firmware for ELMI-based topology discovery feature
For UFM-C model B, version ZBD, and UFM-U model B, version YBC
For UFM-C model A, version ZAT, and UFM-U model A, version YAL
URM Model A XAA, or later
URM Model B XBA or later
MGX 8850 version 1.1.40
SES version 1.1.60
IOS version 12.2 (8)T4
LSC IOS Version 12.2(8)T4 for VC merge
Note VNS interworking is not supported in Release 9.3.30 and later.
Control Card Requirements
All BPX processor cards must be configured with a minimum of 64 MB of RAM, and NPMs must be configured with a minimum of 32 MB of RAM. NPMs require at least 1 MB of BRAM. To verify the BRAM size on IGX 8400 nodes, use the dspcd command.
Control Card Boot Firmware Requirements
As specified below, the correct version of CC boot firmware must be installed on the cards prior to a software upgrade to Release 9.3.
BCC Type
Firmware
BCC-3-64
H.D.M
BCC-4V
H.H.M
BCC-4V/B
H.H.M
NPM Type
Firmware
NPM-32
R.B.S
NPM-64
R.C.S
NPM-32B
R.E.S
NPM-64B
R.F.S
With the new version of NPM boot code (RxS), upgrading does not require physical card resetting with the following steps:
Step 1 Burn the boot code on the active NPM(1).
Step 2 Execute the switchcc command. Wait until the NPM(1) becomes standby.
NPM(2) is now active.
Step 3 Execute the resetcd command to reset the standby (resetcd 1 h). Wait until the reset card NPM(1) becomes standby.
Step 4 Burn the boot code on the active NPM(2).
Step 5 Execute the switchcc command. Wait until the NPM(2) becomes standby.
NPM(1) is now active.
Step 6 Execute the resetcd command to reset the standby (resetcd 2 h). Wait until the reset card NPM(2) becomes standby.
Control Card Compatibility Requirements
Each redundant pair of BCC cards in a given BPX 8600 node must be of identical type and memory configuration. For example, if the active card is a BCC-3-64, then the standby card must be the same. BCC-3 cards with 64 MB of RAM cannot be mixed with BCC-4 cards.
Each redundant pair of NPM cards in a given IGX 8400 node must be of identical type and memory configuration. For example, if the active card is an NPM-32, then the standby card must be the same. NPM cards with 32 MB of RAM cannot be mixed with NPM cards with 64 MB of RAM. Also, NPM-64 cards cannot be mixed with NPM-64B cards.
These requirements apply to all software upgrade procedures. These requirements do not apply to the physical card upgrade procedure, as described below.
Control Card Physical Card Upgrade Procedure
When performing a control card (CC) upgrade, the following procedure must be used on all BCC and/or NPM processors:
Step 1 Remove the current standby CC front and back cards. (Removal of back card only applies to BCC.)
Step 2 Replace with new CC front and back cards that are identical to the current active CC. (Replacement of back card only applies to BCC.)
Note After Step 2, the node contains a mix of an old type CC and the new type CC. This condition is
permitted only while the standby updates to the new CC are in progress, which takes less than
one hour. The time during which this mixture of CC types exists must be kept to a minimum by
immediately replacing the second old type CC with the matching one of the new type.
Step 3 Wait for the standby updates on the newly installed standby CC to complete.
Step 4 Issue a switchcc command to utilize the newly installed CC.
Step 5 Verify that the network is stable.
Step 6 Remove the current standby CC front and backcard. (Remove back card only applies to BCC.)
Step 7 Replace with new CC front and back cards that are identical to the current active CC. (Replace back card only applies to BCC.)
Step 8 Wait for the standby updates on the newly installed standby CC to complete.
The CC physical upgrade is now complete.
Step 9 With the secondary card in the standby state, cause a switchover using the switchcc command. This command tests that the hardware is working correctly.
To take advantage of the dual SIU when upgrading to the BCC-4, the BPX 8600 node must have a new backplane that has dual traces incorporating with the BCC-4.
The dspbpnv command can be issued to verify if the node has the new backplane or the old backplane. The following table details the bit fields for the BCC backplane NOVRAM format. The display of word 2 describes the backplane type.
16 Bit Word
Byte # (hex)
Contents
0
0,1
Hardware revision
1
2,3
Backplane Type (usually 0x65=101 decimal)
2
4,5
Backplane version (0x0000:old 0x0001:new)
3
6,7
Backplane serial number in ASCII - MSB
4
8,9
Backplane serial number in ASCII - MSB
5
A,B
Backplane serial number in LSB
6
C,D
Board FAB number, in ASCII - MSB
7
E,F
Board FAB number, in ASCII - LSB
8
10,11
Board FAB number, in ASCII - LSB
9
12,13
Board FAB number, in ASCII - LSB
A
14,15
Board FAB number, in ASCII - LSB
B
16,17
Board FAB number, in LSB
C
18,19
Unused
D
1A,1B
Unused
E
1C,1D
Unused
F
1E,1F
Checksum bytes - NOT SUPPORTED
The cnfbpnv command can be used to configure the backplane if backplane is enabled.
Obsoleted Hardware and Firmware
BPX BCC-32 cards are no longer supported in Release 9.3.
The following IGX cards are no longer supported in Release 9.3:
FTM
BTM
ALM/A
ALM/B
UVM model A, B, and C firmware are not supported in SWSW Release 9.3 and later.
Adaptive Voice feature is not supported in IGX SWSW Release 9.3.
Notes and Cautions
The peak intervals are controlled to be only those values for which peaks can be accurately collected The following rules apply to peak intervals:
Cannot be 0.
Must be a multiple of the polling interval.
Must be a factor of the bucket interval.
Can be the same as the bucket interval.
Limitations for Release 9.3.40
None.
Compatibility Matrix
This section contains compatibility information for Release 9.3.47.
Compatibility Notes
For a complete list of firmware revisions supported, see the Compatibility Matrix document, which is included in this release package.
This release runs with Release 4.1.0x or 5.0.0x of the MGX 8220.
MGX 8220 Firmware Compatibility
The following table lists the MGX 8220 firmware.
System 5.0
System 4.1
PCB Description
CW2000 Name
Latest F/W
Min F/W
Latest F/W
Min F/W
ASC F/W
ASC
5.0.18
5.0.17
4.1.11
4.1.00
ASC Boot
ASC
1.0.03
1.0.01
1.0.03
4.0.04
ASC/2 FW
ASC
5.0.18
5.0.17
4.1.11
4.1.00
ASC/2 Boot
ASC
1.0.03
1.0.01
1.0.03
4.0.04
ASC/2F FW
ASC
5.0.18
5.0.17
4.1.11
4.1.05
ASC/2F Boot
ASC
1.0.03
1.0.01
1.0.03
1.0.01
BNM-T3
BNM-T3
n/a
n/a
n/a
n/a
BNM-E3
BNM-E3
n/a
n/a
n/a
n/a
BNM-155
BNM-155
n/a
n/a
n/a
n/a
FRSM-4T1
FRSM-4T1
4.0.24
4.0.19
4.0.23
4.0.13
FRSM-4E1
FRSM-4E1
4.0.24
4.0.19
4.0.23
4.0.13
FRSM-4T1-C
FRSM-4T1-C
4.0.22
4.0.19
4.0.23
4.0.13
FRSM-4E1-C
FRSM-4E1-C
4.0.22
4.0.19
4.0.23
4.0.13
FRSM Boot
FRSM-4T1
4.0.00
4.0.00
4.0.00
4.0.00
FRSM Boot
FRSM-4E1
4.0.00
4.0.00
4.0.00
4.0.00
FRSM Boot
FRSM-4T1-C
4.0.00
4.0.00
4.0.00
4.0.00
FRSM Boot
FRSM-4E1-C
4.0.00
4.0.00
4.0.00
4.0.00
SRM T1E1 (B)
SRM-T1E1
n/a
n/a
n/a
n/a
SRM 3T3
SRM-3T3
n/a
n/a
n/a
n/a
CESM-4T1
CESM-4T1
4.0.18
4.0.15
4.0.17
4.0.11
CESM-4E1
CESM-4E1
4.0.18
4.0.15
4.0.17
4.0.11
CESM Boot
CESM-4T1
4.0.01
4.0.01
4.0.01
4.0.00
CESM Boot
CESM-4E1
4.0.01
4.0.01
4.0.01
4.0.00
CESM-8T1
CESM-8T1
5.0.15
4.1.05
4.1.09
4.1.00
CESM-8E1
CESM-8E1
5.0.15
4.1.05
4.1.09
4.1.00
CESM-8 Boot
CESM-8T1
1.0.01
1.0.01
1.0.01
4.1.00
CESM-8 Boot
CESM-8E1
1.0.01
1.0.01
1.0.01
4.1.00
AUSM-4T1
AUSM-4T1
4.0.22
4.0.19
4.0.21
4.0.13
AUSM-4E1
AUSM-4E1
4.0.22
4.0.19
4.0.21
4.0.13
AUSM Boot
AUSM-4T1
4.0.00
4.0.00
4.0.00
4.0.00
AUSM Boot
AUSM-4E1
4.0.00
4.0.00
4.0.00
4.0.00
FRSM-8T1
FRSM-8T1
5.0.16
5.0.10
4.0.24
4.0.13
FRSM-8E1
FRSM-8E1
5.0.16
5.0.10
4.0.24
4.0.13
FRSM-8T1 Boot
FRSM-8T1
1.0.02
1.0.01
1.0.02
4.0.01
FRSM-8E1 Boot
FRSM-8E1
1.0.02
1.0.01
1.0.02
4.0.01
AUSM-8T1
AUSM-8T1
5.0.16
5.0.10
4.0.24
4.0.14
AUSM-8E1
AUSM-8E1
5.0.16
5.0.10
4.0.24
4.0.14
AUSMB-8T1
AUSMB-8T1
5.0.14
5.0.10
4.0.24
4.0.19
AUSMB-8E1
AUSMB-8E1
5.0.14
5.0.10
4.0.24
4.0.19
AUSM-8T1E1 Boot
AUSM-8T1
1.0.02
1.0.01
1.0.02
4.0.01
AUSM-8T1E1 Boot
AUSM-8E1
1.0.02
1.0.01
1.0.02
4.0.01
AUSM-8T1E1 Boot
AUSMB-8T1
1.0.02
1.0.01
1.0.02
4.0.01
AUSM-8T1E1 Boot
AUSMB-8E1
1.0.02
1.0.01
1.0.02
4.0.01
FRSM-HS1
FRSM-HS1
5.0.15
4.0.16
4.0.20
4.0.11
FRSM-HS1/B
FRSM-HS1/B
5.0.14
4.0.16
4.0.20
4.0.11
FRSM-HS1 Boot
FRSM-HS1
1.0.01
1.0.01
1.0.01
4.0.00
FRSM-HS1 Boot
FRSM-HS1/B
1.0.01
1.0.01
1.0.01
4.0.00
FRSM-HS2
FRSM-HS2
5.0.13
5.0.10
n/s
n/s
FRSM-HS2 Boot
FRSM-HS2
1.0.01
1.0.01
n/s
n/s
IMATM
IMATM-T3T1
n/s
n/s
4.0.22
4.0.13
IMATM
IMATM-E3E1
n/s
n/s
4.0.22
4.0.13
IMATM
IMATMB-T1
5.0.15
5.0.10
4.0.22
4.0.13
IMATM
IMATMB-E1
5.0.15
5.0.10
4.0.22
4.0.13
IMATM Boot
IMATM-T3T1
n/s
n/s
1.0.02
4.0.01
IMATM Boot
IMATM-E3E1
n/s
n/s
1.0.02
4.0.01
IMATM Boot
IMATMB-T1
1.0.02
1.0.01
1.0.02
4.0.01
IMATM Boot
IMATMB-E1
1.0.02
1.0.01
1.0.02
4.0.01
MGX 8850 1.1/1.2 Firmware Compatibility
The following table lists the MGX 8850 Release 1.1/1.2 firmware.
The following table lists the MGX 8230 and MGX 8250 firmware.
PCB Description
CW2000 Name
Latest F/W
Min F/W
PXM1
PXM-1
1.2.13
1.1.40
PXM1-2-T3E3
PXM1-2T3E3
1.2.10
1.1.40
PXM1-4-155
PXM1-4OC3
1.2.10
1.1.40
PXM1-1-622
PXM1-OC12
1.2.10
1.1.40
MGX-SRM-3T3/C
SRM-3T3
n/a
n/a
AX-CESM-8E1
CESM-8E1
10.2.13
10.0.21
AX-CESM-8T1
CESM-8T1
10.2.13
10.0.21
MGX-AUSM-8E1/B
AUSMB-8E1
10.2.13
10.0.21
MGX-AUSM-8T1/B
AUSMB-8T1
10.2.13
10.0.21
MGX-CESM-T3
CESM-T3
10.2.13
10.0.21
MGX-CESM-E3
CESM-E3
10.2.13
10.0.21
AX-FRSM-8E1/E1-C
FRSM-8E1
10.2.13
10.0.21
AX-FRSM-8T1/T1-C
FRSM-8T1
10.2.13
10.0.21
MGX-FRSM-HS2
FRSM-HS2
10.2.01
10.0.22
MGX-FRSM-2CT3
FRSM-2CT3
10.2.01
10.0.22
MGX-FRSM-2T3E3
FRSM-2T3
10.2.01
10.0.22
MGX-FRSM-2T3E3
FRSM-2E3
10.2.01
10.0.22
MGX-FRSM-HS1/B
FRSM-HS1/B
10.2.13
10.0.21
MGX-VISM-8T1
VISM-8T1
3.1(1)
2.1.1(0)
MGX-VISM-8E1
VISM-8E1
3.1(1)
2.1.1(0)
MGX-RPM-128M/B
RPM
12.2(11)T2
12.2(4)T
MGX-RPM-PR
RPM
12.2(11)T2
12.2(4)T
CWM
—
11.0.10
10.5.10
BPX 8600 Firmware Compatibility
The following table lists the BPX firmware.
PCB Description
dspcds Name
Card Name in FW Image
Model
Latest F/W
Min F/W
BCC-3-64 boot
BCC-3
BCC
D
HDM
HDM
BCC4 boot
BCC-4
BCC
E
HEM
HEM
BCC4-128 boot
BCC-4
BCC
H
HHM
HHM
ASI 2T3/2E3
ASI-T3
ASI
B
n/s
n/s
ASI 2T3/2E3
ASI-E3
ASI
B
n/s
n/s
ASI 2T3/2E3
ASI-T3
ASI
C
UCF
UCF
ASI 2T3/2E3
ASI-E3
ASI
C
UCF
UCF
ASI-155
ASI-155
ASI-155
B
n/s
n/s
ASI-155-E
ASI155E
ASI-155
D
n/s
n/s
ASI-155-E
ASI155E
ASI-155
E
WEC
WEC
ASI-155
ASI-155
ASI-155
H
WHC
WHC
ASM
ASM
A
GAC
GAC
BXM-BME
BME
BME
K
N/S
N/S
BXM-T3-8/12
BXM-T3
BXM
F
MFX
MFW
BXM-E3-8/12
BXM-E3
BXM
F
MFX
MFW
BXM-155-4/8
BXM-155
BXM
F
MFX
MFW
BXM-622/622-2
BXM-622
BXM
F
MFX
MFW
BXM-T3-8E/12E/12EX
BXM-T3
BXM
F
MFX
MFW
BXM-E3-8E/12E/12EX
BXM-E3
BXM
F
MFX
MFW
BXM-155-4D/8D/4DX/8DX
BXM-155
BXM
F
MFX
MFW
BXM-622-2D/DX/2DX
BXM-622
BXM
F
MFX
MFW
BNI-3T3/3E3
BNI-T3
BNI
C
TCM
TCM
BNI-3T3/3E3
BNI-E3
BNI
C
TCM
TCM
BNI-155
BNI-155
BNI-155
B
VBR
VBR
BNI-155-E
BNI155E
BNI-155
D
VDR
VDR
IGX 8400 Firmware Compatibility
Note For the VSI/MPLS feature, the UXM firmware needs to be upgraded to revision ACC or later. The
upgrade procedure has changed.
If the switch software version on the node is Release 9.2.x, the following steps are required to upgrade the UXM firmware to revision ACC or later:
Step 1 Execute a graceful upgrade to Release 9.3.47.
Step 2 Upgrade the UXM boot code to boot 8.
Step 3 Validate that boot code 8 is running.
Caution Upgrading the run-time firmware to ACC without boot code 8 can damage the UXM card.
Step 4 Upgrade the run-time UXM firmware to revision ABJ or greater.
Step 5 After the card comes up, upgrade the run-time firmware to revision ACC or later.
Warning If these procedures are not followed, the card might enter a state from which it can NOT be recovered. See Appendix B for more information about loading the new firmware.
If a Switch Software Release 9.3.x has been loaded onto the node, the following steps are required to upgrade the UXM firmware to revision ACC:
Step 1 Execute a graceful upgrade to Release 9.3.47.
Step 2 Upgrade the run-time UXM firmware to revision ACC or later.
1 IGX-UVM model E supersedes models A, B, and C firmware. A, B, and C are obsolete and should not be used.
MGX 8220 5.0 Hardware Compatibility
The following table lists the MGX 8220 hardware.
Card Type
Hardware Revisions
Image Type
ASC
AH, AJ, AK, AL, AM, AN, AP, AR
ASC
ASC/B
AN
ASC
ASC2
BA, BB, BC, BD, BE, BF
ASC
ASC2F
BA, BB, BC, BD, BE, BF
ASC
BNM-T3
AJ, BA, BB, BC, BD
ASC
BNM-T3/B
BE, BF
ASC
BNM-E3
AA, AB, AC
ASC
BNM-E3/B
AD, AE
ASC
BNM-155
AA, AB, AC, AD, AE, AF, AH
ASC
SRM-T1E1
AB, AC, BA, BB, BC
ASC
SRM-T1E1/B
BD
ASC
SRM-3T3, SRM-3T3/B, SRM-3T3/C
BA, BB, BC, BD, BE, BF
ASC
FRSM-4T1E1
AJ, BK, BL, BM, BN, BP, BQ, CA, CB, CC, CE
ASC
FRSM-8T1E1
AA, AB, AC
FRSM
FRSM-HS1
AA, AB, AC, AD, AE, AH, AJ
FRSM-8T1E1
FRSM-HS1/B
AA
FRSM-HS1
FRSM-HS2
800-029099-03 AO, 800-02909-04 AO
FRSM-HS2
CESM-RT1E1
AA, BA, BB, BC
CESM
AUSM-4T1E1
AA, AB, AC, BA, BB, BC, BD
AUSM
AUSM-8T1E1
AA, AB, AC, AD, AE, AF
AUSM-8T1E1
AUSM-8T1E1/B
AA
AUSM-8T1E1
IMATM-8T1E1
AA, AB, AC, AD, AE, AF, AG
IMATM8
IMATM-8T1E1/B
AA, AB, AC, AD, AE, AF
IMATM8
CESM-8T1E1
AA, AB, AC
CESM-8T1E1
BPX 8600 Hardware Compatibility
The following table lists the BPX hardware.
Card Type
Part Numbers
Latest H/W
Min. H/W
Controller Cards
BPX-BCC-64M (Non-Orderable)
800-04008-04
A
A
BPX-BCC-BC (Non-Orderable)
73-211380-00
D
A
BPX-BCC-3-64M
73-3720-02
R
J
BCC-3BC
800-02916-01
E
A
BPX-BCC4V
800-03580-06
E
C
BPX-BCC-4V/B
800-06483-02
C
A
ASI-2T3
73-216330-00
F
A
ASI-2E3
73-216330-01
F
A
ASI-155E
73-214250-00
H
F
ASI-155E
73-218100-02
J
A
Alarm Group
BPX-ASM
800-04009-01
C
A
BPX-ASM-BC
73-211910-00
C
A
ASM-LM
800-211910-10
B
A
Broadband Switch Group
BPX-BME
800-02855-04
B
A
BPX-BXM-T3-8
800-02777-07
J
B
BPX-BXM-T3-8E
800-03933-02
A
A
BPX-BXM-E3-8
800-02779-07
J
B
BPX-BXM-E3-8E
800-03928-02
A
A
BPX-BXM-T3-12
800-02776-07
J
B
BPX-BXM-T3-12E
800-03931-02
A
A
BPX-BXM-T3-12EX
800-03934-02
A
A
BPX-BXM-E3-12
800-02778-07
J
B
BPX-BXM-E3-12E
800-03929-02
A
A
BPX-BXM-E3-12EX
800-03930-02
A
A
BPX-T3/E3-BC
73-2759-02
A
A
BPX-BXM-155-8
800-02664-07
J
B (C for APS)
BPX-MMF-155-8-BC
800-03255-01
B
A
BPX-SMF-155-8-BC
800-03257-01
B
A
BPX-SMFLR-155-8-BC
800-02593-01
B
A
BPX-BXM-155-4
800-02666-07
J
B (C for APS)
BPX-BXM-E-155-4D
800-03094-02
A
A
BPX-BXM-E-155-8D
800-03092-02
A
A
BPX-BXM-E-155-4DX
800-03093-02
A
A
BPX-BXM-E-155-8DX
800-03091-02
A
A
BPX-MMF-155-4-BC
800-03256-02
B
A
BPX-SMF-155-4-BC
800-03258-01
B
A
BPX-SMFLR-155-4-BC
800-02594-02
B
A
BPX-BXM-622
800-02646-10
M
D (E for APS)
BPX-BXM-622-2
800-02638-10
M
D (E for APS)
BPX-BXM-E-622-2D
800-03150-02
A
A
BPX-BXM-E-622-DX
800-03151-02
A
A
BPX-BXM-E-622-2DX
800-03149-02
A
A
BPX-622-2-BC
73-2884-01
D
A
BPX-SMF-622-BC
800-03249-01
C
A
BPX-SMF-622-2-BC
800-03251-01
C
A
BPX-SMFLR-622-BC
800-03250-01
C
A
BPX-SMFLR-622-2-BC
800-03252-01
D
A
BPX-XLR-622
800-02738-01
C
A
BPX-XLR-622-2
800-02739-01
C
A
BPX-BME-OC12
73-2469-07
F
A
RDNT-SMF-155-4R
800-03677-01
J
A
RDNT-SMF-155-8R
800-03679-01
K
A
RDNT-LR-155-8R
800-03678-01
J
A
RDNT-LR-622-2R
800-03676-01
F
A
RDNT-SMF-622R
800-03675-01
F
A
RDNT-SMF-622-2R
800-03674-01
J
A
BPX-STM1-EL-4
800-03716-02
A
A
BNI-3-T3/C
800-02858-02
A
A
BNI-3-E3/C
800-02859-02
A
A
BNI-155E
73-218100-01
K
A
BNI-2-155/B
73-4133-01
L
L
BPX-T3/E3
800-03058-02
E
A
BPX-E3-BC
73-213070-01
E
A
BPX-MMF-2-BC
73-214290-00
D
A
BPX-SMF-2-BC
73-216270-00
D
A
BPX-SMFLR-2-BC
73-216270-01
D
A
SMF-LM-OC3
800-216270-10
C
A
SMF-LM-OC3-LR
800-216270-11
C
A
MMF-LM-OC3
800-214290-10
B
A
LM-3T3
800-213070-10
D
A
LM-3E3
800-213070-11
D
A
IGX 8400 Hardware Compatibility
The following table lists the IGX hardware.
Card Type
Part Numbers
Latest H/W
Min. H/W
Comments
Controller Cards
IGX-NPM-32
73-2894-01
W
A
IGX-NPM-64
73-2895-01
W
A
IGX-NPM-32B
73-2554-04
L
A
IGX-NPM-64B
73-2363-02
C
A
IGX-SCM
73-3341-01
Y
A
Revision X or later for nodes with UXM IMA trunks
Alarm Group
IGX-ARM
73-218230-00
B
A
BC-512011
73-212360-00
D
A
Trunk Group
IGX-NTM
73-2296-04
E
A
BC-6271A-TI
73-207380-00
M
A
BC-6171A-E1
73-207370-01
P
A
BC-6083A-SR
73-208540-00
J
A
BC-550150-Y1
73-210820-01
D
A
ACM1
73-2921-03
W
A
BC-571110A-T3
73-2879-01
L
A
BC-571210A-E3
73-2679-01
K
A
BC-571310A-E2
73-215940-00
D
A
BC-571410A-HSSI
73-216370-00
A
A
IGX-UXM
73-2511-03
D
A
IGX-UXM-E
A
A
BC-UAI-4-155-SMF
73-2703-03
D
A
BC-UAI-4-155-MMF
73-2705-03
D
A
BC-UAI-2-155-SMF
73-2699-03
C
A
BC-UAI-2SMFXLR
A
A
BC-UAI-4SMFXLR
A
A
BC-UAI-6-T3
73-2952-02
A
A
BC-UAI-3-T3
73-2954-02
A
A
BC-UAI-6-E3
73-2953-02
A
A
BC-UAI-3-E3
73-2955-02
A
A
BC-UAI-8-E1-BNC
73-2932-02
C
A
BC-UAI-4-E1-BNC
73-3061-01
C
A
BC-UAI-8-T1-DB15
73-2941-02
C
A
BC-UAI-8-E1-DB15
73-2942-02
C
A
BC-UAI-4-T1-DB15
73-3059-01
C
A
BC-UAI-4-E1-DB15
73-3060-01
C
A
BC-UAI-4-STM1E
73-3364-02
A
A
Port Group
IGX-URM
800-06260-06
A
A
BC-2FE2V
800-06257-03
A
A
ACM1A
73-2930-03
W
A
IGX-HDM
73-2853-02
F
A
*Show SDP H/W Rev, DM=SDP+ACM2
ACM2
73-2922-03
T
A
BC-5082A-V35
73-2450-01
K
A
BC-5083A-RS449
73-204850-00
V
A
BC-5084B-RS232
73-2723-01
W
A
IGX-LDM
73-207250-00
K
A
*Show LDP H/W Rev, LDM=LDP+ACM1A
BC-5286A-RS232
73-207180-01
L
A
LDI-4RS232
BC-5287A-RS232
73-207180-00
L
A
LDI-8RS232
IGX-CVM-DSOA
73-3002-02
D
A*
*Show CDP H/W Rev, CVM=CDP+ACM1A
IGX-CVM-T1EC
73-3003-03
E
A*
*Show CDP H/W Rev, CVM=CDP+ACM1A
IGX-CVM-E1EC
73-209660-00
H*
A*
*Show CDP H/W Rev, CVM=CDP+ACM1A
IGX-CVM-TT
BC-6271A-TI
73-207380-00
M
A
BC-6171A-E1
73-207370-01
P
A
BC-550100-J1
73-210820-00
C
A
IGX-FRM
73-2517-03
N
A
IGX-FRM-31
73-2517-03
N
A
IGX-FRM-2
73-2519-01
M*
A*
*Show FRP H/W Rev, FRM-2=FRP+ACM1A
BC-6251B-V35
73-3253-01
M
A
FRI-4V.35-2
BC-6254A-X21
73-211440-00
H
A
FRI-X.21
BC-6355A-X21
73-214120-01
C
A
FRI-2X21
IGX-UFM-4C
73-2531-05
N
A
Needs a minimum of ZAS/ZBC Firmware
IGX-UFM-8C
73-2531-05
N
A
Needs a minimum of ZAS/ZBC Firmware
BC-UFI-8T1-DB15
73-2444-02
D
A
BC-UFI-8E1-DB15
73-2445-02
D
A
BC-UFI-8E1-BNC
73-2449-02
D
A
IGX-UFM-U
73-2349-04
D
A
BC-UFI-12V35
73-2711-01
D
A
BC-UFI-12X21
73-2712-01
D
A
BC-UFI-4HSSI
73-2693-01
C
A
IGX-UVM
73-2361-04
K
A
BC-UVI-2E1EC
73-2420-01
B
A
BC-UVI-2T1EC
73-2373-01
C
A
BC-UVI-2S1EC
73-2374-01
A
A
Known Anomalies for Release 9.3.47
The following table lists the known anomalies for Release 9.3.47.
.
Bug ID
Description
CSCdk22430
Headline: Word 15 of bpnv checksum is not recalculated
Symptom: Checksum word 15 of backplane nvram is not recalculated when words 0-14 are updated using cnfbpnv.
Conditions: Observed with BPX 9.1.01.
Workaround: None
CSCdk80347
Headline: Standby NPM Watchdog Timeout after resetsys, 1M3, 2M, or abort command.
Symptom: NPM 2 restarted due to a Watchdog Timeout
Conditions: Happens when you run resetsys command to reset all the cards (except the active NPM card) on an IGX node with lot of active connections. When the standby NPM comes up, the event log mentions that: "NPM 2 Restarted due to a Watchdog Timeout" where 2 refers to the slot number of the standby NPM card.
Workaround: This does not affect any functionality except for the above log. Instead of running the resetsys command, individually reset the cards using resetcd command.
CSCdk91790
Headline: Eliminate UVMs modem polling to save system idle time
Symptom: SWSW system idle time is below 30% when more than 10 UVMs are activated
Conditions: SWSW polls each activated UVM for modem status every 1 second for each port. SWSW also spends time in processing the responses of the modem polling. When many UVMs are activated, the modem polling handling consumes a lot of system time and resources (buffer queue) which affect system performance. UVM FW has supported asynchronous event to report modem event. SWSW needs to stop polling modem status if the FW in UVM supports the async event.
Workaround: Use cnfnodeparm 46 to increase polling timer to improve system performance.
CSCdm22426
Headline: Commands which lock UI - dspbob - will cause jobs to fail without notice
Symptom: While using jobs to down or up the connection based on a jobtrigger, the job will fail if dspbob is executed while the control signal toggle.
Conditions: Observed with IGX 8.2.56.
Workaround: Retrigger the job after dspbob.
CSCdm40952
Headline: Two PVCs rerouted during switchcc in BPX network
Symptom: On a switchcc, the node will try to reroute some working connections not on their preferred route (dsprrst will show non-zero values). The reroute attempt will not be successful and the connections will continue to use their working path.
Conditions: This will happen only when preferred routes are set up for the connections and these connections are not routed on their preferred routes.
Workaround: If all connections are on their preferred route, this problem will not happen. To ensure that all connections are on their preferred route, execute "cnfpref * +" on that node - this will create a preferred route (same as the current route) for ALL the connections (including those which did not have preferred routes).
CSCdm76279
Headline: Cisco View no Data for FR-RealTimeCounters on IGX
Symptoms: When Using CiscoView to view the FR-RealTimeCounter SpreadSheet only the first two columns are displayed correctly, the remaining columns are displayed as 1's.
Conditions: All conditions are normal.
Workaround: None
CSCdp44912
Symptom: Upgrade from IGX 9.1.04 to 9.1.16 causes UXM Y-red card to go into mismatch.
Conditions: Same as above.
Workaround: delyred can be performed to avoid this condition.
Further Problem Description: Problem isolated "VC shaping" upgrade mechanism.
CSCdp48861
Headline: Polling for voice conn and line stats results in high TRNS RT usage
Symptom: The customer may notice slow UI response, or a difficulty logging into the node using the normal VT session. The dspprfhist shows high RT usage in the TRNS process. The thstats shows high RT usage by state machine 55 (0x33).
Conditions: This is due to statistics updates for voice connections. It may be seen on nodes with a high number of voice cards and voice connections (IGX with CVMs and/or UVMs).
Workaround: The command off1 17 can be performed. This will stop the collection of voice connection statistics (for all connections, not just voice), as well as the operation of the debug command dspchstats. If statistics must be collected, limit the number of statistics. Frame Relay statistics are collected at 5 minute intervals (configurable up to 15 minutes). Most voice statistics are reported at 1 minute intervals, but the following statistics are reported at 3 second intervals:
1. Seconds V.25 Modem On
2. Seconds DSI Enabled
3. Seconds Off-Hook
4. Seconds In Service
CSCdp98648
Headline: CWM 92 equipment manager does not support BXM enhance card type.
Symptom: Equipment Manager cannot tell the difference between BXM legacy or enhance.
Conditions: BPX nodes containing both legacy BXMs and Enhanced BXMs.
Workaround: Log into the BPX node and do dspcd XX and determine from number of channel support. The enhanced version of the BXM card has 61K channels, and the BXM card has less than 61K channels.
CSCdr05291
Headline: Problems deleting feeder trunks via SNMP
Symptom: switchIfService must be specified to delete feeder trunks, but not routing trunks.
Conditions: This requirement confuses CiscoView users.
Workaround: Use the CLI commands to delete feeder trunks.
CSCdr25278
Headline: Loss of Signal not properly indicated per UNI 3.1
Symptom: The SUT and EMS are not indicating LOS as per UNI 3.1
Conditions: None
Workaround: None.
CSCdr45021
Headline: BETA: Request to generate an alarm when an SES trunk use default SCT 1
Symptom: SCT 1 is default SCT reserved for MPLS. When an SES trunk is provisioned, if the default SCT is not changed to SCT 3, trunk will fail to come up.
Conditions: A warning message in configuration screen to indicate that the default is SCT 1 for MPLS and should be changed to SCT 3 for SES will be useful. This is an enhancement request from customer.
Workaround: Make sure that SES uplink uses SCT 3 as service class template.
CSCdr58295
Headline: burnfwrev before the completion of resetcd, makes the UXM card to Fail
Symptom: UXM card is in the "Failed/Unavail" state after the user issues a "burnfwrev" command while the card is coming up after a "resetcd".
Conditions: User issues a "burnfwrev" command before the UXM has come up after a "resetcd h".
Workaround: Do not issue the "burnfwrev" command until the UXM is up. If the "burnfwrev" command has been issued and the UXM is in the "Failed/Unavail" state issue a "resetcd h" to reset the UXM card.
CSCds34334
Headline: Traffic through IMATM trunks on BNI card doesnt fail
Symptom: Traffic statistics on local BNI IMA trunk doesn't fail when trunk card at remote end is downed.
Conditions: Connection between ASI-E3 and ASI-155E between two BPX nodes. Connection has a preferred route with d option through IMA trunk on BNI. IMA trunk between two BPX nodes through an AXIS node. Trunk card at remote end is downed.
Workaround: None.
CSCds47671
Headline: dspcurclk displays incorrect clock path for via nodes
Symptom: dspcurclk displays incorrect trunk numbers in the clock path
Conditions: Need the following clock path in dspcurclk for this problem to surface
Workaround: None.
Further Details: The display attempts to display the port on the via trunk before it is properly set.
CSCds64046
Headline: SW error 254 logged over weekend when network was in steady-state
Symptom: SWSW error 254
Conditions: Heterogeneous network devices 1. BPX, IGX nodes running 9.2.23 with SES PNNI controllers, tag LSCs 7200, tag LER 7200, AXIS feeders 2. Some alarms that were there prior to the SWSW error logged for long time
Workaround: None
CSCds68363
Headline: first_avail_lcn is UNKNOWN after BCC is switchcc or rebuilt
Symptom: dsplogcd shows the first_avail_lcn is UNKNOWN after switchcc or system rebuilt.
Conditions: It happens for BXM card with only ports.
Workaround: addcon to add new PVC, dsplogcd will show correct first_avail_lcn.
CSCds68603
Headline: tstdelay PVC after switchcc, the delay time is too long (> 290 msec.)
Symptom: None.
Conditions: None.
Workaround: None.
Further Problem Description This issue is firmware-related. The software is reporting the times. If the software is an issue, a profiler load taken during the test is required. However, the text makes reference to OAM load on the ASI, which indicates a firmware issue.
CSCds81526
Headline: Downed connections on master come up while on the slave side stays downed on the BPX/IGX.
Symptom:
1. The BPX and IGX nodes were loaded to their connection limit.
2. The dncon COS 0 i command was issued on the BPX node 3.
3. Downing about 70% of 16K connections took more that 2.5 hours (performance issue).
4. When the connections were downed, the master side and the slave side of the connection were showing down state which is correct.
5. The upcon COS 0 command was issued to up all downed connections. The command was issued on BPX node.
6. After CPU idle time reached 70%+ (steady-state) on the network wide, the master side of any connection is upped correctly (OK state). However, the slave side of the connection is still in the down state instead of the up state.
7. The upcon network messages were not propagated to the slave-side of the connection. The result is the master-side of the connection is upped, but the slave-side of the connection is still in down state.
8. The upcon finite state machines could be timing out or handling of such an inconsistent state under heavy loading still needs to be accounted.
Conditions:
1. Almost all 9.2.34+9.2.23 SWSW and SWFW features were provisioned.
2. The nodes were loaded to their limit with maximum terminating connections, VTs, and so forth.
3. Topology is of a tiered network with MGX 8220 and IGX feeders, MPLS LSCs and LERs, and SES PNNI controllers.
Workaround: The dncon/upcon commands with COS option can be executed only by users at SUPERGRP or higher privilege levels.
CSCdt07203
Headline: Hitless rebuilds logged on a failed switchcc can fill hitless lo.
Symptom: The hitless rebuild log filled up due to repeated failed switches.
Conditions: A bad standby BCC is required. The node must be running at least 9.2.
Workaround: Clear the hitless log with the command "dsphitless c" or switchcc less often so that the hitless rebuild log entries get a chance to age out of the log.
CSCdt66696
Headline: AIT-E3 backcard is displayed as BTM-E3 in CLI
Symptom: AIT-E3 backcard is displayed as BTM-E3 in CLI
Conditions: AIT-E3 backcard is displayed as BTM-E3 in switch CLI
Workaround: None
CSCdu03108
Headline: 1427 (NW_MSG_VERSION_MISMATCH) while nodes are upgrading.
Symptom: Software error 1427 logged on BPX node.
Conditions: Upgrade from release 9.1.19 to 9.2.3D (pre 9.2.38). The node logging the 1427 error is sending conditional updates to a node which upgrades during the process.
Workaround: None. However, the updates triggered by the upgrading node CC switch should maintain database consistency between the nodes. If the errors persist after the upgrade, then another issue has occurred.
CSCdu13921
Headline: Not enough trunk conids shows as not enough trunk BW for failed connections.
Symptom: Connection routing fails with the message "No route available (insufficient trunk bandwidth)" as seen with the [dspcon] command. However, when checking the trunk bandwidth usage via [dspload], enough bandwidth is allocated.
Conditions: This problem occurs when all of the connection identifiers (conids) are used. The most common occurrence of this issue is on BXM cards. These cards have configurable conid limits, and the defaults are rather small at 256.
Workaround: Check the [dspload] command. If the "Con ID Avail" count is 0, then the routing failure is due to connection ID exhaustion rather than bandwidth.
CSCdu15686
Headline: Diagnostics PortTest V35/X21
Symptom: Internal port diagnostics fails for V35/X21 ports. use "tstport" command. After the above test, the card goes to "Active-F" state as seen in "dspcds"
Condition: The above problem is seen only when port is configured as DCE and not seen with DTE ports. The UFMU F/W version YAM and YAN was tested and returned the same problem.
Workaround: None
CSCdu22300
Headline: Connections not routed due to wrong Gateway LCN calculation (RARE condition)
Symptom: Connections do not get routed even if there are enough resources on the trunk.
Conditions: All of the following should hold true.
1. Connections are being considered for routing in a network consisting of both UXM and NTM trunks.
2. If node X, node Y and node Z are the possible via nodes for a connection being considered for routing and
a. A UXM trunk (Trk1) connected between node X and node Y has the maximum available bandwidth among all of the trunks connected between node X and node Y.
b. A NTM trunk (Trk2) connected between node Y and node Z has the maximum available bandwidth among all of the trunks connected between node Y and node Z. Or, node Y is the slave node of the connection being considered for routing and is terminated on a non-UXM card. Gateway LCN is required at node Y's end of the UXM trunk (Trk1).
c. Gateway LCN is not available at node Y's end of the UXM trunk (Trk1).
3. The "Trunk Cell Routing Restriction" is set to "No" for the connection being considered for routing.
Workaround: Either one of the following options can be used:
1. Using the "cnfpref" command configure the connection to use a path which you have verified to carry the connection.
2. Using the "cnftrk" command, increase the Gateway LCNs on the UXM trunk (Trk1) at the node Y's end.
3. Increase the available BW on at least any one of the other trunks between Node X and Node Y such that it becomes more than the available bandwidth of the UXM trunk (Trk1).
4. Increase the available BW on at least any one of the UXM trunks between node Y and node Z such that it becomes more than the available bandwidth of the NTM trunk (Trk2). (Applicable only if node Y is not the slave node).
Available bandwidth can be obtained using the "dspload" command. Increasing the "Transmit Rate" and "Receive Rate" of the trunk at both ends of the trunk using the "cnftrk" command increases the available bandwidth.
CSCdv33406
Headline: BXM-155 w/ APS: Automatically loop release by switchyred command.
Symptom: While the APS(1+1) and the loop clock was configured to the BXM cards, the loop clock seemed to be released automatically on the execution of switchyred command.
Condition: APS 1+1 setup present and switchyred executed.
Workaround: Manually set the loop clock to NO once and then set back to YES again.
CSCdv36764
Headline: swerr 1008 was logged due to a BXM card resetting continuously
Symptom: swerr 1008 is logged when a BXM card is continuously reset every 5 minutes
Conditions: One of the BXM cards is continuously reset every 5 minutes due to an issue with the Stats Collection task of the BXM firmware running every 5 minutes on the card
Workaround: None
CSCdv73494
Headline: swerr 886,2071,2059 fills the log
Symptom: swerr 886,2071,2059 are in the log
Conditions: The log display shows the swerr
Workaround: None
CSCdv79961
Headline: Cannot configure stat level on UXM Y-red standby card
Symptom: Unable to configure stats level on standby card after upgrading swsw on IGX from 92 to 93 with UXM in Yred.
Conditions: 9.3.30; After upgrading from 9.2.34 to 9.3.11 UXM pair in Yred try to cnfcdparm for stat level change you receive this error message "Cannot change stats level for yred card or card in service" However, if you try the same thing when the card is not in yred, the node allows you to change.
Workaround:
1. Remove the standby card and place in some other empty slot.
2. Configure the stat level in the new, non-yred slot.
3. Replace the card into the y-red standby slot.
4. Wait until the card comes up fully as a standby, and has completed its programming.
5. Switch to the standby card that has the modified stat level.
6. Remove the new standby card and place in some other empty slot.
7. Repeat steps 2-3 on the next card.
CSCdv87535
Headline: chklm trk topology inconsistence in lsnt/upgrade/fallback
Symptom: Trunk topology inconsistency is observed between various nodes in the network.
Conditions: None.
Workaround: None.
CSCdw01866
Headline: LSNT: hitless rebuild, load updates is extremely slow
Symptom: After hitless rebuild in a large network, dspload does not show used recv load info for a long time. chklm could not be trust until all load updates sync up.
Conditions: During hitless rebuild.
Workaround: None.
CSCdw03498
Headline: Backcards empty after resetsys on node sw150.
Symptom: Backcards are "empty" in slot 3, 4, and/or 8 on sw node
Conditions: resetsys on sw node.
Workaround: None.
CSCdw04847
Headline: FastPackets used instead of cells for ATM queue size and delay calculations.
Symptom: The default value and the range allowed for queue size is wrong.
Conditions: This can be seen while using cnftrkparm to configure the queue sizes.
Workaround: A valid range is approximately half of that allowed in cnftrkparm. Configure the queue sizes to be within the valid range.
CSCdw04934
Headline: CLI switchyred command, took approximately 40 to 70 seconds to complete.
Symptom: switchyred sometimes took 40 to 70 seconds to complete.
Conditions: Network with following software configuration: 9.3.3d MF02
Workaround: None.
Further Problem Description: After loading MF02, switchyred is taking 40 to 70 seconds to complete.
CSCdw07614
Headline: Date and time changed after runrev command was issued.
Symptom: Date and time changed during upgrade.
Conditions: 9.3.3b and 9.3.3d MF01
Workaround: None.
Further Problem Description: The date/time changed after runrev command issued on two different nodes. This was noticed doing dsplog, it showed the date and time changed then changed back.
CSCdw30811
Headline: Improperly format FPAD port object and alarm messages sent to CWM
Symptom: Port and alarm messages for FTM ports are not formatted correctly, consequently the CWM cannot track or manage these entities. Because this message is misformated, the CWM does not know where it starts or ends, and consequently other messages from the switch can be discarded. This could then result in incomplete database tables so the CWM cannot collect statistics, manage the ports or establish new connections. This could also result in discarded alarm messages on the CWM so it may not set or clear alarm messages appropriately.
Conditions: This problem will only occur when FTM/FTC cards are on the IGX.
Workaround: Remove all configuration related to the FTM/FTC cards and remove them from the switch all together. FTM/FTC cards are not supported in 93 software, the last version of software that supported these cards was 92.
After removing FTM/FTC configuration and hardware, resync the CWM workstation by doing one of the following:
1. Do a controller card switch over on the IGX switch. This requires a redundant NPM switch. This breaks the link to the CWM, and when the CWM reattaches it will resync with this one node.
2. Do a hitless rebuild on the IGX switch. This will break the link to the CWM, and when the CWM reattaches, it will resync with this one node.
3. Do a full rebuild on the IGX switch.
Caution This will cause an outage on the node and is customer impacting. This will break the link to the CWM, and when the CWM reattaches, it will resync with this one node.
4. On the CWM, stop and then restart the CWM core.
Caution Note this causes the CWM to resync with all nodes in the network.
CSCdw42981
Headline: off3 parameters 1,2 and 3 get set to the default value after rebuild
Symptom: The settings for the following on3/off3 parameters set to their default values (as shown below) after rebuild; Trace Msg Sent
Disabled Multi-DB Stby Updates
Enabled Trace Conv Msg
Disabled
Conditions: This only occurs if the user has modified the setting from its default value, and then a full rebuild occurs. For example if the value of "Multi-DB Stby Updates" was set to Disabled then after rebuild it will be set to 'Enabled'.
Workaround: After the full rebuild, if required reset the value back to the desired value.
CSCdw44810
Headline: event log for runrev initiated from remote node says loadrev
Symptom: Event log indicates "loadrev (new-revision) initiated from node (remote node)" when the remote node really did a runrev
Conditions: This will occur whenever a node invokes a runrev for another node by doing: runrev (newrev) * or runrev (newrev) (remote node)
Workaround: None.
CSCdw47805
Headline: Possible NTM SR trunk with mismatch tx ts queue depth after upgrade
Symptom: The NTM subrate trunk transmission timestamp queue depth is different at the two ends.
Conditions: 1. With one side of the trunk is up only (the other end down), upgrade from pre-9331 images the node to post-9331 images on both side. Up the other side of the trunk.
Workaround: 1. down the upped trunk after upgrade 2. or use cnftrkparm to change the transmission timestamp queue to be the same size as the other end after upgrade.
CSCdw60790
Headline: addcon fails to add abrfst conn with PCR < 50 for BXM OC12 port card
Symptom: Addcon fails to add abrfst connection with PCR < 50 on OC12 card.
Conditions: Add abrfst connection with PCR < 50. The port card is bxm OC12.
Workaround: When adding the connection, disable 'Default Ext Parms [Enable]:'. Add the connection to a rate >= 50. Use cnfcon to change it to a lower value.
CSCdw64896
Headline: disabling routing state machine does not reduce high CPU usage
Symptom: When a node has a lot of unroutable derouted connections in a node that has more than 12K cons, the CPU usage is very high (close to 90%). When the routing state machine is turned off, the CPU load does not go down for a long time.
Conditions: A node with a lot of unroutable failed connections which have several hops between the master and slave.
Workaround: Down the unroutable connections to bring down CPU load.
CSCdw68880
Headline: Some BXM statistics are not being polled for -- always zero value
Symptom: The interval statistics listed below always return a value of zero:
59 Good Pdu's Received by the Sar
60 Good Pdu's Transmitted by the Sar
61 Rx pdu's discarded by the Sar
62 Tx pdu's discarded by the Sar
63 Ivld crc32 pdu
64 Invalid Length pdu rx by the sar
65 Shrt-Lgth Fail detected by the sar
66 Lng-Lgth Fail detected by the sar
Conditions: Always occurs.
Workaround: None
CSCdw78948
Headline: sw error 105 after node rebuild
Symptom: When performing a hitless rebuild on an IGX node using the command: resetcd <slot> R the UFM card may log a OB error. There could be a software error 105 logged along with the card error.
Conditions: This only occurs if the UFM has ports configured for NNI operation. Note: this is a timing sensitive problem and therefore may not occur on each hitless rebuild. The problem is more likely to occur if the node has more than 400 terminated or via connections.
Workaround: None
CSCdw85810
Headline: upport,cnfport does not enforce port group speed limitation on UFMU card
Symptom: The following port group rules are enforced by SWSW cnfport, upport on UFMU card: 1. Two ports per port group: The sum of port speed should not exceed 8 Mbps. 2. Four ports per port group: The sum of port speed should not exceed 8 Mbps. The UFMU port could be configured but there may be traffic drop and the port may not be up to that speed.
Conditions: cnfport on UFMU card.
Workaround: When doing the cnfport, manually check whether it conforms the port group rules or not.
CSCdw86892
Headline: event log for switchyred errors does not cover all possible errors
Symptom: When a switchyred fails the event log may occasionally log an event of: switchyred error: BXM <prislot>/<secslot> ? where instead of displaying the error code, or the textual reason, it instead shows ?
Conditions: This occurs rarely, when the switchyred command encounters an error that the event log does not know how to map to text. The customer is given an appropriate message at the user interface, but it is not presented in the event log.
Workaround: None
CSCdx22448
Headline: VSI protocol down if delete and re-add mpls VSI controller quickly
Symptom: VSI protocol will be down if delete and re-add mpls VSI controller (c7200/URM) quickly on IGX
Conditions: delete and re-add MPLS VSI controller on IGX before the VSI protocol time out.
Workaround: there are two workarounds: 1. delete the VSI controller and wait the VSI interface on router is down and then add the VSI controller back. 2. on the router, shut then "no shut" any one of the XtagATM interface which is controlled by the VSI controller.
CSCdx23232
Headline: con_verify on BPX for conns logs swerr 1417
Symptom: con_verify on BPX for connections resulted in swerror 1417
Conditions: One end of the connection should be on a node running 9.2.36 and the other end on a node running an upgraded firmware.
Workaround: None
CSCdx27113
Headline: Sometimes Seconds in Service reported 3601 seconds for one hour
Symptom: Customer experienced 'Seconds in Service' for the frame relay connections sometimes reports more than 100% in service, for example, the value of 'Seconds in Service' for one hour shows 3601 seconds.
Conditions: Customers can never find the mibs in the above expected location. Moreover, the oid translator never works for the Stratacom mibs.
Workaround: Call the TAC to find out where the mibs are.
CSCdx33468
Symptom: dspcons shows all connections but dspcon shows "connection does not exit"
Conditions: The network has the following software configuration: SWSW is 9.3.10 BXM FW is MFR.
Workaround: None.
CSCdx34134
Headline: testdelay times out every now and then
Symptom: testdelay from CMGUI/ConnProxy fails every now and then while it passes everytime from CLI
Conditions: None
Workaround: None
CSCdx34855
Headline: dsptech displays a false vc db inconsistency warning
Symptom: Upon login, or invocation of the dsptech command, the display for the VC field is bold and has an asterisk next to it, indicating there is a VC inconsistency -- even when there really is not an inconsistency.
Conditions:
1. There are a large number of connections on the node, 14,000 or more.
2. The user logs in and sees the dsptech login screen or they manual invoke the dsptech CLI command, while connections are still being added.
Workaround: Wait until connection additions have stopped, and then invoke the dsptech command.
CSCdx34887
Headline: Incorrect status reported for failed connections due to open space calculations.
Symptom: Connections failed to route but the dspcon command displays their status as "OK" and the "Path:" as 'looking for a route'. The dspalms command does not show the correct number of failed connections.
Conditions: The open space calculation incorrectly checks the path as OK to route the connection, but the path is actually NOT OK due to lack of resources such as load and conid.
Workaround: The dsprrgrps command can be used to get the accurate number of connections requesting reroute (failed connections).
CSCdx34916
Headline: Routing open space calculation incorrectly checks the max. VPC limit
Symptom: Connections are not routed but dspcon command displays the status as "OK" and "Path" as "looking for a route". The dnib and dspload commands show inconsistent Conid usage.
Conditions: Vpc resource on a trunk is almost used up and only one VPC conid is left. The connection fails on this trunk because the lack of VPC conid.
Workaround: Make VPC conid resource available to route the failed connection by either adding new trunks or free up some VPC conid resource on the trunk with the problem.
CSCdx37714
Headline: After Runrev IGX hangs when performing Ungraceful upgrade.
Symptom: When performing runrev on an IGX node with only one Processor (Ungraceful Upgrade), the node can hang in boot mode until a terminal is connected to the control port. Once a terminal is connected the screen will display "Transition to online in progress" and will recover with the new SWSW rev. In the node log you will often see the NPM has restarted due to either a watchdog or software abort, as opposed to Restarting due to Primary revision change.
Conditions: Single NPM node with no connectivity via control port either by local or terminal server. Nodes can be heavily loaded or have no configuration on them other than name/num/date an so forth.
Workaround:
1. The first workaround is already known and that is to have a terminal connected via the control port. (Not suitable in your scenario). This is the reason the problem has not been reported/documented before as discussions with other engineers and on our internal forums show that there are no examples of Single Processor IGX's having no connectivity via the control port. The Cisco Labs all have the Control Ports connected to a Terminal Server and customer examples of single node upgrades have had engineers onsite.
2. You can also recover the nodes remotely by using an Engineering command called "setimage". This command sets the SWSW level for use in code patches. If you set the required upgrade SWSW level and issue the runrev command the node will again remain in boot mode. However, you can connect via the Ethernet port and perform the Setrev command to force the node to rebuild with the correct revision.
3. If you connect the AUX port to the Control port using two standard 25-pin D types and a terminal cable, you can make the node rebuild correctly with the new SWSW revision. If you wire the control port to the below specification you ensure the node rebuilds and comes back online with the new rev. Testing has shown that inserting wires into the below pinout either before a runrev or after when the node is in boot will have the same effect.
4. A further method of ensuring that the nodes recover after a SWSW upgrade is to have a redundant NPM card. No nodes failed when the node was configured in a redundant mode. In testing the same two card types were used in a single node and performed upgrades through 9.2.33, 9.2.38, 9.3.24, and 9.3.36 without problems.
5. The best option found so far to get around this problem is to disable DTR in the cnfterm for the control port. This has also been found to recover the node after the runrev has been issue.
CSCdx39692
Headline: swerror 1012 on doing dspchuse on a UXM card
Symptom: swerror 1012 is logged on UXM cards
Conditions: Execute "dspchuse" command on a UXM card
Workaround: None
CSCdx48018
Headline: swerror 502 and 504 on a bpx node in upgrades network
Symptom: sw errors 502 and 504 get logged
Conditions: None
Workaround: None
CSCdx48315
Headline: time zone not specified in event, error or abort logs
Symptom: The event log, error log and abort logs do not specify the time zone for when the event, error or abort occurred.
Conditions: This always occurs.
Workaround: None.
Further Problem Description: This can make debugging of a customer network a little more difficult if time zone changes have been made because support cannot easily or concretely determine when an action occurred.
CSCdx48581
Headline: Traffic leaking on IGX trunks upon remote loopback with UXM Y-RED
Symptom: Traffic leaking on IGX trunks upon remote loopback with UXM Y-RED
Conditions: Add trunk remote loop back with UXM Y-RED
Workaround: None
CSCdx48623
Headline: 9084/BC06 when local loop back added to a trunk on a Y-RED UXM
Symptom: A software error 9084 is logged on an UXM with Y-RED configuration when add local trunk loopback on UXM
Conditions: This occurs when addlnloclp is executed on a UXM trunk on a y-red card set.
Workaround: None
CSCdx51883
Headline: Configuring pass sync on virtual trunk doesnt change Pass Sync on all ports
Symptom: Configuring Pass Sync on a virtual trunk doesn't change the parameter on all the virtual trunks sharing that physical interface.
Conditions: Changing the parameter on a lower numbered virtual trunk doesn't affect the higher numbered virtual trunks where as the warning message displays that the parameter will be changed on all the virtual trunks on that port.
Workaround: change on highest numbered virtual trunk on a port.
CSCdx59734
Headline: SLT: swerr 524 is logged on BPX
Symptom: swerror 524 is logged
Conditions: Node has SW Error 524
Workaround: None
CSCdx65552
Headline: Wrong alarm reporting when APS 1:1 configured on BXM
Symptom: Remote SIGNAL FAIL alarm reported as the current APS alarm state.
Conditions: Happens when APS 1:1 is configured and then trunks are upped. One end is seen to report this alarm.
Workaround: None
CSCdx68364
Headline: 1m3 abort logged on IGX
Symptom: 1M3 abort logged on IGX
Conditions: Run over night jobs such as resetcd, switchcc on IGX. This happened on version 9.3.4R of the SWSW. There was a sw error 504(FREE_ERR) logged few minutes before the abort.
Workaround: unknown
CSCdx69339
Headline: 103 logged on IGX when run overnight jobs
Symptom: swerr 103 logged on UXM when running overnight jobs
Conditions: Run overnight jobs such as switchcc, resetcd on IGX nodes
Workaround: Unknown
CSCdx69703
Headline: 9000 logged on UVM
Symptom: SwError 9000 is logged on UVM cards
Conditions: run overnight jobs such as resetcd on IGX nodes
Workaround: unknown
CSCdx69838
Headline: 3M abort message logged on BPX, then BPX to degraded mode
Symptom: 3000000 abort message logged on BPX cause switchcc
Conditions: This particular 3000000 abort occurs because of a card failure that is causing the card to continually log software error 105's. This then causes the messages to be queued up which, if there isn't sufficient memory available will cause the node to run out of memory and then do a 3000000 abort. For the case where this was observed, the node had 15,947 connection -- a very heavily populated node.
Workaround: Periodically the slot that is continually logging the software error 105 that is causing the memory accumulation -- this will clear the queued messages for that slot. Or, remove the card all together.
Further Problem Description: This memory fault is occurring because a BXM was continually encountering buffer full errors for more than 15 continuous hours. 105's are typically caused by faulty FW, and are not expected to occur regularly in the field, and if so, certainly not at the level as encountered by this defect.
CSCdx72680
Headline: 331 fills log on NG upgrade to 934T when on/off (Neighbor Update Errs) enabled
Symptom: swerr 331 fills the log on a BPX node
Conditions: This occurred when a few nodes in the network underwent a non-graceful upgrade to throttle branch, which causes connection reroutes and the on/off flag for "Neighbor Update Errs" was changed from its default of off to on. Turning this flag on causes false 331's to be logged.
Workaround: Use the off command to disable the "Neighbor Update Errs" debug option when routing activity occurs in the network.
CSCdx78034
Headline: 542 CRC error and 1m2 abort logged when upgrade to 9.3.40 on BPX
Symptom: 542 CRC error and 1m2 abort logged when upgrade to 9.3.40 on BPX. Also active BCC report "Flash EEPROM Program Failure"
Conditions: Upgrade sw to 9.3.40
Workaround: These software errors indicate that there is a problem with the memory on the BCC. For such problem user has to replace the card and keep it under observation.
CSCdx84899
Headline: Software Errors 105/100 appeared with SES 1.1.75.103 attached
Symptom: Software errors 100/105 appeared on the BPX with SES version 1.1.75.103.
Conditions: Software error with the following software version configuration: SWSW 9.3.36 SES version 1.1.75.103 BXM FW MFR
Workaround: None
CSCdx85868
Headline: delallsvcrsrc cause APS errors to be sent to CWM
Symptom: After upgrading to 9.3.36 the customer had to issue the command delallsvcrsrc. When this was issued they saw messages for APS being generated in the CWM logs.
1022207183 62 Thu May 23 22:26:23 2002 node1 - Port Id 9.10, state clear on n ode node1 in network XYZ is modified.; .1.3.6.1.4.1.351.1.0.20067 0
1022207183 62 Thu May 23 22:26:23 2002 node1 - Port Id 9.11, state clear on n ode node1 in network XYZ is modified.; .1.3.6.1.4.1.351.1.0.20067 0
1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 11.5, Working line: 11.5, Protection line: 12.5.; .1.3.6.1.4.1.351.1.0.20101 0
1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node node1 Line 3.2, Working line: 3.2, Protection line: 4.2.; .1.3.6.1.4.1.351.1.0.20101 0
1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 11.1, Working line: 11.1, Protection line: 12.1.; .1.3.6.1.4.1.351.1.0.20101 0
1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 11.2, Working line: 11.2, Protection line: 12.2.; .1.3.6.1.4.1.351.1.0.20101 0
1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 3.1, Working line: 3.1, Protection line: 4.1.; .1.3.6.1.4.1.351.1.0.20101 0
Conditions: The BPX was running 9.3.36 and the effecting command was delallsvcrsrc command.
Workaround: None
CSCdx92352
Headline: Changing peak for already enabled TFTP stats does not work
Symptom: TFTP interval statistics peak values are smaller or larger than expected.
Conditions: This problem occurs when a user attempts to change the peak interval for statistics that already have peaks enabled, while leaving the file and bucket interval unchanged. For example, if they started with a TFTP interval stat with a 5 minute bucket, a 60 minute file and a peak interval of say 60 seconds. And they then left all of the other values the same, but changed the peak interval to say 120 seconds, then the operation would "succeed", the high level displays would say that the peak interval is 120 seconds, but the individual statistics would still be doing 60 second peaks.
Workaround: When changing the peak interval, first delete all of the stats then change the peak interval and send the new enable request.
CSCdx93228
Headline: Error message 2004 on the switch
Symptom: Tool gets snmp error message 2004 from the IGX's snmp agent.
Conditions: With SWSW 9.1.12.
Workaround: None.
CSCdy35192
Headline: Minor alarm doesnt clear on CWM GUI BPX icon unless you log into the node
Symptom: Minor alarm doesn't clear on CWM GUI BPX icon unless you log into node
Conditions: an alarm is generated when a card gets pulled from the BPX CWM Topology then shows an alarm on the desktop
Workaround: The only way to clear was to log into the node the CWM topology then shows the BPX no longer in alarm
CSCdy54959
Headline: SW Error 551 clears only on reseating of the BCC card
Symptom: Software Error 551 is logged and the BCC aborts. On reseating the BCC the problem gets resolved.
Conditions: Customer is running 9.3.36
Workaround: Reseating the BCC. Instead of re-seating the BCC following workaround also can be used, - After the error occur and switchover happen. Login to the standby card (which experienced 551) and execute the command 'clrallcnf'. User has to be extra cautious to do this, as it clears the configuration on the card, this has to be done only in the standby card.
Further Problem Description: Software error 551 occur when CRC error is observed in the code space. The recommended solution for this is to replace the card. But sometimes re-seating the card may help since the code is reloaded after the re-seat; doing a 'clearallcnf' also re-loads the code. But it has to be noted that if it is a real hardware issue re-loading the code is not going to help, the card has to be replaced.
CSCdy68473
Headline: Prompt for adding or deleting all loopbacks on IMA is misleading
Symptom: 1. The prompt for adding a local loop back using [addlnloclp] on the primary link of an IMA interface is not clear. It says: "Warning - Loopback all IMA links Continue?" When the user answers no, then only the primary is looped back. However, this is confusing, because answering no to the [addlnlocrmtlp] which can only be done as all or none, will instead cancel the command. 2. Canceling the [addlnloclp] command, by entering the <DEL> or "." at the prompt, does not cancel the command, it instead adds a loopback to the primary link. 3. The prompt for deleting a local loop back using [dellnlp] on the primary link of an IMA interface is not clear, for the same reasons as (1) above. Moreover, this command is used to remove BOTH local and local-remote loopbacks. 4. Canceling the [dellnlp] command at the "all prompt" by entering <DEL> or "." for a local loop back does not cancel the command, it deletes the primary's loopback. 5. The dellnlp command will prompt to delete all local loop backs from an IMA interface when the primary link is specified, even if it cannot be done, a delete all will only work if all are looped back.
Conditions: This problem occurs on IGX IMA interfaces when invoking the [addlnloclp] command or the [dellnlp] on local loopbacks, as explained in the symptom section.
Workaround: None.
CSCdy79353
Headline: Spare bandwidth not fairly allocated between AutoRoute and MPLS traffic
Symptom: Spare bandwidth is not fairly allocated between AutoRoute and MPLS traffic. MPLS traffic will have access to all of the spare bandwidth limiting AutoRoute traffic to its static load.
Conditions: AutoRoute with MPLS overlay
Workaround: Customer installed MPLS only trunks
Further Problem Description: PER 7127 has been raised
CSCdy81298
Headline: Switch does not send ELMI updates to router after changing Dnld type
Symptom: IGX 8410 switch may not send ELMI updates to connected router.
Conditions: It is seen on IGX 8410 running 9.3.36 software version.
Workaround: None
CSCdy89690
Headline: Feeder status changes not logged on BPX hub when BXM runs the protocol
Symptom: BPX does not log feeder alarm change events when the LMI protocol runs on the BXM.
Conditions: The problem only happen when BXM runs the LMI protocol.
Workaround: None.
CSCdy89732
Headline: Software log on standby NPM sometimes cleared after an abort
Symptom:
1. NPM switch over to standby NPM.
2. Event log shows restart reason is a Watchdog Timeout.
3. Abort profile on the standby NPM (dspprf a s t) shows a date and time matching the date and time of the Watchdog Timeout event.
4. The standby error log (abort log in 9.3) is empty.
Conditions: IGX with an abort on the active NPM switches over to the standby NPM.
Workaround: Use the "dmstby" to collect the software log from BRAM on the standby NPM. The software log is from address 0x1010 to 0x19C0.
CSCdz00821
Headline: delshelf is allowed to proceed while there are VSI connections on feeder trk
Symptom: delshelf is allowed to proceed when there are active VSI partitions and VSI connections on the feeder trunk.
Conditions: The problem only happens when there are only VSI but no auto route connections on the feeder trunks.
Workaround: None.
CSCdz02751
Headline: UNKNOWN OAM Cell Rx
Symptom: The field "OAM Cell RX:" on the "dspcon" command shows "UNKNOWN", we expected to see "Clear".
Conditions: Normal operation, no traffic affected, looks like a cosmetic issue.
Workaround: Need to delete the connection and add back.
CSCdz08271
Headline: Rx Port errors on ASI when line is upped but port is not
Symptom: Customer ups a line on an ASI card and after a variable period of time begins to see Rx Port Errors on the output of a dspsloterrs command. Once port is upped the errors immediately cease.
Conditions: None
Workaround: None
CSCdz46757
Headline: SWLOG Error 32 logged continuously
Symptom: SWLOG ERROR: 32 logged continuously
Conditions: Invalid virtual trunk number found in TRUNK_ADDR
Workaround: None
CSCdz48634
Headline: Network clocking split, no warning to user
Symptom: Network Clocking split
Conditions: In the network consisting of IGX and BPX routing nodes assignment of External, Line or Trunk clock references to IGX node may cause network clocking to be split into separate islands consisting of clusters of BPX nodes and IGX nodes
Workaround: Synchronize BPX nodes cluster to IGX nodes cluster by providing reference to one of BPX's nodes using Line, or Trunk coming out from IGX's nodes cluster or use External reference from the same source.
CSCdz53573
Headline: Add an event in node log when ELMI is activated and deactivated
Symptom: Events in the node log indicating when the Relaxed LMI feature (ELMI) enters activated and deactivated states would be useful.
Conditions: Feeder trunk with ELMI enabled, goes into comm fail and clears comm-fails.
Workaround: Look at dsplmistats screen. Set screen updates to 2 seconds.
Further Description: When the Relaxed LMI feature (ELMI) is enabled and a feeder trunk comm failure occurs the feature enters activated state. When comm fail clears feature is in deactivated state. It can also be deactivated for other reasons, such as no traffic polled on trunks, configuration change of feature, and line sampling shut off. These states can be viewed in dsplmistats while they are occurring, but a event log entry would be more reliable to monitor the states.
CSCdz87003
Headline: Test Delay Granularity not accurate
Symptom: UXM testdelay granularity
Conditions: None
Workaround: None
CSCea00485
Headline: Upgrade from 9.2.34 to 9.3.24 APS lines show on their PROT incorrectly
Symptom: Upgrading BPX network from 9.2.34 to 9.3.24 all APS configured BXM 155 DX cards showed to be on their PROT lines after the upgrade. No errors were recorded in either the node or CWM logs, and there was no indication of any switch taking place. Attempts to switch from PROT to WORK had no effect at changing the display, neither did issuing a switchcc. The only way to clear the condition was to switchapsln W-P and then switchapsln P-W using the force option. This suggests the problem is cosmetic only as no user traffic was effected when in the original state. Problem was only found during audit after network upgrade.
Conditions: None
Workaround: Workaround is to switchapsln W-P force, then switchapsln P-W force. Display should then read correctly.
CSCea04404
Headline: HEC line displays t3/636 rather than t3/690 - bandwidth limited
Symptom: UXM T3 lines configured for HEC framing do not reflect the expected bandwidth change from PLCP framing. They display as T3/636 and 96000 cps rather than T3/690 and 104268 cps. The port on such a line does show the bandwidth to be 104268 cps.
Conditions: T3 line on UXM configured to HEC framing.
Workaround: Use PLCP framing for T3 lines on the UXM.
Further Problem Description: This problem does not affect trunks or virtual trunks.
CSCea22154
Headline: upln on BXM-155 logs swerr 5105, inconsistent databases warning on dnln
Symptom:
1. swlog 5105 when upln.
2. dnln on a line gives the following message "Database inconsistency. Inform field support personnel".
3. Checking the CWM network browser shows the ports listed multiple times.
Conditions: None
Workaround: None
CSCea33846
Headline: The point of Slot7 to 7 and 8 on Cross Point is NOT tested by tstber.
Symptom: From 9.2.35, the following two points on Cross Point is NOT tested by tstber.
Active BCC -> Active BCC
Active BCC -> Standby BCC
Conditions: None
Workaround: 'tstber m' command.
Example: tstber m 7 8 0 2 1 20 n;
m:Manual
7:Primary Slot
8:Secondary Slot
0:Destination Port
2:Qbin Number
1:destination Channel
20:BFrams to send
n:Stop on errors;
The point of Slot 7 to 8 is tested by this command.
CSCea54762
Headline: AIS not reported by BPX dspcon, until dspchstats is executed
Symptom: AIS not reported by BPX via dspcon command. If dspchstats command is issued on the connection, then dspcon will show the correct AIS state.
Conditions: BPX running switch software 9.3.36. BXM firmware is MFT.
Workaround: Issue dspchstats command prior to dspcon command.
CSCea55566
Headline: dsptrkerrs reporting large amounts of COMM FAIL on trunks after switchcc
Symptom: After a switchcc on an IGX, most if not all trunks reporting large amounts of COMM FAILs using the dsptrkerrs command. The log does not indicate any COMM Breaks however.
Conditions: IGX node is running 9.2.41 SWSW under normal load and condition is reporting large amounts of COMM FAILs after a switchcc is issued. Please note the errors only seem to occur during the instant the switchcc is in progress. The errors do not continue to increment once the switch is complete.
Workaround: None
CSCea56662
Headline: addcon returns Other end QIR out of range for this end card
Symptom: When trying to add a ABRSTD connection type only using ATM classes 1 and 7 (only), the connections returns "Other end QIR out of range for this end card" message.
Conditions: "addcon" using ATM class number 1 and 7. This problem can be seen in 9.3.45 and 9.3.36
Workaround: None
CSCea56907
Headline: inter card connection between two BXMs is not programmed correctly
Symptom: Failed connections on the SES. Channel Alarms on the feeder node.
Conditions: Customer suddenly notice failed connections on the SES. Connections were also in alarm on the feeder node. Rebuilding the BPX segment of the connection fixed the issue. It seems that two BXM cards that has Y-red not communicating to each other. Inter card connection between the two BXM's are not programmed correctly. BPX is running 9.3.36 and SES has 1.1.75 code.
Workaround: Rebuilding the middle segment on the BPX fixes the issue.
Further Problem Description: This seems to be the inter card connection problem between two BXM's. BXM service modules are not communicating to each other.
CSCea58058
Headline: addcon for an SIW conn doesnt work in a job from the Frame Relay side
Symptom: When you have an addcon statement in a job for a SIW connection. The connection doesn't get added correctly if local connection is the Frame Relay side. The conn gets added as an ATFR instead of ATFX. Manually adding the conn with the same parameters on the Frame Relay side and it works.
Conditions: This is only seen when the runjob is carried out under the conditions stated in the description.
Workaround: 1. Addcon manually 2. Run the Job from the ATM side.
CSCea67768
Headline: Non dax connection information is not updated after dax connection is deleted
Symptom: Non dax connection information is not updated in database after dax connection is deleted.
Headline: Node Abort, following swerr 100, 502, 589 and 504.
Symptom: Following a swerr 100, the node ran into memory management problems with led to an abort. This was indicated by swerr 502, 589 and 504 in quick succession. The abort was 1000003. A basic debug of the errors indicate that the swerr 100 was that the message does match the command and is invalid. Error 589 has Allocated memory block with string ... 1000003 abort has Fault address of FACE
Conditions: There are no specific conditions known to be required at this time. Network running normally with average loading and no reported maintenance or outage activity.
Workaround: There appears to be a memory management error while handling the response mismatch error condition. If you can identify and avoid the mismatch error condition you can avoid the defect in handling the error condition.
CSCin09100
Headline: SWerror 55 was logged in the entire n/w of bpx/igx when fallback
Symptom: On fall back to 9.3.11 on the bpx/igx nodes SW55 was logged on all the nodes in the network.
Conditions: This occurs when the trunk of one of the igx feeder connected to a bpx goes into comm failure.
Workaround: Reset the trunk card on the igx, And the comm failure goes off.
CSCin40238
Headline: Protocol by card field does not refresh on cnftrk
Symptom: Protocol by card field on the cli command cnftrk does not refresh after executing the command.
Conditions: Whenever the user wants to configure the parameter protocol by card using the cli command cnftrk <slot.no>
Workaround: Issue some other cli command and then issue dsptrk.
CSCin42263
Headline: SWLOG 590 - Multiples
Symptom: SW Log seen on BPX
Conditions: None
Workaround: None
Anomalies Fixed in Release 9.3.47
The following table lists the anomalies that are fixed in Release 9.3.47.
Bug ID
Description
CSCdu38434
NWBrowser shows Back card revision for the absent backcards as EW by default
CSCdu43698
able to do a cnftermfunc even user level 6
CSCdw02563
swerr 9000 on node chevy in slot 30 UFM
CSCdw18589
config for pass sync yes on VT as clock source should not be allowed
CSCdw89836
tstber does not work between ASI & BXM with virtual port.
CSCdw93967
switchyred logs event during addjob
CSCdx48549
dspportstats allows feeder trunk interface but displays no data
CSCdy41099
SWERR 923 logged upon card status change of UXM IMA line cards
CSCdy50994
30 & 923 when cnftrkict/dsptrkict run on NTM slot that doesnt have a trunk up
CSCdy54483
oamlpbac support needs removing from dspcd (IGX) and dsplogcd (BPX)
CSCdy55257
SLT: SWERR 9000 logged on IGX01 when switchcc was done
CSCdy55970
Virtual Trunks can be upped with 0 Tx/Rx rate when no port BW is available
CSCdy63195
IP Relay gateway Node not initialized after clrallcnf/lanbtld
CSCdz02229
addlnlocrmtlp on an inactive UXM line yields wrong error message
CSCdz02882
CWM 10.5.10: Unable to modify the connections on the conn manager
CSCdz03828
addapsln allows to add an active protection line
CSCdz10893
Initialize idle data channels as voice channels (Missed reveup changCSCdk80460)
CSCdz19464
CBR cells 100% Oflw CLP0 Dscd at ingress
CSCdz30108
The clock stuck into the HOLDOVER state.
CSCdz38313
Killuser does not clear console - Can not access
CSCdz73261
Load balance problem on parallel trunks between two BPX nodes
CSCea04555
SWSW sending incorrect message to CWM
CSCea36542
VCI=0 on overlapping resources created via switch CLI not added in CWM database
CSCea50327
Unable to modify Slave Endpoint for a DAX conn using SNMP
CSCea50919
BPX, slotFrontCHCount snmp does not respond correctly to BXM-E
CSCea60732
failcd does not accept (self test) and (BUS) for stbybcc from ACTV cli
CSCea71630
Runjob to configure trunk failing for UXM trunks
CSCin03628
Trunks can be added when Pass Sync values at end points do not match
CSCin21585
atmEndPointIBS range is 0..24000, unable to set IBS to 0
CSCin26344
Node alarm status not send for CC alarm
CSCin32081
Enum missing for STS-12c sonetIfFrame in strata.mib
CSCin32713
failcd (SAR) and (UP) for STBY BCC need to be blocked from ACTV Cli
CSCin32729
swerr 4208 (BAD_CA_TYPE) after cnfpref
CSCin33657
SNMP GET stat polling does not return real-time stats
CSCin35235
addapsln causes swerr 25
CSCin36346
swerr 419 on removing a node with voice conns from the network
CSCin36369
swerr 534 on BPX node when dspconcnts t is done
CSCin40514
atmEndptDesc not handled correctly when modifying atm connection
CSCin43274
dncon/upcon with COS option should be accessed from SUPERGRP or higher levels
CSCin43311
If the connection type changed in cnfatmcls then previous connection type defaults are loaded
Anomaly Status Changes in Release 9.3.47
The following table lists anomalies that have changed status since in Release 9.3.47. Changed status means that the anomaly went from open to a state other than resolved. The status field states whether the anomaly is closed, junked, duplicated, or unreproducible.
Bug ID
Status
CSCdw01813
LSNT: power down/up 42 real nodes out of 220 nodes, 419 seen; Duplicated
CSCdw40470
tstpingip result display incorrect for multiple users; Duplicated
CSCdx78070
swerr 5050 with cba_verify; Resolved in UXM AC
CSCdx87582
IMA link not removed from group during statistical errors alarm condition; Closed
Anomalies Fixed in Release 9.3.45
The following table lists the anomalies that are fixed in Release 9.3.45.
Bug ID
Description
CSCdy54662
Heavily loaded node reports cell bus errors and UXM card removals.
CSCdy62028
PXM (feeder) node update status to IGX causes frame bit errors.
Anomaly Status Changes in Release 9.3.45
The following table lists anomalies that have changed status since in Release 9.3.45 as of 12/12/02. Changed status means that the anomaly went from open to a state other than resolved. The status field states whether the anomaly is closed, junked, duplicated, or unreproducible.
Connection requires 11 hops to route fail to report as failure & CPU idle low
CSCdw64831
Heading for VT Oversubscribe feature appears for physical trunks in dsptrkutl CLI
CSCdw66301
swlog error 50 observed
CSCdw68727
Abort 1000003 logged on BPX after executing dsptrkutl following rebuild
CSCdw68912
dcct LCN information overwritten for DAX connections
CSCdw71520
help for ip commands causes last line overflow for nwipcache entry
CSCdw71912
dsptrkutl shows non-existent connections
CSCdw74281
addlnlocrmtlp on IGX/AF side of trunk causes comm-fail should be Clear-OK
CSCdw75500
swerr 5050 generated upon cba_verify after deleting vp-tunneling daxcon
CSCdw75730
cnfasm change to temp threshold doesnt reflect in dsppwr screen
CSCdw79108
BPX node with SWSW 9.1.24 does not sync up with CWM
CSCdw80264
10 hop cons fail to route when resources available
CSCdw84340
dsputl command does not work for UVM/CVM connections
CSCdw86061
rs_get_vpivci() does not correctly check for LMI/ILMI VCI
CSCdw86065
CNFRSRC will not allow VPI over 255 although port NNI
CSCdw88571
Incorrect feeder trunk channel programming for dax-cons
CSCdw92030
Port speeds above 6144 Kbps on UFMU-HSSI are reported incorrectly to CWM
CSCdw94435
dclk output doesnt get updated
CSCdw95202
SNMP support for Trunk VC Shaping and cnftrkq enhancement for feeders
CSCdx06654
line/trk recovered even the active APS line has LOS
CSCdx07451
AutoRoute channels allocated beyond 32768 when VSI Slave channels used on card
CSCdx08325
Unable to add connection from FR end point to ATM feeder end point
CSCdx08838
IGX reports PRI Loss (CLOCK) when deleting line clock source
CSCdx10239
Memory leak in dsptech (swerr 501, 3000000)
CSCdx10874
Enabling LMI on VSI feeder causes unreachable (always) + comm-fail(9340)
CSCdx16103
Trunk channel programming rejected(9082) when connection has PCR > port rate
CSCdx17275
UXM line looped back after sw upgrade
CSCdx17933
Dangling VLCONs and inconsistent trunk loading/conid
CSCdx18387
dsplns/dspports alarm masking reverse video is not captured on ASCII screen
CSCdx19254
swerror 521 on bpx node in upgrades network
CSCdx20304
addfrcons and dspfrchan no longer exist
CSCdx20323
752 logged when FW upgraded
CSCdx27972
RAS: Incorrect Open space calculation when inconsistent conids exist
CSCdx29500
BPX clock does not go to Tracking mode if current clock source is on port 1
CSCdx36217
connection continuously re-routes after active CC fails with swerr 47
CSCdx38407
dspviacons causes session to lockup, IDLE time of 0 and eventually 1m3 abort
CSCdx47173
Incorrect display of IGX FDR NPMs after an upgd
CSCdx57483
Removed ASM card on a BPX cage displayed as Empty Reserved for BCC
CSCdx57872
FRM port alarms are *disabled* by default on upgrade
CSCdx58152
addlnloclp/addlnlocrmtlp does not work when secondary UXM-IMA-YRED active
CSCdx63511
Download Aborted logged and UXM to failed status when burnfwrev to A
CSCin10198
CSCdu85702 fix missing from BPX
Anomaly Status Changes from Previous Releases
The following table lists the anomalies that have changed status prior to Release 9.3.42 as of 12/12/02. Changed status means that the anomaly went from open to a state other than resolved. The status field states whether the anomaly is closed, junked, duplicated, or unreproducible.
Bug ID
Status
CSCdr43758
Unreproducible
CSCdv38347
Duplicate of CSCdx88946
CSCdv84853
Junked
CSCdv89240
Closed
CSCdw00459
Closed
CSCdw01957
Unreproducible
CSCdw15697
Duplicate of CSCdu46642
CSCdw21820
Closed
CSCdw35336
Duplicate of CSCdx17933
CSCdw50328
Duplicate of CSCdu00161
CSCdw52771
Duplicate of CSCdx90569
CSCdw58175
Closed
CSCdw66534
Unreproducible
CSCdw68758
Duplicate of CSCin12498
CSCdw94163
Unreproducible
CSCdx11280
Unreproducible
CSCdx48633
Duplicate of CSCdx58152
CSCdx55926
Unreproducible
CSCdx66732
Duplicate of CSCdx66901
CSCdx67460
Duplicate of CSCdx54453
CSCin10654
Junked
Additional Deliverables
SNMP MIB
The SNMP IGX/BPX switch SNMP MIB is being provided with the delivery of Release 9.3 Switch Software. The MIB is in standard ASN.1 format and is located in the ASCII text files agent.m, ilmi.m, ilmi_ctl.m, ilmiaddr.m, switch.m, swtraps.m, and errors.m which are included in the same directory as the Switch Software images. These files may be compiled with most standards-based MIB compilers. There were no MIB changes in Releases 9.3.11, 9.3.20, 9.3.24, and 9.3.36.
Switch MIB changes of Release 9.3.35
voiceEndptState
New object
winkUndetermined(6)
Switch MIB changes of Release 9.3.30
The following Switch MIB changes have been introduced since Release 9.3.30. The changes include modified objects and new objects.
atmEndptTable
Modified objects
atmEndptEntry
atmEndptTestType
New objects
atmEndPtOAMTestLpCnt
atmEndptOAMTestAbrtFlg
atmEndptOAMTestSccCnt
atmEndptOAMTestRTDMin
atmEndptOAMTestRTDAvg
atmEndptOAMTestRTDMax
atmEndptOAMTestOamFmt
sonetIfTable
Modified objects
sonetIfFrame
atmTrunks
Modified
atmTrkVcShaping
ShelfRtrSlotInfoTable
New objects
shelfRtrSlotInfoEntry
rtrState
rtrIOSAlmStatus
rtrIOSSwImage
rtrVICType
rtrCnfFilename
rtrCnfFilesize
rtrIOSCnf
rtrSerialPort
Switch MIB changes of Release 9.3.11, 9.3.20 and 9.3.24
No MIB changes are contained in these releases.
Switch MIB changes of Release 9.3.10
The following Switch MIB changes have been introduced since Release 9.3.10. The changes include obsolete objects, modified objects, and new objects:
switchIfTable
Modified objects
switchIfPartiId
switchIfScTmpltId
frLportCnfTable
Modified objects
frLportCnfEntry
New objects
frLportNeighborDiscovery
frLportNeighborIpAddress
frLportNeighborIfIndex
atmPortTable
Modified objects
atmPortEntry
atmPortType
New objects
atmPortNeighborDiscovery
atmPortNeighborIpAddress
atmPortNeighborIfNam
atmPortStatTable
Modified objects
atmPortStatEntry
New objects
atmPortStatTxQ0CellDrps
atmPortStatTxQ1CellDrps
atmPortStatTxQ2CellDrps
atmPortStatTxQ3CellDrps
atmPortStatTxQ7CellDrps
atmPortStatTxQ8CellDrps
atmPortStatTxQ9CellDrps
atmPortStatTxQ10CellDrps
atmPortStatTxQ11CellDrps
atmPortStatTxQ12CellDrps
atmPortStatTxQ13CellDrps
atmPortStatTxQ14CellDrps
atmPortStatTxQ15CellDrps
atmEndptTable
Modified objects
atmEndptQIR
atmEndptOeQIR
atmEndptRateUpICA
atmEndptPCR
atmEndptOePCR
atmEndptSCR
atmEndptOeSCR
atmEndptMCR
atmEndptOeMCR
atmTrunkStatsTable
Modified objects
atmTrkStatsEntry
New objects
atmTrkStatsTxQ10CellDrps
atmTrkStatsTxQ11CellDrps
atmTrkStatsTxQ12CellDrps
atmTrkStatsTxQ13CellDrps
atmTrkStatsTxQ14CellDrps
atmTrkStatsTxQ15CellDrps
rsrcPartiTable
Modified objects
rsrcPartiId
rsrcPartiPvcMaxBw
rsrcPartiVsiVpiStart
rsrcPartiVsiVpiEnd
rsrcPartiVsiMinBw
rsrcPartiVsiIlmiEnable
rsrcPartiVsiLcnReprogPermit
rsrcPartiPvcTable
Modified objects
rsrcPartiPvcPvcMaxLcns
rsrcPartiPvcPvcMaxBw
rsrcPartiPvcVpiStart1
rsrcPartiPvcVpiEnd1
rsrcPartiPvcVpiStart2
rsrcPartiPvcVpiEnd2
rsrcPartiPvcVpiStart3
rsrcPartiPvcVpiEnd3
rsrcPartiPvcVpiStart4
rsrcPartiPvcVpiEnd4
atmQbinTable
Modified objects
atmQbinMinBw
atmQbinTmpltCnfg
vsiCtrlrTable
Modified objects
VsiCtrlrEntry
vsiCtrlrPartiId
vsiCtrlrSlot
vsiCtrlrPort
New objects
vsiCtrlrAdminStatus
vsiCtrlrVpi
vsiCtrlrVciStart
Switch MIB Changes to Release 9.3.05
The following Switch MIBs have been introduced since Release 9.3.05.
atmPortTable
New objects
atmPortIlmiResetFlag
atmPortCACReserve
atmPortLportMaxBW
atmPortLportMinVpi
atmPortLportMaxVpi
atmPortMgmtProtoOnCard
Modified objects
atmPortEntry
atmPortMgmtProto
atmPortIlmiAddrReg
atmPortVcShaping
atmPortQueueTable
New objects
atmPortQueueVcShaping
Modified objects
atmPortQueueEntry
atmPortQueueDepth
atmEndptTable
Modified objects
atmEndptVcQSize
switchShelf configuration branch
New objects
shelfCnfgNodeVcSupport
shelfCnfgNodeVcTotal
atmTrunks table
New objects
atmTrkTermUsedPvc
atmTrkViaUsedPvc
atmTrkMgmtProtoOnCard
Modified objects
atmTrkEntry
rsrcPartiTable
New objects
rsrcPartiVsiLcnReprogPermit
Modified objects
rsrcPartiEntry
Obsolete objects
rsrcPartiPvcMaxLcns
rsrcPartiPvcMaxBw
This object limits the number of LCNs to be reprogrammed in a continuous loop so that other software processes get a fair share of the CPU time.
rsrcPartiMaxLcnBatchNumber
rsrcPartiPvcTable
This table is only available for BXM cards. The AutoRoute resource partition does not exist for a down line.
New objects
rsrcPartiPvcEntry
rsrcPartiPvcPvcMaxLcns
rsrcPartiPvcPvcMaxBw
rsrcPartiPvcVpiStart1
rsrcPartiPvcVpiEnd1
rsrcPartiPvcVpiStart2
rsrcPartiPvcVpiEnd2
rsrcPartiPvcVpiStart3
rsrcPartiPvcVpiEnd3
rsrcPartiPvcVpiStart4
rsrcPartiPvcVpiEnd4
serialPortTable
Modified objects
serialPortLeadState
Switch MIB changes to Release 9.3
The following Switch MIB changes have been introduced since Release 9.2.31. The changes include obsolete objects, modified objects, and new objects:
switchIfTable
This table contains a list of ports and sub-ports and their interfaces.
Modified objects
switchIfService
switchIfPhysPort
switchIfScTmpltId
atmPortTable
This table provides the manager a detailed view of the ATM ports available on the switch.
New objects
These new MIB variables support IMA Ports.
atmPortRetainedLinks
atmPortImaProtocolOption
atmPortImaDiffDelay
atmPortImaClockMode
Modified objects
atmPortEntry
Obsolete objects
atmPortSvcChannels
atmPortSvcLcnLow
atmPortSvcLcnHigh
atmPortSvcVpiLow
atmPortSvcVpiHigh
atmPortSvcVciLow
atmPortSvcVciHigh
atmPortSvcQbinBitMap
atmPortSvcQbinSz
atmPortSvcBw
atmPortSvcInUse
atmPortPvcInUse
atmEndptTable
This table is used to model a PVC endpoint and contains the traffic parameters for the ATM endpoint.
Modified objects
atmEndptPolicing
shelfSlotInfoTable
This table provides switch slot information.
New objects
slotCardTopAssemNumber
Modified objects
shelfSlotInfoEntry
slotCardMinBusUBU
ds3LineTable
This table provides the manager a view of the DS3 interfaces on the switch and supports SET functions.
Modified objects
ds3LineAlmType
ds3LineStatsTable
ds3StatsTable
This table provides a list of DS3 line statistics objects.
New objects
ds3StatsUas
Modified objects
ds3LineStatsEntry
sonetStatsTable
This table provides a list of SONET line statistics objects.
Modified objects
sonetStatsPthBip8s
sonetStatsPthFebeEs
sonetStatsSecBip8Ses
sonetStatsPthUas
sonetStatsPthFarendUas
atmTrunkStatsTable
This table provides a list of ATM trunk statistics objects.
Obsolete objects
atmTrkSvcChannels
atmTrkSvcLcnLow
atmTrkSvcLcnHigh
atmTrkSvcVpiLow
atmTrkSvcVpiHigh
atmTrkSvcVciLow
atmTrkSvcVciHigh
atmTrkSvcQbinBitMap
atmTrkSvcQbinSz
atmTrkSvcBw
atmTrkSvcInUse
vsiCtrlrTable
This new table contains the configuration for VSI controllers. The objects are advertised to all of the VSI slaves on the switch when the configuration is changed.
New objects
vsiCtrlrEntry
vsiCtrlrId
vsiCtrlrPartiId
vsiCtrlrIpAddr
vsiCtrlrType
vsiCtrlrSlot
vsiCtrlrPort
Default Values
This section contains default values for the Cisco BPX and Cisco IGX nodes.
This section contains information about the BXM firmware MFX.
About the Firmware MFX
BXM firmware version MFX supports all existing interfaces and models of BXM hardware. The tables in this section outline various levels of hardware revisions supported for BXM firmware version MFX.
Front Cards
Table 12 Front Cards Supported by MFX Firmware
Model Number
Description
FW model
HW Rev
FW Rev
BXM-155-4
4 port OC3 Line Module (Front Card)
F
B
MFX
BXM-155-8
8 port OC3 Line Module (Front Card)
F
B
MFX
BXM-622
1 port OC12 Line Module (Front Card)
F
D
MFX
BXM-622-2
2 port OC12 Line Module (Front Card)
F
D
MFX
BXM-T3-8
8 port T3 Line Module (Front Card)
F
B
MFX
BXM-T3-12
12 port T3 Line Module (Front Card)
F
B
MFX
BXM-E3-8
8 port E3 Line Module (Front Card)
F
B
MFX
BXM-E3-12
12 port E3 Line Module (Front Card)
F
B
MFX
BXM-155-8DX
8 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-155-8D
8 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-155-4DX
4 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-155-4D
4 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-622-2DX
2 port OC12 Line Module (Front Card)
F
A0
MFX
BXM-622-2D
2 port OC12 Line Module (Front Card)
F
A0
MFX
BXM-622-DX
1 port OC12 Line Module (Front Card)
F
A0
MFX
BXM-T3-12EX
12 port T3 Line Module (Front Card)
F
A0
MFX
BXM-T3-12E
12 port T3 Line Module (Front Card)
F
A0
MFX
BXM-T3-8E
8 port T3 Line Module (Front Card)
F
A0
MFX
BXM-E3-12EX
12 port E3 Line Module (Front Card)
F
A0
MFX
BXM-E3-12E
12 port E3 Line Module (Front Card)
F
A0
MFX
BXM-E3-8E
8 port E3 Line Module (Front Card)
F
A0
MFX
Front Card for APS Compatibility
Table 13 Front Cards Supporting APS with MFX Firmware
Model Number
Description
FW model
HW Rev
FW Rev
BXM-155-4
4 port OC3 Line Module (Front Card)
F
C
MFX
BXM-155-8
8 port OC3 Line Module (Front Card)
F
C
MFX
BXM-622
1 port OC12 Line Module (Front Card)
F
E
MFX
BXM-622-2
2 port OC12 Line Module (Front Card)
F
E
MFX
BXM-155-8DX
8 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-155-8D
8 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-155-4DX
4 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-155-4D
4 port OC3 Line Module (Front Card)
F
A0
MFX
BXM-622-2DX
2 port OC12 Line Module (Front Card)
F
A0
MFX
BXM-622-2D
2 port OC12 Line Module (Front Card)
F
A0
MFX
BXM-622-DX
1 port OC12 Line Module (Front Card)
F
A0
MFX
Back Cards
Table 14 Back Cards Supported by MFX Firmware
Model Number
Description
HW Rev
FW Rev
MMF-155-4
4 port multi-mode fiber back card
A
na
MMF-155-8
8 port multi-mode fiber back card
A
na
SMF-155-4
4 port single-mode fiber intermediate-reach back card
A
na
SMF-155-8
8 port single-mode fiber intermediate-reach back card
A
na
SMFMR-155-4
4 port single-mode fiber long-reach back card
A
na
SMFMR-155-8
4 port single-mode fiber long-reach back card
A
na
SMF-622
1 port intermediate-reach OC12 back card
A
na
SMF-622-2
2 port intermediate-reach OC12 back card
A
na
SMFMR-622
1 port long-reach OC12 back card
A
na
SMFMR-622-2
2 port long-reach OC12 back card
A
na
XLR-622
1 port extra long-reach OC12 back card
A
na
XLR-622-2
2 port extra long-reach OC12 back card
A
na
BPX-T3/E3-12
12 port T3/E3 back card
A
na
BPX-T3/E3-8
8 port T3/E3 back card
A
na
RDNT-LR-622-2
2 port long-reach OC12 redundant back card
A
na
RDNT-SM-622-2
2 port intermediate reach OC12 redundant back cards
A
na
RDNT-SM-622
1 port intermediate reach OC12 redundant back cards
A
na
RDNT-LR-155-8
8 port long-reach OC3 redundant back cards
A
na
RDNT-SM-155-4
4 port intermediate-reach OC3 redundant back cards
A
na
RDNT-SM-155-8
8 port intermediate-reach OC3 redundant back cards
A
na
New Features supported in BXM Firmware MFX
Bug fixes only.
Special Installation/Upgrade Requirements
APS Issues
Upgrading from MEK and lower firmware to MFX when feeder trunks are utilized with APS while the BPX node does not have APS requires the following procedure:
Step 1 Change the PXM1-based MGX feeder to use APS1+1 unidirectional AND disable K1K2 processing (may need to delete and then add back APS). On the BPX temporarily configure to use unidirectional mode.
Step 2 After PXM1-based MGX dspapsln shows both lines OK, delete the APS line on the BPX.
Step 3 Proceed to upgrade the BXM cards as if YRED.
Step 4 After both cards are MFW, add back the APS on the BPX.
Step 5 Reconfigure both PXM1-based MGX and BPX to use the appropriate APS configurations.
BXM cards with MCB/MDA firmware or later can be smoothly migrated to the MFA or above version of firmware by using Y-cable redundancy.
To upgrade a BXM card pair in Y-red configuration, complete the following steps:
Step 1 Upgrade the standby card with the MFA or above firmware version. Wait for all of the configuration to be downloaded into the card.
Step 2 Do a switchyred to switch to the card with firmware MFA or above version.
Step 3 Burn the other card with the desired version MFA or above firmware. Follow the standard firmware upgrade procedure for downloading and burning the firmware into the cards.
Step 4 If BCC SWSW version is 9.1.18 and dspnovram shows 0 or 4 for Number of Channel Stats, go directly to MFC or above versions from MCC.
For APS (1+1) MEx or MFA image versions are not to be treated as compatible with MFx (minus MFA) image versions. During an upgrade procedure from MEx or MFA image to MFx (minus MFA) image, both cards must be upgraded to the MFx (minus MFA) image with minimal interval between them.
The incompatibility is due to APS intercard messages from one end not being recognized by the other end. See bug CSCdu67053 for the symptoms caused by this incompatibility.
Intra-MFx (minus MFA) and intra-MEx upgrades are compatible.
Channel Statistics Issues
While upgrading from firmware, on OC3, 1 port OC12 BXM cards, if stats level on BXM is greater than 1, use one of the following upgrade procedures listed below.
Upgrade from firmware revision MEA or higher.
Step 1 Upgrade SWSW to 9.2.30 or higher.
Step 2 Upgrade the firmware to MFW.
Upgrade from firmware revisions lower than MEA.
This procedure avoids card mismatch.
Step 1 Upgrade firmware to MEC.
Step 2 Upgrade the SWSW to 9.2.30 or higher revision.
Step 3 Upgrade the firmware to MFW.
A firmware burn must not be interrupted. A card reset in the middle of burn firmware results in the BXM being maintained in the core state (identified by blinking yellow LED) or failed state (identified by a solid red LED). In this case the dspcds screen reports the card as FAILED. This state can be recovered by reburning the firmware into the card.
Features Obsoleted
The following features have been obsoleted:
1. VSI 1.0 is obsoleted by VSI 2.2 in the MDA release onwards.
2. From versions MFJ to MFN channel statistics level 0 is no longer supported for BXM-155-4, BXM-155-8, BXM-622, BXM-622-2, BXM-T3-8, BXM-T3-12, BXM-E3-8, BXM-E3-12 models. In MFN onwards conditional support for statistics level 0 is revoked. See the Notes, Cautions, and Clarifications section point 13 for more details.
3. In all other models channel statistics level 0 is supported by all firmware versions (BXM-155-8DX, BXM-155-8D, BXM-155-4DX, BXM-155-4D, BXM-622-2DX, BXM-622-2D, BXM-622-DX, BXM-T3-12EX, BXM-T3-12E, BXM-T3-8E, BXM-E3-12EX, BXM-E3-12E, BXM-E3-8E).
Notes, Cautions, and Clarifications
1. BXM Model F firmware is intended for use with 9.3 switch software. BXM Model F firmware may be used to upgrade BXM cards during the upgrade process from SWSW Release 9.2 to 9.3. BXM Model F firmware has not been tested for compatibility with SWSW Releases 8.4, 8.5, and 9.1. It is compatible with IOS version 12.05t2 or greater for MPLS.
2. MFE is a not on CCO as it is an SES specific release.
3. Protection Switching based on BER on BXM may not comply to standards. The GR-253 and ITU-T G.783 requires that switching be completed within 60 msec from the time the error starts. BXM is unable to detect BER threshold crossing until the next poll, which occurs every 250 msec. Thus, switching time may be up to 250 msec under certain circumstances.
4. In APS 1+1 default configuration, both back card LEDs show green when primary card is active and selection is from PROT line. When primary card is active and it is selecting from PROT, PROT backcard should be green, since it is carrying traffic. WORK backcard should also be green since that is the physical path for the primary (and active) card to pass traffic. Backcard LED green means the backcard is directly or indirectly carrying traffic, and pulling the backcard causes traffic disruption (CSCdm53430).
5. In APS 1+1 default configuration and a manual W->P is on and a switchyred is issued, a manual W->P event is logged. By default, on switchyred the new active card comes up in "clear" state. But in this case since there is a manual W->P on, the APS line switches to PROT and the switching is logged (CSCdm53404).
6. In APS 1+1 default configuration if the selected line is PROT and last user request is clear and a switchyred is issued, line switches to WORK. If the last user request is "clear", full automatic APS switching is in effect with the working line being active by default. When there is no last user switch request to switch to any particular line, the working line becomes active. (CSCdm53420)
7. When APS Annex B is added to local end which has the secondary card active, the APS trunk goes into Comm Failure for few seconds and then clears. If the secondary card is active, do a switchyred to make the primary card active. Then, add APS Annex B (CSCdm46359).
8. MFK and above versions support LCN CAC for Class of Services. The controller reserves some LCNs for control VC as default. These reserved LCNs cannot be used by any Class of Service in MFT. If all the LCNs for the partition have been used in a version earlier than MFK after the MFT version is updated in the switch, some connections may not be added. These connections try to use LCNs reserved for control VC which is not allowed. Configure more LCNs for the partition to make sure enough LCNs exist for all the connections.
9. The OC-3 MultiMode Fiber backcards do not support Y-cable redundancy.
10. APS 1:1 is not supported for VSI in versions before MFE. (Bug CSCdp42996) APS 1:1 should not be configured on ports intended to be used by PNNI or MPLS as after switchover traffic flow is stalled on the protection line for releases before MFE. However, in MFE and above, this problem is fixed.
11. Total bandwidth allocated to all VSI partitions on a BXM should not be more that OC12 rate, 1412832 cps. BCC SWSW allows users to configure more than OC12 rate, in which case all the PNNI connection commit requests are NACKed by BXM.
12. In firmware versions prior to MFF signaling bandwidth for an SES controller was not guaranteed. In MFF and above the signaling Qbin feature has been added (with SWSW 9.3.10 and above and SES image 1.0.10 and above) to guarantee signaling bandwidth.
13. Statistics level 0 for legacy BXM cards was obsoleted in Model F releases until MFN. However, in version MFP and above conditional support statistics level 0 for legacy cards is revoked. Statistics level 0 is not supported if VSI configurations exist on the card.
If a card was configured with statistics level 0 with VSI enabled in a previous release of firmware (Model C or E), upgrading to MFP or above revisions causes a mismatch on legacy cards. To avoid impacting VSI operations, reconfigure the card to statistics level 1 or above before upgrading.
Note BXME (enhanced cards) support all statistics levels unconditionally with all valid
configurations, models, and releases.
14. Excessive BIP-8 error rates (10-3) which escalate into unavailable seconds (UAS) are now reported to Switch Software as red alarms. This feature is not configurable, and may cause failed connections and rerouted trunks in configurations where APS is not enabled, alternate trunk routes do not exist or on UNI ports. This feature is not active when APS is configured and enabled.
Known Anomalies in MFX
The following table lists the known anomalies for the BXM MFX firmware.
Table 15 Known Anomalies in MFX
Bug ID
Description
Apply to SES
CSCdx52484
Symptom: CBR traffic got dropped on ENNI link on BPX side where there is congestion.
Condition: resetcd of BXM can solve the problem.
Workaround: Unknown.
No
CSCdx79141
Symptom: Channel allocation inconsistency between BPX and SES.
Condition: Have only 1 part. first (Max. lcn > Min.), add conns. > min. Add more parts such that sum(Mins) >Max(max.).
Workaround: None
Yes
Anomalies Fixed in MFX
Table 16 Anomalies Fixed in MFX
Bug ID
Description
CSCdw16017
Symptom: Traffic is only seen on the ingress of the master and slave nodes.
Conditions: This problem is triggered by a network condition that causes the VPC to reroute. VPC experiencing this problem have been ABRSTD with VSVD enabled one megabits or larger VPC connections.
Workaround: Closed. Workaround is to not assign VCI to 0. Uping and downing the connection clears the problem.
CSCdw76023
Symptom: For APS 1:1 intracard configuration, "dspapsln" command keeps showing false and misleading alarm "APS missing card."
Conditions: APS 1:1 intracard setup using "R" (redundant) designated backcard.
Workaround: Do not use an "R"-designated backcard when configuring APS 1:1 intracard setup.
Use the normal backcard. It is just a false alarm. All APS functionality should still be working correctly.
CSCdw95063
Symptom: "dspapsln" doesn't show "card missing" on standby even though the standby card has been removed. "dspapsln" shows OK even though standby BXM card is removed to cause a switchover to the newly active card.
Conditions: Remove the active BXM to cause the switchover to the newly active card in an APS 1+1 configuration setup.
Workaround: Insert back the standby BXM card.
CSCdx28781
Symptom: When bit errors happen on a line, all the connections provisioned on the line fail.
Conditions: MFM onwards (There is a code change went into firmware image MFM, which puts the line into Path AIS as long as UAS-P condition persists. This change is good for trunks as alternate routes could be chosen. But on lines, especially when they are error prone, there is no choice but to keep using the line, application might slow down but at least connection does not get failed).
Workaround: Use images before MFM or replace the buggy physical cable.
CSCdx40378
Symptom: When sending F5 OAM end to end flows through a DACS SPVC, only the "egress" counters of dspconstats increment. This true for F5 end to end AIS, or F5 end to end loopback.
Conditions: This affects OAM cell counting on all SPVC connections. It occurs with firmware MFW or lower revision.
Workaround: None.
CSCdx50089
Symptom: ILMI did not update its neighbor IP address and IfName to be "N/A", when its physical link on which it was running went down. dspnebdisc would show the previous neighbor IP address and IfName in this situation.
Conditions: The physical link on which ILMI was running went down.
Workaround: Reset the card will clear the old information.
CSCdx72292
Symptom: Commit connection request is failed due to NAK from BXM, while still a lot of available bandwidth at partition level.
Conditions: Single/multiple partitions on a interface enabled.
1. The bandwidth common pool of this interface is zero.
2. At least in one partition, sum of (cos_min_bw) > part_min_bw, due to the round up when applying the policy parameters -minbw to get cos_min_bw.
Workaround: Configuring the multiple partitions gives at least 20 cells in common pool. The work around for CSCdv03058 applies to this problem.
See CSCdv03058 for detail workaround explanation.
CSCdy16927
Symptom: BXM LMI clears Abit alarms on SPVC feeder after switchcc or switchyred.
1. The connection segment in the BPX/SES network is down.
2. The corresponding segment in the SPVC feeder is in Abit alarm.
3. After a switchcc or a BXM switchyred on BPX1, the BXM LMI session at "**" tells SPVC feeder1 to clear the Abit alarm on the segment corresponding to the downed VSI connection in the BPX/SES network.
Workaround: None.
CSCdy57435
Symptom: Fatal PRFD Pending error has been seen at BXM card. (SIMBA errors excess its threshold).
Conditions: Most likely, it happens during FW/SW upgrade.
Workaround: None.
CSCdy75277
Symptom: A pnport stuck is in down state after being added and configured.
Conditions: Add and configure pnport on a freshly added trunk/port. Delete all the configuration and down all interfaces, then newly add and configure the pnport from scratch.
Workaround: Unknown.
CSCdy80205
Symptom: When physical interface in alarm (LOS), dsppnport shows the operating status as up in SES.
Conditions: When SES is running 3.0(10.0) or later, even if the physical interface is in alarm (LOS), if ILMI is enabled, with out configuring signaling type (NNI or UNI) in SES, the operating status of interface is shown as UP. This issue occurs with BXM Image MFW or prior.
Workaround: Configure signaling type in SES.
CSCdy89521
Symptom: The AAL5 Feeder attached to the BPX routing hub becomes unreachable after a delshelf command was issued on the BPX, even though there are no existing connections on either the feeder or the BPX.
Conditions: BXM runs the LMI protocol.
Workaround: None
CSCdz49797
Symptom: Doing a switchyred on BXM causes AXSM connection to go into Abit/AIS alarm.
Conditions: A switchyred on BXM card running XPVC in a mixed MGX 8220 BPX MGX1 MGX45 network can go into alarm, and then the alarm will not clear. Typically a transition outside of the PNNI network (a switchyred on the BPX in this case) can cause the ingress port to generate an AIS alarm, which it sends into the PNNI network and is received by CPE at the other end. Because the AIS is incorrect, there's never any indication to the ingress port that it should clear the alarm.
Workaround: Executing dncon/upcon on the AXSM end which is generating switch side Tx AIS (if that is the master connection) If the problem is on the slave end need to delete and re-add the connection
CSCin33357
Symptom: After burn MFW image, the BXM enhanced card went to resetting.
Conditions: BXME card with statistics level 0 and VSI connections.
Workaround: Do not use statistics level 0 for BXME card.
CSCdz60041
Symptom: BPX may not be able to recover clock from the line with PLCP framing configuration.
Conditions: BPX may experience clock recovery issues when recovering clock from the line connected to other vendor equipment.
1. 1:1 APS with Bi-Dir configured; remote is AXSM/B.
2. Manual switchaps W->PLine from AXSM/B.
3. Forced switchaps P->WLine from BXM.
Workaround: None.
CSCdx45385
Symptom: BXM did not update SES with the latest available cos level LCN when there is cnfrsrc LCN resources (LCN) change on this partition (part_min_lcn, part_max_lcn).
Conditions:
1. A PNNI partition has been configured with some connections up. dsppnportrsrc reports the correct available lcn for each cos level.
2. Do cnfrsrc on this partition, to change the min_lcn and max_lcn at partition level. The available lcn at cos level in SES dose not get updated.
Workaround: Add a con or down a con to trigger the update.
CSCdx55794
Symptom: BXM incorrectly sends back LMI version 4 to IGX AAL5 feeder, while it does not support LMI version 4.
Conditions:
1. IGX AAL5 feeder is added to a BXM feeder trunk in the BPX.
2. IGX feeder LMI is running LMI version 4, and talk to BXM LMI.
Conditions: BXM running MFU firmware. Found in lab environment but likely to also be found in a live network if these trunk parameter values are used and the trunk passes over another medium such as a TDAX or SDH backbone.
Workaround: Set cnftrkparm 9 2500/10000 which is the default for STM1. Do not use the values 2500/15000 for cnftrkparm 9. Tests have yet to show if this would effect other values but default settings have been confirmed problem free.
CSCdx59080
Symptom: Customer is performing tests of MFU firmware prior to deployment in live network and has found that when a BXM trunk is configured for loop clock yes at both ends it remains in a "Looped Back" state when the BXM is reset by command "resetcd ? h".
Conditions: BXME trunk needs to be configured for loop clock yes and the BXM card be reset. Tests showed that causing a LOS or resetting the card again would not recover the trunk.
Workaround: Issue cnftrk and change none of the parameters by stepping through them.
CSCdy01870
Symptom: SIMBA reset card errors logged due to PRFD Pending Errors
Conditions: BXM image MEE and SWSW image 9.3.00
Workaround: None.
CSCdy01951
Symptom: Unnecessary alarms are triggered when BXM sends slot errors to SWSW.
Conditions: The FW adds all slot errors before sending them to BCC. There are situations when the number of traffic related slot errors will trigger unnecessary alarms on SWSW. These alarms will be suppressed.
Workaround: None.
CSCdy05515
Symptom: Current BXM firmware only support a few statistics counters. In order to enhance customer operation and maintenance capability, a few new statistic counters have been added. The detail description about the new created statistics and associated CLI commands and MIBs can be found in the latest VSI document. See DDTS case CSCdy05597 (SES and MIBs).
Conditions: All previous FW do not support the new connection statistics.
Conditions: Delete routed SPVC. Then re-add the SPVC with same VPI/VCI values.
Workaround: Problem is fixed in MFW (MF20).
CSCdy75277
Symptom: pnport stuck in down state
Conditions: Configure PNNI trunk between SES and MGX 8850 (PXM45) using automation script PROU001.
Workaround: Unknown.
Appendix B—UXM Model C ACJ Firmware Release Notes
This section contains information about UXM Model C firmware.
Introduction
ACJ is a firmware maintenance release for UXM card on IGX. Firmware is the same for UXM and UXM-E cards.
New Features
None.
Obsolete Features
None.
Compatibility
1. Software
ACJ firmware is compatible with Switch Software Release 9.3.10 or later.
2. Hardware
ACJ firmware is compatible with all UXM and UXM-E model hardware.
Bugs Resolved in ACJ
The open bugs known at this stage are listed in the Known Anomalies section of this appendix. The firmware release ACH also contains the bug fixes done in the Model B firmware up to revision ABL.
Upgrade Instructions
If the firmware being upgraded is not revision ACB or higher, then the firmware upgrade to revision ACH requires an intermediate upgrade to revision ABJ. However, before upgrading the firmware to revision ABJ, the boot code must be upgraded to boot revision 8.
If the firmware revision ACB has not been burned, follow these steps to upgrade the firmware to revision ACH:
Step 1 Execute a graceful upgrade to Release 9.3.10 or later.
Step 2 Upgrade the UXM boot code to boot revision 9.
Step 3 Upgrade the Administration application firmware to revision ABJ or greater.
Step 4 After the card comes up, upgrade the Administration application firmware to revision ACH.
Warning If these procedures are not followed, the card might enter a state from which it can NOT be recovered. Pay attention to this section before loading the new firmware.
If the firmware revision ACB has been burned onto the card, follow these steps to upgrade the firmware to revision ACH:
Step 1 Execute a graceful upgrade to Release 9.3.10 or later.
Step 2 Upgrade the run-time UXM firmware to revision ACH.
Known Anomalies in UXM Model C ACH
The following table lists the known anomalies in UXM Model C ACH firmware.
Bug ID
Description
CSCdu50731
Symptom: When one of the physical lines within IMA goes down and comes backup remote side of IMA goes out of Sync. The UXM trunks may experience CGW discards due to corrupted Frames passing over unbalanced IMA trunk.
Conditions: This problem is identified and resolved in ABR Release under UXM Model B firmware.
Workaround: Resetting the UXM card will restore the service.
Anomalies Fixed in ACH
Bug ID
Description
CSCdu89369
Symptom: SWERR9000/C311 logged when disable VSI partition on IMA-T1 VT on IGX.
Conditions: When a VSI partition is enabled/disabled on a T1-IMA Virtual trunk SwSw Error9000 is logged.
Workaround: Not a service affecting bug.
CSCdv19468
Symptom: Loopback on Physical Interface not working on E3, T3 and OC3.
Conditions: Loop back on Physical interface is not effective on ports and trunks as the traffic is seen leaked to other end CPE. This bug is found as part of Diagnostic Loopback feature implemented on UXM trunks which is enabled in 9.3.40 SwSw Release.
Workaround: Issue resetcd.
CSCdv38499
Symptom: Traffic is being LEAKED to the remote end when loop back is present.
Conditions: Local loopback on UXM ports will result in traffic leaked to cell bus. Local remote loopback on UXM ports will result in traffic leaked to cell bus from remote end.
This bug is found and resolved as part of the Diagnostic Loopback feature implementation which is enabled in 9.3.40 SwSw Release.
Workaround: Issue resetcd on UXM.
CSCdw14895
Symptom: Adding ds3 trunk from Y-RED side results addtrk failure with message in 'loop back ' detected.
Conditions: This bug was introduced due to CSCdv38499 which has broken addtrk on Y-Red pair.
Workaround: Issue addtrk from remote end if no Y-Red exists on remote end.
Alternatively, physically pullout the Standby and perform addtrk.
CSCdt14885
Symptom: UXM card resets, we see swerr 103 and or cderrs 0B 29 00 A9 01 0D 17.
Conditions: UXM card resets with either 103 SwSw error or 0B h/w error or both on an active UXM which has been Up for 320 days. This bug is due to Gateway Timer Counter overflow which is found to occur every 320 days since card is up. This bug exists in all previous versions of firmware under Model-C UXM as well as UXM-E hardware.
Workaround: Reset UXM card in a maintenance window before 320 days of uptime.
Boot Code Requirements
Boot Code revision boot_10 is needed for the ACJ release.
Unsupported Configurations or Applications.
1. MPLS Controllers other than 7200 series routers.
2. Port Adapter PA-A3 on the 7200 series router not supported for "multi-vc" configuration.
3. The OC3 MMF backcard is not supported for Y-redundancy configuration.
4. Adding more than one controller to a VSI partition is not supported.
5. Adding controllers on trunks is not supported. The controllers must be attached to line interfaces.
6. Usage of IMA interfaces is not supported for attaching the LSCs (Label Switched Controllers) or LERs (Label Edge Routers). This restriction is because of the non availability of IMA interface support in IOS software release 12.1.(3)T for LSC and LER interfaces. The IMA interfaces can be used for trunks between IGX nodes.
7. ILMI implementation does not support service registration and address registration.
Notes and Cautions
1. Switch Software Release 9.3.10 or later is compatible with the following versions of IOS and 7200 port adapter hardware:
IOS 12.1(3)T and later
PA-A1 (non enhanced) flavors of T3, E3, and OC3 ATM adapters
Note PA-A3 adapters are not supported for multi-VC mode as of 9/2000.
2. Changing the VPI range on a UXM interface partition is not causing the Xtagatm interface configuration on the controller to be updated.
This issue is recently discovered in 12.1(3)T.
When the slave ATM switch reports a VPI range change through an "IFC GET CNFG TRAP" the LSC does the following:
a. If the VPI range is reduced, the XTAG interface is toggled down and back up to force LDP/TDP to be reset. The LDP negotiates label ranges (VPI, VCI ranges) only when the session is established. The information displayed through a "show tag int detailed" command should be correct in this case.
Note The above does not apply to the BPX where the VPI or VCI range cannot be SHRUNK using the
cnfrsrc command unless the interface is in the disabled state.
b. If the VPI range is increased, the information is updated in the VSI master but the information is NOT propagated to the XTAG. The LSC ignores the increased range instead of resetting the LDP session which forces VCs to be torn down. The VPI range from the "show tag int detailed" command can be interpreted as the LOCAL range that LDP/TDP used when setting up the session that is active. Changes at the ATM switch level are not reflected in the LSC unless the change explicitly causes the LDP session to be re-established.
3. Only one Xtag interface corresponding to a partition on a UXM interface that has multiple-partitions comes up. Other Xtag interface based on different partitions on the same UXM interface is not coming up.
Turn on "debug VSI errors."
The following errors display the messages: VPI/VCI in use or VCI in use. Overloading of the 0/32 tag-control PVC has occurred.
a. Example 1: Node tagigx4 dspctrlrs for tagigx4, shows two controllers, one each for partition 1 and partition 2.
b. Example 2: dsprsrc for 7.1, shows partitions 1, 2 and 3 on trunk 7.1
Trunk : 7.1
Maximum PVC LCNS: 256 Maximum PVC Bandwidth: 65000
(Statistical Reserve: 5000)
State MinLCN MaxLCN StartVPI EndVPI MinBW MaxBW
Partition 1: E 30 100 50 75 1000 10000
Partition 2: E 10 100 90 150 1000 10000
Partition 3: E 10 100 180 240 1000 5000
c. Xtagatm interface configuration for partitions 1 and 2 on Trunk 7.1
Make sure that only Xtag ATM interface uses the default tag-control-vc of 0/32. All other Xtag ATM interfaces on the same UXM interface should use non-default tag-control-vcs using the "tag-switching atm control-vc" command.
The following example shows xtagatm71 configuration on the LSC connected to 3.3 using default tag-control-vc of 0/32
Current configuration:
!
interface XTagATM71
ip unnumbered Loopback0
no ip mroute-cache
extended-port ATM2/0 vsi 0x00070100
tag-switching ip
end
The following example shows xtagatm71 configuration on an LSC connected to 19.3 using configured tag-control-vc of 90/32
When configuring a Cisco MPLS LSC on T3 interfaces, make sure the payload scrambling option on the UXM T3 line matches the config on the LSC. The default for the LSC is OFF, and the default for the UXM is ON since the lines come UP and CLEAR.
The following examples show T3 UXM configurations:
Controller 1 on node tagigx3 is connected to 12.6. If the IP address in the CtrlrIP column is correct, you know that the LSC is being seen by the IGX and vice-versa. Otherwise a 0.0.0.0 displays.
Firmware Filenames and File Sizes
The following list contains the firmware file information for the UXM Model C.
Filename(s)
Size (bytes)
ACJ.000 to ACJ.024
65536
ACJ.025
1762
ACJ.img
784
Filename(s)
Size (bytes)
AC09.000
56624
AC09.img
784
Appendix C—UXM Model B Firmware ABU Release
Introduction
UXM ABU is Model-B firmware release for UXM card on IGX. Firmware is the same for UXM and UXM-E cards.
New Features
RCMP Parity Policing
CSCdz03296 implementation of policing RCMP parity errors on UXM.
This feature allows the UXM card to continue to be in service under a low rate of parity errors while informing the user of parity event. The card resets if the error rate exceeds a threshold rate.
Obsolete Features
None.
Compatibility
1. Software:
ABU is compatible with Switch Software Releases 9.1, 9.2, and 9.3.
2. Hardware:
ABU is compatible with all models of URM and UXM-E hardware.
3. Previous versions of UXM firmware:
On IMA trunks this version is not compatible with UXMs Model B firmware versions ABA to ABD.
On IMA trunks Model B firmware (AB*) is not compatible with model A (AA*) because model B is Standards compliant and model A is not. Therefore, IMA trunks must be upgraded together.
Anomalies Resolved in ABU
The following table list the resolved anomalies in firmware ABU.
Bug ID
Description
CSCdu66836
Switchyred fails an IMA trunk momentarily and then clears failure.
CSCdx41404
IMA protocol OK keeps on being recorded.
CSCdx44466
T3 trunks go into looped Back state at the same time.
CSCdy02463
Dropping cells on IMA port after upgrade to ABS firmware.
CSCdy20922
End-to-end OAM cell not received on the remote CPE.
CSCdy54168
UXM/UXM-E-T1 fails loop back test on line interfaces upon loss of cell alarm.
Upgrade Instructions
Update boot code to boot 09 before upgrading to ABU.
Boot Code Requirements
Boot code revision boot_09 is needed for the ABU release.
Unsupported Configuration or Applications
None.
Firmware Filenames and Sizes
ABU Firmware Boot Code
Filenames
Size (bytes)
ABU.000-ABU.017
65536
ABU.018
60251
ABU.img
784
Notes and Cautions
None.
Appendix D—URM Model B Firmware XBC Release Notes
This section contains information about the URM Model B firmware XBC.
Introduction
URM XBC is Model-B firmware release for URM card on IGX. The URM is an IOS-based routing module for the IGX. This release is an upgrade from XBB.
New Features
RCMP Parity Policing
CSCin32112 - Implementation of Policing RCMP parity errors on URM.
This feature allows URM card to continue to be in service under low rate of parity errors while informing the user of parity event. The card will be reset if the error rate exceeds a threshold rate.
URM IOS CLI
This feature improves the management of the URM by allowing access to the IOS CLI running on the URM via the IGX CLI. This feature will also enhance Serviceability by further enabling remote recovery of the URM beyond the RRC feature introduced in 9.3.30 software.
This feature allows users to access the IOS CLI of the URM embedded router from the IGX CLI, so that users can access the router without having to be physically connected to the IOS Console port on the URM backcard
Obsolete Features
None.
Compatibility
1. Software
XBC firmware is compatible with Switch Software Release 9.3.47.
2. Hardware
XBC firmware is compatible with URM hardware.
Anomalies Resolved in XBC
The following table list the resolved anomalies in firmware XBC:
Bug ID
Description
CSCdz48550
addloclp causes alarm or continuity problems on ATM connection.
CSCin15267
DUART hangs up when there is heavy interrupts (Rx and Tx) from both the channels simultaneously.
CSCin21211
For all rsh commands, Lines were truncated beyond 80 characters.
CSCin21212
"-MORE" is attached to the end of the "dsprtrlog" response even though there is no more data to view.
CSCin39677
After changing the Max and Min LCNs of VSI partition using cnfrsrc, SWerr:5050 was logged when "cba_verify" command was executed.
Upgrade Instructions
No special upgrade instructions in upgrading the URM Admin firmware from XBB to XBC.
Boot Code Requirements
Boot Code revision boot_2 is needed for the XBC release.
Unsupported Configurations or Applications
The 0/1023 is a special VC used by URM for IPC between Admin Processor and IOS. When configuring MPLS network, do not commit any cross-connect or control-vc on the port. Otherwise, SWERRS or non-working configurations might occur.
Firmware Filenames and Sizes
This section contain URM-B firmware file information.
XBC Firmware Boot Code
Filename(s)
Size (bytes)
XBC.000 to XBB.019
65536
XBC.020
33025
XBC.img
784
XAA Firmware Boot Code
Filename(s)
Size (bytes)
XA2.000
57328
XA2.img
784
Notes and Cautions
1. The URM back card is hot-swappable; however the IOS processor is held in reset when back card is removed.
2. Card Mismatch might occur since XBA supports both BC-2FE2V and BC-2FE. Card mismatch is declared if BC-2FE2V and BC-2FE are swapped out of an ACTIVE URM card. Back cards of two different types can be swapped only in a STANDBY URM card.
3. If Remote Router Configuration feature is used to burn the IOS configuration in the card, the burned configuration cannot be deleted but can be overwritten only by another configuration.
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:
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated regularly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual or quarterly subscription.
Registered Cisco.com users can order a single Documentation CD-ROM (product number DOC-CONDOCCD=) through the Cisco Ordering tool:
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.
You can e-mail your comments 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-9883
We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com, which includes the Cisco Technical Assistance Center (TAC) website, as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from the Cisco TAC website. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC website, including TAC tools and utilities.
Cisco.com
Cisco.com offers a suite of interactive, networked services that let you access Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com provides a broad range of features and services to help you with these tasks:
Streamline business processes and improve productivity
Resolve technical issues with online support
Download and test software packages
Order Cisco learning materials and merchandise
Register for online skill assessment, training, and certification programs
To obtain customized information and service, you can self-register on Cisco.com at this URL:
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: the Cisco TAC website and the Cisco TAC Escalation Center. The type of support that you choose depends on the priority of the problem and the conditions stated in service contracts, when applicable.
We categorize Cisco TAC inquiries according to urgency:
Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration. There is little or no impact to your business operations.
Priority level 3 (P3)—Operational performance of the network is impaired, but most business operations remain functional. You and Cisco are willing to commit resources during normal business hours to restore service to satisfactory levels.
Priority level 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operations are negatively impacted by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Priority level 1 (P1)—An existing network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Cisco TAC Website
The Cisco TAC website provides online documents and tools to help troubleshoot and resolve technical issues with Cisco products and technologies. To access the Cisco TAC website, go to this URL:
All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC website. Some services on the Cisco TAC website require a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to this URL to register:
If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC website, you can open a case online at this URL:
If you have Internet access, we recommend that you open P3 and P4 cases online so that you can fully describe the situation and attach any necessary files.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. These classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer automatically opens a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this URL:
Before calling, please check with your network operations center to determine the Cisco support services to which your company is entitled: for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). When you call the center, please have available your service agreement number and your product serial number.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
Cisco Press publishes a wide range of networking publications. Cisco suggests these titles for new and experienced users: Internetworking Terms and Acronyms Dictionary, Internetworking Technology Handbook, Internetworking Troubleshooting Guide, and the Internetworking Design Guide. For current Cisco Press titles and other information, go to Cisco Press online at this URL:
Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:
iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:
Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, 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, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, 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. (0303R)