9.1.18 Version Software Release Notes
Cisco WAN Switching System Software

CSCdk48816

Symptom:

There is no UAS alarming. Spec requires that when we have more than 10 consecutive SES then we should enter UAS. Because this is currently not implemented, no UAS alarm is generated in this situation.

Conditions:

This requires that both firmware and switch software fixes to the following bugs must be present to fix this problem.

CSCdk48827 - Firmware bug to fix the thresholds for SES to kick in. This is fixed in firmware image BXMMCB or later images. CSCdk48816 - The software portion of this problem to alarm based on UAS. Without the software fix to this bug, customer cannot upgrade firmware beyond MBY because when we enter UAS, per specification, we stop counting Bip8 ES and SES - as such we will not have alarming on ES as well as no alarming on SES. MBY provides a temporary fix to keep the ES alarming on by raising this threshold.

Workaround:

Work around is to continue to use MBY which will prevent SES alarming to kick in. The side effect is that this will prevent the customer from using the features introduced in the MC firmware.

CSCdk50441

Symptom:

The connection between ASI-155 and AUSM ATM VC with VPI 16 or higher at ASI-155 port do not pass ATM cell.

Workaround:

None

CSCdk55887

Symptom:

dspport command not available to level 6 user ids.

Conditions:

After upgrade from 7.x software to 8.1+ software.

Workaround:

Increase user privilege.

Further Problem Description:

The privileged level of the dspport command was changed in release 8.1 to level 2 from level 6. This difference was first noticed by off-site user after upgrade from 7.4 to 8.5.05.

User who running 8.x.x software hasn't noticed this difference until opening of this problem.

CSCdk73104

Symptom:

Error 105 is logged for standby ASI T3 card. The function code is 01 (CRD_UP).

Conditions:

When active BCC's are reset in a network one after another in one minute interval. Switch software revision is 9.1ak.

Workaround:

None

CSCdk73308

Symptom:

Software errors 379 and 614 logged after node rebuild.

Conditions:

Node rebuild was executed on this node within one minute of doing the same of neighboring node.

Workaround:

Avoid resetting the node repeatedly within short interval of time.

CSCdk79654

Symptom:

Connections on AUSM does not pass VCI >4095

Conditions:

In the AUSM-8T1/E1 VPC connection, the VCI range of user side is limited from 0 to 4095. For example, If customer equipment send cells with VCI # 5095 via VP connection, the remote end AUSM port deliver the cell with VCI # 1000. (That means our system process the VCI value only with 12 bit) When the Dacom sell VP connection service to user, they can not restrict the VCI value of network user. The standard says it range from 0 to 65535(16bit).

Workaround:

Currently no workaround available.

CSCdk81940

Symptom:

In 9.1.03 IGX, BPX setup. Feeder traps from IGX:UVM card like "LN x.x Activated; LN x.x Deactivated" as forwarded by gateway occasionally has the gateway name used instead of the feeder name.

Conditions:

Cisco Wan manager 9.1.05, switch software 9.1.03, BPX as gateway, IGX:UVM setup with upln, dnln command to trigger event log be forward by BPX

Workaround:

The event log from BPX might indicate the feeder note has trap send when this happens.

Further Problem Description:

The problem happens occasionally. There is no reliable way to reproduce it.

CSCdk88998

Symptom:

Software error 21 (BAD_CMD) is logged on BXM port or trunk card if switchyred command is performed on the card prior to the configuration being programmed on the standby card.

Conditions:

If switchyred command is invoked prior to the standby card being programmed, several software error 21 are logged.

This may impact data continuity depending on which commands are being rejected by the BXM firmware.

Workaround:

Before invoking switchyred command, verify that the standby card is already programmed and does not show "PRGRM" on the status line of dspcd screen.

CSCdk89386

Symptom:

Line integrated alarm may be cleared and re-declared after switchyred is invoked.

Conditions:

On BXM line card, if the switchyred command is invoked, the line which is currently in LOS will be cleared and re-intergrated.

If there are connections terminated on this line and LMI is enabled, the remote endpoint A-bit status will also toggle.

There is no data loss. The A-bit alarm is temporary toggle for the duration of alarm integration.

Workaround:

None

CSCdk93674

Symptom:

Not seeing same errors on both ends

Conditions:

Line code errors were reported on 8.4.21 node end while the 9.1.00p version with exact same configuration and stats enable is not seeing these errors.

Workaround:

None

CSCdm02185

Symptom:

Connections are deleted by the VNS and these are deleted at the owner end but remain at the remote end.

Conditions:

Customer has a network of IGX's with VNS. Most of the connections are created by the VNS. Switch software is 9.1.03

Workaround:

A switchcc will delete the connection fully.

CSCdm06789

Symptom:

In releases 8.1 and later, use of the ACO button will not keep the same alarm from being regularly reported.

Conditions:

An alarm occurs in the system with the switch configured to use the external alarm device (buzzer/light).

Workaround:

Clear the alarming condition.

CSCdm07546

Symptom:

Users deleted with deluser are not completely deleted.

Conditions:

The delete user operation is not processed correctly by the standby CC. While the user will be deleted on the active CC the user is not deleted on the standby CC. When the standby CC becomes active the user will return.

Workaround:

1. Reset the standby CC on every node in the network following a deluser command.

2. If the user is being deleted for security reasons, use cnfpwd to change the password of the user as an alternative.

3. If the maximum number of users(64) is allocated, a deluser command followed by an adduser will cause the new user to take the place of the deleted user on the active and standby CC. Dummy users may be added to reach 64 users.

CSCdm09094

Symptom:

BPX dsplogcd 111 <slot> may cause an 1M3 abort on some BXM-T3 backcards.

Conditions:

This problem may happen when you perform dsplogcd 111 against some BXM-T3 backcards. Not dependent on other conditions.

Workaround:

Replace the BXM-T3 backcard

Further Problem Description:

It is reported that 1M3 abort occurs every time when they execute dsplogcd. As a result of troubleshooting, it is found that the abort seems to occur on specific backcard its port number was changed from 12 to 8 by cnfbkcd once and turned back to 12 port by cnfbkcd again.

CSCdm10213

Symptom:

After upgrading from to 9.1 or a switchcc in 9.1, there is some connection database corruption. You can dspcon on one end but dspcon on the other end shows the connection does not exist. dspchstats on one end ok but the other end shows the connection does not exist.

Cards previously without connections, may have new connections.

Conditions:

The active CC has conns to a remote node. After a switchcc extra connections appear. These connections appear on a slot which matches to remote node's slot number.

There is an extra logical endpoint for the connection. dcct of the connection shows the OE LCN non-zero, even though the connection actually terminates on another node. The OE LCN field should be set to a non-zero value only for dax conns. This is a side affect of CSCdk78681 where the LCN and OE LCN fields are not initialized during an addcon.

N/A

Workaround:

Identify the original valid connections. Examine dcct of these connections. For Voice and data: LCN and OE_LCN values are non-zero. For Frame relay: Only the OE LCN is non-zero but the conn is not a dax conn Delete these connections. Reset the standby CC. VT to the standby CC. Verify that all the valid and duplicate conns are gone. Switchcc. Re-add the valid connections.

Or

For Voice and data conns: Patch the LCN and OE_LCN to 0 For Inter-node frame relay conns: Patch ONLY the OE_LCN to 0. Reset the standby cc. VT to the standby cc. Verify that the LCNs are 0 and no extra conns exist.

Or On nodes with 9.1.11 and higher ONLY:

Execute rbldlogepdb on the processor card which has the extra logical endpoints. Examine dspcons, the extra conns should disappear. Examine dcct, the OE LCN should be set to 0. This command needs to be executed on the active and standby cc separately. For voice and data conns where both the LCN and OE LCN need to be 0, delete and re-add the conns.

CSCdm13655

Symptom:

Customer cannot free up any VCPARMS from the VCPARMS table (limit of 255 has been reached). We tried reconfiguring connections to make them join an existing VCPARMS index, but we cannot match the parameters successfully.

Conditions:

Only Frame relay connections are affected. Connections on UFM Model A have variable configurations for VCq and ECN threshold. This causes use of different VCPARMS entries.

Workaround:

cnfcon from both ends of connection, cnfcon *... from both ends.

Or

delete and re-add the connection.

Further Problem Description:

9.1.06 has two defects CSCdk83358 fixed in 9.1.07 and CSCdk63187 fixed in 9.1.10 both dealing with the modification of VC queues. As a result the VCPARMs indices are not reused. Furthermore UFM model A has altered VCq and ECN thresholds creating new profiles. UFM model B firmware will allow reconfiguring the queues to FRM values.

CSCdm17824

Symptom:

Software error 9082. This bug complains about 2 situations: - Sending objects x74 and x75 to physical trunks - Sending ABIT or AIS on a channel which has not been configured yet

Conditions:

The first of the two problems is a 9.2 specific problem and has been corrected in all released versions of 9.2 software. The second may happen during rebuilds or switchcc's.

Workaround:

No workaround necessary. There is no side effect.

CSCdm22241

Symptom:

Using the 'dspchstats' on a BXM there are missing value's

Condition:

During 9.1.08 system software testing the lab personnel discovered that the BXM statistics usually recorded in an enhancement in switch software 8.4.09 has been removed.

Workaround:

None

CSCdm26290

Symptom:

CBR/VBR/ABR connections may discard traffic when reconfigure as UBR connections on BPX.

Condition:

If an ATM connection (configured as ABR, VBR or CBR) is added across a BPX (BXM only) network, with an end loop, and then deleted and re-added, with the same VPI/VCI end points, as a UBR connection, traffic will not pass on return loop. Cells will pass from port to network at BPX1 and onto BPX2 and out the far end port. When they return from the loop they will pass from port to network at BPX2 but they are then discarded at BPX1 and show up as Rx CLP 0+1 and Rx CLP0 discards using dspchstats at the network side.

BPX1 BPX2

tester--STM1--(BXM--BXM)----STM1----(BXM--BXM)----STM1--loop

Workaround:

The workaround to make the connection work correctly is to disable FBTC then reset the card (a reset alone does not work).

CSCdm26317

Symptom:

Port based traffic shaping on CBR connections on BXMs may require the PCR to be set at approx 500cps higher than the actual data stream to avoid discards at egress. This appears to be a traffic shaping granularity issue.

Workaround:

None

CSCdm31518

Symptom:

After performing a software upgrade on a node, the node rebuilds after the loadrev of the new release is executed. After the rebuild, the card that was active is failed. The detailed card display shows the failure reason as 'Flash EEPROM Program Failure'.

Conditions:

Flash EEPROM failure after using loadrev to program the upgraded version of software in flash memory.

Workaround:

Use the standby control card unlocking procedure that specifies a dummy revision name for the first loadrev. The unlocking procedure is to accommodate flash failures during the unlocking process. The procedure is part of most upgrade procedures, but was omitted from this customer's upgrade.

CSCdm36041

Symptom:

When a backcard to an active BCC is removed or inserted, no entry is logged into the event log. When the backcard to a standby BCC is removed or inserted, an entry is logged into the event log.

Workaround:

None

CSCdm39088

Symptom:

A trunk that was previously configured to support voice connections was reconfigured to not support them. Following a reroute the connections were rerouted over the trunk.

Additional Information:

No cause was found for the issue and the connection data base setting may have been the source of the problem.

Workaround:

Prefer route the connections.

CSCdm40707

Symptom:

Software error 4229 logged.

Condition:

switchcc was performed on a BPX having connections. The BPX was previously upgraded from rel 9.1.09 and the connection (due to which the error was logged) was added in release 9.1.09.

Workaround:

None

CSCdm42254

Symptom:

When a user ID is deleted from the user database, subsequent users are shifted and use of the same privilege level as the immediately following user.

Conditions:

Customer network at 9.1.09 where issue was discovered. Lab network at 9.1.09, 9.1.10, and 9.2.00 with problem. Not observed in lab environment at 8.4.21.

Workaround:

In order to prevent the shifting, a dummy user ID needs to be created any time an existing user ID is deleted. The dummy ID will fill the spot vacated by the deleted user ID and user IDs below the deletion will shift back to their normal positions.

If the database has had multiple adds and deletes prior to this issue being observed, it may be required to add dummy users until there are maximum entries.

It is recommended that the default password be changed for these dummy users.

CSCdm42912

Symptom:

SNMP Proxy Agent fails on SET of PrefRoute with 10 hops. Switch rejects.

Condition:

When configuring a prefer route of 10 hops using CWM Service Agent, the request failed will error message that the "Route contains too many hops for its connection type (9). Same request works from the CLI of node.

Workaround:

None

CSCdm45750

Symptom:

Node keeps aborting 3000000.

Conditions:

While upgrading to 9.1.09

Workaround:

None

CSCdm50659

Symptom:

Trunk alarms are not generated when random bit errors are injected onto a trunk using an Adtech Sx14 test set at a rate of 10E-3. There are trunk statistics generated but no trunk alarm because the statistics that cause alarms on do not meet the threshold for MAJOR or MINOR alarms.

Conditions:

This was generated in a lab environment with test equipment that was set to inject bit errors randomly through the entire bandwidth. Some HCS errors were generated as well as Path unavailable and Path Far End unavailable.

Workaround:

Lowering the alarm threshold for MAJOR and MINOR HCS errors can help to generate a trunk alarm. Use the cnflnalm command and modify the HCS error alarm thresholds to .01 for MAJOR and .0001 for MINOR. These thresholds are as low as they can be set currently.

CSCdm53734

Symptom:

When provisioning a Virtual Trunk, the tstdelay command failed. The specific cause of this Virtual Trunk was not determined. Other Virtual Trunks were added and carried traffic successfully.

Workaround:

None known at this time.

CSCdm54534

Symptom:

ATM Port LMI/ILMI failure not reflected to A-bit on UXM-UFM SIW DAX connection

Conditions:

UXM-UFM SIW Local connections

Workaround:

dncon/upcon or probably other operations whatever else which changes the connection status.

CSCdm54631

Symptom:

IGX node with 9.1.11 switch software had multiple connections that couldn't be deleted, were associated with NTM logical endpoints, and had only one endpoint in the network. The connections were cleaned up by switchcc, rbldlogepdb, and patching memory.

Workaround:

None

CSCdm60702

Symptom:

When a bus error occurs on a node, and a rebuild results, other nodes in the network will see the rebuilding node in the degraded state. This shows up as "UNDeg" in the dspnds screen. A log message will also appear on these other nodes indicating that the rebuilding node went unreachable due to degradation. The unreachability will recover automatically.

Conditions:

Only occurs if a node rebuilds due to a bus error, and degraded mode is enabled in cnfnodeparm. Will not occur if a node switches processors due to a bus error.

Workaround:

No workaround needed. No adverse effects.

CSCdm60707

Symptom:

Can take longer than expected to clear unreachability with a node that has rebuilt due to a bus error. Other nodes in the network will declare the node unreachable due to degradation ("UNDeg"). The unreachability will eventually clear automatically.

Conditions:

Only occurs if a node rebuilds due to a bus error, and if degraded mode is enabled in cnfnodeparm on that node.

Workaround:

None needed. Problem clears automatically.

CSCdm63476

Symptom:

Software errors 379 and 614 reported when switchcc in 9.1/9.2 interop network

Condition:

In 9.1/9.2 mixed network, customer performed switchcc and the 9.2 node reported software errors 379/614.

Workaround:

None

CSCdm64127

Symptom:

NPM card goes into update mode repeatedly without operator intervention,

Workaround:

None

CSCdm68934

Symptom:

Inconsistency behavior of virtual trunks

Condition:

When we have more than one virtual trunks from a BNI-BXM pair and we change the Payload scrambling parameter on one of the virtual trunks which is not yet added, This would cause the payload scrambling to change on all the other trunks. This causes Comm. failure on the other trunks, this is an expected behavior and is by design. But when we try to toggle the Payload Scrambling back, it would not result in the restoration of the trunks. They continue to be in Comm failure.

Workaround:

If we delete one of the trunks and delete the PVC used in the virtual trunking and add it back. This would update the database and all the other trunks would come back.

CSCdm69931

Symptom:

When adding Frame Relay connections through Connection Manager, as the sum of the connection speeds reaches the maximum/oversubscription speed of the port, the Connection Manager screen displays a message indicating that the add request failed due to an SNMP agent time out on the IGX node.

While this is happening, the SNMP transactions consume well over 85% of CPU time. IDLE drops to zero and the CLI becomes extremely sluggish. The SNMP process is a low priority process so critical high priority processes are still running.

Conditions:

This issue as observed/tested in 9.1.12 only.

Workaround:

Make sure the sum of the connections speeds of all connections on the port are less than the maximum speed of the port.

CSCdm70092

Symptom:

BXM card errors reported during multiple node rebuilds.

Conditions:

The network is running in mixed 9.1.09/9.2.10. After did node rebuilds to several nodes, the BXM that running M.C.C. firmware and switch software 9.1.09 reported card error.

Workaround:

None

CSCdm71785

Symptom:

When we add a line (upln) on the BME card on switch software 9.1.15, software errors 319 and 524 are logged.

Workaround:

None

CSCdm72249

Symptom:

BPX node with BCC-3 revision DMM does not use configured clksrcs but internal oscillator

Workaround:

None

CSCdm72409

Symptom:

dspcons does not show all the existing connections.

Condition:

When we issue the command dspcons slot.port, and if that port has connections which have a VPI of "0" they would not be listed.

Workaround:

dspcons slot.port.0.0 would show all the conns present.

CSCdm72910

Symptom:

BPX reported 2000000 Abort

Conditions:

Running switch software 9.1.09

Workaround:

None

CSCdm73026

Symptom:

IGX with 2 UXM T1-IMA trunks, if one goes down the TDM TIMEPLEX connections on the UVM's deteriorate due to bursty frame relay connections.

Conditions:

If bursty frame relay connections are re-routed off the T1-IMA trunk - the TIMEPLEX restores to VERY GOOD condition.

Workaround:

Possibly try to either re-route the frame relay connections or to lower PIR, QIR and port speed for the frame relay connections.

Further Problem Description:

IGX with 9.1.09 software. UXM model A firmware. UVM model E firmware. SCM is latest AX.

CSCdm73220

Symptom:

Virtual trunks which use BXM-E cards and Virtual trunk Wrap around drop cells

and there is no traffic continuity on the trunk.

Workaround:

Virtual trunk wrap around works ok with BXM cards (Normal BXM cards).

CSCdm74724

Symptom:

2M abort on BPX

Conditions:

Running 9.1.09 switch software

Workaround:

None

CSCdm78174

Symptom:

The Card is Reset when a trunk on the BXM-E card is deleted. This causes the

all the other trunks on that card to go down temporarily. This also results in the

reroute of all the conns going through the trunk.

Workaround:

None

CSCdm81954

Symptom:

swlog 103 causes a UXM card and all the connections on that card to fail.

Workaround:

None

CSCdm83131

Symptom:

When we have a multi-layer multicast setup using BME cards, tstdelay on the conns from the second layer BME to any other card fails. This happens with conns using VPI or VCI of "0".

Workaround:

In most of the cases we have seen only tstdelay fails. i.e. there is no traffic

disruption. but there are cases where traffic was disrupted.

CSCdm68968

Symptom:

The problem is related to the VCQ Depth setting that stays at its default value (65535) even if we change it.

Conditions:

This scenario happens only if we add the connection between a routing and a feeder node (IGX).

Workaround:

None

Further Problem Description:

Unable to change vc_q value of ATFR connection but able to change for FR connections.

CSCdm75577

Symptom:

Traffic gets 100% discarded when connection is added through CWM with IGX as master. The connection is between UFM-C on IGX to BXM on BPX.

Conditions:

Connection is added through CWM with IGX as master.

Workaround:

(1) Add the connection through CLI from IGX/BPX side.

(2) Add the connection through CWM with BPX as MASTER.

(3) For existing NON-WORKING connections: DO THE FOLLOWING THREE STEPS ON BPX

Step1: Using cnfcon configure the Vc_Q value ALONE to some value DIFFERENT from the current value (on BPX).

Step2: Again using cnfcon configure the Vc_Q value ALONE to original Value (on BPX).

Repeat the above two steps for all the connections.

Step3: Now reset BXM card on BPX (CMD: resetcd <BXM_SLOT_NUM> h)

CSCdp06751

Symptom:

The switch may abort with 1M3 if a UXM is reset.

Conditions:

The switch may abort if the UXM which is reset is configured as a trunk card with trunk connections on it.

Workaround:

Before resetting the UXM card reroute the trunks away from the card so that the UXM card does not have any trunk connections on it. Please note that this workaround may not work the second time the UXM card is reset if the workaround was not applied the first time the card was reset.

CSCdp15350

Symptom:

SNMP GET-NEXT does not work on frLportStatTable, SNMP GET on the elements in the table works.

Conditions:

Normal Conditions

Workaround:

Use SNMP-GET to access this table.

Further Problem Description:

The SNMP AGENT for this table frLportStatTable is not responding correctly to SNMP GET-NEXT Requests.

CSCdp20486

Symptom:

- UXM physical line alarms are not sent to the CWM maintenance log, but they are logged in the node's local event log.

- If the node terminating an IMA trunk is a CWM gateway node, the alarm is logged in the CWM maintenance log for the gateway node only.

Conditions:

- IGX node using UXM IMA T1/E1 trunks - Physical line failure condition occurs

Workaround:

None

CSCdj57458

Symptom:

A user with privilege level SuperUser cannot execute the "dspqs" command. The user has to be of privilege level StrataCom or Service to execute the "dspqs" command.

Conditions:

Ensuring that there are no standby database updates pending is an important step in executing a graceful switchcc. One can determine this fact through the "dspqs" command.

Workaround:

Login with a privilege level higher than SuperUser.

CSCdj79112

Symptom:

Unable to add a PVC on a BXM card at less than 50cps/19.2kbps.

Conditions:

The current BXM has a limit for smallest SCR/CIR, not allowing a PVC to have a SCR/CIR less than 50cps/19.2kbps with policing. The system software was restricting SCR/PIR to no lower than 50 CPS (where 6 CPS could be supported).

This Command: addcon 9.3.44.444 node name 9.2.44.444 abrfst 40

PCR(0+1) value out of range (local end). Valid range 50 - 96000. PCR(0+1) [50/50]:

Workaround:

None

CSCdk55034

Symptom:

BIP8 errors are received at 10E-3 and the line/trunk is in MINOR alarm. The line/trunk MAJOR alarm threshold is configured at 10E-3 (cnflnalm command).

Condition:

When BIP8 errors are received on an E3 line or trunk at a rate of 10E-3, the line or trunk will not go into a MAJOR alarm state. The line/trunk will instead go into a MINOR alarm.

Workaround:

Change the MAJOR alarm threshold for BIP8 to 10E-4 using the cnflnalm command.

CSCdk76438

Symptom:

Software error 319 is logged on BPX node.

Conditions:

The above software error may be logged on a BPX node. This condition may occur on a BXM y-red pair and the active card is the secondary card.

A function is called using the physical card slot instead of the logical card slot when retrieving information from logical database.

Work around:

Switch back to the primary card if possible.

CSCdk93423

Symptom:

Extra connection statistics are reported in statistics file, or the Cisco WAN Manager rejects the statistics file indicating that it is corrupted.

Conditions:

This problem will occur when the user has an access device configured that is supporting connection other than the voice connections, and the Cisco WAN Manager's Statistics Collection Manager has statistics of the subtypes FastPAD Voice, FastPAD Switched Voice, FastPAD Data, or FastPAD Frame Relay enabled.

Work around:

Do not enable statistics for the subtypes listed above when there are access devices other than FastPADs configured in the network.

CSCdk93924

Symptom:

When SNMP SET was used to add a voice/data connection with an invalid channel number, switch software might take it to program the card. Software error or something else might happen.

Conditions:

Add voice/data connection from SNMP

Workaround:

Make sure the channel number is valid before addcon from SNMP

CSCdm05301

Symptom:

After issuing the command dspstatsinfo and progressing to the 5th screen, the UI locks up. After approximately 14 minutes, the node logs a software error 52 and if a secondary CC is available, it switched over. If no secondary CC is available, a full rebuild is done.

Conditions:

This requires specific conditions to occur.

1) A BXM feeder trunk must be added.

2) Any line card with lines up must exist in slots smaller than the BXM feeder trunk slot. (i.e BXM feeder trunk at 12.12, then an active line card must be in slot 1-11.)

3) The logical trunk number of the BXM feeder trunk, must correspond to the logical line number of one of the lines in the earlier slots.

The logical trunk number can be obtained with the service level command dsplogtrk.

Then invoke the command dln using the logical trunk number as the logical line number index.

The resulting screen will indicate if this logical lines slot is earlier than the trunk's slot.

EXAMPLE:

BXM Feeder trunk at slot 12.1.

A dsplogtrk 12.1 indicates the logical trunk number is 2.

A dln 2 indicates the corresponding slot is 3.

Slot 3 is less than slot 12, this configuration will cause a watch dog timeout (software error 52) and rebuild, or switch-over, if dspstatsinfo's 5th screen is displayed.

Workaround:

If the node has this configuration, do not use the debug command dspstatsinfo. But must inform all SE's or engineers working on the node of this limitation, as it is becoming a common and useful command.

Further description:

The BXM can act as either a trunk card or a line card. A code segment in dspstatsinfo does not have the proper intelligence to distinguish if it is in line card mode or trunk card mode and is treating the corresponding logical trunk as a logical line and resets loop variables under the explained configuration. The loops exit value is therefore never received and the loop continues infinitely.

CSCdm05502

Symptom:

Parm 8 and parm 9 for echo convergence time and double talk detection should be made user configurable to be in sync with UVM FW change.

Conditions:

Command Line Interface change.

Workaround:

None

CSCdm12055

Symptom:

A software error 586 appears in the software error log. The event log shows that the standby was updated.

Conditions:

This software can occur on an IGX switch that has a redundant processor card and a large number of trunk failures or node alarm state changes occur in the network. This was observed during tests, by failing all trunks in a network, except for one which allows the network to remain reachable. The test network had roughly 100+ trunks, where many of them where IMA trunks supported by 8 physical lines.

The problem has been observed in the field when a node goes unreachable, causing other nodes (roughly 130) to transition from the clear alarm state to the minor alarm state. This condition can be easily detected by comparing the software error 586 time stamp with the "Minor Comm Break" event log time stamp.

Workaround:

Increase the amount of memory allowed for standby updates via the command "cnfnodeparm", specifically for the option "Max Mem on Stby Q (%)". The default is to allow up to 33% of the total dynamic memory for standby update queuing.

Note that this mechanism was put in place to ensure that we do not get into a situation where we have used up all of the dynamic memory for standby queuing, thereby causing a memory resource failure that would lead to memory errors such as software errors 3000000, 501 or even abort 3000000.

In the field the standby queue memory has been increased from 33% to 50% without other memory problems on an NPM with 32 Meg. RAM. The dspqs screen should be cleared and monitored to determine the queue utilization after the change.

If the overflow is due to updates when a node transitions from clear to minor alarm, the updates can be reduced by forcing all nodes to be in minor alarm. Networks which have a large number of nodes in minor alarm due to port comm. failures will not have as many node alarm state changes when a node becomes unreachable.

CSCdm16904

Symptom:

Processor card repeatedly sends message 0x52 to the UXM card for all the dax connections.

Condition:

DAX connections are added on an IGX node, with % Util less than 100. Switchover is performed.

Workaround:

DAX connections cannot have %Util less than 100. Do not add DAX connections with %Util less than 100.

CSCdm19532

Symptom:

ABIT alarm not propagated through network after changing from NNI to UNI port.

Conditions:

Changing the port from a NNI to a UNI and connected a router to the UNI port with LMI talking which clears the Failed condition but does not propagate the abit status across the network.

Workaround:

The workaround for the customer is to use UNI and turn LMI off to mask any alarms and then turn it back on.

CSCdm22252
CSCdp37572

Symptom:

The addcon command fails to display connection being added until after the user add confirmation is done.

Condition:

When performing the 'addcon' command there was no display of the connection being added.

Workaround

Use the command display line to see what connection is being added and view against the existing connections after the add is confirmed, or, execute 'dspcons' first to see the existing connections.

CSCdm23206

Symptom:

cnfcon gives the following error message: "Extraneous value entered, ignore and continue (y/n)? "

Condition:

cnfcon was given for an ATM non-dax connection, such that all the parameters were entered on the command line at the same time, rather than entering one by one.

Workaround:

None. However the problem is harmless unless you need to give cnfcon in a script file. Just press 'y' and enter the value of the parameter 'Trunk Cell Routing Restrict' if/when prompted. Command would work fine.

CSCdm30359

Symptom:

addcon for a dax path connection fails with error "Local channel unavailable".

Condition:

Tried to add a dax path connection as follows: >addcon a.b.c.* <node_name> x.y.z.* Where a connection such as x.y.c.d already existed where c is not equal to z and d can have any value.

Workaround:

delete the connection x.y.c.d if possible or change the vpi of a.b.c.* to a value say 'n' such that connection x.y.n.d does not exist, where 'd' could be any number.

CSCdm32384

Symptom:

Comm. fail or no continuity on connections after switchcc or hitless rebuild.

Condition:

The comm. fail happens because a blind channel LCN was re-allocated to a routing channel on a BXM card when the node is in switchcc or hitless rebuild mode. BXM routing channel rebuild is done a little later after local rebuild is done which leaves a window of possible LCN re-allocation and may cause either comm. fail or no continuity on connections.

Workaround:

Avoid rerouting or adding connections while the node is in switchcc or hitless rebuild.

CSCdm37802

Symptom:

Software error 706 logged.

Conditions:

This problem occured when HDM fails the self test continuously due to the bad hardware.

Workaround:

Disable the HDM's selftest by the cnftstparm command.

CSCdm38190

Symptom:

Not enough information is logged on the software error stack when a software error 514, 506 or 502 is logged.

Condition:

These software errors should never happen. They are defects. However, if they do happen, pushing more information onto the software error stack would aid in debugging these problems.

Impact:

There is no direct impact. This defect would improve the information pushed on the software error stat when one of the above mentioned software errors occured, which could then improve the resolution time for these problems.

Workaround:

None

CSCdm39227

Symptom:

CAC allows oversubscription

Conditions:

Any environment

Workaround:

None

CSCdm39836

Problem:

Whenever NMS like Cisco view inquires about UXM back card and whenever we have E1 backcard with BNC type of connectors, we send uaiE1 as enumerated value. Now, NMS inquires about port and finally get as DB-15 as connector type. If we have BNC type of connector, we end up in giving wrong back card - connector info to NMS.

Condition:

UXM with E1 back card and BNC type of connectors

Solution:

Use CLI to find out type of connector ("dspcd <slot>") or do not reply for SNMP query for UXM with E1 backcard with BNC connectors.

CSCdm41881

Symptom:

Software errors 514, 589 and 502.

Condition:

Under rare circumstances the first fragment of a message did not match the following received fragment causing buffer overwrites.

Workaround:

None

CSCdm44387

Symptom:

Software error 1433 was sometimes logged on the Standby.

Conditions:

When executing command 'dspstbyclk'

Workaround:

None

CSCdm44536

Symptom:

Command "dcdrtbl" causes software errors 532 and 55

Conditions:

This behavior is for BXM and BNI cards

Workaround:

None

CSCdm45263

Symptom:

The remote IGX virtual trunks (except first VT on the port) load is not visible from local BPX through dspload.

Conditions:

"dspload" on BPX.

Workaround:

None

CSCdm45889

Symptom:

Software errors 509 and 101 logged

Conditions:

This occurs when firmware debug command response from the card is processed immediately after the node rebuilds or after a switchover. There is a very remote chance for this error condition to occur.

Workaround:

Avoid issuing rsh command before a switchcc or node rebuild.

CSCdm46537

Symptom:

Addcon is being allowed to oversubscribe the receive bandwidth of the port.

Condition:

Addcon command was given on a port with CAC override disabled.

Workaround:

Manually calculate the available receive bandwidth of the port before adding/configuring a connection.

CSCdm46790

Symptom:

dspswlog has SWERR 501, possible ABORT 3000000 (3M). dspprf r t shows overflows from DYNM region. dspprf m t shows high memory usage in TRNS process. nwstats shows a very high number of received bandwidth updates (fcode 80 has one of the highest message counts).

Conditions:

When the bandwidth for a connection is increased the nodes along the connection path are locked until the process is complete. If there are multiple nodes attempting to increase connection bandwidth at the same time there may be a collision if the connection paths go through the same node. A collision is when a node attempts to lock a node that is already locked. When this occurs, the locked node sends a message saying that it is already locked, and the locking node aborts the lock on all nodes along the connection path. If there are changes that affect adaptive voice connections a node will broadcast a message to abort a lock.

The memory leak occurs whenever a node is locked for a bandwidth change, and receives a message to abort the lock. It is possible that this could happen while bandwidth is changed due to user configuration (frame relay connection configuration) or FAX/modem upgrade, but it is unlikely due to the low rate of change and the low probability that a locked node will receive a second request to lock. The memory leak is most likely to be observed in networks which have PCM, ADPCM, or LDCELP connections, and have adaptive voice enabled (cnfswfunc) because the bandwidth lock abort message is broadcast to all nodes.

Workaround:

1. Use cnfswfunc to disable 'Adaptive Voice'. Switch CC after disabling adaptive voice to free any leaked memory.

2. If adaptive voice cannot be disabled, monitor the network for memory accumulation and switch CC if memory accumulation is observed. Use existing memory accumulation maintenance guidelines to determine when a switch CC should be performed. Existing audit scripts for SW release 8.4.xx will need to be modified for changes to the memory display screens.

Further Problem Description:

The SWSW will be changed to not leak memory when a node which is locked for a bandwidth update change receives a message to abort the bandwidth update lock.

CSCdm53126

Symptom:

User id updates may not stop when one user id is marked with a corrupted password. This can take up bandwidth for control messages.

Workaround:

No easy one. Patch memory of the user id database on the node with the number to clear the corrupted password flags.

CSCdm53182

Symptom:

Two 'Error 923' log entries added to the software error log after entering the dsptrkred command. The data field of the error is 00000000.

Conditions:

dsptrkred command entered on IGX.

Workaround:

The error is a warning that an invalid logical trunk number of 0 was passed to a routine to get the trunk information. In some cases this may indicate a database inconsistency, but in this case it indicates an software loop index that starts with 0 rather than 1.

The error can be ignored, but the swerr log should be cleared after using the dsptrkred command to prevent the log from filling up with 923 errors, which may prevent the recording of important software errors necessary to diagnose more significant problems.

CSCdm53402

Symptom:

nwstats shows many packet CRC errors (thousands)

Impact:

Messages get retransmitted. Usually this does not result in Comm Breaks, only in a slow down of message transmission.

Workaround:

To reduce probability of Comm Breaks increase the number of retransmissions from 7 to 12 (cnfnodeparm 8 12).

CSCdm54599

Symptoms:

This problem is likely to manifest after a switchcc or an upgrade and results in loss of continuity to a large number of connections.

Workarounds:

The best way is to clean up the database manually (change memory) Other things are more drastic and not fool-proof, including deltrk / addtrk, and node rebuild.

CSCdm59268

Symptom:

Node becomes very busy

Condition:

When VAD/LDCELP conn. is added

Workaround:

None

CSCdm60541

Symptom:

Software error 919 was logged.

Condition:

Jobs were running on the node, to reset the card (for which the error was logged) periodically.

Workaround:

None

CSCdm61126

Symptom:

The BPX node reported that the firmware upgrade was completed, but the actual burnt firmware failed.

Condition:

Due to a bad flash, the firmware upgrade aborted. The firmware upgrade can also abort when we try to burn a certain kind of firmware over a very old and incompatible firmware. In such cases the firmware burn would abort but switch software would report incorrectly that the burning of firmware has been completed.

Workaround:

None.

Usually burning of firmware takes 2 - 3 minutes. If swsw reports the burn to be complete within 20 - 30 seconds these are signs that something is wrong. Also there must be no card errors while the burnfw is taking place.

CSCdm63072

Symptom:

Software error 31 and software error 52 (software watchdog abort) logged.

Conditions:

Command addlocrmtlp causes the remote node to abort when the remote end of the connection is a BPX feeder and the connection is a VPC. The local end of the connection may be a BXM or ASI port. The problem only occurs when command addlocrmtlp is initiated from a BPX, i.e. a UXM to BPX feeder VPC connection will not trigger the problem in a mixed network.

Workaround:

1. Use VCC connections for troubleshooting when possible.

2. Make sure a standby BCC in STANDBY state is available on the remote node as an abort/switchover will occur.

CSCdm64066

Symptom:

tstdelay command given for an ATM connection, reports with the message 'State Table Hung'.

Condition:

Test was getting aborted due to some card failure events reported for that card.

Workaround:

None. Interpret the message 'State Table Hung' as 'Test delay aborted'.

CSCdm64380

Symptom:

dsptrkcnf/cnftrk of BNI feeder shown an incorrect PVC. Should be 2027 not 1771.

Conditions:

When bni is configured as a feeder, the algorithm for the PVC calculation is incorrect.

Workaround:

None

CSCdm65181

Symptom:

User can add a connection from remote end (Node1) with vpi, vci values that are used by ILMI/LMI channel for that local node port (Node2).

This can have dangerous effects like, we send data on ILMI/LMI channel and ILMI/LMI channel data comes on data channel.

Condition:

addcon from remote end with vpi, vci values that are used by local port ILMI channel vpi, vci

Workaround:

Do not add connection from remote end with vpi, vci that is used by ILMI/LMI channel of port of local node.

CSCdm66452

Symptom:

tstber in manual mode stops receiving after nearly 1 1/2 hours.

Condition:

When auto tstber also runs at the interval set in cnftstparms for self test.

Workaround:

Disable self test using cnftstparms if you need to run tstber in auto mode continuously.

CSCdm70167

Symptom:

Software errors 900 or 1427 were observed in the network.

Condition:

Node sending messages to Cisco Wan Manager timed out on the application level, while network handler was still sending the message.

Workaround:

None

CSCdm72719

Symptom:

Unable to add BNI VT

Conditions:

BNI VT connected to an ASI cloud port, No shift.

Workaround:

Down the trunk, up some dummy trunks, and try to add the trunk again.

CSCdm77070

Symptom:

1) Even when there is a VPC conn. on an ALM-A card, the line mode is allowed to be changed to VCC.

2) Even when there is a VPC conn. (non -dax) on an ALM-A card, the user is allowed to add a VCC conn. with the same vpi

Condition:

The connection should be non dax connection.

Workaround:

None

CSCdm85764

Symptom:

Software error 2051 is logged every hour when the switch is writing to the TFTP Statistics File.

Conditions:

The problem may be seen on IPX or BPX nodes collecting physical line statistics.

Workaround:

The problem is caused by a TFTP file overhead calculation which fails under certain boundary conditions. Workarounds are as follows:

- Disable collection of physical line statistics

- Enable or disable individual statistics to avoid file overhead calculation boundary condition.

- Enable or disable statistics objects to avoid file overhead calculation boundary condition.

Further Problem Description:

When the overhead was calculated for the TFTP file, the physical line object subtype counts were not included in the calculation. As a result, slightly more file memory could be required than allocated for the file. Under certain boundary conditions, the file size was exceeded, resulting in the logging of the 2051 error.

CSCdm89320

Symptom:

Channels on AXIS have alarms while corresponding connections on BPX are fine.

Conditions:

1. The connection on BPX feeder trunk is local.

2. BPX feeder trunk loses signal and recovers.

3. The conditions do not necessarily lead to the problem.

Workaround:

Delete and add back the connection

CSCdm94587

Symptom:

Software errors 532 and 923 logged

Conditions:

Run deltrk on a downed card

Workaround:

None

CSCdp13454

Symptom:

Replacing active BXM card with BXM-E may show up as mismatch

Condition:

For Port Group (>1), if BXM card is replaced by BXM-E then it shows up as mismatch.

Workaround:

Replace with BXM-E having same number of channels in each port group

CSCdm86633

Symptom:

Poor voice quality (garbled or no voice) for VNS connections may be intermittently observed.

Conditions:

The VNS call (SVC on the IGX/IPX system) is terminated/deleted when the slave node is in a comm break state with the master node.

Workaround:

Issue the command updates 3 * from every node in the network (or more precisely, from every node that experienced a comm break with a node that it previously had a SVC connection with).

Further Problem Description:

This problem is tied to comm breaks and call termination. If the network is not experiencing comm breaks at this time, then there is degradation in service. The degradation is caused by the slave end of the connection not being deleted and subsequently interacting with a later call.

CSCdm92021

Symptom:

Parity error may be logged unnecessarily if UXM is in test mode or debug mode. The checking of this condition was not valid.

Conditions:

When UXM is in test mode or debug mode we would ignore the parity error. But the checking of this condition was using the wrong index so this checking may not be valid. This problem was created when fixing CSCdk21888.

Workaround:

None

CSCdk32046

Symptom:

E1 CCS Frame relay lines continue to send Yellow alarm to the remote end after a failure (red alarm) due to cnfclnsigparm 9 being set to 'YES'.

Conditions:

When an E1 configured for CCS fails and cnfclnsigparm 9 is set to Y. The E1 line will send yellow alarm to the remote end and will continue to do so even after LOS Red alarm is cleared.

Workaround:

Issue cnfclnsigparm 9 N to disable:

9 CDP & CIP Condition CCS Lines? [YES]

CSCdk33999

Symptom:

Connections are deleted without user intervention and software errors 532 logged with 000000FF in the data field. The software errors are logged prior to the logging of the connection deletions in the event log.

Conditions:

The source node for the deletions (the one with the software error 532s) is an IGX or IPX. The connections deleted terminate on FRM or FRP cards on the source node.

This problem has only observed a few times, but was observed multiple times on at least one node. It is very likely that an operation performed on the node triggered the problem, but this operation has not been identified.

Workaround:

The conditions for this problem need to be identified before a workaround can be provided.

To help characterize the problem, please collect the following:

Issuance of the switchcc command will probably not restore the connections, but may be necessary to resolve inconsistencies that prevent adding the connections again. The connections were probably deleted to resolve an inconsistency. Unfortunately the auto deletion is not complete, and logical endpoint data from the auto deleted connections may prevent adding connections after the auto deletion. The logical endpoint data is rebuilt after a CC switch, thus removing the inconsistency.

Further Information: If this problem is observed, please determine what operations were performed on the node at the time the problem was observed.

The auto deletion condition has not been identified, and the problem has not been reproducible in the lab. Inconsistencies induced into the connection data bases have not produced the characteristics observed in the field (primarily the software error 532). The induced inconsistencies have shown that the auto deletions of the connections may be incomplete, and a switchcc is often required after the auto deletion to restore the logical endpoint structure.

CSCdk36040

Symptom:

The FRP front card type is reported in trap 20004 (card Alarm) when the back card is pulled.

Conditions:

None

Workaround:

After receiving this trap, do a dspcds to see which card is missing.

CSCdm38356

Symptom:

ALM/A VPC connections discard 100% of traffic when routed over ALM/B trunks after a switch software upgrade from 8.2.59 to 9.1.09.

Conditions:

ALM/A VPC connections routed over ALM/B trunks; 9.1.09 and higher software.

Workaround:

Route ALM/A VPC connections over NTM or UXM trunks.

CSCdk39687

Symptom:

If Cisco View is used as equipment manager then any SMF OC3 backcards are shown as MMF OC3 backcards.

Condition:

Do rear view on a BPX node having SMF OC3 backcards using CV and they will be shown as MMF OC3 backcards.

Workaround:

None

CSCdm47933

Symptom:

When you do dspnds -d, the columns wrap and the display is a mess. You have to do a clrscrn to get rid of all the junk before you can display anything else correctly. The problem is that prior to release 9.1, the command displayed the node name followed by IPX, IGX, or BPX. Now, the command displays the node name followed by the longer part number (84xx or 86xx).

Conditions:

Normal operation

Workaround:

None

CSCdm51607

Symptom:

Printer output is not properly formatted in 9.1.09. Headers are not printed properly for every print operation.

Conditions:

Issuing any print command.

Workaround:

None

CSCdk53041

Symptom:

Software error 925

Conditions:

Issue cnfcdpparm command.

Workaround:

Make sure that all trunk cards are in their slots. If the card is removed, then this error will be logged.

Further Problem Description:

The switch software is using physical card information which disappears when card is removed.

CSCdk63524

Symptom:

In response to an incorrect user port ID input, a max size of '16' is reported.

Conditions:

User port command execution with port number greater than supported number.

Workaround:

None

Further Problem Description:

This is a cosmetic problem. The correct number of ports are supported. If a user attempts to input a port greater than the supported ports, but less than, or equal to 16, the request will be rejected.

CSCdk69865

Symptom:

Frequent card background test failures.

Conditions:

Declaring a card error after the background test has failed, when three consecutive retries did not pass, is too stringent.

Workaround:

None

CSCdk70069

Symptom:

Node may become unreachable during card resets.

Conditions:

Happens during card resets when the LMI is enabled on ports.

Workaround:

None

Further Problem Description:

There is a very small chance of this occurring in releases 9.1 and before.

CSCdk77462

Symptom:

ATM Port real-time counters are not collected correctly.

Condition:

When the ATM Port Stat table is walked from SNMP manager, unexpected results occur.

Workaround:

None

CSCdk78467

Symptom:

Software error 9000 is logged on FRM cards during switchcc due to background test failure.

Conditions:

Happened when port configuration got corrupted.

Workaround:

None

Further Problem Description:

The FRM card in slot 25 has incorrect port number configuration in novram as captured below. During switchcc, this will cause card verification failure and trigger software removal and re-insertion of the card. The port configuration, channel configuration, background test commands are all rejected since the firmware card status is still deactivated.

CSCdk78980

Symptom:

atmEndptCellRouting on BPX can not be disabled. In addition the cell routing restriction would be enabled if it was disabled through SNMP SET to disable the cell routing restrict on the atmEndptCellRouting.

Conditions:

It happened only when the connection existed and we tried to configure cell routing restrict on BPX through SNMP.

Workaround:

Use UI cnfcon to disable the cell routing restrict.

CSCdk80460

Symptom:

cnflnsigparm is used to change signalling parameters for entire node. These changes are not being reflected in the line 2 of a UVM

Conditions:

None

Workaround:

cnfchdl can be used.

CSCdk81355

Symptom:

Error 372 is logged when configure a BXM port using CLI cnfport.

Conditions:

Number of connection end points is greater than 12000 on the BXM card. One dax connection can create two end points on one BXM card, if the connection goes back to the same card.

Work Around:

None

CSCdk83150

Symptom:

Output of command nwstats is messed up in 9.1

Conditions:

Source of excess packets screen is messed up in 9.1 for total number of nodes in the network greater than 14.

Work around:

None

CSCdk83511

Symptom:

When issuing a tstconseg on a connection endpoint, the software passes a returned F5 OAM Segment loopback with a correlation tag different from what was sent. This is in violation of ATM Forum specification UNI 3.1 section 3.5.3.2 But CLI indicates test passed.

Conditions:

BPX switch software 9.1.04

BXM firmware M.B.Y

tstconseg on a connection endpoint

Workaround:

None

Further Problem Description:

Non-compliant with ATM forum, ITU and Belcore specifications.

CSCdk83903

Symptom:

When we used SNMP to get lineChanIfOnhkAbit, lineChanIfOnhkBbit, lineChanIfOnhkCBit and lineChanIfOnhkDBit, the value returned was 1 less than the value defined in the MIB file.

Conditions:

SNMP GET/walk for the values of lineChanIfOnhk[ABCD}Bit

Workaround:

Increase the values returned from SNMP GET/walk by 1

CSCdk84590

Symptom:

BCC-4 displayed as BCC-3 in the event log.

Condition:

Command dsplog was given on a BPX node with processor card of type BCC-4.

Workaround:

Use the command dspcds to confirm the card type and interpret the event log accordingly.

CSCdk85297

Symptom:

The dlcon t command connection summation value did not match the same value as the manual summation of the connection types.

Conditions:

Issue the dlcon t command when there were greater than 9999 connections.

Workaround:

Manually sum up the connection types.

Further Problem Description:

This was a display only issue that was caused by the change in number of supported connections. While the correct count was being painted on the screen, a later field painting overwrote one character in the count display.

CSCdk85514

Symptom:

Virtual trunk goes into Major - Rmt Path Trc Fail (YEL) and doesn't clear.

Conditions:

If a virtual trunk is added through a VPC cloud and the cloud port is configured to have ILMI with polling enabled and trap disabled, this problem occurs.

Workaround:

Configure the cloud port to have ILMI with polling disabled and trap enabled. Down the VPC connection and up again or down the virtual trunk and up and configure again.

CSCdk88074

Symptom:

When the ASM card is in "Active-F" state, the command dspcd <ASMslot> will cause a software error 36 to be logged.

Workaround:

A resetcd F should clear up the failed bit. But the polling has stopped after the card fail and will not start again. Command resetcd H will start polling again, but unfortunately it does not declare that the node is out of failed state, even if in actuality, the card has become healthy and responds to all polls correctly.

If you believe that the card is ok, use both commands will bring the card's polling back and display it correctly.

Further Problem Description:

The problem has been fixed in 9.2

CSCdk88695

Symptom:

CIR and QIR values appear inconsistent when ABRSTD connection is added from different nodes.

Condition:

Connection needs to be added from different nodes.

Workaround:

Ignore the CIR and QIR values as they are not valid for connections.

CSCdk89096

Symptom:

The statistical reserve values can not be configured to a value greater than 65535 cps. If the trunk is already added and the statistical reserve is reconfigure to a value greater than 65535 cps, then the load information shown in dspload will be incorrect.

If the trunk is added after the statistical reserve is configured to be greater than 65535 cps, then the statistical reserve on that trunk is automatically changed to a smaller value.

Condition:

This problem is observed on UXM T3, E3, and OC3 trunk.

Workaround:

None. This is just a display problem. The detailed dspload of the trunk shows the correct value.

CSCdk89673

Symptom:

The connection loading is asymmetric. It has different value at the end points. The trunk load is also asymmetric.

Conditions:

This happens only when cnfcon times out. This is a rare occurrence and can happen only when the node is very busy and the cnfcon command is executed.

Workaround:

Workaround for this situation is to reconfigure the connection again. It will fix the problem, connection endpoints will be in sync again.

CSCdk90061

Symptom:

Line diagnostics is not performed on Y-red secondary card.

Condition:

If the line failed on a secondary Y-red card, the line diagnostics is not performed.

This does not impact user traffic. Line diagnostics is used by software to determine if line failure is due to an external device or the backcard.

Workaround:

None

CSCdk90392

Symptom:

Complete set of statistics not being collected from BXM trunk card. This can include TFTP statistics and even AUTO statistics used for statistical alarming on the trunk.

Conditions:

Only occurs when secondary card of y-red pair is active card.

Workaround:

switchyred to primary card of y-red pair

CSCdk91665

Symptom:

dspcons command does not show connections starting from the specified port. Connections are displayed from the next port/slot.port having connections.

Condition:

Command dspcons was given as follows:

dspcons <slot.port> i.e. vpi and vci values were not provided.

Workaround:

Give the dspcons command as follows: dspcons <slot.port.0.0>

CSCdk91858

Symptom:

An invalid logical trunk error code (923) is recorded in the swlog for the upping of the first UXM trunk.

Operational Impact:

None determined.

CSCdk92892

Symptom:

There is no obvious symptom when this problem occurs. This problem consumes more trunk bandwidth than what the connection needs.

Conditions:

This problem occurs to the G729 connection only. The problem occurs when a FAX session is terminated from active state. When a G729 connection upgrade to the FAX session its bandwidth is configured to be 64Kps. When the FAX session is over, the connection's bandwidth should be configured back to 8Kps. But due to the software bug the connection's bandwidth remains in 64Kps.

Workaround:

dncon and then upcon

Further Problem Description:

There will be no any problem to the connection when this problem occurs. The only problem is that the system bandwidth is not used efficiently.

CSCdk93620

Symptom:

Node aborted while running dspchstats

Condition:

Type and number of channels stats supported by the card must change while dspchstats command is running. Don't know how to reproduce in 9.1, but fixed the code to initialize pointer correctly anyway.

Workaround:

None

CSCdk93669

Symptom:

There is no symptom in earlier release versions. The bug is benign and does not cause any noticeable problem.

Conditions:

This happens when dspcon a data or voice connection. The wrong field of VC_DB is accessed and some local variable is initialized from this wrong field.

Workaround:

None

CSCdm01239

Symptom:

Feeder connections go into the A-bit failure, when the hub it's connected to goes into flooded mode.

Conditions:

Same as above. Happens intermittently.

Workaround:

None

CSCdm02140

Symptom:

Pulling out the active BTM card was disrupting the traffic because sw was not sending message 0x32 and others to the new active card (secondary card)

COndition:

Y-red BTM card

Make primary card active

Add some connections, routed over BTM trunk on this card

Workaround:

Put the primary slot back in and do resetcd on secondary card

CSCdm02272

Symptom:

dsplogcd 112 5 command entered and screen frozen

Conditions:

The card is BXM-T3/E3 and sonet mode attribute has bad value. Use dspcmi p to examine the value. It is bad if the value exceeds 6.

Work Around:

Patch sonet mode to 0. Please contact Cisco for the operation.

CSCdm02967

Symptom:

writeOnly(3) is returned when get atmQbinAdminStatus and rsrcPartiAdminStatus in SNMP.

Conditions:

On BXM cards

Work Around:

None

CSCdm04420

Symptom:

The TBL updates don't work after they are disabled and re-enabled using the command cnftlparm. This will cause the load to be imbalanced later because of the update mechanism not working.

Conditions:

Same as above. Someone manually needs to doable/re-enable the TBL updates. The mechanism will be working properly if this is not tampered with.

Workaround:

Will have to do a switchcc or node rebuild once this happens so as to start the state machine again.

CSCdm05008

Symptom:

The display of dsplns command does not go to the second screen and gets stuck in the first screen.

Conditions:

If a line corresponding to an ALM card is the first card to be displayed in the second screen of dsplns output, the display is stuck in the first screen and the second screen is not displayed.

Workaround:

Ensure that the line corresponding to an ALM card is not the first line displayed in the second screen of the dsplns output.

CSCdm05911

Symptom:

Software errors 925 and 31 logged

Condition:

When executing command addcon with dlci as range i.e. as follows:

addcon slot.port.dlci1-dlcin <remote node> ....

It does not add the connections but logs software errors 925 and 31.

Workaround:

Range specification is not allowed with addcon. Do not give command addcon with range.

CSCdm06599

Symptom:

Stats Reserve in Robust Object Trunk Msg is not correct for the VSI trunk.

Condition:

This happens only if VSI is configured on the trunk.

Workaround:

Subtract the VSI bandwidth from the statistical reserve reported in the Robust Object Trunk Msg to get the correct stat reserve value.

CSCdm08878

Symptom:

Continued hitless rebuild due to some uninitialized variables

Workaround:

None

CSCdm12850

Symptom:

Implementation of the idle time has a defect. Idle time can be under-reported or cpu consumption over reported.

Conditions:

In the procedure one_sec_tick, the idle time is taken from Prf_Buffer.intp_pdata[IDLE_PROC].ip_ticks. The ip_ticks is driven from the tick_int and could be

refresh based on the interval parameter set in cnfprfparm (default is 20 sec). This cutting time does not align with the time used by one_sec_tick. This results in idle time being under-reported or cpu consumption over reported.

Workaround:

Configure 20 sec. interval using cnfprfparm.

Further Problem Description:

There is a race condition when idle tick got cleared in re_profile.c and One sec interrupt routine result in using wrong idle tick count.

CSCdm14446

Symptom:

3-byte frames routed over a UXM trunk on a frame forwarding connection between a UFMU and a UFM port are not being received by the other end.

Condition:

If you transmit 3 bytes frames on a frame forwarding connection between a UFMU and a UFM port, routed over a UXM trunk, the frames get corrupted at the UXM card on the transmitter node and hence are discarded by the receiver node.

Workaround:

Do not transmit frames of size less than 5 bytes on a frame forwarding connection between two UFMU ports routed over a UXM trunk.

CSCdm15298

Symptom:

Software error 445 logged on the standby node.

Condition:

Unknown

Workaround:

None. The error however is completely harmless.

CSCdm16778

Symptom:

Background test failures on BXM when the node is in Degraded/flooded state.

Condition:

The node must be in degraded or flooded state when the card errors get logged.

Workaround:

Clear the card errors and ignore them when the node is in degraded mode or flooded mode.

CSCdm17745

Symptom:

cnfpref will not accept the trunk number having ltrk greater than 32.

Condition:

If a trunk is specified in cnfpref command, on IGX, and the trunk happened to be the one with ltrk value greater than 32, then the trunk will not be accepted.

Workaround:

Try to including only those trunks, using cnfpref, which have ltrk less than 32.

If not then check if the trunk (with ltrk > 32) can be downed and created fresh, so that it can have new ltrk value less than 32.

CSCdm19696

Symptom:

The cnfport command is not allowed on BME card ports. This command is used to change the "Shift" and "CAC Override" defaults for the port. Although this was not a part of the original design, a valid reason has been presented to allow configuration of these two fields.

Conditions:

No special conditions. If the command cnfport is executed on a BME card ports, the message "BME ports are not configurable" will appear on the user interface screen and changes will not be allowed.

Workaround:

None. The cnfport command will be unblocked for BME ports when this software change is integrated. It is recommended that only the "Shift" and "CAC Override" fields be modified (if desired) and to leave all other values at their default.

Defaults:

CSCdm20480

Symptom:

Incorrect card state

Conditions:

When a failed UFM card is exchanged with another UFM, this problem occured.

Workaround:

Remove the card and plug the card back in.

CSCdm20716

Symptom:

When switching controller cards, some connections for which this node is a VIA or SLAVE node may reroute.

Conditions:

Occurrence is related to the presence of Virtual Path Cons (VPC). When a switchcc is done on a slave or via node for a VPC, there is a chance that one unrelated connection could reroute for every VPC. There is also a chance that the VPC may reroute. Graceful upgrade of a node can cause this to happen, too.

Workaround:

None

CSCdm22269

Symptom:

Software Error 9082s gets logged.

Conditions:

When standby UXM card, one of the Y-red pair of UXM cards, is inserted back-in then this error may be reported. In the lab, this happened when the card had lots of connections.

The reason why this error occurs is that software is sending 0x52 message to the newly inserted UXM card, assuming its a hot standby, even before configuring the card as a hot standby, which is done by sending 0x50 mesg.

But eventually card does get 0x50 mesg and other relevant messages. Only side effect of this bug is that swlog may gets filled.

Workaround:

None

CSCdm22316

Symptom:

Traffic going out of the vsi feeder endpoint will be mapped to the wrong vpi/vci.

Conditions:

A connection is added from a VSI feeder endpoint to any other endpoint. Traffic is passing from the other endpoint to the VSI feeder endpoint.

Workaround:

None

CSCdm22695

Symptoms

During the rebuild, a number of software error 372 appear, and some connections may be deleted. The affected connections appear to all have vcs with indexes greater than 2749.

Condition:

- On IGX nodes with NPM 64M cards and more than 2750 connections,

- After upgrading the node from 9.1

- and further, rebuilding the node (resetting the active card, or reloading a saved config to the active card) (Switching to the standby controller card should not cause the problem.)

Workaround

None

CSCdm23548

Symptom:

BPX/BXM Cell loss on ingress (before hitting backplane/arbiter), incrementing unknown VPI.VCI on trunk stats.

dsptrkstats slot.port

This will show 'Lst Un Vpi/Vci xx.xx' and 'Unknown Addr : ' will be incrementing.

Conditions:

This has been seen to occur with BXM firmware MBX, switch software 8.4.21.

Workaround:

None

CSCdm23669

Symptom:

The port got the wrong value FFFFFFFF. This value is out of range of the port number allow.

Condition:

This happen when a trunk is deleted. It happen for 9.2.0I in regression network

Workaround:

None

CSCdm23964

Symptom:

User changed configuration of a BXM port from ILMI to LMI, immediately afterwards the node aborted with software error 1000003.

Conditions:

The condition was unknown because the problem couldn't be re-created. There were other users testing the node at the same time the user was switching from ILMI to LMI. The node was aborted because of an uninitialized pointer in the code. The problem has been fixed.

Work around:

None

CSCdm24140

Symptom:

After deleting a connection there is a delay in the response of low level tasks, such as the user interface.

Conditions:

IGX with software release 9.1 (may also apply to other platforms and SW releases). Platform may have few objects (connections, ports, lines, and trunks), but has many statistics enabled for each object. After the deletion of the connection dspqs will show a very high "Trns Exchange" interval (greater than 500ms) with "Obj,Evt,Old,New" "80 F1 PROCESSING IDLE". The thstats will also show high "TotMsecs" for "SM#" 80.

Workaround:

1. Reduce the number of statistics enabled for each object. Only statistics that are needed should be enabled. The TFTP statistics enable file should not have statistics for objects which are not on the switch (such as FastPad if FastPad is not used).

2. Use dlcon and dvc to determine if they have a sparse distribution. A sparse population may be created if there are a lot of VC additions and deletions (VCs are not very perminant). With a sparse distribution the delay can be decreased by using cnfnodeparm to decrease the "Stat Config Proc Cnt" from 1000 to 2. The default value is optimal for a homogenous densely populated connection database (a lot of ATM PVCs), but does not work well with a heterogeneous sparsely populated database.

The trade-off of the parameter change is that the overall time to enable all statistics on all objects will be greater when statistics are first enabled. Once all statistics are enabled for existing statistics objects, the time to enable statistics for a new statistics object (such as a connection) will not change. If the connection composition on a node becomes larger and/or more homogenous the parameter may need to be changed to optimize performance.

CSCdm28561

Symptom:

Software errors 4225, 614, 534, 612, 4208, and 3058 are logged. The 4225 error caused the rest of the errors to be logged.

Condition:

The 4225 error was logged on a node which has jobs that do switchcc, full/hitless rebuilds, delcon/addcon, and rrtcon.

WorkAround:

This error was logged because a logical endpoint was not cleaned up properly. The rebuild code which logged the errors already cleaned up the problem for us. No need to do anything else.

CSCdm29600

Symptom:

Unable to add connections. Addcon command errors such as "Local resources unavailable or Network Expansion not allowed" or "Local channel unavailable" may be displayed. Commands such as dcct t will produce software errors 374 and 752.

Conditions:

Command "dvc #" (where # is a number between one and the maximum number of VCs supported by the switch) for an unused VC shows "VC #0" on a BPX running release 9.1. Only VC 0 should have "VC #0". A VC with an invalid VC index may also have an invalid connection type for an uninitialized VC. If the first "dvc #" screen has "VC #0", "Exists: 0", and "Con Type: ADPCM", attempting to display the second screen will probably cause a 1000003 abort.

Do not use "dvc" on an IGX. It will probably cause a 1000003 abort without displaying the first screen.

This problem is observed after a non-graceful upgrade from release 8.4 to release 9.1 or on BPX from release 9.1 to release 9.2. There is not a problem with - graceful upgrades, or - non-graceful upgrades from releases 8.2.xx (xx = 55 or higher) or 8.5, or - non-graceful upgrades of IGX from release 9.1 to release 9.2.

The problem is that VCs which were used for connections that were deleted in the previous release will have a VC number 0. There is not a problem with VCs which are used for connections, or which have never been used.

Workaround:

Audit the standby BCC. If the standby BCC does not have the "VC #0" set for VCs other than 0, and other standby databases are updated, perform a switchcc. Do not reset the standby BCC prior to the switchcc, as this will send the invalid active BCC "VC #0" over to the standby BCC for used VCs. Unused VCs will not be updated the standby CC.

If the active BCC is in better condition than the standby, the standby BCC may be reset prior to the switch. The used VCs with index 0 will be auto deleted during database cleanup performed after the switch.

Do not use "dvc" to audit an NPM/C.

Prior to performing the switchcc, enable connection logging to the event log (cnffunc) so that any connections that are deleted as part of the database cleanup can be identified.

If a non-graceful upgrade was performed because a standby CC was not available, loadrev the 9.1 release into flash, then rebuild the node a second time in 9.1 (the first rebuild was the non-graceful upgrade). (Use 9.2 instead if that's the release you are using)

Further: The software initializes the VC number for all VCs when the node rebuilds. In the case of a non-graceful upgrade, software maps the BRAM from the old release to the new release after the rebuild. The VCs are mapped one at a time. A VC is mapped by clearing all fields (all fields initialized to 0), then mapping the values from BRAM. This mapping is performed for all connections that exist in BRAM. Connections that do not exist in BRAM have their LCON index set to 65535 (-1), but the other fields are not mapped from BRAM. VCs which have never existed (never been used for a connection) are not processed by the BRAM mapping software. Thus the VC number initialized by the rebuild initialization software is not cleared by the BRAM mapping software.

CSCdm29706

Symptom:

To configure HCF shift to "on" or "off" on a port, the connections must be deleted and the port downed and upped.

Workaround:

Delete all the connections, down the port, change the parameter, up the port, and re-add all the connections.

CSCdm29866

Symptom:

Software errors 30, 33 occur

Conditions:

This might happen during a rebuild.

Workaround:

None

Further Problem Description:

This software error was due to a problem in range checking before logging the error. This doesn't have any other bad effect.

CSCdm38971

Symptom:

When you reset the standby card using resetcd command, it just re-starts the Switch Software. The Standby card does not re-start from the boot code level.

Conditions:

This is not a problem, unless the customer needs to update the Firmware in a Standby NPM card. The customer normally burns the NPM firmware on the active card, does a switchcc and tries to reset the standby card (which was active earlier and the firmware burnt on it). Since the resetcd command does not start the standby card from Boot code level, the newly burnt firmware does not come into effect.

Workaround:

The customer needs to physically re-seat the standby card, for the new boot code to take effect.

With this new fix the standby card restarts at boot code level when resetcd is executed.

CSCdm53376

Symptom:

Trunk errors not reported under dsptrkerrs after the upgrade from 8.4.14 to 9.1.09

Conditions:

Trunk errors were reported on heavily loaded NTM trunks with Bursty Data B traffic prior to the upgrade. Since the IPX/IGX upgrade to 9.1.09 no error are registered.

Workaround:

Delete, down, up, and re-add the trunk in question. Merely deleting and re-adding will be insufficient. If delete and add trunks are not desirable, a procedure to patch memory are described in the workaround enclosure. This procedure applies to all platforms.

Further Problem Description:

This problem affects BPX, IGX and IPX trunks, lines AUTO statistics collections after upgrade from 8.4 to 8.5 or 8.4 to 9.1 or 8.5 to 9.1.

CSCdm58469

Symptom:

A 1000003 abort occured after deletion of an Axis shelf.

Conditions:

1. Must have an expanded BCC, a BCC with 4 MB of BRAM

2. Shelf deletion

Workaround:

The defect may occur if a shelf is deleted. Even if a 1000003 abort is not observed on shelf deletion, the database that maps from vpi/vci to lcn for the LMI protocol may be corrupted. Therefore, the recommendation is as follows:

1. Do not delete a shelf unless absolutely necessary

2. Before deleting a shelf make sure the standby BCC is in standby. A 1000003 abort may occur. If a 1000003 abort is not observed, perform a switchcc. The abort or the switchcc will rebuild the corrupted database

CSCdm59091

Symptom:

LDM and CVM connections cannot be modified by the Cisco Wan Manager (CWM) GUI. Specifically, preferred route and COS cannot be changed and the connections cannot be deleted.

Conditions:

LDM and CVM connections which have been added to an 8.4 network and upgraded to 9.1.12 cannot be modified nor deleted by CWM GUI. command line access works fine. Connections deleted and re-added or which are added in 9.1 work fine.

Workaround:

Delete (via CLI) and re-add (via CLI or CWM) the connections after the upgrade is complete to restore full management capability.

CSCdm59267

Description:

In the Robust ATM Connection Object message sent from Switch Software to StrataView, certain connection object subtypes are not being sent. In particular, the following are not being sent. Instead, they are being mapped to other subtypes.

The mappings need to be removed so that the additional details will be available to StrataView.

Workaround:

There is no workaround needed for this situation. It will not affect most customers. The additional information is sometimes useful to StrataView.

CSCdm68729

Symptom:

AIS cell generated even when remotely looped connection was in OK state

Conditions:

addrmtlp on a failed routed connection, failed because of LOS on the remote-end line connection on this-end, non LOS end from where addrmtlp is executed, get into OK state but still it generates AIS cells

Workaround:

Before doing addrmtlp do addlnlocrmtlp on LOS-end and then do addrmtlp

CSCdk41514

Symptom:

Any connection that is added from a BPX running 9.1.02 to a BPX running 8.X

Conditions:

This problem is only seen on a BPX running 9.1.02. I have reproduced this in our lab as well

Workaround:

Customer can add his connections from the lower release BPX. But in some circumstances this is undesirable as it could mean a single node owns more connections than the customer wants.

CSCdk55331

Symptoms:

Maximum PVC LCNs shown on cnfrsrc screen of BXM port card are set to 256 incorrectly after upgrade from 8.4 or 8.5 to 9.1.

As a result, the user may be able to add more connections to that port and exceed the Maximum PVC LCNs limits shown on cnfrsrc screen.

Conditions:

On BXM port card, if user has more than 256 connections added on a port prior to upgrade to 9.1, then after upgrade to 9.1, the cnfrsrc command (which is new in 9.1) will show that the maximum number of PVC LCNs is 265 which is incorrect. This number should be set to the total number of connections currently existing on this port.

Prior to upgrade, if there are less than 256 defined on a BXM port, then this problem does not exist since the default maximum PVC is defined as 256 in cnfrsrc command.

Work around:

Use cnfrsrc command to change the Maximum PVC LCNs to same number of connections currently exist on the BXM port. User can count number of connections using dspcon command or use debug command 'dsplogcd 112 <slot> to display the total number of connections defined on a port.

PORT[i] line_info

mln_line_num = 0; mln_line_type = 0; mln_portgroup_id=0

mln_pvcs_cnfgd = 500, mln_pvcs_cnt = 500, mln_nw_cnfgd = 0

mln_svc_cnfgd = 0 &mc_lnred_info = 31122034

&port_cnf &ch_info &ch_indx &thisend &PortLccb &TrkXlat

00000000 310C4FD0 310BCFD0 310BC750 31121DB2 310CE0D0

Where i in PORT[i] shown above is the port number (1 base). Use cnfrsrc command to change Maximum number of PVCs to the same as mln_pvcs_cnfgd.

With the fix in place, everything works fine if no ports are activated during upgrade and no connections are added/deleted. If any of these is done during upgrade (ie when STBY is either upgrading or in upgraded state), then resetcd on STBY need to be done, otherwise STBY will not be updated with modified values.

CSCdk73530

Symptoms:

cnftrk allows the user to enter a value for transmit rate that is smaller than the current configured value for VSI bandwidth. Although this condition will cause the cnftrk command to fail and generate an error message when the user configure the stats reserve parameter, it is desirable that the error message be reported immediately upon the user entering the value for the transmit rate parameter.

Workaround:

None required

CSCdk83175

Symptom:

Cannot configure ESP parameters with the CLI cnfport. Get the message "VSI configuration active on card. Cannot modify ESP parameters"

Conditions:

First enable a VSI partition on a BXM port. Disable all of VSI partitions on the card.

Work Around:

Down all of the lines on which a VSI was enabled and disabled later. If cannot execute dnln on the interfaces, no work around is available.

CSCdk86467

Symptom:

Adding virtual trunks from CiscoView results in the following error message:

genErr: switchifService must exist for a SET operation

Conditions:

None.

Workaround:

Therre are 2 work arounds.

WORK AROUND #1

1) Select the rear view.

2) Chose the port that has the trunks up on it.

3) Change the Admin Status of one of the trunks that are upped from UP to ADDED

4) Change the Service type from atmRoutingTrk to atmRoutingTrk (so no real change).

5) Select modify.

At this point the trunk is added, however, we should not have to re-tell the tool that this is an atmRoutingTrk. It already knows, that it should place that into the SNMP SET PDU (if this is truly the problem).

WORK AROUND #2

1) Select the rear view.

2) Chose the port that has the trunks up on it.

3) Change the Service type from atmRoutingTrk to atmRoutingTrk (so no real change).

4) Select Modify

This causes the error message "genErr:Interface [9040010] is already ACTIVATED"

5) Change the Admin Status of one of the trunks that are upped from UP to ADDED

6) Select modify.

Now the trunk is added.

CSCdk88488

Symptom:

Trunk alarm enable flag is cleared. If failure on trunk occurs, remote nodes are not notified.

Conditions:

Trunk was upped via SNMP Manager.

Workaround:

1. Up trunk via UI

2. Reconfigure alarm enable flag after trunk is added

CSCdk89665

Symptom:

Unable to configure a UFM-C E1 line to unchannelized with 9.1.x switch software. Cannot set E1 line framing to OFF. Cannot set line Signalling to None.

Conditions:

Customer environment not relevant. Affects 9.1.03 and 9.1.06 and probably all releases of 9.1.

Workaround:

None

CSCdk90927

Symptom:

When the value of the 'Deroute delay timer' is changed for any virtual trunk by giving the command cnftrk <virtual_trunk_no> it changes the value of the 'Deroute delay timer' for all the virtual trunks on the same port to this new value.

Workaround:

No workarounds possible. Try not to change the value of this field.

CSCdm00224

Symptoms:

Under certain conditions use of the cnfrsrc when creating a job may cause fatal memory access error.

Conditions:

- entering the cnfrsrc command when creating a job

- select yes when asked whether you want to edit VSI parameters

- select enable for the partition state

Workaround:

Activation of a VSI partition using cnfrsrc should only be done in interactive mode.

CSCdm00517

Symptom:

The command cnfrsrc will allow VSI to use the same VPI as ILMI/LMI protocol and vice versa.

Conditions:

This problem only happens if the VSI partition is enabled through cnfrsrc.

Work Around:

If the ILMI/LMI VPI is configured to some value other than 0, when configuring the VSI start and end VPI remember that VPI value and do not assign it to VSI.

CSCdm06968

Symptoms:

When you execute the cnfrsrc command to configure resources for creating a VSI partition, sometimes the node may abort. This will happen if

- you are trying to configure resources on a trunk only. AND

- you are NOT changing the cnfrsrc parameter values.

Work Around:

The chances that this happens is very small. One thing that can be tried is to configure a port first and then the trunk. The internal variable will get initialized when configuring the port and not be used, and thus avoid aborting the node.

Please make sure that you change at least one value in the parameter list of the cnfrsrc command - then the node will not abort.

CSCdm34856

Symptom:

cnfrsrc will allow deletion of partitions even when the port group lcns is reduced.

Condition:

Always happens

Workaround:

None. Do not delete a partition if the port group lcns are going to be reduced. Increase the lcns of another partition of the port group before deleting the partition.

CSCdm65380

SYMPTOMS:

The VCIs used for physical trunks would start at 4096, which would not allow a user to trunk through a cloud which limits the VCI field to 12 bits (4095).

CUSTOMER IMPACT:

Inability to use wraparound trunks over certain clouds.

WORKAROUND:

None

CSCdk85811

Symptom:

LAN fuse failed on IGX-NPM

Conditions:3

dspcd 1, dspcd 2

shows LAN fuse failed

Workaround:

resetcd (1/2) f, switchcc

Further Problem Description:

Service affecting if done on a node with single processors

CSCdm43471

Symptom:

After upgraded from 8.4 to 9.1 Cisco Wan Manager can not see switch software FRM, VOICE and DATA conns anymore. Only FRM to ATM endpoint connections showed.

Conditions:

Problem exists on upgrade to Rel 9.1 SWSW from Rel 8.2, Rel 8.4 or Rel 8.5.

Workaround:

1. Delete conns and re-add

or

2. Rebuild

Further Problem Description:

After upgrade from 8.2, or 8.4, or 8.5 to 9.1 Cisco Wan Manager can not see SWSW FR-FR conns, voice conns, and data conns anymore. Only FR to ATM endpoint conns are not affected.

CSCdm44675

Symptom:

Unable to configure for loop clock on an FRM port in switch software 9.1.09. The system respond is "back card supports only NORMAL clock". It is able to configure for looped clock on an FRM port in switch software 8.4.21.

Conditions:

Upgrade from release 8.4.x to release 9.1.x

Workaround:

None

Further Problem Description:

This problem only affect upgrades from 8.4.x to 9.1.x.

CSCdj42877

Symptom:

The dspbpnv/Display Backplane NOVRAM command has a mis-spelled word in the help text.

Workaround:

None needed. The word is clear by context reference.

Further Information: The spelling is already corrected in the 9.1 release.

CSCdk30928

Symptom:

During the upgrade from 8.1.72 to 8.4.19 the following parameters were changed on all nodes with voice connections on CDP/CVM's.

Cnfecparms 4: IEC Nonlinear processing changed from "Center Clipper" to "Multiplying" Cnfecparms 7: IEC Voice Template changed from "USA" to "UK"

Conditions:

This problem was not duplicated so the conditions are unknown. However, a review of the code revealed the bug.

Workaround:

Change the parameters back to the correct values after the upgrade.

CSCdk53126

Symptom:

1M3 abort.

Conditions:

1) after moving cards around in the cage.

2) after clrallcnf and load new revision.

Work around:

None.

Further Problem Description:

Abort protection code was put in to avoid aborts at the point of failure.

CSCdk74438

Symptom:

The job does not take 8/8 option.

Conditions:

N/A

Workaround:

Manually create the connection.

CSCdk77005

Symptom:

1000003 abort in SNMP process.

Conditions:

After an ARP request is received by the switch with the network id of the senders address different than the network id of the switch subsequent walks of the ARP table will cause a 1000003 abort.

Workaround:

Remove walks of the switch ARP table or set the SNMP get community string to NOACCESS.

CSCdk77562

Symptom:

The LOS line alarm is not displayed for the first activated line when the T1/E1 cable is connected to the port.

Conditions:

The problem occurs only in the first activated line.

Workaround:

Use cnfln command to force the detection of the alarm.

CSCdk81248

Symptom:

cnfchec skips some channels and displays error message saying it is a data channel.

Conditions When a data connection existed (is now deleted) on the channel.

Workaround:

Add a voice connection to the channel and delete it.

CSCdk84083

Symptom:

IP Connectivity to popeye1 feeder node may be lost.

Conditions:

Whenever a popeye node is added as a feeder to a BPX a channel with vpi.vci as 3.8 is allocated for IP relay function between the BPX and the feeder node. The above mentioned symptom can occur if a user connection with the same vpi.vci (3.8) was added and then subsequently deleted.

Workaround:

DO NOT add user connections with a vpi.vci of 3.8. (This range is within the lower range reserved for signalling and administrative functions. The fix to this defect explicitly prevents the addition of a user connection with a vpi.vci of 3.8)

CSCdk87005

Symptom:

The addcon command using the avoid satellite links in 8.5 and 9.1 needs to have all the optional parameters entered as stars before the *s can be used.

ie

addcon 8.1.100 igx32-1 9.1.100 4 * * * * * * * * *s

Shouldn't need the starts for optional parameters.

Condition:

Always happens

Workaround:

Use the full command for specifying restrictions (with the *'s for the optional parameters).

CSCdk89044

Symptom:

A 1 million 3 abort may occur in some rare conditions when a change, which causes an update to the channel configuration database, happens.

Conditions:

The buffer that is allocated for the update message happens to be at the end of a memory region.

Workaround:

None

CSCdk89105

Symptom:

Connections are not displayed from the specified port when dspcons command is given such that only slot and port are specified with the command. Connections are displayed from the next available port/card if any exist.

Condition: dspcons command is given as follows: dspcons <slot.port>

Workaround:

Give the command as: dspcons <slot.port.0.0>

CSCdk93490

Symptom:

Need ability to debug resource handler task. Command rhstats accomplishes this. It has similar format to other debug commands fhstats and thstats.

Conditions:

Resource handler is the highest priority task in the system. Should it get excessively busy, slow performance of the other tasks occurs.

Workaround:

None

CSCdk94112

Symptom:

Running the dspcon user command on an igx node in order to display a connection that has already been routed, shows incorrectly that the connection is being re-routed.

Condition: This condition will occur for bpx <--> igx connections when one of the trunks in the path has a logical trunk value that is greater than 32.

WorkAround:

This problem is just a display problem. Displaying the connection on the bpx side will actually shows that it is routed.

The problem will not occur if none of the bpx trunks in the network has a logical trunk greater than 32.

Also, if this problem occurs, re-routing the connection so that it picks a path where all the logical trunks are <= 32 will fix it.

CSCdm00711

Symptom:

Hardware watchdog aborts on all versions of release 9.1 on an NPM-32. When software attempts to access memory in the 32-64Mb range on an NPM-32 an access error interrupt will not be generated, the CPU will freeze until a hardware watchdog occurs. A switchover will occur if a standby NPM is available. A rebuild will occur if a standby NPM is not available.

Conditions:

NPM-32 with the SNMP Get community string configured. Certain SNMP operations are causing switch software to access non existent memory.

Workaround:

Set the SNMP Get community string to NOACCESS.

CSCdm00869

Symptom:

Incorrect connection bandwidth sent to FW for modem upgrade.

Conditions:

This problem occurs at rate of 10% of the modem upgrade cases. It occurs randomly. It is not related to any configuration.

Workaround:

Deactivate the connection by the dncon command first. And then activate the connection by the upcon command.

CSCdm01743

Symptom:

Software error 514 seen upon deletion of UXM to UXM ATFR connections. The error is seen only some times.

Condition:

UXM to UXM (both ATM endpoints) if used to add an ATFR connection, and the connection stats are enabled. There is a very remote possibility that specific stats received from the card can indirectly cause this error.

Workaround:

None

CSCdm02642

Symptom:

Trunks sometimes do not show up when walk on switchIfTable.

Conditions:

If CVM (CDP) card plugged in precedes BTM/NTM trunks. In other words, the trunks will not be seen if their slot numbers are greater than the slot numbers of CVM cards in snmpwalk.

Workaround:

Make sure there is no CVM/CDP cards plugged in precedes BTM/NTM trunks.

CSCdm02874

Symptom:

Software error 513 logged when switchcc occured.

Conditions:

This problem happens if a slot was previously used for the card other than an UXM and the slot is then replaced with an UXM card.

Workaround:

There is no workaround. This problem will not cause any harm.

CSCdm05373

Symptom:

Most of time no specific symptom shows up. Sometime channel configuration may be corrupted.

Conditions:

When a channel configuration changes this problem may occur. But if the default channel configuration is used then there is no problem.

Workaround:

Reconfigure the channel again.

CSCdm07472

Symptom:

No traffic continuity on BME cards if switched from Active to Standby slot (BME in Y-red configuration and the processor is BCC4)

Condition:

This problem happens when a BME cards are in Y-red and BCC is BCC-4. When we switch the card from Active to Standby then we lose the continuity.

Workaround:

Do not add yred on BMEs. (if the processor is BCC4)

CSCdm07546

Symptom:

Users deleted with deluser are not completely deleted.

Conditions:

The delete user operation is not processed correctly by the standby CC. While the user will be deleted on the active CC the user is not deleted on the standby CC. When the standby CC becomes active the user will return.

Workaround:

1. Reset the standby CC on every node in the network following a deluser command.

2. If the user is being deleted for security reasons, use cnfpwd to change the password of the user as an alternative.

3. If the maximum number of users(64) is allocated, a deluser command followed by an adduser will cause the new user to take the place of the deleted user on the active and standby CC. Dummy users may be added to reach 64 users.

CSCdm13645

Symptom:

After renumbering deltrk and other commands relying on distributing information in hop-count based waves do not work.

Workaround:

Avoid renumbering in networks with releases containing fix CSCdk81800 but not this fix.

CSCdm14418

Symptom:

dsppwr shows voltage of 75 and status of OVER for missing DC power supply.

Conditions:

PEM in slot B with -53V (measured), no PEM in slot A:

A shows voltage of 75 and status of OVER

B shows voltage of 54 and status of OK

Workaround:

- Install second DC PEM

- Install "daisy-chain" power cable, sharing existing DC supply with both PEMs

CSCdm15043

Symptom:

There may exist dangling lcns, which indicate one less connection to add on the card.

Conditions:

There are two conditions when this may happen:

1. If addcon fails with "Warning: Inconsistent shift mode"

2. After executing the command rbldcondb, if there are software errors 614 & 612.

Workaround:

Switchcc will clean up the dangling lcns.

CSCdm16210

Symptom:

- Node properly displays connections for a given slot when 'dspcons' command is used.

- When using 'dspcon' command for any connection endpoint on the same slot other than the first, node responds with "connection does not exist" message.

- On DAX connections, the remote end LCN is zero. This is displayed using 'dcct <conn>' or 'dlcon <lcon_num>' commands.

Conditions:

The 'dspcon' problem described above tends to occur when the first connection on the slot is a DAX connection. However there still may be DAX connections on the slot which have a remote end LCN of zero. When these are encountered, only one end of the connection can be displayed using the 'dspcon <conn>' command. This problem can occur on IPX, IGX and BPX platforms.

The problem affects frame relay and ATM DAX connections. These connections should not use a remote end LCN value of zero.

Workaround:

- Do not use the command 'rbldcondb'. Use of this command has been observed to set the remote LCN to zero on DAX connections.

- When a corrupted DAX connection is found, do the following:

- Delete/re-add the connection from the end that can be displayed.

- Execute 'switchcc' command to rebuild the connection database. The CC switch can be delayed to allow for a maintenance window, but the 'dspcon' problem, if encountered, will persist until the CC switch is performed. If there is no standby CC available, a node rebuild (reset active CC) is required to rebuild the connection database.

CSCdm21298

Symptom:

swerr 1000003 and 2000000 logged

Conditions:

This condition occurs when cbtool is running and the slot has a pending message.

Workaround:

Do not use cbtools.

CSCdm22405

Symptom:

The NPM card shows that it is in the "Active-F" state.

Condition: This condition can occur when the active NPM runs the CBUS_TEST test when the standby is in the Cleared state. As a result the test fails. However, the failure occurs because the test was run at the wrong time and not because there is actually a problem.

WorkAround:

None

CSCdm25227

Symptom:

There is a potential for a faster Comm Break when many trunks fail/repair at the same time.

Workaround:

Increase the number of normal timeouts in cnfnodeparm from the default 7 to 12.

CSCdk51259

Symptom:

Only for the UXM and BXM can NMS get the information of slotBackNumPort from the MIB.

Conditions:

When query from SNMP.

Workaround:

None

CSCdk61736

Symptom:

The ds3 statistics, ds3PktCrcs is a statistic that cannot be enabled or collected on the BPX, yet it exists in the BPX's MIB. To support eventual MIB removal, this MIB entry is being deprecated.

Condition:

Not applicable

Workaround:

Not applicable

CSCdk78911

Symptom:

When the command DSPBOBTRK is issued on version 9.1.03 it does not display anything at all. This command does work in 8.5.x.

Workaround:

As of now, there is no known workaround.

CSCdk87166

Symptom:

Modifying connection with StrataView Plus (no change) causes PVCs to go in and out of alarm.

Conditions:

Modification issued from 8.4.21 node with other endpoint being 9.1 in a mixed network.

Workaround:

Do the modification from 9.1 end of the connection in a mixed network.

CSCdk81800

Symptom:

OC3 rate hi-priority traffic circulating on a trunk.

Conditions:

The network was physically divided in 4 segments thus making nodes of one segment unreachable from the nodes in any other segment. The inter-segment cables on the trunks were physically removed by a couple of working together simultaneously causing this condition to occur. This caused one of the nodes to have incorrect view of some of the other nodes in the network. This also causes routing loops to happen because of which the cells keep on circulating.

Workaround:

Identify the node with incorrect view and delete the networking channel on it for the node to which it's transmitting.

CSCdk82907

Symptom:

IGX aborts during upln on UXM.

Conditions:

The abort occurs after the following steps are done: 1. Insert two UXM and configure as yred 2. Up two trunks and one line on the UXM pair 3. Remove primary UXM and insert a mismatched UXM into secondary slot 4. Upping a new line causes abort

Workaround:

Make sure there is an available card (active or standby state) in the slot before upping configuration

CSCdk82927

Symptom:

Slow response and timeouts when telneting from CAT5000 or NMS workstation to IGX switch LAN port running 9.1.04. Most of telnet sessions disconnect after 5 minutes. Average delay is between 3-4 seconds for telnet connect.

Conditions:

Relatively new switch without large quantity of traffic running on it. The telnet, tcp, nwip, and snmp settings are set to defaults. LAN is configured with IP, subnet, gateway, and default port number. Doing a switchcc does not increase telnet connect time.

Workaround:

Telnet from a NMS workstation with acceptable telnet delay set above 4 seconds.

CSCdk83358

Symptom:

cnfcon did not configure oe_vcq in 9.1.06

Conditions:

Connections affected were FRM-FRM, FRM-UFM running software 9.1.06

Work around:

vt to other node and configure this

CSCdk87193

Symptom:

\Qno such name' is returned when query object shelfCnfgVcPollRate.0 on an IGX or a BPX node in SNMP.

Conditions:

The problem exists in rev 9.1.08 or less.

Work Around:

Not in SNMP. The value can be displayed with CLI cnfsysparm.

CSCdk87939

Symptom:

dspchcnf displays ECNQ threshold as a byte value rather than a percentage.

Workaround:

Compute the percentage by dividing the displayed value for ECNQ Threshold by the VCQ depth times 48 (to convert the VCQ depth from cells to bytes).

CSCdk93649

Symptom:

Customers SVC voice network experienced low CPU idle time, high call failure rate and slow response time.

Conditions:

On fully loaded nodes CPU idle time is close to 0. SVC calls can not route through.

Workaround:

Split the heavy loaded switches into triangles. This would increase the available CPU idle time and increase successful call rate.

Further Problem Description:

VNS needs to know how busy the switch is to better manage the high rate of incoming calls. The enhanced call throttling mechanism requires switch software to provide the average percent idle time through snmp to VNS.

CSCdm01514

Symptoms:

When deroute by COS is effective (e.g. trunk failures), if the current COS is not satisfied, and the number of connections already derouted is greater than the deroute bundle size, connection gets derouted at the local end and not at the slave (and via) endpoints.

Conditions:

The connections are derouted only at the master side.

Workaround:

Set the Max Derouting Bndl to 0. (the command is cnfcmparm)

21 Max Derouting Bndl (0=all)[ 0] (D)

NOTE:

Deroute by COS feature (for trunk failures) was introduced in 9.1.07. Refer to bug CSCdj81576 for more details. This bug fixes a defect that was found in the feature in the recent testing. This fix should go to those customers who want to use this feature.

CSCdm02015

Symptom:

Cost based routing had an upper cost limit (150) that was less than a maximum possible route cost (500) when all trunks utilized the maximum allowable cost of 50.

Conditions:

Cost based routing is enabled and trunk costs are configured such that a valid path (and possibly the only path) will have a cost that exceeds the maximum allowable cost.

Workaround:

Utilize trunk cost based on the maximum number of hops in the network. The hop count can be up to 10.

CSCdm05728

Symptom:

When trying to set "pass sync" on a trunk between nodes running 9.1 and 8.5, from the 8.5 side, you get the message that you cannot set pass sync on a trunk when the other side is set for loop clock.

The problem is, the other side in NOT set for loop clock.

Conditions:

This is a test environment. Only 4 notes, with very few pvc's.

Workaround:

If you set the remote side of the trunk (the 9.1 side) to loop clock = YES, it will pass sync, but this is not permanent, it will switch back.

CSCdk48473

Symptom:

During upgrade to 9.1 or switchcc in 9.1, all or some of the axis feeders in a heavily loaded node seems to be logging minor alarm showing loss of LMI with the routing node.

Conditions:

Heavily loaded nodes with connections about 12000 per node

Workaround:

1. Increase the time timeout values in axis(NODE_STATUS)

2. Upgrade using 9.1.09 or later versions of 9.1

CSCdk72199

Symptom:

Trunk Capacity is not displayed correctly on a DSPLOAD of an IMA group. Trunk on UXM and IMA T1 Back cards. One end of the IMA trunk shows a reduction in available receive bandwidth though all physical lines are clear of alarms. Connections fail if their bandwidth requirements exceed the available bandwidth on the reduced side.

Conditions:

This has been observed when IMA physical line failure and repair events occur in rapid succession.

Workaround:

Three possible workarounds are available:

1. Call TAC and have them issue manual updates 2 command

2. Delete and re-add the trunk, if possible

3. Set the number of retained links equal to the total number of physical lines in the IMA trunk group. If the loading problem was encountered, workaround 1 or 2 must be done first

CSCdk85787

Symptom:

During upgrade, feeder alert message is sent to the AXIS feeder only when the option is enabled in cnfnodeparm option 42. Feeder alert should be sent to feeder regardless of this option.

Conditions:

In a heavily loaded BPX, user may experience feeder communication failure during upgrade or switchcc. This is because during upgrade or switchcc, the BPX is busy rebuilding the database and may not have CPU time to process message to/from feeder causing BXM/feeder to declare communication failure.

This problem is fixed in CSCdk70799. However, it is required that user needs to enable feeder alert option (cnfnodeparm 42) on upgraded BCC prior to executing `runrev 9.1' on a node. Since this operation is tedious when there is a lot of nodes to be upgraded, this option should not be used during upgrade. The feeder alert message should be sent to the feeder during upgrade regardless of the feeder alert option.

The feeder alert option should be used only for: (1) During network flood

(2) When the node is in degraded mode

(3) During switchcc

Work Around:

Use cnfnodeparm option 42 to enable feeder alert on the upgraded BCC prior to runrev operation.

CSCdk87166

Symptom:

Modifying connection with StrataView Plus (no change) causes PVCs to go in and out of alarm.

Conditions:

Modification issued from 8.4.21 node with other endpoint being 9.1 in a mixed network.

Workaround:

Do the modification from 9.1 end of the connection in a mixed network.

CSCdk87876

Symptom:

Feeder Alert Mechanism on BPX which is invoked during network flood may not work properly if the SAR overflows. (cnfnodeparm 42)

Condition:

Feeder Alert Mechanism is first introduced in 9.1.08. BPX will send feeder alert message to the AXIS feeder upon network flood. It uses dropped coerced packets threshold to determine the network flood condition. (Refer to bug CSCdk74247).

Under flooding, if SAR on the BCC overflows, any cells that overflow the queue is subjected to be dropped. If the dropped cells are part of coerced message, then the software may think that the flooding is no longer there and take the feeder out of alert.

In addition, if the diagnostic loopback cells that BCC received from the remote BCC during flood condition should not transmit back to the originator.

This problem is duplicated only in the lab using a faulty hardware to simulate the flood.

Work around:

None.

CSCdk91650

Symptom:

Unable to get to `Upgraded' mode when attempting to upgrade from 8.2.6x to 9.1.0x (x < 9). Software errors 286 and abort 20000000 may be logged on the standby CC running 9.1.0x. The active CC running 8.2.6x will show standby updates stopping and restarting.

Conditions:

Upgrading IPX, IGX, or BPX from 8.2.6x to 9.1.0x (x < 9)

Workaround: None

CSCdk92568

Symptom:

During network flood simulation testing, the BXM port remained in communication failure (ILMI) throughout the test. In some cases, the failure does not clear after flooding is removed.

Conditions:

This problem is detected only in the lab environment. Network flood is simulated using a specific firmware and software combination. While the network is flooded, ILMI port communication failure is detected on BXM port. Sometimes, the failure does not get cleared even after the flood has stopped.

Workaround:

None.

Further Problem Description:

All network traffic and ILMI traffic shares the same SAR on the BCC. Thus, during flood, the ILMI messages are subjected to dropped. This may cause the ILMI protocol to behave strangely.

The problem is resolved by not to process ILMI messages during network flood. As soon as flooding is detected, the port communication failure timer is disabled. Thus, the ILMI port status remains at the same state until flooding is cleared. The ILMI protocol processing is resumed after the network returns to normal state.

CSCdk24511

Symptom:

When displaying clock sources with dspclksrcs after a clock source has been configured using cnfclksrc, the clock source may listed incorrectly. If the clock source was initially a secondary source and is moved to the primary source then this clock source will appear as a primary and a secondary.

Workaround:

The workaround for this problem is to use clrscrn and then redisplay the clock sources.

Further Problem Description:

Modify function cnfclksrc() in \cmds\clk_cmds.c to include a clr_scrn when we update this screen. Looks like this originally worked but someone deleted the clear screen to stop blinking. However, if we don't erase the screen first, then we need to be able to clear previous screen data that is no longer applicable.

CSCdk35496

Symptom:

The BPX resets under flood of network messages.

Conditions:

This only exists under network flooding conditions, which are being tested with the Network Protection feature that checked in after 9.1.03.

Workaround:

None

CSCdk49036

Symptom:

Several problems with cnftrk during job addition:

1) Error 1417 logged

2) Error 532 logged

3) Traffic classes input has no default - user is forced to enter values.

Conditions:

When add command cnftrk in a job.

Work Around:

None

CSCdk50872

Symptom:

The voice quality is bad for a connection between UVM and FTM (3810)

Conditions:

This problem occurs only for the connection between UVM and FTM. The connection between UVM and UVM is fine.

Workaround:

No work around.

Further Problem Description:

The problem was caused by incorrect interface defined between software and firmware.

CSCdk56035

Symptom:

Tag switch controller is not receiving the ifc down trap when the last trunk/port is down. So this situation forces the TSC to discover the ifc down state by timing out on keepalive messages.

Conditions:

When the last trunk or port deleted on a BXM slot.

Work Around:

Disable the BXM trunk or port before downing the trunk or port.

CSCdk56580

Symptom:

CAC Override disable does not work properly when percent utilization is applied. Switch software does not prohibit addcon from adding a connection that makes the port over subscribed even when CAC Override is disabled. Once the port is oversubscribed, switch software allows a connection to be configured to preserve more bandwidth by cnfcon command.

Conditions:

This problem shows up when configuring the port as CAC override Disable and %util enable.

Workaround:

Manually calculate the total bandwidth of connections on a port so that it will not exceed the port speed.

CSCdk59745

Symptom:

The following BNI errors cannot be seen from the detailed display of the dsptrkerrs command.

Tx BDA Ovfl C Drp, Tx BDB Ovfl C Drp, Tx CBR Ovfl C Drp, Tx VBR Ovfl C Drp, Tx ABR Ovfl C Drp

Impact:

The users must use the summary screen for dsptrkerrs and refer to the "TX Cell Drop" column which is a sum of all the TX cell drop stats, or they must use the dsptrkstathist command to look at the 10 minute historical values, however, they will never have the cumulative count for these errors until this defect is resolved.

CSCdk60375

Symptom:

cbtool unable to connect to node

Conditions:

All telnet sockets in use

Workaround:

Log out of a telnet session

Further Problem Description:

Problem can also manifest itself in a failure to reconfigure the LAN IP or NWIP addresses.

CSCdk63019

Symptom:

Long delay in handling card failures such as card removal causing abort 52 if there are a lot of connections on the card.

Impact:

This is a performance issue; it could be serious if it causes abort on a node with lots of connections. The improvement reduces the delay to less than a minute and abort will not happen now.

Further descriptions: The performance problem is caused by a huge number of sanity checking, most of these checks were repetitive--the same checks were done in different functions at different levels. A lot of computed information (e.g. LCCB) were computed over and over instead of being stored in some place and reuse.

Once the repeated amount of work is removed, the performance is greatly improved.

CSCdk63527

BNI VT's can support only 1 traffic class of service at a time and these are limited to CBR, VBR and ABR.

The dsptrkerrs command should only show the traffic class of service drop errors that are valid for the specified virtual trunk.

However, it is showing all 9 traffic classes of service.

CSCdk63922

Symptom:

dspport on a card returns error instead of displaying the port.

Workaround:

This happens only when the card is in the first slot.

CSCdk65971

Symptom:

VSI requires BCC with 4MB BRAM (BCC3-64 or BCC4). This requirement is currently not enforced by the user interface. The user is able to enable partitions, add VSI controllers or configure VSI qbins when the BCC does not have the required BRAM size. The operation should be blocked in this case.

Conditions:

This error can be reproduced with any BCC with less than 4MB BRAM.

Work Around:

Use BCC with 4MB BRAM (BCC-3-64 or BCC-4)

CSCdk66317

Abstract:

There are no commands to easily see which VC_BW_PARMS is currently being used on the connection.

Workaround:

Execute dcct on each connection to see the parms index.

Description of new option to the command dvc: Option b will display the current vc bw parms index.

STATIC NODE VC SUMMARY DISPLAY Vc: 7/12000

0: 0 1 1 1 1 1 1 . . . . .

12: . . . . . . . . . . . .

24: . . . . . . . . . . . .

36: . . . . . . . . . . . .

48: . . . . . . . . . . . .

60: . . . . . . . . . . . .

72: . . . . . . . . . . . .

84: . . . . . . . . . . . .

96: . . . . . . . . . . . .

108: . . . . . . . . . . . .

120: . . . . . . . . . . . .

132: . . . . . . . . . . . .

144: . . . . . . . . . . . .

156: . . . . . . . . . . . .

Last Command: dvc b

This means vc 0 is using parms index 0 and vc 1-6 are using parms index 1. Execute dvcparms to see the detail of the vc bw parms.

CSCdk66370

Symptom:

A new field has been added to the dlcon t command. The field, "VC/BW: xx/yy" will display the number of virtual circuits used on the node (xx) and the sum of the entries from the dvcparms t display (yy).

Workaround:

Not applicable.

CSCdk69498

Symptom:

The A-Bit status of a connection is not correctly displayed on LMI failure at the user end over a frame relay NNI link.

Conditions:

Environment is not an issue as this happens on the customers network and in the LAB with just a single node. This problem has only been seen on 9.1.03 and 9.1.04.

Workaround:

No workarounds have been found.

CSCdk70506

Symptom:

In release 9.1, the output of dsptrkerrs of NTM and BTM trunks had some missing statistics. These statistics were available in prior release.

Conditions:

This is only the display problem in dsptrkerrs. The statistics are being collected and statistical alarm are being processed.

Workaround:

To view the necessary trkerrs, use the dsptrkstats for ATM trunks and dsptrkstathist for non-atm trunks.

CSCdk70799

Symptom:

After upgrade, a PVC terminating on a feeder did not return to clear state; remaining in a-bit failure

Conditions:

This symptom was observed while upgrading from 8.4.21 to 9.1. The feeder had over 10000 cons terminating on it.

Workaround:

None.

Further Problem Description:

The cause of this problem is that the feeder has not been able to communicate to the router node using the LMI protocol due to the routing node's CPU being busy with higher priority tasks.

The solution is to use a mechanism similar to the "Feeder Alert" feature implemented for the Network Flooding prevention effort.

A brief description of the resolution is as given below

The feeder alert mechanism is used to resolve this defect.

When a BPX is going through an upgrade or is in the process of switching to the standby controller card, it will do the following.

1. Attempt to send a message to the feeders (AXIS or IPX) indicating to them that the routing node is in the process of switching/upgrade.

2. BPX will stop sending any kind of connection status updates to the feeders.

3. Polling the feeder is stopped and due to this feeder communication failures will not be reported.

On the feeder:

Upon receiving the indication that the BPX is being upgraded or is switching the feeder performs the following:

1. The feeder will stop sending any kind of connection status updates to the BPX.

2. Polling the BPX is stopped and due to that communication failure with the BPX will not be reported.

This functionality is available IF AND ONLY IF feeder alert is enabled via the cnfnodeparm command. (`cnfnodeparm 42 Y')

When the feeder alert is enabled and the BPX sends this message to the feeder there will be no LMI communication between the BPX and the feeder. This will ensure that the end equipment (router) which is connected to the feeders at both ends will not see any change in A-Bit state thus providing data continuity. Since there is no LMI communication any real A-Bit failures at the remote end will not be propagated to the feeder.

When the upgrade/switchcc process is over, regular LMI communication will be reestablished, the A-Bit states are exchanged end-to-end and all the nodes and feeders will have correct A-Bit state.

NOTE

1. The AXIS should be running version 4.0.12 or higher.

2. The feeder alert option should be enabled from cnfnodeparm (option 42)

CSCdk71291

Symptom:

* AutoRoute port interface end point using LCN in the VSI space.

* software error 524 - BAD_CHAN_NM logged on card rebuild

Note 1: To check if a specific connection is using a channel out of range:

- verify channel number (LCN) used by the connection via command dcct - page 3 - field LCN

- get vsi end lcn using dsplogcd - page 2 - field mc_vsi_end_lcn

- in normal conditions mc_vsi_end_lcn should be > than LCN

Note 2: To check if any connection in the port card is using a channel out of range:

- get vsi end lcn using dsplogcd - page 2 - field mc_vsi_end_lcn

- use dspchmap to display the map of lcns used by connections in the card; in normal conditions no lcn higher than mv_vsi_end_lcn should be associated with an AutoRoute connection.

Conditions:

The following conditions must be true for this bug to occur:

1. AutoRoute and VSI share resources on port BXM card.

2. AutoRoute connections exist on the card.

3. Following sequence of events takes place in the order given:

3.1 - AutoRoute connections were added on the BXM slot.

3.2 - Some (but not all) AutoRoute connections were deleted on the BXM slot.

3.3 - With some of the original connections programed in 3.1 and not deleted in 3.2 the number of pvc lcns is decreased on the BXM slot using cnfrsrc.

3.4 - With some of the original connections programed in 3.1 and not deleted in 3.2 and after pvc lcns are decreased in 3.3, the number of vsi lcns is increased on the BXM slot using cnfrsrc.

Workaround:

- To fix the problem: Delete and re-add AutoRoute connection

- To prevent the problem: Do not reduce pvc lcn configuration with active AutoRoute PVCs in the slot.

Note: As part of the changes to fix this bug a new parameter last_ar_lcn_used that represents the highest lcn used by AutoRoute has been added to the second page of the dsplogcd screen. This value should always be less than mc_vsi_end_lcn.

CSCdk71298

Symptom:

On a BXM feeder trunk, there may be some dangling connections. This may impact user traffic.

Conditions:

The dspcons on a BXM feeder trunks does not match at two endpoints. The dspcon screen is shown properly on one endpoint, however, on the remote endpoint, the dspcon screen also show that the connection exists. However, if user do dspcon, the system response with connection does not exists.

This problem is very rare.

The cause of this is under investigation.

Workaround:

* Try to delete and re-add the connection.

* A new command "rbldcondb" has been added to BPX/IGX/IPX to rebuild the con database and check/remove any inconsistencies in between LCON and VC databases. This command does the following things:

- Checks the VC_DB against LCON DB and removes any inconsistencies.

- Checks the LCON DB against VC DB and removes any inconsistencies.

- Checks the via connections and removes the inconsistencies.

- Rebuilds all the logical endpoints for all the connections on the node again.

This command should be run only under the following conditions:

- There shouldn't be anything going on in the network i.e. no network modifications or connection modifications.

- There should be ample IDLE time on the node. Ensure this using the dspprf command.

This command is password protected (same password as cnfswfunc) and should be used only by the DEs or the field support people.

Further, the database inconsistencies, if any, will be removed and an update will be sent to the standby. However, to rebuild the logical endpoint database, user have to VT to the standby processor card and run this command separately. However, this isn't necessary because the logical endpoints are built separately on the active and the standby processor cards.

CSCdk72033

Symptom:

Some conns got rerouted during upgrade from 8.4.21 to 9.1

Conditions:

Same as above

Workaround:

Route the conns back to their original path after performing the upgrade.

CSCdk72708

Symptom:

Changed the PAR string to be AAL/5 string.

Conditions:

This only affects on the display and addshelf commands for the popeye shelf.

Workaround:

None. User will see the string of `AAL/5' instead of `PAR' for the PAR feeder. The following commands are affected: dspnode, dsptrk, addshelf.

CSCdk73507

Symptom:

Allow to set trunk TX rate (atmTrkXmitRate) to a value less than statistic reserve in SNMP.

Conditions:

When PDU of a set request does not contain object atmTrkStatRes.

Workaround:

Always set statistic reserve to a reasonable range when change the TX rate.

CSCdk73537

Symptom

The default % utilization for VAD type of connection is 40%. As this is too aggressive, it has to be changed from 40% to 60%.

Workaround

cnfchutl can be used to set the % utilization to any desired value.

CSCdk74247

Symptoms:

Communication failure being declared by BPX and AXIS under network flood.

Conditions:

The BPX does not send a feeder alert under NW flood conditions. The current implementation on the BPX sends a feeder alert to AXIS only when the BPX is degraded.

Workaround:

None.

CSCdk74302

Symptom:

The card status is being shown incorrectly as "FRI : OK" when command dspcon is given for a frame relay connection.

Conditions:

The connection was established between a channel on the UFMU card on the local node and a channel on an FRM card on the remote node. `dspcon' command was given to see the details of the connection.

Workaround:

Since the backcard for an UFMU card is UFI and not FRI. The dspcon command should display the status of the backcard as "UFI: OK" and not "FRI:OK". Changes were made in the dspbkstat() function in dspcon.c file.

The problem has been fixed for releases 9.1 and 9.2

CSCdk75382

Symptom:

10% of the time the modem upgrade failed.

Conditions:

This happen randomly.

Workaround:

Try again after failed.

Further Problem Description:

This problem is caused by a race condition in software. It occurs only about 10% of the modem session.

CSCdk75433

Symptom:

Software error 921 is getting logged on slave end when one tries to do an addcon for a non-existent line.

Conditions:

Port number supplied for slave end should be greater than what's supported on that card.

Workaround:

Check for lines on the slave end before adding a connection to make sure that it exists.

CSCdk76425

Symptom:

Software error 961 (BD_CHAN_INDX) is logged on BPX node.

Conditions:

The above software error may be logged on a BPX node. This condition may occur on a BXM when number of channels in LCCB is different from the actual number of channels the card support.

f_ln() is using physical slot instead of logical slot for nm_chs_per_slot()

Work around:

Make sure that physical and logical card has same number of channels before dntrk. (Setnovram can be used to reduce the number of channels)

CSCdk77200

Symptom:

+ cnfln, dsplncnf, and dspportstats do not work in 9.1

Conditions:

- After upgrading to 9.1.06 from 8.2.56

- This was also seen in the lab at 9.1.03, and 9.1.t5

Workaround:

An ALM-A line does not have a logical line number, it acts a trunk and thus is associated with a logical trunk number.

Do a "dnib" to find the logical trunk number, lets say "a", for this ALM-A line. Do "dlns" to find if that whether logical line number "a" is occupied or not. If yes, then dsplncnf for ALM-A lines will work. If not, do "upln" on other cards to activate logical line number "a". Then dsplncnf/cnfln for ALM-A lines will work properly.

Further Problem Description:

A possible workaround would be the substitution of UXMs for the ALMs, although there are logistical issues for this solution.

CSCdk77771

Symptoms:

UVM connection may show discards.

Conditions:

The node (network) has UVM cards, UXM cards and are in release 9.1.xx.

Detailed Description:

Note: FPA = fast packet address, CBA means cell bus address

In 9.1.xx switch software overloads CBA and (dc,chaddr). If a cell connection and a voice connection from a UVM connection get the same address, then the UXM will be putting FP and Cells on the bus. The UVM HARDWARE is unable to discard the cells. So, if the sink CBA of a cell connection (via node) and the sink (dc,chaddr) for a voice connection on the same node, are both (10,04), then UVM will start discarding data.

If a node has a UXM - UXM trunk and a UVM endpoint card. Say a cell connection using CBA X is going between UXM-UXM. Say the same FPA X is used on the UVM, then this problem could appear.

The probability of this problem is pretty low, happening with the following conditions all together:

- VIA node (typically)

- UXM -UXM trunk on the via node

- OR UXM-trunk <--> UXM port card on the node

- UVM endpoint on the same node

- UVM using FPA "X", and the UXM's involved use the same CBA "X"

Workaround:

Usually re-routing that UVM connection will force switch software to choose another pair of FPA and the problem goes away. If it does not go away at all, it should be determined which is the CBA and FPA which is colliding and re-route that via connection. Other tricks user can try to force the voice connection to use a different FPA is:

- Delete the connection showing discards

- Add a dummy dax connection

- Add the connection which was deleted

This will force switch software to allocate a different FPA.

Solution:

After loading the new image with this fix, user must execute cnfnodeparm and enabled the "45 - Verify CBA for non-FRP" entry. At this time all non-FRP/ATM connections will reroute.

Prior to enabling the feature, user must delete all local (dax) non-FRP/ATM connections, and add the connections back after the feature is turned on.

CSCdk78656

Symptom:

After 9.1.06 ->9.1.07 update, FRM cards with yred get software error 21.

Conditions:

Y-redundancy configuration on FRM card

Workaround:

Delete Y-redundancy before update and re-add after update.

CSCdk78804

Symptom:

The ACTIVE ARM card goes to STANDBY state after doing switchcc twice on the node.

Conditions:

Same as above.

Workaround:

After each switchcc run the command addalmslot again. This will ensure that the card remains active on the next switchcc also.

CSCdk79433

Symptom:

D4/AMI trunk will not come up on UXM single T1 or UXM IMA.

Conditions:

AMI line coding is not an ATM supported feature. Since the UXM is standards based, AMI is not supported.

Workaround:

Use NTM cards to connect D4/AMI trunks. Use ESF/B8ZS only for UXM T1 trunks.

Further Problem Description:

E1 trunks may not use AMI line coding either.

CSCdk79498

Symptom:

Deactivating a line or trunk when the BXM is missing will cause an abort.

Conditions:

The abort occurs after the following steps are done: 1. Insert BXM

2. Up a line on BXM

3. Remove BXM

4. Down line on BXM

Workaround:

None.

CSCdk79912

Symptom:

The range of MIB variable atmPortPort is wrong. The port number can be greater than 2.

Workaround:

Ignore the range limitation.

CSCdk80637

Symptom:

Response of SNMP object atmPortStatLmiStatEnqRxs is wrong. Counter of atmPortStatLmiStatEnqTxs is returned to NMS. Similarly, response of atmPortStatLmiStatEnqTxs is returned with counter of atmPortStatLmiStatEnqRxs. The two objects are used to count numbers of LMI Status messages received and transmitted.

Conditions:

It happens in SNMP.

Workaround:

To query number of LMI Status messages received, use atmPortStatLmiStatEnqTxs. On the other hand, for LMI Status messages transmitted, use atmPortStatLmiStatEnqRxs.

CSCdk81975

Symptom:

The Feeder alert message that is sent to a feeder when a routing node is in the degraded state may be slightly delayed.

Condition:

This symptom is less likely to be encountered. It may happen if the feeder has not yet acked the previous message when user want to send a "feeder alert" message to the feeder when the routing node is degraded.

Workaround:

None

CSCdk81976

Symptom:

Unable to use cnfnodeparm to enable/disable feeder alert in a mixed network.

Conditions:

This option should be independent of different revisions of switch software in the network.

In a mixed network, this option cannot be altered.

Workaround:

Wait until the entire network is upgrade to 9.1 prior to changing this parameter.

CSCdk82231

Symptom:

The default tone disabled for UVM is set to G.164. The default should be changed to G.165 for UVM. For CVM card, the default should be set to G.164.

Condition:

After the first circuit line is activated on a UVM or CVM slot, the default tone disabled of this slot is set to G.164. The default should be set to G.165 for UVM and G.164 for CVM.

Work Around:

Use cnfecparm command to change the tone disable type after the first circuit line is activated.

CSCdk83798

Symptom:

Regular logging of software error 923 on the standby controller card.

Conditions:

When a node was upgraded from 8.2.56 to 9.1.06, with a trunk in slot 32, the standby controller card regularly logged swlog entries 923. If the node was installed with 9.1.06, this did not occur.

Work around:

Deleting and downing the trunk 32 stops the errors. When trunk 32 is upped and added again, the symptoms do not reappear.

CSCdk85068

Symptom:

Changing IGX ATM trunk parameters with SNMP using the atmTrunks table causes the trunk routing cost of the trunk to be reset to zero.

Conditions:

Changing the parameters of an ATM trunk on the IGX via SNMP.

Workaround:

None.

CSCdk86412

Symptom:

Connection route cost value changes back to default value (100) after a node rebuild on BPX.

Conditions:

Connection route cost value can be changed using `cnfrtcost' command. However, the new value that user configured will not survive a node rebuild. After the node rebuild, the value will change back to the default value.

Work around:

None.

CSCdk89123

Symptom:

Software error 1M3 is logged when dsplog is invoked.

Conditions:

If the Port Concentrator event log entry contain unknown event code, the dsplog command may cause the above software error. The processor will switch to the standby card.

This problem occurs only once in the lab while the port concentrator is being moved around from one port to another port.

Work around:

The first occurrence of 1M3 software log cannot be avoided. If this occurs, invoke the clrlog command to avoid the subsequent error.

CSCdk90163

Symptom:

Node may experience swlog 1M3 when `.' command is used to display the command history.

Conditions:

This problem is found if the `.' command is used followed by a number greater than 6.

This command is enhanced to display the history of user tasks `i' where `i' is the number following the `.'. The `dspusertasks' command shows the number of user tasks on the system. If the user task command history is not initialized, then the node will experience 1M3. User task greater than 6 command history is initialized only if VT is enabled.

Workaround:

Do not enter any number after `.' command. Just use this command to look at current user command history and not other user tasks.

CSCdk25153

Symptom: User cannot use cnfcon in a job.

User uses jobs to adjust PVC utilization. Jobs containing cnfcon or cnffrcon cannot be added containing these commands. For example the job rejects the command "cnfcon 8.1.100 * * * * * * * * 50/50 with error message "too many parameters" Also if trying to change ForeSight using "cnffrcon 8.1.100 * * * * * * * n", the error message "util must be between 0-100" will occur.

Conditions: Under all conditions. User adding a "cnfcon" to a job

Workaround: None.

CSCdk34764

Symptom: The problem occurs when the user adds an atfr (atm to frm) connection, specifying the number of cells when entering the vc q depth. The max allowed is 1366 cells which translates to (1366 x 48) 65568 bytes. That is greater than the max number of bytes 65535 allowed. The code checks the entered value, 1366, in order to make sure that it is not out of range. It does not round-off the bytes value after converting cells to bytes.

This fix adds code which makes sure to round-off the max number of bytes to 65535.

Conditions: addcon atm to frame conn (atfr)

Workaround: None

CSCdk43180

Symptom: YELLOW alarm condition does not recover on FRP when RED alarm recovers. When an FRP-E1 line experiences Loss of Signal (a RED alarm), and the LOS then clears, the line shows Clear-Ok but the equipment attached to it still receives a Yellow alarm. When the connection to the external equipment is removed and the FRP port is looped back on itself, the line then shows "MAJOR - Rmt Oof (YEL)".

Conditions: This happens if cnfclnsigparm 9 "CDP & CIP Condition CCS Lines?" is set to "Y" on E1 CCS lines and the line experiences a Loss of Signal.

Workaround: If the problem described above has not been encountered, the way to prevent it is by configuring cnfclnsigparm 9 to `N'. If the problem has been encountered, the way to recover is to configure cnfclnsigparm 9 to `N' and then execute the dncd and upcd commands on the card with the problem. The dncd/upcd sequence will reprogram the line database with the new value for cnfclnsigparm.

CSCdk43700

Symptom: On a standby NTM or NTC card with BC-SR (Subrate) backcard, the system logs software error 923 after user resets the card using `resetcd' command or after the configuration is cleared after `clrcnf' command.

Conditions: The system logs software error on standby by NTM or NTC card with BC-SR backcard. This occurs only if the card is in standby mode and with BC-SR backcard. If the card is in active state or if other backcard (BC-T1 or BC-E1) is used, the error does not occurs. This error is not harmful since it is logged when the card is not in active mode, i.e. not in use. There is no traffic impact.

Work Around: None. The error can be ignored.

CSCdk45040

Symptom: The removing or recovery of the primary or secondary clock sources from the network can cause the standby BCC momentarily get out of sync.

Conditions: Standby BCC-3-32 goes into UP Failure when Primary clock source goes into Bad Clock Source.

Work Around: 1. Delete the clock source

2. Switch to the internal oscillator *or* clear the alarm with "clrlnalm 16"

3. Readd the clock source

CSCdk48794

Symptom: The addlnloclp user command does not check to see if Alloc_mem succeeded before using the pointer that is returned. As a result, an abort can potentially occur.

Condition: Run the addlnloclp user command when there is no memory available.

Workaround: Make sure that there is memory before using the addlnloclp user command.

CSCdk48969

Symptom: For CVM connections, the addcon user command does not take into consideration the number of channels in the specified rate when validating the user input. Thus, a connection can be added on the signalling channel.

Condition: Specify a rate and a channel where the num of channels in the rate + the specified chan number crosses the signalling channel

.Workaround: Since addcon does not protect against this condition, the user must protect against it himself.

CSCdk49257

Symptom: Software error 2058 is logged (one or more times) after upping a BXM T3 or BXM E3 line or trunk.

Conditions: Software error 2058's will continue to be logged filling the software error log, as well as some 2059's and 2071's. This will most likely occur on a BCC-32, when the user has many (more than 20) trunks or lines up and attempts to up a BXM T3 or E3 trunk or line.

Work Around: When the user receives 2058's after upping a trunk or line. Immediately down the trunk or line, and then use the command cnfnodeparm to adjust the Stats Memory Value to be smaller than it currently is.

Stats memory is shared between TFTP and AUTO statistics. By making this value smaller, the memory is taken away from TFTP stats and give it to AUTO stats.

After reducing the stats memory re attempt the upping. User may need to repeat the downing, adjustment process until the error is no longer occurred.

Normally, this is an automated process, but the defect is causing this extra work.

CSCdk55325

Symptom: The `dsppwr' output screen shown power supply as "Unknown" and Status of that Power supply as "OK".

Conditions: This symptom occurs with Power Supply Monitor firmware revisions AR and AS. The revision is displayed on the `dsppwr' output screen.

Workaround: If the Status column of the `dsppwr' output screen is not blank and the Power Supply State is shown as "Unknown" then consider the Power Supply State as "Present".

CSCdk55331

Symptom: Maximum PVC LCNs shown on cnfrsrc screen of BXM port card are set to 256 incorrectly after upgrade from 8.4 or 8.5 to 9.1. As a result, the user may be able to add more connections to that port and exceed the Maximum PVC LCNs limits shown on cnfrsrc screen.

Conditions: On BXM port card, if user has more than 256 connections added on a port prior to upgrade to 9.1, then after upgrade to 9.1, the cnfrsrc command (which is new in 9.1) will show that the maximum number of PVC LCNs is 265 which is incorrect. This number should be set to the total number of connections currently existing on this port.

Prior to upgrade, if there are less than 256 defined on a BXM port, then this problem does not exist since the default maximum PVC is defined as 256 in cnfrsrc command.

Work around: Use cnfrsrc command to change the Maximum PVC LCNs to same number of connections currently exist on the BXM port. User can count number of connections using dspcon command or use debug command `dsplogcd 112 <slot> to display the total number of connections defined on a port.

PORT[i] line_info

mln_line_num = 0; mln_line_type = 0; mln_portgroup_id=0

mln_pvcs_cnfgd = 500, mln_pvcs_cnt = 500, mln_nw_cnfgd = 0

mln_svc_cnfgd = 0 &mc_lnred_info = 31122034

&port_cnf &ch_info &ch_indx &thisend &PortLccb &TrkXlat

00000000 310C4FD0 310BCFD0 310BC750 31121DB2 310CE0D0

Where i in PORT[i] shown above is the port number (1 base). Use cnfrsrc command to change Maximum number of PVCs to the same as mln_pvcs_cnfgd.

With the fix in place, everything works fine if no ports are activated during upgrade and no connections are added/deleted. If any of these is done during upgrade (ie when STBY is either upgrading or in upgraded state), then resetcd on STBY need to be done, otherwise STBY will not be updated with modified values.

CSCdk55494

Symptom: dsppwr command incorrectly displays failure status of the Power Supplies. If one of the AC power input is failed, dsppwr shows that all power supplies are failed. When AC2 has failed, dsppwr shows DC failed instead of AC failed. There is a problem in the way power supply status is displayed.

Condition: This display problem occurs only when the power fails. Under normal circumstances, it's working fine.

Workaround: none.

CSCdk58052

Symptom: Cannot down a line on BXM - get database inconsistency message. In some case, software error 923 or 922 is also logged.

Conditions: If number of lines/trunks on a BXM card is greater than 6. This problem is caused by the size of an array is smaller than it should be. Thus, part of the stack is overwritten causing unexpected result of this command. This problem is found only on the BXM card with more than 6 ports.

Workaround: None

CSCdk59679

Symptom: If comm break occurs due to flooding (excessive messages), doing a "dsplog" on a node having nodename of eight characters causes software error 526

Conditions: same as above

Workaround: None

Further Problem Description: The event log message during comm break is changed so as not to cause software error 526. The word "Communication" is abbreviated to "Comm" in comm break event log message.

CSCdk61630

Symptom: Software error 44 may be logged on BPX after a processor switch (switchcc).

Conditions: The above software error may be logged after switchcc. This software error is harmless. This error can be ignored. This software logged is now removed as a result of this bug fix.

Work Around: None.

CSCdk62544

Symptom: When the PCR of a connection routed on a trunk was increased beyond the bandwidth that the trunk had available, the bandwidth on connection did change but the connection stayed routed on the same trunk and the load on the trunk didn't change.

Conditions: Same as above. Happens when configuring a connection.

Workaround: None

CSCdk64349

Symptom: The Trap Reason 3107 for the Card alarm is generated from the switch but has no associated StrataView Plus Trap.

Conditions: This trap reason can be generated in a Card Alarm received from the switch.

Workaround: If a 3107 is received for a node running release 9.1 (9.1 AND 9.1 ONLY) treat that as an Informational alarm with no failure implications.

Further Problem Description: This is a very transient issue present only in this particular 9.1 Build and has no serious implications.

CSCdk64543

Symptom: When configuring a connection as type "td" for D-Channel compression, the connection still takes full bandwidth on the trunk (381 packets) regardless of the utilization.

Conditions: D-Channel compression isn't working on UVM - Model C, Hardware D, Firmware rev A (D.C.A)

Workaround: None

CSCdk64695

Symptom: The dspbusbw command for a secondary UXM is failed.

Conditions: The dspbusbw command is failed for the secondary card only. It still works for the primary card.

Workaround: execute the dspbusbw command when the primary card is running.

CSCdk64852

Symptoms: Software error 1012 is logged on STBY-BCC running 9.1 during 8.4 - 9.1 upgrade.

Conditions: This is logged from incr_num_chans, when effort is made to increase number of allocated channels beyond max number that can allocated in a particular port group.

Work around: None

CSCdk64867

Symptom: The command "switchyred" on Y-redundant cards allowed even when standby has no backcard.

Conditions: Same as above

Workaround: Make sure that standby has backcard present.

CSCdk65207

Symptom: There are two errors related to this defect in `cnfport' on BPX:

- Incorrect error message is given when user changes NNI/UNI port type on a BXM port.

- When changing NNI/UNI port type on a BXM port, the changes is applied to all ports on the same card.

Conditions: The system gives incorrect error message to user when cnfport is used to change the port type of a BXM between NNI/UNI type.

The system does not allow user to change port type if there is at least one connection defined on that port. The message is misleading indicated that all connections must be deleted from the card.

When user change port type from UNI to NNI or vice versa on a BXM card, the changes will be applied to all ports on the same card. For example, if user changes port type from UNI to NNI on port 1, the system will automatically changes the port type from UNI to NNI on all ports on the same card.

This problem is now fixed such that user can change the UNI/NNI on a BXM port independently. The error message is also changed to inform user that the port type cannot be changed if there is at least one connection defined on that port.

Workaround: None.

CSCdk65393

Symptom: Loadrev 9.1.03 causes IPX-32 bus to fail

Conditions: This problem occurs only on IPX-32 with the following revision of SCC backcard:-

Part number Hardware Version

---------- ----------------

IPX-SCC-6236A= A, B, C, D, E, F, G, H, I, or J

IPX-SCC-6236B= A, B, or C

Note that if the latest SCC hardware is used, then this problem will not occur.

Workaround: Replace SCC card with latest revision. Otherwise, waits for this problem to be fixed in SW.

Further Problem Description:

It is not possible to determine the SCC hardware from SW, user must pull out the SCC backcard from the slot and look at the revision number written on the card. The latest revision of SCC card was introduced approximately in 1995. If the customer has installed IPX-32 prior to this date, it is more likely that old revision is used.

CSCdk65743

Symptom: Software error 52 in dspswlog with VT_1 as running process

Conditions: One-time occurrence of a watchdog timeout on a BCC while VT'd in from another node

Work Around: No workaround

CSCdk65967

Symptom: In the command cnfrsrc, when configuring the vsi min & max bandwidth, it is possible to go over the maximum bandwidth. For example, at the vsi min bandwidth prompt, enter a huge value (10000000) and the available bandwidth will be displayed. This value does not reflect the real limit. If you enter this value the command will accept the configuration, but when you execute cnftrk and just hit return, cnftrk will fail.

Conditions: CNFTRK will fail only if the available bandwidth limit is entered for vsi min & max bandwidth.

Workaround: The command dsprsrc will display the max pvc bandwidth, always use this number as the limit of the bandwidth before configuring the vsi min & max bandwidth.

CSCdk67128

Symptom: Port card (UFM-U or FRP-V35) are in yred configuration. Resetting one or both of the cards causes the card to go into mismatch with reason: "Backcard is reserved for Missing"

Conditions: Yred configuration on port cards. Upped ports and then downed all ports. This causes backcard type of primary slot to be cleared.

Workaround: Delete yred configuration. Mismatch clears. Readd mismatch configuration.

CSCdk67790

Symptom: User may experience LOS on a BXM port with loopback.

Conditions: This problem is found on BXM 12-ports port card with a Y-red pair. The port is also configured with line loopback using `addlocrmtlp' command. After user enters dncd on an active BXM card, the secondary card becomes active and those lines may experience a LOS alarm temporarily (5 seconds.)

Workaround: None.

CSCdk68206

Symptom: UXM IMA trunk temporarily shows Comm Fail after dncd/upcd command is entered. Dsplog shows misleading information.

Condition: On IMA trunk with multiple physical lines, if dncd/upcd is entered, the trunk will go into comm failure and cleared. However, the event log may contain misleading information indicating that IMA trunk is OK while the dsptrks screen shows that the trunk is in comm failed. This condition is temporary and the comm failure is cleared on the next comm test.

Work Around: None. The comm failure is expected after dncd/upcd operation.

CSCdk69204

Symptom: Cannot addyred between BXM cards which are running M.C.B firmware and M.B.X firmware. Wrong error message is reported: "This card pair is incompatible due to channel support"

Conditions: This message is incorrect because slot 5 and slot 6 do have the same channel support, but do contain BXMs with different versions of firmware. The failure is due to incompatible VSI support. This can be checked with CLI command "dspcmi p".

Workaround: Get another BXM card with compatible VSI support and addyred again.

CSCdk69440

Symptom: `dspprf' shows IDLE very low when many UVM cards in IGX chassis with switch software 9.1.04

Conditions: `dspprf' is as low as 27%

Workaround: When turning off either `off2 1' or `off2 10' or `off1 16' parameters the idle time rises to over 70%.

Disabling Modem Test (off1 16) will disable modem upgrade detection capability on the node.

CSCdk69942

Symptom: CVM connections following firmware upgrade to BDC and software 9.1.04 are staying toggled to Modem even after the actual traffic has stopped. These connections do not return to an off-hook or on-hook state until they are deleted and readded.

Conditions: See further problem description

Workaround:

1. Configure the channel utilization to default (40%) or to another acceptable value (see Further Problem Description).

2. Do the following:

- Delete and re-add the connection to clear the fast modem condition.

- Disable V.25 modem detection on the channel.

Further Problem Description:

Background:

When the modem polling state machine runs, it checks a number of conditions before attempting to downgrade a fast modem connection. These checks are done on a per channel basis. One such condition is whether the connection has V.25 modem detect enabled. To determine this, software checks the CDP channel data base for the value of the fmodem field. The field is zero if modem detect is disabled. You can view the database with the command dspchan.

Problem:

There is a coding error in 9.1 that causes the software to read the wrong field in the database. The channel utilization field is read instead of the fast modem field. As a result, connection upgrade/downgrade performance depends on the configured channel utilization value.

When checking for the V.25 modem detect state, The software erroneously checks the data structure for bit 5 of the ch_util (size: 1 byte) field. If the bit is set, modem detect is enabled. So, we need to ensure that bit 5 (zero-based bit count) of the ch_util byte is set (1) for modem upgrade/downgrade to work properly.

for example:

If the channel utilization is 75%, the 8-bit binary representation is...

01001011

^-------- Bit 5 is not set, so modem downgrade fails.

if the channel utilization is 40%, its binary representation is...

00101000

^-------- Bit 5 is set, so upgrade/downgrade works.

So any utilization value that sets bit 5 will allow proper modem upgrade/downgrade performance.

CSCdk71286

Symptom:

The number of vsi (Virtual Switch Interface) channels allocated when the partition is set up for vsi channels is sometimes less than the actual number configured by the user.

Conditions:

This is only a problem if all the following are true:

* if a VSI controller is used on the BPX switch

* partition is enabled through the cnfrsrc command

* for BXM-OC3 and BXM-OC12 cards which supports VSI

* if for port group 1 the sum of mins is greater than the max of max and for port group 2 the max of max is greater than the sum of mins.

The current formula used to derive the number of channels to allocate is:

Max(Sum (Sum (Sum(min_lcn))), Sum (Max (Max(max_lcn))))

all all all all all all

pgs ifcs parts pgs ifcs parts

in in in in in in

card pg ifc card pg ifc

The actual formula should be:

Sum( Max(Sum (Sum(min_lcn)), Max (Max(max_lcn))))

all all all all all

pgs ifcs parts ifcs parts

in in in in in

card pg ifc pg ifc

NOTE: BXM-OC3 & BXM-OC12 cards have more than one port groups

pgs - port groups

ifcs - interfaces

parts - partition

min_lcn - vsi min channels

max_lcn - vsi max channels

Workaround: I

f there are AutoRoute and vsi sharing the same resources: before loading the new image with this fix, verify that 1. For port group 1 the sum of mins is greater than the max of maxs and for port group 2 the sum of mins is greater than the max of maxs or 2. For port group 1 the max of maxs is greater than the sum of mins and for port group 2 the max of maxs is greater than the sum of mins

CSCdk71360

Symptom:

Fatal SAR errors. BCC reset.

Conditions:

As a result of Tx-BIP-16 errors

Workaround:

None.

Further Information: November 20, 1998 Release CT

The SAR detects one Tx BIP-16 errors which it logs as fatal. This causes the BCC to reset. The change was to integrate this Tx BIP-16 errors over a 10 second period. If 4 or more errors are detected then a fatal error is reported.

CSCdk71951

Symptom:

The Yred CVM became mismatch after an upgrade from 8.4.21 to 9.1.06. All the connections terminated on the card were failed.

Conditions:

The mismatch condition occured for Y-red CVM only. Non Y-red CVM upgraded successfully.

Workaround:

Delete the Y-red before running the upgrade. Add the Y-red back on after successfully upgrading to 9.1.

CSCdk72959

Symptom:

System was rebuilt while it should have gone to degrade.

Conditions:

The failure to degrade was due to the processor using too much time in an interrupt routine while preparing to degrade. The excessive time was spent freeing stats memory. This would only happen when the stats memory was maxed out.

The fix was to use reserved memory when degrading and freeing stats memory later in the process when we are not in an interrupt routine.

Workaround:

None

CSCdk75382

Symptom: 10% of the time the modem upgrade failed.

Conditions: This happen randomly.

Workaround: try again after failed.

Further Problem Description: This problem is caused by a race condition in SW. It occurs only about 10% of the modem session.

CSCdk78299

• Symptom: 1000003 abort during upgrade of the network.

• Conditions: Happens randomly.

• Workaround: none.

• Further Problem Description: Node goes through rebuild. No configuration is lost.