This feature adds the ability to the IGX to act as an AAL5 feeder to the PXM45-based Cisco MGX 8850, the PXM1E-based Cisco MGX 8850 and Cisco MGX 8830, or the BPX+SES. In prior releases, the IGX could only be a feeder to the BPX (or another IGX). The two nodes communicate by using Annex G LMI over a proprietary Auto Route Networking Channel.
This new IGX AAL5 feeder support is added by encapsulating the LMI messages in ATM AAL5 cells on the UXM feeder trunk connected to an AXSM, AXSM-E, PXM1E, or BXM card.
Refer to the "SNMP MIB" section for more information on the SNMP interface changes for this feature.
Additional Capabilities
The dsplmistats command now includes the LMI Node Status statistics
New CLIs: cnffdrlmiparms/dspfdrlmiparms to configure/display the feeder LMI timers.
Last Command: cnffdrlmiparms 10 10 10 5 5
T393 Status Enquiry Timer: 10
T394 Update Status Timer: 10
T396 Polling Timer: 10
N394 Max Status Enquiry Retry: 5
N395 Max Update Status Retry: 5
Last Command: dspfdrlmiparms
Next Command:
New CLI rmfdrrsrc: Superuser command to remove a feeder that is in LMI communication failure because the routing node is no longer attached. If the routing hub deletes an IGX feeder while there are existing connections on the feeder, the feeder will become dangling.
To cleanup a dangling IGX feeder:
Step 1 Delete all existing connections on the IGX feeder
Step 2 Issue the new command rmfdrrsrc
Syntax
rmfdrrsrc <slot.port>
Parameters
Parameter
Description
slot.port
Slot and port numbers corresponding to the feeder trunk interface.
Attributes
Privilege
Jobs
Log
Node
Help
History
Lock
Hipri
SuperUser
No
Yes
BPX, IGX
Yes
Yes
Yes
No
Limitations on the IGX AAL5 Feeder Feature
1. The IGX AAL5 feeder trunk (to the PXM45-based Cisco MGX 8850, the PXM1E-based Cisco MGX 8850 and Cisco MGX 8830, or the BPX+SES) is only supported on UXM or UXM-E cards.
2. The control VCs for LMI and IP Connectivity use VPI/VCI of 3/31 and VPI/VCI of 3/8 respectively. These values are not user configurable.
3. XPVCs and XPVPs remain unsupported on the IGX, whether it is a feeder or a routing node.
4. The URM card remains unsupported on the IGX AAL5 feeder
5. The UXM IMA back card with the BNC connectors is not supported on the IGX AAL5 feeder.
VSI Service Class Template Configuration
CLR (Cell Loss Ratio) is a new configurable parameter in the QBIN template. The value of CLR from the template will be used as default for CAC calculations, if a value of zero is specified for CLR in the connection request.
CLR is negotiated by PNNI for SVCs, but not for SPVCs. Hence for SPVCs the value of CLR from the template will be used, rather than assuming a CLR of zero for eCAC calculations.
This enhancements also make the existing "Discard Selection" parameter in the QBIN template configurable on an interface.
In a Multi-VC TAGCOS solution 8 IP TOS (Type of Service) values are queued into 4 classes. Each class is assigned a Qbin. To differentiate between two different TOS in the same Qbin, cells belonging to one of the TOS are marked with a CLP = 1. For this scheme to work, which means to provide a higher QOS to the TOS with greater precedence or priority; the discard method used at the Qbin should be CLP Hysteresis, and not EPD.
Previously, there was no way of changing the Discard Selection mechanism used at the Qbin. The Discard Selection at the Qbin is now configurable, allowing you to choose whether EPD or CLP Hysteresis should be used as the discard algorithm at the Qbin.
The configuration of CAC treatment in the VC descriptor template has been made more user friendly by displaying the available CAC options on the screen. Input error checking has been added to ensure that you select a valid CAC treatment for the selected Service Class.
Affected CLI command - cnfqbin
CLR (Cell Loss Ratio) parameter
The cnfqbin command has been modified to allow configuration of CLR parameter.
Syntax:
cnfqbin <Interface> <Qbin> .........<CLR>
Parameters:
Parameter
Description
<Interface>
Specifies interface on which CLR need to be configured.
<Qbin>
Qbin number for CLR configuration.
<CLR>
A value 1 through 15.The configured number indicates the negative power to which the base 10 will be raised to obtain the value for CLR.For example a value of 8 would indicate a CLR = 1/10^8.
Attributes:
Privilege
Jobs
Log
Node
Help
History
Lock
HiPri
1-6
Yes
Yes
BPX/IGX
Yes
Yes
Yes
No
Discard Selection parameter
The cnfqbin command has been modified to allow configuration of the Frame Discard Select parameter of the Qbin template. You can now choose between PPD or EPD.
Specifies interface on which Frame Discard Select need to be configured.
<Qbin>
Qbin number for Frame Discard Select configuration.
<Frame Discard Select>
Discard schemes
PPD
EPD
Attributes:
Privilege
Jobs
Log
Node
Help
History
Lock
HiPri
1-6
Yes
Yes
BPX/IGX
Yes
Yes
Yes
No
Example:
NODE TN Cisco BPX 8620 9.4.00 Date/Time Not Set
Qbin Database 4.2 on BXM qbin 10 (Configured by ATMF_tagcos_1 Template)
(EPD Enabled on this qbin)
Qbin State: Enabled
Discard Threshold: 24000 cells
EPD Threshold: 95%
High CLP Threshold: 100%
EFCI Threshold: 100%
Cell Loss Ratio : 8
Frame Discard Select : EPD
This Command: cnfqbin 4.2 10 e n 24000 95 100 100
Cell Loss Ratio [8] :
Affected CLI Command - cnfqbint
Cell Loss Ratio:
A new parameter will be displayed onthe cnfqbint command. This parameter will take values from 1 through 15.The configured number indicates the negative power to which the base 10 will be raised to obtain the value for CLR.For example a value of 8 would indicate a CLR = 1/10^8.
2 CLP Low/EPD Threshold: 95 (% of Discard Threshold)
3 CLP High Threshold: 100 (% of Discard Threshold)
4 EFCI Threshold: 100 (% of Discard Threshold)
5 Frame Discard Select: PPD
6 Vc Shaping: Enabled
7 Cell Loss Ratio 8
This Command: cnfqbint 1 10
Enter index for parameter to modify:
TFTP Interval and SNMP Channel Statistics Configuration
In previous releases, TFTP Interval Statistics for connections were configured on a node basis. When a particular channel statistic type was enabled, all connections which supported the enabled statistic attempted to collect it. On a node with a large number of terminated connections, huge amounts of resources are used to collect, format and store the statistics. The TFTP Statistics operation leads to an unnecessary overhead if statistics are needed for only a small subset of terminated connections.
SNMP or Counter Channel Statistics are automatically enabled whenever a connection is added from or to a node. SNMP Statistics collection also leads to unnecessary overhead if the user does not require these statistics for all connections.
This feature allows you to configure individual connections to enable or disable TFTP channel interval Statistics or SNMP Channel Statistics or both. TFTP and SNMP Statistics will only be collected for those connections that have collection of the respective statistics enabled.This leads to an improvement in performance. In order to achieve this performance improvement, you have to disable both SNMP and TFTP statistics on each connection for which statistics collection is not required.
The default settings for this feature are TFTP Channel Interval Statistics collection enabled and SNMP Channel Statistics collection disabled. (As seen by the new command, 'dspstatcon' screen.)
Refer to the "SNMP MIB" section for more information on the SNMP interface changes for this feature.
URM IOS CLI
This feature in IGX Switches allows you to access the IOS CLI of the URM embedded router from the IGX CLI without having to be locally attached to the console, auxiliary or ethernet port of the URM.
In previous releases, a physical cable was required to connect to the console router port. Therefore, it required that you were physically on site to access the router, or if there are more than one router in the same IGX shelf, then it would require physical moving of the cable from router to router or multiple connections to individual router ports.
With this feature, you can access the router remotely and perform maintenance on the router without having to be physically on site, as there is no physical cable to move.
Note Only one session per node can be active at a time.
Line Rate PCR
This feature provides the capability to configure a VSI partition to advertise either VI Rate or VSI Max Bandwidth to the controller. Depending on this the PNNI connections on that VSI partition can have a PCR up to the VI Rate or the VSI Max Bandwidth.
AutoRoute allowed the connections to have a PCR up to the VI Rate in releases prior to 9.4. In prior releases, as connections were migrated from AutoRoute to PNNI, since the PNNI connections could have a PCR only up to the VSI Max Bandwidth, the connections would need to have the PCR adjusted to meet the PNNI restrictions. With this feature the PNNI connections can retain their PCR setting upon migration.
CPU Idle Time from SNMP
This feature introduces a new SNMP MIB object which returns the CPU idle time calculated by the Profiler. In other words this object will give the idle time as displayed in the "dspprf" screen. The way the profiler works is that it has discrete time interval (configurable using "cnfprfparm") and when that time interval expires it sums the values and takes the average. Using the above timeline, the profiler, if set to 20 seconds, would take the values for 1 through 20, compute their average and then display that value, non-changing for the next 20 seconds. Until at time t=40, it would take the values for 21 through 40, compute their average and then display the value, non-changing for the next 20 seconds. Until at time t=60, it would take the values for 41-60, compute their average and then display the value, non-changing for the next 20 seconds. CPU idle time is accessible via SNMP interface through the MIB object "shelfCnfgAverageIdle".
Refer to the "SNMP MIB" section for more information on the SNMP interface changes for this feature.
BCC SAR Failure
This feature, which can be enabled or disabled by a debug flag on/off3, provides the capability to automatically do a switchover on a SAR failure of the BCC. The modifications in the switch software flag the BCC failures on an Active or Standby cards as MAJOR alarms and do an automatic switchover as necessary when this feature is enabled. Refer to the "Default Values" section for a screen shot of the on3 command.
The BCC switchover will only occur if the node has a healthy card in standby state that is ready to take over. The switchover recovery will not occur if the standby is in a failed state (or even SAR failed), or in download or update phase, instead the node will undergo a hitless rebuild. If the standby is in an upgraded state, then the SAR failure will trigger a hitless rebuild as opposed to a switchcc. The same will be the case, if the standby is not ready to takeover the control, either because of a failure or because of an ongoing update. The failure on the card will be cleared, if the BCC undergoes a hitless rebuild and an event will be logged to reflect this. If the switchover occurs to a healthy standby, the original active's failure will not be cleared so that the user will have a chance to examine the failure reason later.
Auto Switchyred on UXM
This feature, which can be enabled or disabled by a debug flag on/off3, provides the capability to automatically do a switchyred up on receiving a Loss of Cell on a UXM-OC3 interface, if a y-redundant pair is available. This feature also adds the capability to support the switchyred command on the IGX platform, for both UXM as well as legacy cards, similar to the switchyred command currently available on the BPX platform. Refer to the "Default Values" section for a screen shot of the on3 command.
IGX and BPX Connection Scaling
This feature speeds up the CWM sync-up time when there are more number of connections in a network. This feature provides a debug flag(on/off3) from the switch CLI to enable or disable the sending of the slave endpoint connection updates to the CWM.The improvement in the CWM sync-up time can be achieved if the slave end point connection updates debug flag is set to disabled. Refer to the "Default Values" section for a screen shot of the on3 command.
Continuous Alarm on Invalid Login Attempts
Currently if generation of MAJOR alarm on invalid log in attempts is enabled (by putting the value for cnfsysparm 22 to 3 or more) switch software generates a MAJOR alarm on (say) 3 consecutive invalid login attempts and generates a 20005 trap. This trap will not be sent again until the alarm has been investigated and cleared by using the CLI command "clrloginalm". Refer to the "Default Values" section for a screen shot of the cnfsysparm command.
This feature provides support to generate this trap for each block of consecutive invalid login attempts whether the command clrloginalm is executed or not.
Revising Access Levels for Configuration Commands
The access levels are raised for the following commands:
cnfsnmp (IGX/BPX) - from ANYUSER to SUPER User
cnfqbin (BPX) - from ANYUSER to SUPER User
cnfportfunc (IGX) - from ANYUSER to SUPER User [command is new on the BPX]
cnfabrparm (BPX) - from GROUP5 to SUPER User
Special Installation and 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.3.33.
Before upgrading the switch software, make sure the cards have the minimum firmware revision per the compatibility matrix.
Procedure for Adding New BCC Cards as a Part of Upgrading to Release 9.4
If new BCC cards are to be installed as part of the upgrade to Release 9.4, 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.3.30 and 9.4.00 nodes to coexist and interoperate. This capability allows users to upgrade their networks from 9.3 to 9.4 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.4.
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 12.0.00
UXM firmware
For MPLS VC merge and trunk loopback features, ACK 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 or later
SES version 1.1.75 or later
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. VSI on IGX requires NPMs with at least 4 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.4.
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.
Limitations for Release 9.4.00
When an IGX is added as a feeder to a SES/BPX or MGX node, it will have a default node number, this node number may not be unique within the network. If it is not unique then it needs to be modified to a unique node number by issuing cli command "rnmnd <x>" where x should be unique with respect to all other auto-route nodes. To find the other node numbers, use the CLI command "dspnds +n". Failing to do so, CWM Databroker may have incorrectly formed hybrid connection database, and the CWMGUI may show the connection as incomplete..
Compatibility Matrix
This section contains compatibility information for Release 9.4.00.
Compatibility Notes
For a complete list of firmware revisions supported, see the Compatibility Matrix document, which is included in this release package.
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.22
4.0.19
4.0.23
4.0.13
FRSM-4E1
FRSM-4E1
4.0.22
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.17
4.0.15
4.0.17
4.0.11
CESM-4E1
CESM-4E1
4.0.17
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.14
4.1.05
4.1.09
4.1.00
CESM-8E1
CESM-8E1
5.0.14
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.21
4.0.19
4.0.21
4.0.13
AUSM-4E1
AUSM-4E1
4.0.21
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.15
5.0.10
4.0.24
4.0.13
FRSM-8E1
FRSM-8E1
5.0.15
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.14
5.0.10
4.0.24
4.0.14
AUSM-8E1
AUSM-8E1
5.0.14
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.14
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.14
5.0.10
4.0.22
4.0.13
IMATM
IMATMB-E1
5.0.14
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.
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.4.00
The following table lists the known anomalies for Release 9.4.00.
Table 3 Known Anomalies for Release 9.4.00
Bug ID
Description
CSCdk22430
Headline: Word 15 of bpnv checksum is not recalculate
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: No workaround is available at this time.
CSCdk62225
Headline: SWSW DSPPWR is incorrect for a DC Power Self
Symptom: DSPPWR is incorrect for a DC Power Self
Conditions: None
Workaround: None
CSCdk65076
Headline: non fatal card errors when BXM-T3 is put in
Symptom: Non fatal card erros when BXM-T3 was inserted
Conditions: None
Workaround: None
CSCdk83372
Headline: TFTP Download of Software abort with no status message
Symptom: While attempting to download switch software to a node, the dspdnld screen would show the download progressing and then suddenly stop and begin the download anew. No messages are logged in the even log (dsplog) which describe the nature of the problem. The output from the tftpstats and dspilacc, or dsppna commands do not really give a clear picture either.
Conditions: Unknown what background conditions cause the process to fail.
Workaround: No known workaround.
Further Problem Description: This DDTs report was raised to address the need for further debugging/log output to diagnose these file load failure issues. Without further information no judgment as to the actual root cause of the failure can be determined.
CSCdk90900
Headline: SV+: Connection Mgr makes the UXM go into alarm and resets when modifying conn
Symptom: The UXM card on an IGX goes into alarm and resets if the connection was added using CLI and then modified using the Connection Manager.
Conditions: Cisco Wan Manager 9.1.05 Patch 4 UXM in IGX swsw 9.1.07
Workaround: The work around is to add connection using the Connection Manager and modify it using the CLI.
CSCdm00298
Headline: Abstract: cant Add/Modify ATM-ATM PVCs with PCR104268 through SV
Symptom: After line config change cant configure ATM-ATM PVC with PCR=104268 through SV+
Conditions: After changing the line conf. cell framing from PLCP to HEC on BXM-T3 line.
Workaround: Should work via CLI, not dependent on robust mesg update.
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.
CSCdm38743
Headline: Addcon in a addjob for cbr connection doesnt let you configure PCR(0+1)
Symptom:While configuring an addcon in a addjob, no error message is display indicating that the line need to be up first. The error message appear if the addcon is done from the CLI.
Condition: None
Workaround: None
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).
CSCdm71136
Headline: BDB Packet drop alarms are not forwarded by the SNMPAgent
Symptom: Minor and major alarams for BDB packet drops on trunks are not forwarded to the remote network manager using the trap forwarding facility by the SNMP proxy agent.
Conditions: Observed with IGX SWSW 9.1.12 and CWM 9.1.08.
Workaround: No workaround available at this time.
CSCdm76279
Headline: Cisco View no Data for FR-RealTimeCounters on IGX
Symptom: When Using CiscoView to view the FR-RealTimeCounter SpreadSheet only the first two collums are displayed correctly, the remaining collums are displayed as 1's.
Conditions:All conditions are normal.
Workaround: None
CSCdp26838
Headline: SWERR 2058 logged on standby NPM, dspstatparms shows more stats on stby NPM
Symptom: Software errors 2058 are logged continuously on the standby NPM. If there is a switchcc, the errors will continue to be logged continuously on the active NPM. The node's event log shows "Standby NPM <slot> Update Completed" without an immediately preceding "NPM <slot> Removed" event logged. The dspstatparms display on the NPM logging the 2058 errors has a higher statistics count than the NPM which is not logging the errors.
Conditions: An IGX running software release 9.1.xx. There may be a defect or an execessive number of standby CC updates which is causing the standby CC update queue to be flushed. The flushing of the standby CC update queue causes the standby CC to be completely updated without resetting the card. Due to this defect, the complete updating of the standby CC without a preceding reset may cause excess TFTP statistics to be enabled on the standby CC. If there enough excess TFTP statistics enabled, the TFTP memory will be depleted and software errors 2058 (BAD_TFTP_MEM_OUT - TFTP memory full) will be logged.
Workaround: The excess statistics on the standby NPM can be removed by resetting the standby NPM. This will also stop the logging of the software error 2058s. If there is a higher statistics count on the active CC after the standby CC is updated, there may also be excess statistics on the active CC. These can be removed with a switchcc. See CSCdm12055, CSCdp07967, and CSCdm64863 for workarounds and corrections to defects that can cause the "Standby NPM <slot> Update Completed" event which precipitates the excess TFTP statistcs.
CSCdp33698
Headline: CVM-TT(CVM model C): Got Agent Error: No Such Name when added voice conn
Symptom: Connections of CVM-TT (CVM FW Model C) can not be created by Connection Manager.
Headline: Upgrade 9.1.04 to 9.1.16 causes UXM Y-red cards to go into mismatch
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 usag
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
CSCdp61249
Headline: Bus errors logged at a high rate, filling the nodes event log
Symptom: Event log fills with multiple bus error entries every minute. This may displace other entries which are of interest from the event log.
Conditions: The IGX node has a bus error.
Workaround: Correcting the bus error condition will stop the reporting of the errors to the event log.
CSCdp98648
Headline: CWM 92 equipment MGR does not support BXM enhance card type.
Symptom: Equipment MGR can't 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.
CSCdr01353
Headline: AIS (BLU) from IMATM trunk causes comm break
Symptom: BPX's with BXM's connected by AXIS IMATM can comm break following an IMA group failure even though other paths exist to the remote node. The comm break will clear quickly but can delay rerouting of conns to the remote node up to a minute.
Conditions: A failure in 1 direction of the IMA T1's, producing AIS (BLU) alarm on BXM trunks, causes a comm break. A failure in both directions simultaneously causes the expected reroutes (and comm fail) in a timely manner.
Workaround: Restric CC traffic on these trunks.
CSCdr15925
Headline: A bit advertised may be incorrect after switchcc
Symptom: A-bit may be advertised to CPE as active when it should be inactive after a switchcc/runrev. dspcons -fabit on switch shows A-bit is failed.
Conditions: Switch has NNI connction(s) with A-bit failed, and there is a CC switch over.
Workaround: The correct status will be sent if the connections is downed and upped (dncon/upcon). A reset of the endpoint card (FRM or UFM) will also cause the correct status to be sent.
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.
CSCdt07203
Headline: Hitless rebuilds logged on a failed switchcc can fill hitless log
Symptom: The hitless rebuild log filled up due to repeated failed switchccs.
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 entried get a chance to age out of the log.
CSCdu15686
Headline: Diagnostics PortTest V35/X21
Symptom: Internal port diagnostics fails for V35/X21 ports. use "tstport" command. After the above test, 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 - Tested with UFMU F/W version YAM and YAN and seen the same problem.
Workaround: None
CSCdv33406
Headline: BXM-155 w/ APS: Automatical 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.
CSCdw04934
Headline: CLI switchyred command, took approx. 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: 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.
CSCdx33468
Headline: dspcons shows connections but dspcon shows connection does not exit
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.
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. This has been found on NPM32, NPM32B and NPM64 using latest rev S firmware for each of the Build models per card. Once a terminal is connected the screen will display "Transistion 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 connectivty 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 etc..
Workaround: 1. The first workaround is already known and that is to have a terminal connected via the control port. (Not suitable in your scenerio). I also believe 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 allows me to set the SWSW level for use in code patches. Once i have set the required Upgrade SWSW level and issue the runrev command the node will again remain in boot mode but now i can still connect via the Eithernet 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 25pin D types and a terminal cable this also has the effect of making the node rebuild correctly with the New SWSW revision. Moving on further and trying to simpify this further i have tested in my lab on 2 seperate occations for each NPM type that if you wire the control port to the below specification you ensure the node rebuilds and comes back online with the new rev. My tests showed that inserting wires into the below pinout either before a runrev or after when the node is in boot will have the same effect. TX 2 ------------- 8 CD RTS 4 ----------5 CTS DSR 6 ---------20 DTR Pin Outs of the interface can be found at below URL!!! http://www.cisco.com/univercd/cc/td/doc/product/wanbu/igx8400/8_5/ic85/igxicbl. htm#xtocid483424 4. A further method of ensuring the nodes recover after a SWSW upgrade is to have a redundant NPM card, no nodes failed when node was configured in a redundant mode. After the above tests i used the same two card types in a single node and performed upgrades through 9.2.33, 9.2.38, 9.3.24 and 9.3.36 without problems being encounter. 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.
CSCdx52484
Headline: CBR traffic got dropped on BPX side on ENNI link when there is congestion
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.
CSCdx79141
Headline: chan allocation inconsistency between BXM and SES
Symptom: chan allocation inconsistency between BPX and SES.
Condition: Have only 1 part. first (Max. lcn > Min.),add conns. > min..Add more parts such that sum(Min.s)>Max(max.).
Workaround: None
CSCdx84899
Headline: Software Errors 105/100 appeared with SES 1.1.75.103 attached
Symptom: Sofware 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
CSCdx93228
Headline: Error message 2004 on the switch
Symptom: Concord's Network Health tool gets snmp errors from the IGX's snmp agent.
Conditions: With SWSW 9.1.12.
Workaround: None.
Further Problem Description: error message 2004
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
CSCdy51972
Headline: switchyred on BXM while SES has chan alms gets alms stuck
Symptom: False chan alms got stuck after switchyred on BXME.
Conditions: FW upgrade of BXME cards to MFP caused a ln alm. The customer tried a switchcc on the SES to clear the ln alm. This caused false chan alms. The customer then tried a switchyred to clear the false chan alms faster. This made the false chan alms stay. The customer had to reset the FRSM cards to clear the alms.
Workaround: Reset the FRSM cards on the MGX(8220) or Don't switchyred on the BXME while there are false chan alms. The false chan alms would clear in about 30 min.
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 resloved.
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.
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: Customet installed MPLS only trunks
Further Problem Description: PER 7127 has been raised
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: No particular environment required. I have duplicated this in the lab.
Workaround: None. (Except to up port)
Further Problem Description: Customer sees this as an issue.
CSCdz36965
Headline: BXM fail after firmware burn
Symptom: After BXM Burns, the BXM card comes up as failed. On resetting the card and or reprogramming the card the card gets successfully upgraded
Conditions: BPX 8620, with 9.2.32 BCC with HDM and the BXM with MEJ being upgraded to MFT.
Workaround: Depends on the card. ON resetting the card hard, the card comes back in standby and successfully burnt on not at all. If burn is not successful a second attempt goes through fine
CSCdz87003
Headline: Test Delay Granularity not accurate
Symptom: UXM testdelay granularity
Conditions: No special environment.
Workaround: No work around
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.
CSCea08808
Headline: ILMI advertizing incorrect values for Virtual Trunks
Symptom: In a BPX/SES PNNI scenario, SVC/SPVC connections do not route over PNNI virtual interface (VNNI, virtual trunk) when using different VPIs in both ends of the Virtual Path Connection. Connections fail with cause code #35: Last Fail Cause: requested VPCI/VCI not available.
Conditions: The scenario is similar to this: BXM_VNNI-----VPI1-----VPC_Cloud-----VPI2----BXM_VNNI where VPI1 is different than VPI2
Workaround: Disable ILMI autoconfiguration using the command cnfautocnf from the SES Controller. With auto-configuration disabled, the ILMI slave does not start ATM layer parameter-negotiation while ports come up. Instead, the ILMI slave uses the local configuration parameters. The default state for auto-configuration is enabled.
Further Problem Description: If this problem is present, the command dsppnport shows a minSvccVpi greater than maxSvccVpi, and minSvccVci greated than maxSvccVci in the end with higher VPI value. This can be seen below: nodename.7.PXM.a > dsppnport 1:1.4:14 Port: 1:1.4:14 Logical ID: 16848910 IF status: up Admin Status: up UCSM: enable SVC Routing Pri: 8 Auto-config: enable Addrs-reg: enable IF-side: network IF-type: nni UniType: private Version: pnni10 PassAlongCapab: n/a Input filter: 0 Output filter: 0 minSvccVpi: 11 maxSvccVpi: 10 <===== minSvccVci: 35 maxSvccVci: 65535 minSvpcVpi: 11 maxSvpcVpi: 10 <=====
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 personel" 3. Checking the CWM network browser shows the ports listed multiple times
Conditions: There are no specific condititons that lead to this problem
Workaround: No workarounds are known at this time. Avoid doing an upln on the problem interface.
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.
CSCea36542
Headline: VCI=0 on overlapping resources created via sw cli not added in cwm db
Symptom: BPX switch software 9.3.11, SES software 1.0.14 and WAN Manager 11.0.10 patch1 When creating connections from switch cli with vci=0 on overlapping resource partitions, the connection is added on the switch but not into the WAN Manager database.
Conditions: The VCI has to be zero and the VPI in an overlapping resource partition.
Workaround: Do not use VCI = 0.
CSCea54019
Headline: Switchcc from BCC-3 to BCC-4 triggers comfailure on feeder trks
Symptom: Switchcc from BCC-3-64 to a BCC-4 triggered Com Failures
Conditions: 9.3.36 software converting to BCC-4 from BCC-3-64 All perchecks showed no errors After switchcc slot 9 went into a Comm failure state other card in slot 5 after removing it and replaceing slot 8 resolved the failures.
Workaround: Replace BCC-4 with old BCC-3, isolated card causing slot errors - remove all standby SM's - Insert one at a time monitoring sloterrs, dspsloterrs. EFA suspect cards
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 at this time.
Further Problem Description: None, see information above under the "Conditions" heading.
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
Symptom: Failed connections on the SES. Channel Alarms on the feeder node.
Condition: 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: inter card connection between two BXMs is not programmed correctly
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 F/Relay side. The conn gets added as an ATFR instead of ATFX. Manually adding the conn with the same parameters on the F/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.
CSCea62029
Headline: SNMP for Data Connection returns fail for UVM card ( connection addition)
Symptom: Not possible to add nx56 or nx64 connection when using Connectin Manager GUI
Conditions: Always
Workaround: Use CLI
CSCea76950
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 command, i.e 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.
CSCea80645
Headline: Huge time drift for stats reset during high CPU usage
Symptom: Node suffer from 0 CPU idle time. dsplog shows a lot of expected time change together with unexpected "Stats reset: time drift"
Conditions: None
Workaround: Execute command switchcc
Additional Deliverables
SNMP MIB
The SNMP IGX/BPX switch SNMP MIB is being provided with the delivery of Release 9.4 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.
Switch MIB changes of Release 9.4.00
atmTrunks
New object
atmTrkAal5FdrTrk
A new MIB variable atmTrkAal5FdrTrk has been added to the atmTrunks table.
atmTrunks OBJECT-TYPE
SYNTAX SEQUENCE OF AtmTrkEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "A list of atmTrk interfaces"
--DEFAULT test-function test_atmrtetrktable
--DEFAULT next-function next_atmrtetrktable
--DEFAULT get-function get_atmrtetrktable_%t
::= { trunkServiceObjects 2 }
atmTrkEntry OBJECT-TYPE
SYNTAX AtmTrkEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "A interface entry"
INDEX { switchIfIndex }
::= { atmTrunks 1 }
AtmTrkEntry ::=
SEQUENCE {
....
atmTrkVTPathFailReason INTEGER,
atmTrkHcfShift INTEGER,
atmTrkMaxXmitRate INTEGER,
atmTrkAal5FdrTrk INTEGER
}
atmTrkAal5FdrTrk OBJECT-TYPE
SYNTAX INTEGER {
notApplicable(1)
enable(2),
disable(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Indicates if the trunk should be used as an AAL5 feeder trunk. If enabled, the LMI messages will be encapsulated in the standard ATM AAL5 cells. If disabled, the LMI messages will be encapsulated in the proprietary AutouRoute networking messages. This object is applicable for UXM feeder trunks on the IGX feeders only. The default value is disable(3). For UXM feeder trunks on the IGX routing nodes or any ATM routing trunks, notApplicable(1) will be returned."
--DEFAULT view-mask IGX_VIEW
:= {atmTrkEntry 71}
Modified objects
atmTrkType
A new read-only enum trkTypeAal5(12) has been added to the MIB variable atmTrkType in the atmTrunks table.
atmTrkType OBJECT-TYPE
SYNTAX INTEGER {
trkTypePHY(1),
trkTypeCBR(2),
trkTypeVBR(3),
trkTypeABR(4),
trkTypeIPXAF(5),
trkTypeAXISAF(6),
trkTypeESPAF(7),
trkTypeIGXAF(8),
trkTypeVSIAF(9),
trkTypePARAF(10),
trkTypeRTVBR(11),
trkTypeAal5(12)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION " The type of this trunk. The values of trkTypeCBR(2),
trkTypeVBR(3), and trkTypeABR(4), and trkTypeRTVBR are
writable for virtual trunks only. The trkTypePHY(1) value
is returned for a get-request on a physical trunk. Other
values are returned for a get-request on a feeder trunk."
::= { atmTrkEntry 9 }
Changed object
atmTrkOeNdType
A new enum ndTypeMGXH(10) has been added to the MIB variable atmTrkOeNdType in the atmTrunksTable.
atmTrkOeNdType OBJECT-TYPE
SYNTAX INTEGER {
]ndTypeOther(1),
ndTypeIPX(2),
ndTypeBPX(3),
ndTypeIPXAF(4),
ndTypeAXIS(5),
ndTypeIGX(6),
ndTypeIGXAF(7),
ndTypeESP(8),
ndTypePAR(9),
ndTypeMGXHub(10),
ndType8450(16)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION " The type of node or shelf at the other end of this
trunk. Enumeration ndType8450 is obsolete."
::= { atmTrkEntry 13 }
shelfCnfgObjects
New objects
shelfCnfgTftpChanStats
shelfCnfgSnmpChanStats
Two new scalar objects (shelfCnfgTftpChanStats and shelfCnfgSnmpChanStats) have been introduced to enable or disable TFTP and SNMP statistics on ALL connections on a node.
shelfCnfgStatMaster OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "This object provides the network manager the
IP address of the master statistics collection
management workstation."
--DEFAULT get-function get_shelfcnfg_%t
::= { shelfCnfgObjects 1 }
................................
................................
shelfCnfgTftpChanStats OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2),
NoChange(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Specifies whether the user would like to collect TFTP
statistics for all connections on node. If the user value is 'enable' then any configured
TFTP channel statistics will be enabled all connections. If the user value
is 'disable' then connections will ignore the TFTP channel statistics
configuration. The value of `NoChange' is always returned for a GET operation"
--DEFAULT test-function test_shelfcnfg
--DEFAULT get-function get_shelfcnfg_%t
::= { shelfCnfgObjects 40}
shelfCnfgSnmpChanStats OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2),
NoChange(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Specifies whether the user would like to collect SNMP
statistics for all connections on node. If the user value is 'enable' then
SNMP channel statistics will be enabled for all connections. If the user value
is 'disable' then connections will ignore the SNMP channel statistics
configuration. The value of `NoChange' is always returned for a GET operation "
--DEFAULT test-function test_shelfcnfg
--DEFAULT get-function get_shelfcnfg_%t
::= { shelfCnfgObjects 41}
shelfCnfgProfilerIdle OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The CPU idle time (in %). This system-wide object, which is maintained at all time after boot, is the idle time of the switch to be used to see how busy the switch is. This is calculated every interval set by the CLI command 'cnfprfparm'. This idle time is the same IDLE value displayed in 'dspprf' screen for the current interval"
--DEFAULT get-function get_shelfcnfg_%t
::= { shelfCnfgObjects 42 }
AtmEndptTable
New object s
Two new objects, atmEndptTftpStats and atmEndptSnmpStats, have been added to the atmEndptTable. These objects allow you to enable or disable TFTP and SNMP statistics on ATM connections.
atmEndptTable OBJECT-TYPE
SYNTAX SEQUENCE OF AtmEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The ATM End-Point table. This table
is used to model a PVC end-point. This table
contains the traffic parameters for ATM end-point."
::= { switchConnection 8 }
atmEndptEntry OBJECT-TYPE
SYNTAX AtmEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "An entry in the ATM End-point table."
INDEX { atmEndptIndex }
::= { atmEndptTable 1 }
AtmEndptEntry ::=
SEQUENCE {
atmEndptIndex INTEGER,
atmEndptDesc DisplayString,
............
............
atmEndptTftpStats INTEGER
atmEndptSnmpStats INTEGER
}
atmEndptTftpStats OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Specifies whether the user would like to collect TFTP
statistics for the connection. If the user value is 'enable' then any configured
TFTP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the TFTP channel statistics
configuration. "
::= { atmEndptEntry 94 }
atmEndptSnmpStats OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Specifies whether the user would like to collect SNMP
statistics for the connection. If the user value is 'enable' then
SNMP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the SNMP channel statistics
configuration.
::= { atmEndptEntry 95 }
AtmQbinTable
New object
atmQbinClr
atmQbinTable OBJECT-TYPE
SYNTAX SEQUENCE OF AtmQbinEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The ATM Port or Trunk Qbin Configuration table."
--DEFAULT test-function test_atmqbintable
--DEFAULT next-function next_atmqbintable
--DEFAULT get-function get_atmqbintable_%t
--DEFAULT view-mask BPX_VIEW | IGX_VIEW
::= { rsrcServiceObjects 2 }
atmQbinEntry OBJECT-TYPE
SYNTAX AtmQbinEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "An entry in the ATM Ports or Trunks Qbin Configuration table."
INDEX { switchIfIndex, atmQbinId }
::= { atmQbinTable 1 }
AtmQbinEntry ::=
SEQUENCE {
atmQbinId INTEGER,
atmQbinAdminStatus INTEGER,
atmQbinOperStatus INTEGER,
atmQbinMinBw INTEGER,
atmQbinDepth INTEGER,
atmQbinLoClp INTEGER,
atmQbinHiClp INTEGER,
atmQbinEfci INTEGER,
atmQbinTmpltCnfg INTEGER,
atmQbinVcShaping INTEGER,
atmQbinEpd INTEGER,
atmQbinClr INTEGER
}
...................................
atmQbinEpd OBJECT-TYPE
SYNTAX INTEGER {
EPD(1),
PPD(2) (CLP Hysterisis)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Indicates whether Early Packet Discard (EPD) or Partial Packet Discard is enabled on this qbin."
::= { atmQbinEntry 11 }
atmQbinClr OBJECT-TYPE
SYNTAX INTEGER ( 1- 15)
ACCESS read-write
STATUS mandatory
DESCRIPTION "Indicates a number for Cell Loss Ratio(1 through 15).The configured number is the negative power to which the base 10 will be raised to obtain the value for CLR.For example a value of 8 would indicate a CLR = 1/10^8.
"
::= { atmQbinEntry 12 }
frEndptTable
New object s
Two new objects, frEndptTftpStats and frEndptSnmpStats, have been added to the frEndptTable. These objects allow you to enable or disable TFTP and SNMP statistics on Frame relay connections.
frEndptTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Frame Relay End-Point Configuration table.
This table is used to model a Frame Relay end-point.
The table contains the configuration parameters
required to create and configure a Frame Relay end-point."
--DEFAULT test-function test_frendpttable
--DEFAULT next-function next_frendpttable
--DEFAULT get-function get_frendpttable_%t
--DEFAULT view-mask IPX_VIEW
::= { switchConnection 5 }
frEndptEntry OBJECT-TYPE
SYNTAX FrEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "An entry in the Frame Relay End-point Configuration table."
DESCRIPTION "Specifies whether the user would like to collect TFTP
statistics for the connection. If the user value is 'enable' then any configured
TFTP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the TFTP channel statistics
configuration. "
::= { frEndptEntry 48 }
frEndptSnmpStats OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Specifies whether the user would like to collect SNMP
statistics for the connection. If the user value is 'enable' then
SNMP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the SNMP channel statistics
configuration. "
::= { frEndptEntry 49 }
voiceEndptTable
New object s
Two new objects, voiceEndptTftpStats and voiceEndptSnmpStats, have been added to the voiceEndptTable. These objects allow you to enable or disable TFTP and SNMP statistics on voice connections.
voiceEndptTable OBJECT-TYPE
SYNTAX SEQUENCE OF VoiceEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The voice channel connection table has Channel Connection
information. This table contains parameters which are
used to create a Voice connection and configure the channel."
--DEFAULT test-function test_voendpttable
--DEFAULT next-function next_voendpttable
--DEFAULT get-function get_voendpttable_%t
--DEFAULT view-mask IPX_VIEW
::= { switchConnection 13 }
voiceEndptEntry OBJECT-TYPE
SYNTAX VoiceEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "An entry in the voice Endpoint Channel Connection table."
DESCRIPTION "Specifies whether the user would like to collect TFTP
statistics for the connection. If the user value is 'enable' then any configured
TFTP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the TFTP channel statistics
configuration. "
::= { voiceEndptEntry 30 }
voiceEndptSnmpStats OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Specifies whether the user would like to collect SNMP
statistics for the connection. If the user value is 'enable' then
SNMP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the SNMP channel statistics
configuration. "
::= { voiceEndptEntry 31 }
dataEndptTable
New object s
Two new objects, dataEndptTftpStats and dataEndptSnmpStats, have been added to the dataEndptTable. These objects allow you to enable or disable TFTP and SNMP statistics on data connections.
dataEndptTable OBJECT-TYPE
SYNTAX SEQUENCE OF DataEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The data End-Point table."
--DEFAULT test-function test_dataendpttable
--DEFAULT next-function next_dataendpttable
--DEFAULT get-function get_dataendpttable_%t
--DEFAULT view-mask IPX_VIEW
::= { switchConnection 17 }
dataEndptEntry OBJECT-TYPE
SYNTAX DataEndptEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "An entry in the data End-point table."
DESCRIPTION "Specifies whether the user would like to collect TFTP
statistics for the connection. If the user value is 'enable' then any configured
TFTP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the TFTP channel statistics
configuration. "
::= { dataEndptEntry 29 }
dataEndptTftpStats OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Specifies whether the user would like to collect SNMP
statistics for the connection. If the user value is 'enable' then
SNMP channel statistics will be enabled for the connection. If the user value
is 'disable' then the connection will ignore the SNMP channel statistics
configuration. "
::= { dataEndptEntry 30 }
rsrcPartiVsiBwOverbooking OBJECT-TYPE
SYNTAX INTEGER {
enable(1),
disable(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "This object is used to indicate what bandwidth a partition should advertise to a controller. If Enabled a partition advertises VI Rate and PNNI connections on that VSI partion can have a PCR upto the VI Rate. If disabled the partition advertises the VSI Max bandwidth and PNNI connections on that VSI partition can have a PCR upto the VSI Max bandwidth. The default is disabled."
--DEFAULT view-mask BPX_VIEW
::= { rsrcPartiEntry 14 }
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 4 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 5 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 6 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 and 9.4 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 or 9.3 to 9.4. 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. M.F.E 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 7 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:
chan allocation inconsistency between BPX and SES.
Condition:
Have only 1 part. first (Max. lcn > Min.),add conns. > min..Add more parts such that sum(Min.s)>Max(max.).
Workaround:
None
Yes
Anomalies Fixed in MFX
Table 8 Anomalies Fixed in MFX
Bug ID
Description
CSCdw16017
Symptom: Traffic is only seen on the ingress of the master and slave nodes.
Condition: 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. Up-ing 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 just 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 will occur with firmware MFW or lower revision.
Workaround:
None.
CSCdx50089
Symptom:
ILMI did not update its neighbour's IP address and IfName to be "N/A", when its physical link on which it was running went down. dspnebdisc would show the previous neighbour's 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.
Condition:
1.Single/Multiple partitions on a interface enabled.
2.The bandwidth common pool of this interface is zero.
3.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:
When configure the mutiple 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 operstatus 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 signalling type (NNI or UNI) in SES, the operstatus of interface is shown as UP.
With BXM Image MFW or prior.
Workaround:
Configure signalling 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 MGX8220 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 conenction) If the problem is on the slave end need to delete and readd the connection
CSCin33357
Symptom:
After burn MFW image, the BXM enhanced card went to resetting.
Conditions:
BXME card with stats lvl 0 and VSI connections.
Workaround:
Don't use stats lvl 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 trunkparm 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 stats counters have been added. The detail description about the new created stats and associated CLI cmd and MIB 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 stats.
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: addtrunk 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 ABT Release
Introduction
UXM ABT is Model-B firmware release for UXM card on IGX. Firmware is the same for UXM and UXM-E cards.
New Features
UXM trunk and line loopback.
Obsolete Features
None.
Compatibility
1. Software
ABT is compatible with Switch Software Release 9.3.30 or later.
2. Hardware
ABT is compatible with URM and UXM-E hardware of all models.
Anomalies Resolved in ABT
The following table list the resolved anomalies in firmware ABT.
Bug ID
Description
CSCdu66836
Switchyred fails an IMA trk momentarily and then clears failure.
CSCdv73321
UXM fails RCMP SRAM Parity Test.
CSCdv91482
ACR is only 7 and traffic loss when trk vc shaping enabled for UBR.
CSCdw02669
UXM constantly fails when remote IMA configured for ITC.
CSCdw03819
On loc or rmt lpbk on uxm, IMA feeder trk to clear & fail state.
CSCdw04142
Traffic being leaked to remote end while loc lp exists on IMA feeder trks.
CSCdw08662
ACR is MCR when trk vc shaping is enabled for ABR conn.
CSCdw14895
Adding trunk on UXM Y-Red failed with error message Loop Back Detected.
CSCdw32804
Remaining IMA config in 1xT1 trunk. Ima not cleaned up.
CSCdw62198
Ubr does not tag all the cells to clp 1.
CSCdw78656
VT failure update takes long time - upto 6 secs.
CSCdw86157
UXM QE locks up causing 103s, frozen pvcs.
CSCdx02932
Looped PVC (abrstd with VSVD) on UXM IGX.
CSCdx30234
Improper use of timer in Cmi message handler.
CSCdx48613
Y-RED IMA TK cannot back to OK status after del TK remote loop back.
CSCin04753
Selftest failure on UXM card.
Upgrade Instructions
Update boot code to boot 09 before upgrading to ABT.
Caution This upgrade must be completed before upgrading to ABT.
Boot Code Requirements
None for the ABT release.
Boot code revision boot_09 of ABS release is the same for ABT release.
Unsupported Configuration or Applications
None.
Firmware Filenames and Sizes
ABT Firmware Boot Code
Filenames
Size (bytes)
ABT.000-ABT.017
65536
ABT.018
58074
ABT.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
DESCRIPTION:
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
DESCRIPTION:
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.4.00.
2. Hardware
XBC firmware is compatible with URM hardware.
Resolved Bugs
CSCin39677
DESCRIPTION:
After changing the Max and Min LCNs of VSI partition using cnfrsrc, SWerr:5050 was logged when "cba_verify" command was executed
SYMPTOM:
SWERR:5050 was logged when cba_verify command was executed.
FREQUENCY:
Always
WORKAROUND:
None
SOLUTION:
XBC resolves this.
CSCdz48550 - addloclp causes alarm or continuity problems on ATM connection
DESCRIPTION:
When addloclp is done on VBR/UBR/CBR type of ATM connections, the slot goes into alarm.
When the same is done for ABR connection with FBTC and then local loop is deleted by dellp then the traffic does not passes to other end.
SYMPTOM:
Adding a local loop (addloclp) to a connection will cause "QBIN: Ingress Cells discarded" on CBR, RT-VBR, and NRT-VBR connections. The count will continue to increment while traffic is flowing from the CPE and the loop is up. This will trigger an alarm for the slot of the UXM. The count stops incrementing when the loop is deleted. For ABRFST connections, addloclp will not cause the alarm but when the loop is deleted, traffic does not flow through the connection normally.
FREQUENCY:
Always
WORKAROUND:
1. For CBR, NRT-VBR, and RT-VBR delete loop and use clrcdstats to clear counter.
2. For ABR connections do not use the FBTC option unless you are running frame based AAL5 traffic.
SOLUTION:
XBC resolves this.
CSCin21211
DESCRIPTION:
For all rsh commands, Lines were truncated beyond 80 characters.
SYMPTOM:
The Information beyond 80 characters per line was missing in the output of the "dsprtrlog".
FREQUENCY:
Always
WORKAROUND:
None
SOLUTION:
XBC has fix for this
CSCin21212
DESCRIPTION:
"-MORE" is attached to the end of the "dsprtrlog" response even though there is no more data to view.
SYMPTOM:
Even though the message could carry up to 1k of data, the URM admin f/w was not sending full 1k of data in one message for "dsprtrlog" command instead it was sending 1k of data in 2- messages by attaching -MORE to the end of 1st message.
FREQUENCY:
Every time when the "dsprtrlog" response was exactly 1k
WORKAROUND:
Use "rsh <urm-slot> m "to view the remaining data of the message.
SOLUTION:
XBC has a fix for this.
CSCin15267
DESCRIPTION:
DUART hangs up when there is heavy interrupts (Rx & Tx) from both the channels simultaneously.
SYMPTOM:
The URM stops responding to the IOS CLI command from IGX CLI
FREQUENCY:
Intermittent
WORKAROUND:
Reset the card.
SOLUTION:
XBC resolves this.
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 XBC.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 monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Registered Cisco.com users can order the Documentation CD-ROM (product number DOC-CONDOCCD=) through the online Subscription Store:
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 your comments by mail by using the response card 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 levels of support are available: the Cisco TAC website and the Cisco TAC Escalation Center. The avenue 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.
Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Cisco TAC Website
You can use the Cisco TAC website to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC 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 through the Cisco TAC website so that you can describe the situation in your own words 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 level of 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 monthly periodical that provides industry professionals with the latest information about the field of networking. You can access Packet magazine at this URL:
iQ Magazine is the Cisco monthly periodical that provides business leaders and decision makers with the latest information about the networking industry. You can access iQ Magazine at this URL:
Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in the design, development, and operation of 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 Breakthrough, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN 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, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, 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. (0301R)
