9.1.19 Version Software Release Notes
Cisco WAN Switching System Software

CSCdk48364

Symptom:

After upgrading from 8.4 to 9.1, a software error 1017 is logged.

Conditions:

An abort occurs on the standby processor, which is running 8.4.21, during the runrev. This precludes the standby from remaining in the locked state.

This appears to be a small window of vulnerability in our basic runrev mechanism. The locked standby was lost, making it impossible to switch back to 8.4.21, but when a loadrev of 9.1 was executed, that completed successfully.

This problem is caused by hardware failure in a small window when user is executing runrev.

This is in actuality an 8.4 problem.

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

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 a 9.1 release 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 effect of the non-dax OE LCN field not being set to zero in pre 9.1.15 releases during a connection add.

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

CSCdm24829

Symptom:

There are two symptoms for this problem:

1. After successfully adding a new connection from the BPX end using standards based (Bc, Be) bandwidth parameters, the connection cannot be modified from the IGX end using cnfcon. The following error string is displayed: "MIR and/or QIR cannot exceed the PIR at remote end"

2. When adding a connection from an IGX to a BPX the following error is displayed: "MIR and QIR cannot exceed the PIR at remote end"

Conditions:

Using Standards Based (Bc, Be) Frame Relay parameters. Be which is not default (not */*).

Workaround:

Use proprietary bandwidth parameters or default (*/*) Be.

Further Problem Description:

When the Be is default, the internal peak on the BPX may be 0, but the BPX assigns the lesser of the port speed on the BPX, or the maximum FRP port speed (16384000). When the Be is not default, the BPX does not override the internal peak. If the internal value for the peak is 0, an error will be returned to the IGX because the peak (0) is less than the MIR and/or QIR.

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.

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.

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

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 using the 'delcon X.X.X' command. The non-DACS type connections only existed on one network node (e.g., had only 1 logical endpoint). Some connections where shown as using the same slot as an NTM (invalid logical endpoint). Software errors 537 were being logged against the invalid connections.

IWorkaround:

The connections were cleaned up by switchcc, rbldlogepdb, and patching VC and LCON memory.

CSCdm60699

Symptom:

Port configured for Annex_D LMI and Async updates will send async updates showing a PVC is active when the PVC's VCQ fills to approx 75%, and reduces to 25%.

Conditions:

No relevant conditions are required in the network to see this problem other than the connections VCQ filling. The problem was noticed after the customer started a program to reduce the size of connection VCQ's. It can cause competitor router DLCI's to lock up. The only way to restore the competitor DLCI is to either DOWN and UP the PVC, or reset the competitor DLCI.

Workaround:

Customer can switch Async Updates off, however this does prevent the CPE from detecting a change in PVC status until a full status is sent by the switch. Customer can try to make sure the VCQ does not reach 75% by using foresight, and making sure there is enough bandwidth in the network to prevent congestion

If Async Updates must be left enabled, the following step can reduce the amount of Async Updates caused by exceeding the RNR Thld:

This workaround measure will reduce the amount of Async Updates due to reaching the RNR:

1) temporarily configure the port to Stratum LMI

2) change Upper RNR Threshold to 100% [leave lower RNR Threshold as is].

3) change the port back to the other LMI [such as Annex D].

This will force the VCQ level to be at 100% before an Async update is sent due to exceeding this level.

Further Problem Description:

The Async Update is sent because the VCQ level exceeded the Upper RNR Thld [as shown on the 'cnfport' screen]. Once the upper RNR thld is reached, when the VCQ level falls below the Lower RNR Thld, another Async Update is sent. The default Upper/Lower RNR Thld is 75%/25%.

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.

CSCdm68934

Symptom:

Inconsistency behavior of virtual trunks

Condition:

When there are more than one virtual trunks from a BNI-BXM pair and changing 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.

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

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.

CSCdm78174

Symptom:

The Card is Reset when a trunk on the BXM-E card is deleted. This causes 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

CSCdm78257

Symptom:

UXM cards are in Y-red. If they are firmware revision AAD and customer want to upgrade to firmware AAE. After burn in firmware AAE will yield the message cards are mismatch.

Conditions:

IGX's UXM cards with firmware rev. A.A.D or previous cannot be y-red with UXM firmware A.A.E

Workaround:

Should upgrade firmware on maintenance window by delete y-red. Upgrade each card to AAE then add y-red.

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.

CSCdm92535

Symptom:

Upgrade from 8.2.56 to 9.1.15 causes Fastpad Connections corrupted.

Conditions:

upgrade with Fastpad connections.

Workaround:

none.

Further Problem Description:

Only FastPad connections are affected after upgrade. Connection type sessions were changed to be FR and if issue dcct on the original connection it'll display: Illegal endpoint for connection. If issue dcct on the corrupted connection it'll display: Connection does not exist

CSCdp10434

Symptom:

After IGX upgrade to 9.1.15, session PVC between two FTM ports can not transmit voice data from 3810.

Conditions:

Problem occured after FTM upgrade firmware.

Workaround:

No workaround needed. The problem is caused by FTM firmware, not IGX software.

CSCdp27157

Symptom:

When a failure occurs in only one direction of a full duplex connection SWSW 'fails' the pvc and thus blocks the RDI cells from the downstream cpe from traveling through the good leg of the connection to the upstream cpe.

Conditions:

Problem occurs when one direction of a full duplex connection fails and the ingress UNI detects LOS.

Workaround:

None

Further Problem Description:

According to the ATM standards, AIS and RDI should operate as follows when a failure occurs in only one direction of a pvc... When a failure occurs in only one direction of a full duplex connection, the node downstream from the failure generates an AIS alarm which propagates to the other connection end. The CPE at the other end, in turn generates an RDI signal which travels back across the connection (on the good leg) to notify the upstream CPE of the connection failure. Without the RDI signal, the upstream CPE is not aware that the connection failure is on it's transmit leg.

The problem logged here is that when one end of the UNI in the BPX network detects a LOS due to one direction of the connection failing, SWSW 'fails' the pvc and thus blocks the RDI signal from traveling through the connection from the downstream CPE to the upstream CPE.

CSCdp28931

Symptom:

The BXM-155-8 does not generate a Path RDI when a Loss Of Cell Delineation occurs as required by ATM Forum UNI 3.1.

Conditions:

The cell header so Loss of Cell Delineation occurs. The SONET "PATH RDI" indication is not transmitted as outlined in the UNI 3.1 specification.

Workaround:

None

CSCdp38746

Symptom:

Software errors 418, 501 and 3M logged.

Conditions:

The node may abort

Workaround:

None

CSCdp46812

Symptom:

We are not able to set up tag on release 9.1.17 or 9.1.19. We have tried all different combinations of firmware with this software release and failed. We are pretty sure that this is not a configuration issue as the same configuration works with 9.2 swsw.

Condition:

Either there must be some thing special with 9.1 or some thing broke. The problem seems to be the ospf. We were not able to get the ospf up between two TSCs. we are able to bring up ospf between the tsc and ter on the same node. We have a setup on one of our networks.

Workaround:

None

CSCdp49951

Symptom:

Cannot vt nor telnet to BPX node although it is not unreachable from the rest of the network. CPU utilization raises up to 100% and most of the RT CPU usage is consumed by the TUNL task. The following event in the log indicates the high CPU usage:

Info Cpu usage is 100

Conditions:

Unknown.

Workaround:

Use the command 'cnfcbtunl' to configure the field "Xmit Port Num" to have a different value than 3000, say 2998.

CSCdp51531

Symptom:

Software error code 21 is logged when a UBR connection is added on an ASI-155 card.

Conditions:

- Prior to release 9.1.17, the error is logged when the UBR connection has CLP disabled, and the PCR is less than 10 cps.

- In release 9.1.17 and later, the error is logged under two conditions; when the UBR connection has CLP enabled, OR when CLP is disabled on a connection with PCR less than 10 cps.

Workaround:

No workaround is available.

CSCdp54044

Symptom:

Virtual path connections (VPCs) fail to reroute after a trunk card is reset. Based on information from the "rrtinf" command, there were no VPC conids available at the master node. Also, based on information from rrtinf, VPCs appear to be stuck attempting to route across a VT-wraparound trunk.

Conditions:

- Nodes (BPX or IGX) terminate a mix of VCCs and VPCs.

- Network has a mix of physical, virtual, and VT-wraparound trunks.

- VT-wraparound trunk(s) configured such that "VPC Conns disabled" parameter is set to "Yes". The trunk that VPCs attempt to use is configured in this manner.

Workaround:

Select new routes for the connections using the "cnfpref" command.

Solution:

The "VPC Conns disabled" trunk configuration parameter does not impose a VPC route restriction. Setting the parameter to "Yes" allows connections to use conids typically reserved for VPCs to route across the trunk. The parameter was added to alleviate connection addressing problems encountered when using VT-wraparound trunks with some public ATM networks. Since VT wraparound trunks don't support VPCs, yet still appear as physical trunks to the software, it's assumed that the customer will take action to ensure that VPCs won't route across them.

For example:

1. Use preferred, directed routing for VPCs. If the preferred route is not available, the connection fails.

2. Configure VT wraparound trunks as "Satellite" links, and configure the VPCs to avoid satellite links.

CSCdp54097

Symptom:

After attempting to delete a VSI partition on a BXM trunk using the "cnfrsrc" command, certain trunk parameters still cannot be modified using "cnftrk". The following message is observed:

"VSI configuration active on card. Cannot modify ESP parameters."

Conditions:

Use of VSI partitions on BXM trunks.

Workaround:

No workaround is available. The trunk must be deleted and added to remove parameter editing restrictions.

CSCdp57089

Symptom:

After joining a network running a 9.1.19 test version (9.1.1W) with another network running 9.2.22, one of the 9.1.19 nodes was reported as unreachable. All 9.2.22 nodes saw the node as unreachable. The node was reachable from all nodes in the 9.1.19 network.

Note: This condition could not be reproduced.

Workaround:

Delete and re-add the trunk connecting the two networks.

CSCdk45354

Symptoms:

Equipment connected to HDM reports 'clock error'.

Conditions:

HDM<->UVM data connection.

Workaround:

None

CSCdk53336

Symptom:

tstdelay always reports 0 ms.

Conditions:

When the connection is on the port two.

Workaround:

None

Further Problem Description:

When the tstdelay command is executed on the connections added on the port two tstdelay reports 0ms

CSCdk60213

Symptoms:

Customer traffic interrupted (errors occur on external equipment) when background diagnostic tests are executed.

The following background test failure may result:

Last Test Packet Transmitted (Payload Only): 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

Last Test Packet Received (Payload Only): F7 B1 10 0B C6 01 F5 53 A1 65 2D 7B 55 45 9B 0F

Note, the Packet Received is not a sequential pattern which would be typical of background diagnostic test packets, but rather resembles a random pattern typical of user traffic.

Circumstance:

This occurs when the customer traffic bandwidth is very near the bandwidth allocation on the cellbus (within 400 packets/s). For example, an HDM with two 1152 kb/s 7/8 coded ports is allocated 8 UBUs (as per dspubus) (equivalent to 8*2,000, or 16,000 packets/second bandwidth). The bandwidth required for these connections is:

2 * 1,152,000 bits/s / (168 * 7/8) bits/packet = 15,673 packets/s

leaving 327 packets/s spare.

The HDM background diagnostic test consumes approx. 400 packets/s, and thus does not have enough bandwidth to run.

Frequency:

This symptom is 100% reproducible given the above circumstances.

Workaround:

Disable HDM background diagnostics using "cnftstparm" - or -

Add dummy connections to unused HDM ports in order to prevent the "data channel" portion of the background diagnostic - or -

Add a dummy connection to an unused port in such a way to ensure the allocated bandwidth is more than 400 packets/s greater than the actual bandwidth consumed by the HDM.

CSCdm10213

Symptom:

After upgrading from a 9.1 release 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 effect of the non-dax OE LCN field not being set to zero in pre 9.1.15 releases during a connection add.

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.

CSCdp03317

Symptom:

Trunks remains in VT Path fail alarm state.

Conditions:

Usually when ILMI has just been enabled on a cloud port, or UXM VT is left up for some time without being added. Problem should be sporadic.

Workaround:

For the cloud problem down and up the VPC con. For the UXM VT poll issue, path the port field to zero (patch memory)

CSCdp25034

Symptom:

From the point of view of some nodes, a node or nodes get removed from the network. To correct the topology, nodes must be deleted and re-added to the network.

Conditions:

Although the conditions that cause this problem have never been precisely nailed down, it is believed that this occurs when there is heavy network communication going on. External events like trunk outages or node failures can cause the kind of traffic that can lead to this problem. In addition, there must be communication with Cisco Wan Manager as well.

Workaround:

Possible workarounds include:

1. Reduce the number of CWM stations attached to the network.

2. Monitor closely problems that can cause network messaging and eliminate them as quickly as possible.

3. Reduce other parameters that can lead to heavy network messaging, e.g. statistics collection.

CSCdp27598

Symptom:

Unable to enable echo canceller.

Warning issued:

Last Command: cnfchec 15.1.11 e e e e

Warning: Channel Pair Problem

Next Command:

Conditions:

Customer experienced echo on a channel, so they disabled echo cancellation on that one channel, then tried to re-enable it.

Workaround:

None

CSCdp32823

Symptom:

A slow user interface may be noticed. dspprf shows sustained high RT usage in the FAIL process (over 20%). fhstats shows high RT usage for events 0 and 47.

Conditions:

IGX with several cards (FRM or UFM) that have at least one port with NNI enabled.

Workaround:

1. Reduce the number of cards with NNI enabled on at least one port (reduce event 47 on the fhstats display).

2. Reduce the time spent checking for major and minor alarms (reduce the time for each 0 event on the fhstats display) by inducing a major alarm (line or trunk) and minor alarm (line, trunk, clock source, or power supply) on the node.

CSCdp34687

Symptom:

CommBreak every 5 seconds on a BPX running 9.2.22 without any apparent reasons. nwstats on the destination node shows growing number of Bad Coerce Bits.

Conditions:

Rare race condition

Workaround:

Issue the command

nwtst <dest node> 2 1

on the node experiencing the Comm Break. <dest node> is the node it is in Comm Break in.

CSCdp41410

Symptoms:

Fax calls drop out of V25 mode back to voice mode after the first set of queued fax pages have been transmitted.

If the connection is an ADPCM type (a32,c32,a24,c24) then, for the second set, the fax call drops down to a lower speed and continues transmission, which in effect is the same as having a 32K modem upgrade setting in "cnfvchparm".

For higher compression rates (g729a) it was observed that the fax call does not go through for the second set since it is no more in pcm mode.

Conditions:

Fax machines are set up so that they queue fax sets with a delay of more than 5 seconds between each set.

Workaround:

Establish connection as adpcm type (a32,c32,a24,c24) or pcm(p).

OR

Reduce delay between fax sets to less than 5 sec if fax m/c has that option.

Important Information:

This change requires a FW change. With the old FW the resolution will be 20ms, thus the UI will be wrong. With the new FW the resolution will be 40ms.

Before upgrading to 9.1.19 with this change, make sure UVM f/w is upgraded and the gap between s/w and f/w upgrades should be kept minimal.

Please note also the default value is now displayed as 3.2 seconds instead of 1.6 seconds with the old 20ms resolution(20x80).

CSCdp45833

Symptom:

Users of VNS may experience poor voice quality. dspchst on the connections shows data in one direction.

When the command xlat_verify is run software error 332 is logged with FFF1 in the data field. This usually seen on the slave and via nodes of the leftover SVC. The master node shows it as deleted. dspcon on the slave and dspviacons on the via nodes show the leftover conn.

Conditions:

CSCdm86633 in 9.1.16 fixed most occurrences but not all of the dangling SVC conns and hence occasionally poor voice.

Workaround:

Manual updates could be sent through the updates 3 * command to clean dangling SVC lcons.

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 Stats 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 FastPad's 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

Symptom:

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

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, do 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 Portgrp (>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 CommBreak 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 CommBreak with a node that it previously had a SVC connection with).

Further Problem Description:

This problem is tied to CommBreak and call termination. If the network is not experiencing CommBreak 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:

1. constats

2. dsprrst

3. dspswlog d

4. dsplog (showing auto deletions and prior activities)

5. Anything that does not look 'normal'.

6. Input from the customer regarding activities performed on the node.

7. dspsvcst

8. dspsnmpstats

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:

Port: 6.1 [ACTIVE]

Interface: E3-2 CAC Override: Enabled

Type: UNI %Util Use: Disabled

Speed: 80000 (cps) Vc Shaping: Disabled

Shift: SHIFT ON HCF (Normal Operation)

SIG Queue Depth: 640 Port Load: 0%

Protocol: NONE

SVC Channels: 0

SVC VPI Min: 0

SVC VPI Max: 0

SVC Bandwidth: 0 (cps)

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.

ATFTFST ---\

ATFXFST ---/ ATFST

ATFT ---\

ATFX ---/ ATF

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 truely 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

Symtoms:

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 "daisey-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 depricated.

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. telnet, tcp, nwip, and snmp are set to defaults. Lan is configured with IP, subnet, gateway, and default port number. 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 closed 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 MGX 8220 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 MGX 8220 (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 MGX 8220 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 MGX 8220 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 orig 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 corrected 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.

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 (MGX 8220 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   The MGX 8220 should be running version 4.0.12 or higher, and 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 MGX 8220 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 MGX 8220 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 avoid. If this occurs, invoke 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 unharm 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: If 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.

Work Around: 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.

CSCdi83867

Symptom:

The card type indicated in the StrataView Plus maintenance log or on the printer log may be incorrect for port failures.

Conditions:

All releases of software to date. May be observed any time the port failure is not on the StrataView Plus gateway node.

Workaround:

Ignore the card type. The rest of the information in the message is correct.

Further Problem Description:

When a port fails the port failure is reported to the StrataView Plus gateway node. The gateway node builds a port failure message which is sent to StrataView Plus or to the printer. To build this message the gateway node uses the slot number to get the card type from itself. If the card type in the gateway node is not the same as the card type on the node with the port failure, the card type will be wrong.

Example: If an FRM on node A has a port failure in slot 16 the StrataView Plus gateway node will report:

FRM Port 16.3 Failure if the gateway node has a FRM in slot 16

UFMU Port 16.3 Failure if the gateway node has a UFM in slot 16

CDP Port 16.3 Failure if the gateway node has a CDP in slot 16

NTC Port 16.3 Failure if the gateway node has a NTC in slot 16

Card Port 16.3 Failure if the gateway node has an empty slot 16

CSCdj43157

Symptom:

Standby NPM resets. Node event log and StrataView Plus maintenance log show CC redundancy alarm. Software error 100 is sometimes logged. Software abort errors are not logged, and abort profile does not show an abort occurred.

Conditions:

Seen on IGX nodes running software releases 7.4, 8.1 and 8.5.

Workaround:

None.

Further Problem Description:

The active NPM reinitializes the standby NPM after the standby NPM resets its CBUS controller. CC redundancy is lost during the reinitialization. The standby NPM resets its CBUS controller and logs a software error 100 when a problem is detected with the DMA message pointers. These pointers are maintained by the NPM processor and the CBUS controller to transfer messages from the CBUS to the NPM software. It is rare for the pointers to have a problem, but when this happens the only resolution is to resync the NPM processor and the CBUS controller by resetting the controller.

The DMA message pointers on the active NPM may also become invalid, but resetting the CBUS controller on the active CC does not cause a switchover or a loss of redundancy. A software error 100 will be logged.

While there have been many reported incidences from the field, the probability of this problem occurring is very rare, given the total up time of all deployed NPMs. The implications of the rare occurrence of this defect is a loss of redundancy while the standby NPM is updated. This loss of redundancy can be minimized by upgrading to software release 8.4 or above, which have improvements to update the standby CC much more quickly than previous releases.

CSCdk65610

Symptom:

There is no continuity for a FTM - FRM connection after an access device, connected to the FTM, was down and up again.

Conditions:

Configuration: Access_device <-> FTM - FRM <-> Router When the access device was up again the FRM fails to notify the Router with the LMI message.

Workaround:

dncon and upcon the FTM-FRM connection will cure the problem.

CSCdk64237

Symptom:

Node may randomly log software error 514 or 1M3 abort in a large BPX network.

The error could occur in a network consisting of more than 15 BPX nodes. However, it is more likely to occur in a network larger than 30 or 40 BPX nodes.

Conditions:

In 9.1, a feature is added to bundle several networking channel programming on the same CommBus message in order to improve the performance. There is an error in the code such that the loop will not terminate properly if there are more than 15 nodes in the network. This causes memory corruption when the CommBus message is being built beyond 15 nodes. The exact combination of number of BNI trunks and number of nodes that may cause this error is unknown.

This error is found in the lab in a large network with 30 to 40 BPX nodes. In a smaller network, the error was never reported.

This error does not occur if the network is a pure IGX/IPX network or in a mixed network with IPX/IGX/BPX without any BNI trunks.

Workaround:

None.

CSCdk64203

Symptom:

The IGX32 with 9.1.04 is showing software abort with 3M code. The NPM switches to standby processor. After a while the node aborts due to memory not available.

Conditions:

The Y-Red configuration of UFMU was triggering this problem.

Workaround:

No workaround at this time. DE is working on the issue. Identified the following workarounds:

1. Delete the yred configuration

2. Down the secondary of the Y-Red pair, if it is in standby.

CSCdk59581

Symptom:

Bad UVM voice quality over UXM trunk

Conditions:

When user has FST and Voice traffic over the same trunk, the voice traffic may be dropped when the trunk has high utilization. User may also experience that the Fax modem upgrade does not work properly over the same trunk.

This problem occurs because all queues except High priority queue (networking traffic) have the same priority. When congestion occurs, voice traffic will be dropped since it has the same priority as other traffic.

Workaround:

None

CSCdk57214

Symptom:

When Foresight is configured using cnfcon on a UFM-FRP connection, the connection fails.

Conditions:

This happens only on a connection between a UFM card and a FRP/FRM card.

Workaround:

Delete the connection and add it again with desired Foresight parameter

CSCdk56820

Symptom:

Software error 84 appears if a dsplog is done followed by replacing back cards of type SMLR, STM1, STP, UTP

Conditions:

Replace the active back card of 4 port SMFLR with a 2 port SMFLR card.

Workaround:

None

CSCdk56630

Symptom:

While trying to configure a UXM card in an IGX using the cnftrk command that user is unable to select AMI line coding. The default will be B8ZS and user won't be unable to change it

Conditions:

The Line Coding option shown on cnftrk command and cnfln command does not allow user to select AMI. The Line Coding is always default to B8ZS for T1 and HDB3 for E1.

AMI is not supported.

Workaround:

No known workaround

CSCdk55415

Symptom:

Complex Gateway Cells Discard may happen on feeder trunk happen for 8.5-9.1 network nodes.

Conditions:

atfr/atfst connection added from 9.1 routing node to 8.5 routing hub for 2 segment connection. The connection shows up incorrectly as fr/fst.

Workaround:

None.

CSCdk55343

Symptom:

Software error 1417 occurs after comm break clears.

Conditions:

Software error 1417 might be logged after comm break clears and there have been topology changes on the node which was in comm break with other nodes.

This bug will NOT cause any problem except for logging software error 1417 which should not be logged under these circumstances.

Workaround:

None.

CSCdk52672

Symptom:

If a connection is added from a node to some other node which had just done a switchcc, the connection gets deleted.

Conditions:

The slave endpoint of the connection should be on a node which just did a switchcc.

Workaround:

Connection additions should be done approximately 10 minutes after switchcc.

CSCdk51913

Symptom:

EFCN threshold of BdataB queue is incorrectly programmed on UXM trunk.

Conditions:

EFCN threshold of BdataB queue is being programmed incorrectly. When computing the queue depth, the ABR queue size is used instead of BdataB queue. This queue depth is computed using the total queue size multiply by EFCN percentage.

Since the ABR queue is defaulted at a larger size than the BdataB queue, the incorrect EFCN queue depth is probably larger than the value that user want. Thus, as a result the congestion message may not be generate properly.

Workaround:

If ABR queue is not used, set ABR queue depth to be the same as BdataB queue depth. Queue depth of a UXM trunk can be changed using cnftrkparm command.

CSCdk51126

Symptom:

Invalid error message "VPI reserved for VSI" appears while adding connections on cards that doesn't support VSI (ASI/BNI cards)

Conditions:

Add Connections from/to ASI/BNI endpoints

Workaround:

None

CSCdk50761

Symptom:

When a 3810 device fails the associated UVM voice channel is not busied out.

Conditions:

The problem occurs for the voice connection when 3810 fails.

Workaround:

Use T1 or E1 back card for FTM to connect to 3810. Do not use V.35 backcard for this type connection.

CSCdk50102

Symptom:

Switch software sends too many CBUS messages to a BXM card (FnCd = 0x56, OpCd = 1). Switch may log error 105 as well.

Conditions:

Many line/trunk statistics are enabled on a BXM card which has many active lines or trunks. Reset the BCC card.

Workaround:

Disable statistics on BXM cards before reset BCC.

CSCdk49886

Symptom:

BNI trunks will not go into alarm even though the "Transmit Hi Priority Cell Drop" value exceeds the configured statistical alarms threshold.

Conditions:

Having a BNI trunk up automatically starts this statistical alarm, however, it will never work.

Impact:

The user may think that it never has enough Transmit Hi-Priority Cell Drops to cause the trunk to go in alarm, even though it really might.

User can configure the statistical alarm for this statistic, however, it will never be raised.

Workaround:

None. Note: BXMs work fine.

CSCdk49033

Symptom:

There is a problem adding connections from ports 1 and 2 to ports 5 and 6

Conditions:

If the y-redundant card in slot 2 is the active card.

Workaround:

Connections can be added without any problems if the primary BXM is active. Once the connections are up, they function correctly irrespective of which of the two yred is active.

CSCdk49018

Symptom:

After power cycle the IGX node, the local connections terminated on UFM_U card conns will not pass data.

Conditions:

UFM_U dacs conns do not recover on router after IGX is power cycled. Connections appear as OK on IGX, and deleted on router. Only dncon/upcon will recover the connection.

Workaround:

Down the connection then up the connection.

CSCdk48360

Symptom:

While upgrading a UFM (card type) to FRP (card type) connection from 8.5 to 9.1, the connection type gets changed from "fr" to "atfr". This is true for an UFM to UFM connection also.

In mixed network, consisting of 8.5 and 9.1 nodes, UFM to FRP conn added from 8.5 will make the conn appear as "atfr" from 9.1 end and "fr" from 8.5 end.

Conditions:

This problem will be visible only if we have "fr" conns with UFM card as endpoint. So, we will have problem visible in 8.5-9.1 upgrade and 8.2.55-9.1 upgrade, and also 8.5-9.1 mixed network will have the problem in adding conns.

Workaround:

None for the upgrade case. For mixed network, conns added from 9.1 node from UFM card will come up with correct values.

Further Problem Description:

This problem does not have major effect on traffic continuity as conns have proper bandwidth parameters from 8.5, only the new fields which are introduced in 9.1 are defaulted to "atfr" default values.

CSCdk48351

Symptom:

Have some dangling cons on the via node, if some connections from master were deleted when there was a one-way comm-break between the master and the via node.

Conditions:

Same as above.

Workaround:

Doesn't really need a workaround because it doesn't cause any harm.

Further Problem Description:

After a Comm Break a via node sends a VIA_EXISTS_UPDT message if the formerly unreachable node is a master of any of the via LCONs.

The master will respond with a NON-EXIST CM update, and no longer needed via LCONs can be cleaned up.

If however the master was in Comm Break with the via, but the via was not in Comm Break with the master, this exchange does not take place. If a connection was deleted while the master was in Comm Break with the via, the via will not learn about it, and the via LCON cannot be cleaned up.

CSCdk48133

Symptom:

The data sent from the tester is not received back by the tester.

Conditions:

This problem only occurs for an UVM data connection over a feeder

Workaround:

No work around.

Further Problem Description:

The data flow may be received back according to the dspchstats. But it is not sent back to the tester.

CSCdk47544

Symptom:

BPX sends two tstdelay messages instead of one in the Y-Red condition. The other end device will receive 2 tstdelay messages whenever tstdelay command is run on the connection with y-red.

Conditions:

Should have two BXM cards in a Y-red condition. 'tstdelay' should be run on a connection on these BXM cards.

Workaround:

None.

CSCdk47439

Symptom:

FAB number of BCC is missing in dspcd command.

Conditions:

In the dspcd <bcc-slot>, the FAB number is missing from the display.

Workaround:

None.

Further Problem Description:

With this fix, FAB number display of active BCC is added back. For the display FAB number of standby, user must vt to the standby BCC card and do the dspcd there.

CSCdk47426

Symptom:

Voice card circuit lines continuously fail and clear.

8 CVM AFF T1 AL Active

Clear LN 8 OK 09/11/98 18:28:09

Major LN 8 Rmt Oof (YEL) 09/11/98 18:28:08

Clear LN 8 OK 09/11/98 18:28:07

Conditions:

When the lines are terminated with loop back plugs.

Workaround:

After downing the line, it will stop toggling.

CSCdk47253

Symptom:

Query of switchIfMediaType in SNMP might get incorrect response.

Conditions:

This happens when query on BXM T3/E3 cards. The response is sonet instead of ds3.

Work Around:

Use slotBackLnFormat to find out the media types.

t3, e3 - ds3

oc3 or oc12 - sonet

CSCdk47079

Symptom:

For the data and voice connections, the routing takes much more time, even if the connections are all mastered at the same node.

Conditions:

Happens at the time of voice/data connections reroutes.

Workaround:

Doesn't need any workaround. The routing is slow but works fine.

CSCdk45701

Symptom:

For the data and voice connections, the routing takes much more time, even if the connections are all mastered at the same node.

Conditions:

Happens at the time of voice/data connections reroutes.

Workaround:

Doesn't need any workaround. The routing is slow but works fine.

CSCdk45640

Symptom:

Virtual trunk feature can be enabled with CLI cnfswfunc in 9.1 IGX. The feature is not supported in 9.1 IGX. So far no side effect has been observed.

Workaround:

Never enable the feature in 9.1 IGX.

CSCdk45369

Symptom:

The Debug Command scanrgn does not correctly show the address of the allocated block.

Conditions:

Whenever 'scanrgn' command is used the block address field is the same for all the areas displayed.

Workaround:

None.

CSCdk45279

Symptom:

Unable to configure PCR0+1 above 96,000cps because the mib is not updated to do so.

StrataView Plus ConnMgr GUI does user input validation on the values given according to the SWITCH mib.

Following is the extract from SWITCH mib for PCR(0+1).

atmEndptPCR OBJECT-TYPE

SYNTAX INTEGER (50..1412832)

ACCESS read-write

STATUS mandatory

DESCRIPTION "PCR(0+1), Peak Cell Rate, specifies an upper bound on rate at which traffic can be submitted on an ATM connection. This object applies to the First Leaky Bucket for leaving cells with Cell Loss Priority of 0 or 1.

. Units: cells per second.

. Applicable connection types:

UBR, CBR, VBR, ATFR, ABRSTD, ABRFST, ATFST

. Default: 50

. Ranges:

T3 : MCR-96000

E3 : MCR-80000

OC3 : MCR-353208

OC12: MCR-1412832

Limited to 7-5333 cells/sec for ATFR connections."

::= { atmEndptEntry 76 }

According to this definition for T3 interface the range for PCR(0+1) is from 50-96000 CPS and that's what is checked by StrataView Plus.

However, if the line is configured for HEC Cell Framing the port speed is changed from 96000 CPS to 104268 CPS on the switch for BXM-T3 card. And, switch accepts connections with PCR(0+1) value set to this maximum limit.

However, StrataView Plus can't check for this limit and accept as there is no description of this behavior in the Switch MIB and that is the only interface for StrataView Plus connection manager and the SNMP Agent on the switch. Please also note that similar differences may exist for other interfaces like E3, OC3 or OC12 with Cell Framing set to HEC.

Conditions:

BPX Switch Software 8.4.19 BXM card (with M.B.X. of BXM Firmware) StrataView Plus 9.0.03

Workaround:

None

CSCdk45222

Symptom:

Software error 532 is logged.

Condition:

This is because the VC pointer is not valid when we use it.

Workaround:

None

CSCdk44734

Symptom:

The BXM yred pair comes out as mismatch following a graceful upgrade from 8.4.20 to 9.1.0a

Conditions:

Upgrade from 8.4.20 to 9.1.0a

Workaround:

Reset the card when the cards are in mismatch state will clear the problem.

CSCdk44173

Symptom:

Incorrect values reported to line diag and line stats when line/trk is in alm.

Conditions:

When line or trunk is in alarm, two different state machines are running, collecting and resetting stats. The end result is that interval, summary and real time counters are smaller than they should be.

Workaround:

None.

Further Problem Description:

When a line is in alarm, two 0x56 (LINE) stat sample requests are generated. One for LINE_DIAG and the other for STATISTICS.

The problem is that whenever we obtain stats from the card we reset the cards counters, so when both polls are going on simultaneously, they are both only getting part of the information, which causes incorrect statistics and incorrect line diag values.

CSCdk43947

Symptom:

The command tstport port leaves the remote ends of the connections stuck in test mode. The connections do not pass customer data while in this mode. The test mode is identified by performing dspcons at the remote nodes. The connections will be displayed as follows:

6.1.102 igx 24.1.200 TOk fst 0

6.1.103 igx 24.1.400 TOk fst 0

Subsequent attempts to run tstport are not successful because the test aborts.

Conditions:

The problem occurs when running the tstport command on a FRP/FRM V.35 DCE port. The port must have connections, and these connections must terminate on a remote node. The problem has not been seen on ports containing only DAX connections. This problem could also occur on FTC/FTM ports under similar conditions.

Workaround:

Switchcc on the node where tstport was performed.

CSCdk42901

Symptom:

Software errors 111 and 190 are logged on a BPX node with a BXM card.

Conditions:

This defect will be encountered on a card with enough statistics enabled to cause the internal software buffers to overflow.

For example: A BXM T3 card with 12 ports and all the possible (30) line statistics enabled will have ((30 x 12)+ overhead = 360+) more than 360 objects in the message when the Software buffers can handle only 250 at a time.

This defect will be encountered on 8 port and 12 port T3/E3 BXM cards if all the line statistics are being collected.

Workaround:

Disable any statistic types that are not absolutely required for that card.

CSCdk41992

Symptom: There are two symptoms:

1. When raising a circuit line on an UFM-C card, the endpoints on an FRM connection will undergo the following change in the dspcon screen output:

M3206 FRM: OK M3207 FRM: OK

FRI: OK FRI: OK

M3206 FRM: OK M3207 FRM: OK

Line 13: Failed FRI: OK

Note that the endpoint on the local node where the UFM-C circuit line was created changes from FRI to Line 13. In this instance, it was the 13th UFM-C line which was raised, and the connection under investigation was from a FRM card in slot 13.

2. When a UFM/UVM/UXM card is introduced on a node A and lines are upped, there is a chance that cons on FRM V35/x21 on NodeB fail. Here is more concrete example

Assume - Node A has FRM-V35 card in slot 3.- Node B has FRM-V35 card in slot 5.

If you introduce a UFM card on NodeB, and up the lines in such a way that one of the UFM lines get mapped to logical line 3 and let it stay in LOS. Do dspcon on Node A for cons on slot 3. You will see that it is in failed state!

Conditions:

In order for this situation to develop, the Logical Line value set for the connection must be set to the slot and not to the NULL_LLINE value. This can be seen by issuing the command dcct and supplying the connection value you wish investigated.

This problem can occur when you reach a release which support logical lines from a release which does not support logical line.

Examples paths are given.

Pre8.1-8.1-8.2.33-8.2.5x-8.5.06

Pre8.1-8.1-8.4-8.5

8.1-8.2.33-8.2.59-9.1

8.4-9.1

8.5.x-9.1 (provided the fix did not make it to 8.5.x)

etc.

FOR RELEASE 9.1 refer to BUG CSCdk41992

Workaround:

These are the possible work arounds listed in the order of effectiveness, and ease.

1. Delete the connections and re-add them. This approach is cleanest, with least amount of risk and would take the problem away completely and would not happen again!

2. Patch the memory for LLINE for each of the vc on all the FRM cards. Force a write to BRAM and Standby.

3. To workaround connection failures on non UFM-C cards, resolve the problem with the associated UFM-C line. For example put a loop back so that it does not go into alarm!

CSCdk41084

Symptom:

Line and trunk stats are reporting a value of zero even when you know that the value should be non-zero.

Conditions:

This can happen when the secondary card in a y-redundant pair is the active card.

Workaround:

Ensure the primary card for a y-redundant pair is the active card.

CSCdk40766

Symptom:

The modem session for an UVM connection failed.

Conditions:

The modem session always fails for a local (dax) UVM connection. There is only about 5% chance of failure for an inter-node connection.

Workaround:

No workaround.

CSCdk40681

Symptom:

RAM ID & size, BRAM ID & size, Flash ID & size are displayed as NA or string(0) in CiscoView & StrataView Plus.

Conditions:

When access shelfSlotInfoTable in SNMP, the incorrect information is relayed to NMS.

Workaround:

No other way to access the information in SNMP. But, they can be displayed using CLI commands: dspcd.

CSCdk40356

Symptom:

UXM trunk discard alarm occurs on BdataB queue with T1/E1 backcard

Conditions:

Trunk qbin discard is reported on BdataB queue on UXM trunk with T1/E1 backcard.

This problem occurs on a FRM/UFM FST connection with VC queue depth is very low. When UXM trunk on the terminating node is programmed, the connection VC queue depth is used to determine the CLP High/Low threshold on the trunk. If VC queue depth is very low, FRM/UFM will mark the FastPacket to have DE bit set. These FastPackets can be dropped since the VC Threshold is very low. As the result, the trunk qbin discarded alarm is reported.

To fix this problem, the UXM trunk qbin threshold at the terminating node will be set to a default value similar to the via node. The VC queue depth will be used only at the UFM/FRM port card and will not change the UXM trunk's default threshold.

Workaround:

Use cnfcon command to change the VC queue depth to be at maximum.

CSCdk38345

Symptom:

cnfrsrc BXM trunk with PVC = 0 and error 1012 is logged.

Conditions:

Some connections are routed over the trunk and set PVC = 0. This forces a reroute of the connections.

Work Around:

Try not to decrement PVC if connections are routed over a BXM trunk

CSCdk38088

Symptom:

Invalid slot number pass into the function get_log_ptr, therefore we log a software error bad LCD index.

Condition:

Run the command delfdrlp with invalid slot number, software error 532 (BAD_LCD_INDEX) was seen.

Workaround:

None

CSCdk38029

Symptom:

When an 8.2.55 network is upgraded to release 9.1.03, under extreme stress/ trunk load conditions a very few connections are observed to reroute, so as to take a least cost path.

Conditions:

Upgrade from release 8255 to 9103

Workaround:

Configure the preferred route to the routed path in 8.2.55 (cnfpref * +).

The problem is observed only in a case when the trunks are fully (close to maximum) loaded.

CSCdk36573

Symptom:

Increasing trunk stat reserve via 'cnftrk' command always deroutes locally owned connections.

Conditions:

When the trunk stat reserve is increased via 'cnftrk' command, the local node always deroutes connections off that trunk and routes connections again which may or may not be on the same trunk. This is a normal behavior in prior releases. In Release 9.1, optimization is being added to initiate derouting only if the total trunk BW exceeds the available bandwidth. However, this was done only when the local node received update message from a remote node. The same check should be done at the local node as well.

Workaround:

None.

CSCdk34895

Symptom:

The voice quality is not good.

Conditions:

The poor voice quality occurs with intra-node FTM-UVM connections (DAX connections). This is not a problem with inter-node FTM-UVM connections.

Workaround:

No workaround.

Further Problem Description:

The problem is caused by the incorrect PCM A law configuration.

CSCdk34002

Symptom:

Job Trigger can cause a node abort (1000003)

Conditions:

When setting up a job trigger to reestablish default preferred routes when a trunk fails, the execution of that trigger can cause an abort. This may lead to a continuous condition when the standby become active and then it also activates the job.

Workaround:

None; however, setting up a job trigger to handle a trunk failure case should not be used.

CSCdk33721

Symptom:

The connection got deleted because the update message sent from Master node is inconsistent with the Slave node. Software error 614 was logged.

Condition:

During graceful upgrade the software error 614 was seen.

Workaround:

None.

CSCdk33290

Symptom:

Software error 372 was produced.

Conditions:

For BXM trunk, if the total number of connections are more than 12000, then trying to add the feeder trunk onto the same BXM card. The software error 372 (bad VC_NUM 372) will be seen.

Workaround:

None.

CSCdk32946

Symptom:

If we have a IGX with NPM-32 in between 2 IGXs with NPM-64 and the number of connections between the 2 IGXs with NPM-64 is greater than what NPM-32 supports, we can have loading inconsistencies.

Conditions:

Same as above.

Workaround:

Have all the connections between the 2 IGXs with NPM-64 routed over some other via node rather than the middle node, if possible.

CSCdk31996

Symptom:

A downed BXM card comes back up as active on node rebuild.

Conditions:

- Down a BXM card

- Reset the node

- When the node comes back up, BXM will come up as active.

Workaround:

Keep the number of PVCs on the BXM card = 0 (cnfrsrc). So even if it comes up no connections will get routed over it.

Further, if the downed BXM was a trunk, restrict the CC traffic over it so that the switch won't select that trunk for internode communication, even if it comes up.

CSCdk31651

Symptom:

For a connection between a BPX and a port mode card in IPX/IGX, the correct port/line status of the remote card is not displayed. If the remote port has PortCommFail, it is not displayed on BPX in dspcon.

Condition:

This happens only on a connection between a BPX card and a port mode card in IPX/IGX; and by doing a dspcon on the BPX side.

Workaround:

Do a dspcon on IPX/IGX to get the correct Port Status.

CSCdk30129

Symptom:

Incorrect card type reported to Cisco StrataView Plus.

Condition:

On an ACTIVE BXM card, the backcard is pulled out, and replaced with a backcard with a different sonet mode (ie, replacing an SMF backcard with an MMF backcard). In this case, the Cisco StrataView Plus would still show the old backcard type (ie the SMF in this example).

Workaround:

Switch active card to standby state before replacing the backcard.

CSCdk29850

Symptom:

The protocol type value for an FRP port in the Cisco StrataView Plus database is 0.

Conditions:

Whenever a FRP port is added to the node, the Cisco StrataView Plus data base is updated and receives a message with the protocol type field in it. This field can have the value 1.

Workaround:

Treat the value 1 as a "Non signalling value" (2)

CSCdk29716

Symptom:

Discrepancy in the "dspchstats" when you compare the 2 end points

of a given PVC. More traffic appears on one side than the source sends.

Conditions:

After a switchcc occurs while connections are rerouting.

Workaround:

"dncon" and "upcon" will resolve this problem

CSCdk28946

Symptom:

Major and minor statistical alarms are not triggered at the rates configured using the cnflnalm command. Alarms are triggered after thirty seconds.

Conditions:

This is the case for all statistical line alarms.

NOTE: This software fix corrects the problem for errors in the range of 10E-8 to 10E-4. Errors detected at these rates will cause alarms based on the thresholds configured using the cnflnalm command. Errors at the rates of 10E-9 and 10E-3 do not properly trigger alarms.

Workaround:

For errors detected at 10E-3 which is to change the major alarm threshold from

10E-3 to 10E-4.

There is no workaround for declaring minor errors at 10E-9. Both of these issues are still considered open and will be addressed.

Although there are no trunk alarms triggered at 10E-3 and 10E-9, the errors are correctly reported and can be displayed using the dsptrkerrs command.

CSCdk28009

Symptom:

The StrataView Plus maintenance log displays a frame relay connection (format slot.port.dlci) as "1.2152" rather than "1.2.152" when the connection is "Upped" or "Downed".

Conditions:

StrataView Plus gateway node is a BPX running software release 8.1 or above.

Workaround:

None.

Further Problem Description:

The BPX software is incorrectly building the maintenance log string sent to the StrataView Plus. It is not placing the "." between the port and DLCI.

CSCdk27774

Symptom:

The loop backs added on the trunk are cleared following a Node rebuild.

Conditions:

Rebuild the Node with the software loop backs on

Workaround:

Need to add the loopbacks back in after a rebuild.

Further Problem Description:

Software loopbacks are cleared after the node is rebuilt, but it is preserved on a switchcc or a graceful upgrade, even though it is stored in the BRAM.

CSCdk27688

Symptom: When the command dspportstats is executed with an invalid port number, a software error 921 is asked.

Conditions: Execution of command dspportstats with an invalid port number.

Workaround: None

CSCdk26930

Symptom:

Software error 586 is logged. This happens when the system thinks that the memory is not available to allocate for sending updates to the standby.

Impact:

Once this condition is reached, the standby updates will never get through and a flood of software error 586 will be seen.

Workaround:

None.

CSCdk26240

Symptom:

AIS alarm counts are not displayed for E3 lines and trunks when using the commands dsplnerrs <CmdArg>line_num<noCmdArg> and dsptrkerrs <CmdArg>trk_num<noCmdArg>.

Conditions:

The problem occurs on BPX nodes using E3 lines or trunks.

Workaround:

No workaround is available; however, the AIS alarm status is correctly displayed.

CSCdk23431

Symptom:

The StrataView Plus database does not include inactive ports on the T1/E1 backcards of UFM/FRM/FTM.

Conditions:

The 'dspports' command on the IGX switch shows inactive ports on the T1/E1 backcards of UFM/FRM/FTM on the screen. However, this information is not available on the StrataView Plus workstation. The inactive ports on the V.35 and X.21 on the same card types are properly matched on the switch and the StrataView Plus.

Workaround:

Delete all inactive ports using 'delport' command on the above card to avoid the problem.

CSCdk22903

Symptom:

On the arbstats screen, the "Inv. Secondary Addresses" count keeps on increasing on the BPX.

Conditions:

Happens when we have a trunk card in the node (without Y-red) connected to an MGX 8220 shelf. In this case we program the SAR with the secondary address as 0 which is not valid.

When the card is Y-red, the secondary slot address with which the SAR is programmed is correct and thus we don't see this problem in that case.

Workaround:

Doesn't cause any harm, so there isn't a need for a workaround.

CSCdk21358

Symptom:

The MIB variable slotCardStatus does not show proper value.

Conditions:

The IPX/IGX/BPX SNMP agent reports the above MIB variable as active when there is no backcard installed.

Work Around:

None.

CSCdk19026

Symptom:

There was an observance of gaps in traffic using DS0A connections. The gap duration corresponds to the in/out framing threshold of the CVM determined by the cnfcdpparm command.

Conditions:

Utilizing a unique DS0A application which is sensitive to the delay caused by the traditional range of configurable in/out framing thresholds (500 to 1000 msec). A lower threshold value is required.

Workaround:

None

CSCdk07044

Symptom:

Software error 614 (VC auto deletion) is logged on BPX/IGX node.

Conditions:

Some of the connections get auto deleted when loading new BPX/IGX image. The database inconsistency occurred when the node is rebuilding causing the connections to be deleted. The cause is being investigated. The occurrence of this problem is very rare.

Work Around:

None.

CSCdk04633

Symptom:

"repair" (RTS high) job trigger doesn't work in Y redundant HDM if secondary card is active.

Conditions:

Running video equipment on IGX/HDM to multiple locations on the network 8.2.56, lab reproduction was being done on 8.5.04

Workaround:

No workaround.

Further Problem Description:

Connections which have been set up prior to roll-over to the secondary HDM of the Y red group will stay up after roll-over. If an existing downed connection is to be upped upon the "repair" (RTS high) condition, however,

CSCdj93681

Symptom:

A card entry is shown in card table of StrataView Plus for slot 2 on IGX or IPX and slot 8 for BPX even if the card is not present and "CC Card redundancy is not configured". The card state is shown as 0 (UNinitialized card state).

Conditions:

Every time.

Workaround:

No workaround.

CSCdj75367

Symptom:

A connection routed over an ALM trunk is showing discards on one end. The dspchstats screen for the connection shows discards on the frames sent to the port. dsptrkerrs does not show errors on the trunks along the connection path.

Conditions:

A connection routed over an ALM trunk.

Workaround:

Setup a cbus trace to determine if the ALM card is frame aborts or CRC-32 errors. The cbus trace should be setup for the ALM card slot, function code 0x81, byte value 0x59, and byte offset 1. An example of the message collected is shown below.

The following is an alternative workaround:

1. Use cnftrkstats to enable the desired statistics. In release 8.2.56 the desired statistics are:

170) CGW Aborted Frms Rx From Line

172) CGW Bd CRC32 Frms Rx from Line

2. Use dsptrkstatcnf to validate that the desired statistics are enabled

3. Use dsptrkstathist to monitor the statistics

Since these statistics require software to allocate memory to collect them it is a good idea to monitor the statistics memory used by using dspstatmem

Further Problem Description:

This example shows that there are 2089 (0x829) aborted frames received from the line, all of which have bad CRC-32. There are no discarded cells at the trunk due to the aborted frames. The discarded cells are the only value in this message which is processed by the software. The discarded cells are shown on the dsptrkerrs screen as "CGW Dscd Cells".

27 +390 69798610 23 3 81

81 59 00 19 EB 00 11 03 00 00 45 00 08 29 00 00 00 00 08 29 00 00 00

np fptx clrx frln abtrx cldscd lncrc32 lnlngth

np - Stat number (0x16 << 2) and page (1).

fptx - CGW Packets Tx to IPX Net

clrx - CGW Cells Rx from Line

frln - CGW Frms Relayed from Line

abtrx - CGW Aborted Frms Rx From Line

cldscd - CGW Dscd Cells <-- on dsptrkerrs

lncrc32 - CGW Bd CRC32 Frms Rx from Line

lnlngth - CGW Bd Lngth Frms Rx from Line

CSCdk43303

Symptom:

The UXM backcard state is shown as empty. Sometimes the UXM is in fail state

Conditions:

The problem is caused by newer versions of NTM hardware. When the problem occurs, it is most likely that there is an NTM inserted into slot 3 while the NPM in slot 2 is active.

This problem is found only with new versions of NTM hardware. The FAB number shown on the setnovram screen indicates which version of NTM hardware.

FAB Number 213210-00 -- Problem does not exist (NTM HW model A)

FAB Number 214402-00 -- Problem exists. (NTM HW Model B with assembly number 73-214402-00).

FAB Number 28-2022-02 -- Problem exists. (NTM HW Model C with assembly number 73-2296-01 through 04).

Refer to the following URL for additional information related to NTM HW: http://www.cisco.com/warp/customer/74/124.html

Workaround:

1. Do not insert an NTM HW Model B with assembly number 73-214402-00 or an NTM HW Model C with assembly number 73-2296-01 through 04 into slot 3.

or

2. Allocate 10 - 20 UBUs to the active NPM using the getubus command.

or

3. Do not use the NPM in slot 2. Always make the NPM in slot 1 active.

CSCdk32790

The following bug was previously fixed but was not documented in the 9.1.03 Release Notes.

Symptom:

ASI-155/BNI to BXM connections may lose traffic.

Conditions:

The BCC-4 arbiter does not recognize that the ASI-155 has only a single receiver, therefore, all the cells that are tagged to go through the second receiver will be dropped. This also happens on BNI cards.

Workaround:

No Workaround.

CSCdj73314

Symptom:

The bug does not give very specific statistics that do not add up on dsptrkerrs screen. Inferring from the screen and by talking to the bug submitter These are the statistics which they claim are not working for E3 trunks:

1. Frame Sync Errors 2. HEC errors 3. BIP-8 Errors

Conditions:

Inject the above said errors and they will not be counted.

Workaround:

None.

Further Problem Description:

Here is initial analysis.

1. Frame Sync Errors:

Depends on what you interpret as Frame Sync Errors. If it refers to PLCP Frame errors, then for E3 (direct map mode) there is no such count and on E3 trunks we support ONLY direct map mode. This has been tested on E3 trunk and hence we don't see the count. The other two errors might be real problems. Here is more details on them.

2. HEC errors: This has been fixed as part of CSCdj82655 See comments from that bug

These modifications are dependent upon CR CSCdj76850 and CSCdj44011 which add support for new stats (rx_clp0 etc.).

Modifications here added support for new stats: non-compliant clp0 discarded non-compliant clp1 discarded congested clp0 discarded congested clp1 discarded

Modifications also included fixing issues with the HEC errors and the HEC correctable errors with the BXM cards.

3. BIP-8 Errors If it is a T3 trunk it should work. It may not work for E3 trunks with the SWSW you have. The problem has been addressed with the fix in the bug.

If you WANT TO COUNT THE STATS USING SV+ then

Make sure that you enable PCV (code Violations) to see BIP-8 equivalent. The PCV stat object records the BIP-8 errors for BXM E3 trunks. Under cnfstatparms command you should be able to see strings "Pcvl" / "Line Parity Errors" which indicate that statistics

OTHERWISE you will see them as part of dsptrkerrs (CodeErrors).

CSCdj73463

Symptom:

No warning seen, when the max bandwidth on a port (BXM only) has been configured to a very low value or zero, and a connection is now added.

Conditions:

The check is done against max port bandwidth and not against the newly configured bandwidth. So the error message is not seen.

Workaround:

Connection addition will not fail due to lack port bandwidth.

If traffic is being sent on the connection, and it gets dropped due to policing, increase the port bandwidth using the cnfrsrc command to reconfigure the port bandwidth to a higher value.

CSCdj85636

Symptom:

A PVC connection has a 1-way loss of data continuity. This is visible using the command tstdelay or dspchstats.

Conditions:

The condition for this problem to occur is due to an internal data structure overflow which changes the state of the port.

The overflow occurs when the bandwidth loading exceeds the data structure capacity.

Workaround:

Reroute the connection will restore the data continuity provided that different paths are taken. An other alternative is to reduce the PVC bandwidth allocations.

CSCdj90601

Enhancement:CAC Override Option for Ports (BXM/ASI) on the BPX baseline.

CAC stands for Connection Admission Control. Currently, connections are added (or configured) even if the bandwidth requirements exceed the Port capacity. In the switch, Port Over Subscription is allowed, so the default value for CAC Override is set to Enabled. A new feature is being requested, using which CAC Override can be enabled or disabled on a per port basis. This would give the customer freedom to allow or disallow port over subscription.

This feature can be enabled/disabled on a per port basis. It is possible to have a card with CAC Override feature enabled on one port and disabled on another. ASI and BXM cards will support this feature.

Enforcing of CAC Override involves, rejecting requests to add connections or change the parameters of a connection if port over subscription is detected. It applies for both DAX and NON-DAX connections.

CAC Override Feature is applicable only on the port on which it is enabled. If a connection is added between two ports one with CAC Override enabled and another with CAC Override disabled, enforcing of the CAC Override (port over subscription) is done only on the side where it is disabled. In this sense it is a strictly a local feature, applicable and enforced on a single port.

Conditions:

Network containing nodes running 8.4.19 and earlier releases of 8.4 (say 8.4.18)

a.) If CAC Override Feature is disabled on the ports on nodes running 8.4.19 and above. Addcon: If addcon (from 8.4.18 to 8.4.19) results in Port Over subscription on the 8.4.19 node, the following error message will be displayed on the node running 8.4.18: "Unknown response at remote node: 96"

The connection is not added. Cnfcon: cnfcon also generates an error message: "Unknown response: 96" The connection is not changed.

b.) Percent Util greater than 100% on nodes running 8.4.19 with or without disabling the CAC Override Option

Addcon: If addcon uses a value greater than 100 for percent utilization, the remote node running (8.4.18 or lower) will reject the connection add request with the following error message: "Remote % Util value out of range."

The connection is not added.

Cnfcon: Using cnfcon to change the percent utilization to higher values than 100, also produces the same error message.

c.) Cnfcls command can be used in 8.4.19 and higher releases to configure classes to have values higher than 100 for percent utilization. Since ATM classes are network wide, all the nodes in the network are updated.

If there happens to be a node in the network running 8.4.18 or lower. If now an attempt is made to add a connection using the class which has been changed, the connection will not add. An error message: "% Util value out of range (remote end). Valid range 1 - 100." is seen.

The solution is to reconfigure the class and add the connection, or add the connection by specifying all the parameters.

CSCdk00290

Symptom:

thtrace reveals that there are unexpected events being received by the tstcon state machine.

Conditions:

These events were generated by the Foresight RTD measurements for FST connections. These events were being received and rejected. No State transitions happened.

This was seen only once.

Workaround:

These events can be cleared using the command cth. They do not in any way affect the functionality of the switch.

CSCdk06365

Symptom:

Can not transfer data on newly created PVC after rebuild of BPX node.

Condition:

Data transfer was initiated from an ATM broadband test set to the MGX 8220 port. We see data transfer from the MGX 8220 port being looped back at the bpx feeder trunk but fail to see it reaching the bpx feeder trunk to the MGX 8220 shelf (we monitor the bpx feeder trunk using the ATM broadband test set).

CSCdk14364

Symptom:

When an user issues the command dspcons, the software errors 4208 and 532 may be observed when the connections are being deleted at the remote nodes at approximately the same time. The software errors do not have any bad service affecting effects and can be ignored. Eventually, the correct information for connections can be properly displayed in the dspcons commands.

Condition:

The software errors may be observed when the command dspcons is executed at the same time when some connections are deleted from remote nodes.

Workaround:

None.

CSCdk14676

Symptom:

SNMP MIB variable atmEndptPercUtil range checking is incorrect.

Conditions:

Range checking of SNMP MIB variable atmEndptPercUtil range was between 0 to 100. This correct range should be 0 to 127 which is introduced as part of CAC feature. Refer to bug CSCdj90601 for further description of CAC feature.

Work Around:

Use CLI to add connection using CAC feature.

CSCdk17055

Symptom:

For BXM, number of ports on back card is always equal to its front card. E.g., if the front card has 8 ports and its back card has 4 ports, 8 is returned for both slotFrontNumPort and slotBackNumPort. But only 4 ports are operational.

Customer Impact:

Are confused on number of operational ports.

Work Around:

No work around.

CSCdk17404

Symptom:

SNMP get/next functions are timing out when accessing

slotCardMinReqBusBWCell, slotCardMaxPortBusBW, slotCardAvgUsedBusBWCell, slotCardUsedPeakBusBWCell, slotCardAllocBusUBU, slotCardMinBusUBU, slotCardMinReqBusBWFpkt, slotCardAvgUsedBusBWFpkt, slotCardUsedPeakBusBWFpkt,

Also a walk on shelfSlotInfoTable is also timed out.

Impact:

Not able to access UBU configuration data using SNMP.

Workaround:

The UBU information can be obtained using CLI command dspbusbw

CSCdk18706

Symptom:

SNMP MIB variable slotFrontLnFormat and slotBackLnFormat always return incorrect value in a SNMP Get response.

Conditions:

When accessing the above variables, the SNMP agent always return value null (1).

Work Around:

None. Use CLI to retrieve such information.

CSCdk18709

Symptom:

When a user is logged into the Control Port at normal user priority, and then something happens on the node that makes the processor card very busy with high priority work, the Control Port user will get locked up. It will not be possible to force a logout, so that the user can then log in at high priority.

At the customer's request, a change is being made to have the DTR check of the Control Port made at a very high priority. This way, the user can pull the RS232 cable at the Control Port to force the low priority user session to end. Then the user can log in at high priority.

CSCdk19125

Symptom:

After doing a runrev operation, it was observed that the software errors 69 and 21 were logged, which indicates there was a problem communicating with a BXM-OC3 card.

Conditions:

This problem seems to happen only on this particular card that experience several card failures.

Workaround:

None.

CSCdk19709

Symptom:

BPX cards may be incorrect detected as "suspected of failure".

Conditions:

When BXM selftest is enabled, the system may incorrectly declared several cards as "suspected of failure". This is because the cells that are used in the crosspoint test are not unique and may get confused with a neighbor node causing the incorrect declaration of failure.

Work Around:

Ignore "Suspected of failure" error in the event log or disable the BCC selftest.

CSCdk21358

Symptom:

The MIB variable slotCardStatus does not show proper value.

Condition:

The IPX/IGX/BPX SNMP agent reports the above MIB variable as active when there is no backcard installed. The status is shown as "empty" via CLI.

Work Around:

None.

CSCdk21457

Symptom:

swerr 3034 is logged on the switch.

Condition:

When the RSRC tried to send the deprogram command to the card and in the same time the card is not available. Under this situation, the TRK_XLAT will stay in T_STATE_CLR_CHN_WAIT state. So when we call the function clr_trk_xlat_on_ptl to clean up we will see the swerr 3034.

Workaround:

None.

CSCdk21503

Symptom:

Software error 921 may be logged when accessing atmTrunkStatsTable using SNMP get operation on an AIT/BTM/ALM trunk.

Condition:

The above software error is logged when the above MIB variable is being accessed via an SNMP get operation on IGX/IPX node.

Work Around:

None.

CSCdk22067

Symptom:

The switch logged swerr 532 after you execute the dcct command.

Condition:

If you type in "dcct XXX", XXX is the letters (e.g. groups) instead of connection address (e.g. 1.1.1.3) and you will get swerr 532.

Workaround:

None

CSCdk23145

Symptom:

UVM to 3810 connection reports incorrect connection status.

Condition:

After user power down an 3810 or reload the 3810, the above connection reports as OK on UVM end while the remote end reports connection is in failed state.

Workaround:

None.

CSCdk23574

Symptom:

The Qbin discard threshold of qbin 10 for VSI may have incorrect default value.

Conditions:

Cnfqbin command on the BXM port card should be based the computation of qbin discard threshold on the card transmit rate instead of the PVC maximum bandwidth.

Work Around:

None.

CSCdk23580

Symptom:

The IGX may not return proper value on a SNMP get operation of the MIB variable switchPhysPorts on UXM trunk.

Conditions:

The SNMP agent may return incorrect value of the above MIB variable. This variable is available on UXM IMA trunk.

Work Around:

None.

CSCdk23867

Enhancement:

The new command 'recovertopo' is meant to be executed in emergency situations where the only other workaround to recover a lost trunk (and possibly nodes) would be to actually delete the trunk.

In cases of trunk parameter discrepancies the usual updates should be used, unless these discrepancies resulted in a Comm Break causing the normal updates not reach the destination.

Syntax:

recovertopo <destination node> [<source node>]

<destination node> is the node that has a corrupted nib.

<source node> is the nib that is corrupted. If this argument is missing, the nib of the node the command is typed on, is used.

The command can be typed on any node from where <destination node> is reachable.

As a side effect, normal updates of the source node are also requested by the destination node.

CSCdk23870

Symptom:

Software error 710 (BAD_TYPE_LCD_TDM) is logged on IGX node.

Conditions:

During IGX node rebuild, the above software error may be logged on the card that has been removed.

Work Around:

None.

CSCdk24659

Symptom:

Software error 21 (BAD_CMD) is logged on UXM port card.

Conditions:

The above software error is logged. This is caused by trying to condition (set ABIT status) on a connection BEFORE the connection has been programmed on the card.

This occurs during a node rebuild, when a card must be completely reprogrammed. UXM cards reprogram their connections using a throttling algorithm to reduce the overhead required. During this throttling period, connections on the UXM may require ABIT status change. There is a race condition between programming the connection and setting its ABIT status.

Work Around:

None.

CSCdk24777

Symptom:

User is able to increase number of Gateway channels on UXM cards to be larger than the limit.

Conditions:

Using 'cnftrk' command, user is able to increase number of Gateway channels on the several UXM trunks such that total number of Gateway channels on the same card exceeds the limits (4000 channels less number of networking channels.) This problem only occurs if the user use cnftrk command after the trunk is added. If the user change the number of Gateway channels prior to addtrk, then the checking is properly done.

Work around:

Use 'cnftrk' command to increase the Gateway channels prior to addtrk.

CSCdk25057

Symptom:

Able to add a routing trunk on VSI only trunk which has start VPI = 1 in SNMP.

Customer Impact:

The routing trunk and VSI partition share the same VPI = 1.

Workaround:

Avoid cnfrsrc with VSI start VPI = 1.

CSCdk25618

Symptom:

Feeder connections on BXM trunk may not be programmed properly.

Conditions:

This problem is random due to uninitialized variable.

Work Around:

None.

CSCdk25670

Symptom:

:Wrongly use the function (logcd_supports).

Condition:

The checking is done for FRP port, in our case, it won't create any problem but we need to correct those buggy code.

Workaround:

None

CSCdk25736

Symptom:

When resetting BXM Model C Firmware, the system may log software error 21 on function code 0x62.

Conditions:

The software error occurs upon card reset on a Y-red pair of BXM which is configured as a secondary card. This is because incorrect information is sent down to FW and BXM FW rejects such command.

Work Around:

Always use BXM primary card in Y-red configuration.

CSCdk25958

Problem Description:

Due to a defect in the code the ILMI protocol does not work on trunks.

Impact:

The impact of this defect is that VT's can not use ILMI to determine if the VPC supporting the trunk is working.

Workaround:

None.

CSCdk26211

Symptom:

The BXM throughput is limited to 77% when using MBX firmware and 9.1.02 image or earlier version.

Conditions:

It happens when using BCC-4 and the new backplane.

Workaround:

Reverted to 10 Giga switch by using BCC-3 or the old backplane.

CSCdk27075

Symptom:

The default value of maximum PVC conid is incorrectly initialized on BNI virtual trunk. The user may not be able to perform 'addtrk' command on BNI virtual trunk in node by node upgrade.

Conditions:

This problem occurs only on BNI virtual trunk.

Work Around:

Wait until all node is upgraded to 9.1 prior to adding virtual BNI trunk.

CSCdk27150

Symptom:

UXM card is declared as parity failure even though it is not.

Conditions:

Software should ignore parity checking when the card is in standby mode. This is a hardware limitation. While the card is in selftest, the parity line is float.

Work Around:

None.

CSCdk27421

Symptom:

you see the wrong count of the ATM connections and FR connections

Condition:

when you execute the "tstcon *" command, this command counts the ATM connections and FR connections.

Workaround:

None.

CSCdk27437

Symptom:

System does not reject when user is adding ATM connection between BPX and IGX nodes. Improper error message "Unknown response at remote node: 0" was shown. This should be blocked during interoperability between 9.1 and 8.5.

Conditions:

This problem occurs only interoperability between 9.1 and 8.5. Adding ATM connections between BPX and IGX should be blocked instead of showing incorrect error message above.

Workaround:

Wait until all node is upgraded to 9.1 before adding ATM connection between BPX and IGX.

CSCdk27774

Symptom:

The loopbacks added on the trunk are cleared following a node rebuild.

Conditions:

Rebuild the node with the software loopbacks on

Workaround:

Need to add the loopbacks back in after a rebuild.

Further Problem Description:

Software loopbacks are cleared after the node is rebuilt, but it is preserved on a switchcc or a graceful upgrade, even though it is stored in the BRAM

CSCdk28039

Symptom:

Queries of atmTrkOeIfIndex and fpRteTrkOeIfIndex return incorrect values. 0 is always returned.

Conditions:

Happens in SNMP operations walk, get, next.

Work Around:

None.

CSCdk28154

Symptom:

When you do "dspcon xxxx", you will see the "New Conn" shown on the screen instead of "OK"

Condition:

You add the new conn and you see the problem right away.

Workaround:

None.

CSCdk28204

Symptom:

A swerr526 appears if a card failure event log string is longer then what can fit on the display screen.

Conditions:

This problem can be created if a dspswlog is done for the screen on which the long string is present.

Workaround:

None.

CSCdk28347

Symptom:

Connection to FastPAD failed when remote FP becomes unreachable.

Conditions:

This can happen due to a FTM rest, card down and up, node rebuild.

Workaround:

Rebuild local end of connection or down and up connection.

CSCdk28370

Symptom:

Unreachability occurs in the network after one or more links in an IMA group go down and come back up.

Conditions:

This occurs only if the IMA trunk, on which the links went down/up, was being used for networking traffic. Also the network has to be big for this to happen.

Work around:

Use 'cnftrk' command to restrict the CC traffic on the trunk, before doing the link-level-redundancy testing. Also, keep the "Restrict CC traffic = Y" on the IMA trunks, if possible.

CSCdk28408

Symptom:

dspload shows 381 cells for 't' and 'p' type connections.

Conditions:

UXM trunks between two IGXs, two voice circuit lines of any type.

use cnfcmb dspload cnfchutl and dsptrkutl commands.

Workaround: For voice connections cnfchutl. None for 't' or 'p' connections.

Further Problem Description:

70% of an IMA trunk group cannot be used if transparent voice connections are configured. This is due to voice cell overhead, IMA and ATM overhead and the one fastpacket per cell rule. For voice the current gateway is very inefficient.

CSCdk29201

Symptom:

Cannot change UFM T1 frLportSigProt in SNMP. Get error "Annex A and Annex D are not supported on this FRP 14"

Conditions:

This happens when set frLportSigProt in SNMP.

Work Around:

Use CLI to change the value.

CSCdk30737

Symptom:

VSI TAG Controller connections to BXM card in Y-red pair is not set up properly which may cause problem after Y-red switch.

Conditions:

This problems occurs only on a BXM Y-red pair with VSI TAG configuration. The control channel between the VSI controller and the BXM were not deleted when the trunk is removed. Thus, later when the BXM card is used in a Y-red paired on the same node, the control channel still exists which cause problem with the VSI TAG controller.

Work Around:

None.

CSCdk30904

Symptom:

Software error 901 may be logged in 8.5 node in interoperability network.

Conditions:

This above software error is logged when adding ATM-to-Frame Relay connections between 8.5 and 9.1 nodes. This is caused by incompatible network messages between 8.5 and 9.1. The CM rate index contents are not compatible between the two releases.

Work Around:

None. Do not add the above connections between 8.5 and 9.1 network. Wait until the network is upgraded to 9.1.

CSCdk31998

Symptom:

When the Node is upgraded from Release 8.4.1 to 9.1 the new field vc_shaping, introduced in the port configuration is getting an undefined value.

Conditions:

Upgrade from release 8.4.1 to 9.1

Workaround:

Configure the desired value(enabled/disabled) for vc shaping after upgrade

CSCdk32827

Symptom:

Software error 256 may be logged in 8.4/8.5-9.1 interoperability network. And also, The flooding of message happens in only mixed network.

Conditions:

The flooding of message happens in only mixed network (Some nodes with 8.4 and some with 9.1) i.e only couple of nodes are upgraded to 9.1 and there happens ping-pong of the message between 8.4 and 9.1 node. But the condition is that A) 9.1 node should have the lowest node number, B) Before upgrade the 8.4 network has the User_Id with privilege level 0. Conditional update message sent from the Master node (i.e the lowest node no.) of the network DROPS the User_Id (which has the group level 0). The transmit part of the message has some protection check code for invalid message which was buggy.

Work Around:

None.

CSCdk33055

Symptom:

When both the UVM cards in the Y-red pair aren't present, and we insert one card, then it goes into mismatch state instead of going to active.

Conditions:

Insertion of one UVM card, when both the cards in the Y-red pair aren't present.

Workaround:

Reset the UVM in the mismatch state.

CSCdk33250

Release Note: BPX Upgrade from Release 8.2.55 to 9.1 will not be successful for the images made after 8/7/98.

Workaround:

Use the IB91 PUBLIC image 9.1.l7 or later

CSCdk34002

Symptom:

Job Trigger can cause a node abort (1000003)

Conditions:

When setting up a job trigger to reestablish default preferred routes when a trunk fails, the execution of that trigger can cause an abort. This may lead to a continuous condition when the standby become active and then it also activates the job.

Workaround:

None; however, setting up a job trigger to handle a trunk failure case should not be used.

CSCdk34286

Symptom:

When the card is in self test failure i.e. in Active-F state, the connections on it also remain failed and thus no data continuity on those connections.

Conditions:

Reset the card which is in ACTIVE-F state on BPX. * When the card comes back up, the connections on it will remained failed. * Happens only for the port card.

Workaround:

Clear the self test failure by issuing "resetcd <slot #> f". The connections will immediately become okay and start passing traffic.

CSCdk36359

Symptom:

After upgrade from 8.5/8.2.55, ucbr & uvbr conns share the same Vc_Bw_Parms entry. Also bw_con_type shows up as BW_VBR_CON or BW_CBR_CON.

Conditions:

If the nodes which are upgraded from 8.2.55/8.5 to 9.1 have ucbr & uvbr conns that share the same Vc_Bw_Parms entry in older releases; then this problem will show up.

Workaround:

Deleting and re-adding all the ucbr & uvbr conns after upgrade from 8.2.55/8.5 to 9.1

CSCdj52956

Symptom:

Connection continues to route forever, if DC/CHADDR (or CBA) are not present on the via node.

All other resources such as bandwidth, vlcons etc. are available for routing.

Conditions:

If the via node runs out of DC/CHADDR (or CBA) the connection will attempt to route forever. All the other resources are available.

Workaround:

To prevent the connection from routing forever, down the connection, since it can not be routed.

CSCdk08077

Symptom:

The UVM connection state in one end shows OK, but in other end shows DSP_F.

Conditions:

This occurs when DSP_F is shown in a UVM connection in both ends. If the master node reset, then connection state in master side is OK but the other side is DSP_F.

Workaround:

Reset the UVM in master side.

CSCdk13558

Symptom:

The output of the CLI command dspcd now indicates whether the specified slot is undergoing channel programming. This indication is updated in intervals of 2 to 5 seconds for about 1 min.

Workaround:

None.

CSCdk14364

Symptom:

When an user issues the command dspcon, the software errors 4208 and 532 may be observed when the connections are being deleted at the remote nodes at approximately the same time. The software errors do not have any bad service affecting effects and can be ignored. Eventually, the correct information for connections can be properly displayed in the dspcon commands.

Workaround:

None.

CSCdk14935

Symptom:

For a newly upped trunk, some of the port and trunk stats will be incorrect (too large) for the first sample, and if there is a line whose logical line is the same as the upped logical trunk, its port and lines stats will be incorrect (too small).

Conditions:

To get the incorrect trunk and port stats the user only needs to up a trunk. The first statistical sample will not be dropped, and hence will be too large.

To get the incorrect line and port stats the user needs to up a trunk, where its logical trunk number matches an existing logical line number. The result is not only incorrect trunk stats, as stated above, but the corresponding line and port stats for the logical line will be dropped.

(Instead of setting the drop-first-stat bit for the trunk, it is being set for a line).

Workaround:

Disregard the first sample.

CSCdk15308

Symptom:

Traffic continuity is affected when local loop is added to a FR connection with FRM card termination or to the FRM port. See bug CSCdj71238 for details.

Workaround:

Do not use the software loopback function.

CSCdk15680

Symptom:

dspcd may display incorrect line type when the UXM backcard is either missing or mismatch.

Conditions:

When the UXM backcard is removed or in a mismatch state, the display on the above command may show information of the backcard that was previously there.

Workaround:

Reset the UXM card to display the correct information.

CSCdk15682

Symptom:

Statistical alarms for: Bipolar Violations, Frame Slips, Out of Frames, Loss of Signal, Frame Bit Errors, CRC Errors, Out of Multi-Frame, All Ones in Timeslot 16, Line Code Violation, Line Parity Errors, Path Parity Errors, BIP-8 Code Violations, Frame Sync Errors Can be adjusted via the cnflnalm command. When their time value is reduced, it is possible that they will immediately go into alarm (falsely).

Conditions:

The customer has UXM trunks upped and they enact the cnflnalm command for a physical alarm, as listed above.

Workaround:

If you do not use the cnflnalm command this will not be an issue.

The alarm *will* clear itself, eventually and then work correctly from that point on (until cnflnalm is used again).

CSCdk16126

Symptom:

SNMP walk on connTable or atmEndptTable timeout. This happens when there is no connection on the node.

CUSTOMER IMPACT:

Cannot walk on the node. Walk stops at either connTable or atmEndptTable.

Workaround:

Avoid walking on empty connTable and atmEndptTable. Add a connection on the node and walk will be fine.

CSCdk16244

Symptom:

Software error 532 may be logged when the node is loaded with new Software via runrev.

Conditions:

Software error 532 may be logged on an NTM trunk card when the new version of software is loaded. An extra backcard event is received causing the above software to be logged. This is for information only.

Workaround:

Remove the standby BCC-4 from the BPX after running cnfbpnv. Then run 'resetcd h' on the active BCC-4. After it becomes active again, insert the standby BCC-4.

CSCdk16366

Symptom:

Running the cnfbpnv command to convert a BPX from 9.6Gbps to a 19.2Gbps followed by a switchcc on BCC-4, does not force the BPX to recognize the 19.2 Gbps backplane. The dspbpnv still shows 'Word #2' as '0000' (or some value other than '0001').

Conditions:

This occurs on BPX 8.4.18

Workaround:

Remove the standby BCC-4 from the BPX after running cnfbpnv. Then run resetcd h on the active BCC-4. After it becomes active again, insert the standby BCC-4.

CSCdk16598

Symptom:

All ALM/BTM trunk card failed on an IGX node failed at the same time.

Conditions:

Under a rare condition, all ALM/BTM trunks on a fully loaded IGX nodes may experience failure at the same time. The dspcderrs screen shows that the card error as:

0B 00 07 A7 01 5B 02

Error Fcode: Unknown Failure Type: Watchdog Processor Number: 01

The occurrence of this problem is very rare. It occurred once or twice under stress testing, i.e. reset other trunk cards or port cards every 10 minutes on a remote node which causes reroute to occurs on the local node.

Workaround:

Reset the card that failed.

CSCdk16952

Symptom:

Software error 532 and 923 may be logged when a UXM trunk is deactivated while the trunk is in mismatched state.

Conditions:

Software errors 532 and 923 occured after the following sequence of operation:

1) On active UXM trunk, the backcard is replaced with a higher density of ports. For example, a 3 ports T3 backcard is replaced with 6 ports OC3 backcard.

2) The original backcard with lower port density is reinserted back to the slot. The system declares mismatch.

3) The UXM trunk is deactivated. The above software errors are logged.

Workaround:

Do not replace the backcard with higher port density unless this is an upgrade path since the system will mismatch if the lower port density backcard is inserted back.

CSCdk17234

Symptom:

The SNMP gets for DS3 and SONET stats from UXM trunks always returns a zero.

DS3 stats are: Out of Frame Loss of Signal ATM Cell Header Checksum Errors

SONET stats are: Out of Frame Loss of Signal Line Code Violations C-bit parity Errors P-bit parity Errors PLCB BIP-8 Errors ATM Cell Header Checksum Errors Packet Header CRC errors PLCB Out Of Frame Errors

Conditions:

This only happens for UXM trunks. These stats are properly obtained for UXM lines and all other trunk and line cards.

Workaround:

Obtain these statistics using the SV+'s TFTP interval statistics functionality. These stats are properly collected, they are just not being reported correctly for SNMP.

CSCdk17289

Symptom:

Unable to activate an NTC trunk after the last uptrk command failed with the error message:

There is no enough bandwidth available.

Conditions:

On an IPX node that has all of the bandwidth utilized, the user enters uptrk on an NTC card, and the command fails with above error message. However, if the user tries to uptrk again on the same slot, the command fails with error message:

Trunk is already up.

Workaround:

Rebuild the node and the user should be able to activate the trunk again.

CSCdk17306

Symptom:

The new field as displayed by command cnffunc was not getting the correct default value. The particular field is "Logging of Bus Diagnostic Events in local event log".

Conditions:

This will occur while upgrading from Rel 85 to Rel 91 gracefully.

Workaround:

Using the command cnffunc change the new field to its default value.

CSCdk18411

Symptom:

The IPX/IGX feeder node becomes unreachable if the routing node is in degraded mode.

Conditions:

If the routing node is in degraded mode (rebuild prevention), any IPX/IGX feeder attached to that node will be unreachable. This does not affect the MGX 8220 feeder.

Workaround:

None.

CSCdk18425

Symptom:

Data Continuity loss of all connections routed over BNI trunk.

Conditions:

When an active BNI card is replaced with an ASI or BXM card, the card mismatch is declared properly. However, after reinserting the original BNI card into the same slot, the BNI user channels on this trunk card are not being programed.

Workaround:

Reset BNI card after mismatch state is cleared.

CSCdk18742

Symptom:

Software error 100000M on IPX/IGX. This causes the node to rebuild if the trunk or line is being activated after the y-red is added.

Conditions:

The above problem occurs only on a port or trunk card that does not support hot-standby such as FRM/NTM/BTM/ALM. The following is the sequence of operation:

1) User performs a clrcnf or clrallcnf on a node in preparation to load 9.1 software.

2) While the cards are in standby mode, addyred is invoked to define y-red pair.

3) The first line or trunk on the primary card is activated. At this point, the above software is logged.

Workaround:

Interchange the operation of step 2 and 3 above. The trunk or line should be activated first prior to addyred is executed.

CSCdk19136

Symptom:

The software error 21 occurred when the control card on an IGX was communicating with a UXM-E3 card.

Impact:

Unknown.

Workaround:

None.

CSCdk19229

Symptom:

The NPM may be cycling between boot and online after loading with new software.

Conditions:

If the NPM was previously loaded with older version of software (say 7.4) and it is plugged in to a running 9.1 software as a standby card. After the card is upgraded to 9.1 and change the status to standby, the user executes runrev, the standby NPM becoming active may experience going into boot mode and online continuously.

This problem was found once in an NPM node which had UXM y-red pair on that node.

Workaround:

Remove the problem card from the node. Remove Y-red pair and reinsert the NPM. Wait until the NPM is upgraded and ready in standby state before attempting the next runrev.

CSCdk19500

Symptom:

the swerr 3017 filled up the log when you deltrk the trunk from the IGX node and then down the trunk at both node right away. It is not easy to duplicate in most of the network.

Conditions:

the reason we have swerr 3017 is because that deltrk command will delete the conid DB and dntrk command will remove the TRK_XLAT_DB database. Due to the race condition, the TRK_XLAT_DB is gone before the conid DB. But in order to remove the conid DB, we need to access some information from TRK_XLAT_DB database and this is the reason why we saw the swerr 3017 filled up the log.

Workaround:

After you deltrk, don't dntrk right away.

CSCdk19561

Symptom:

Memory may leak if rsh command is incomplete due to the luck of communication channel between UI & CBUS.

Conditions:

This is a debug command that customer has no way to access.

Workaround:

None.

CSCdk19840

Symptom:

The dsplog does not show incorrect VSI feeder when it is first added or deleted.

Conditions:

When user add a VSI feeder on a BXM using addshelf, the event log does not show proper information. This is only a display problem. The VSI Feeder should function properly.

Workaround:

None.

CSCdk19872

Symptom:

An event log specifies that the card has rebuilt because of a "Watchdog Timeout".

Conditions:

If simulation of statistics is being performed using the simerrs command, UXM cards will generate slot alarms.

Workaround:

Do not use simerrs. This is debug command only.

CSCdk19971

Symptom:

Switchover to a UXM Hot Standby card causes some connections to lose continuity. These connections have lcn numbers greater than 4000.

Conditions:

UXM trunks added as yred pair. Large number of connections (> 4000) routed over the trunk.

Workaround:

1. Patch secondary UXM logical card attribute table to have 8000 lcns rather than 4000 lcns. Reset the card.

2. Limit total number of connections on UXM trunk card to 4000 channels if the trunk card has a y-red pair.

CSCdk20328

Symptom:

The degraded mode status of another node is lost on a node that does a switchcc.

Conditions:

A node in the network has to be in degraded mode. Another node does a switchcc to the standby card. When this occurs, the node that does a switchcc loses the information about the degraded mode status.

Workaround:

At the highest level of login in to the node - StrataCom the node in degraded mode can issue tstrev command that will send a TST_REV_COMP message over to a specified node (in this case the node that just switched) forcing exchange of the degraded status as well.

CSCdk20807

Symptom:

Before this change, only a select group of user commands were able to run when the user was logged in at high priority. A new command is being added named cnfhipriallcmds. This command will configure all user commands to be available to a high priority user.

High priority logins are not intended for normal node operations. They are meant to be used for maintenance when the processor card is very busy, and the user is having difficulty logging in at normal user priority.

CSCdk21287

Symptom:

:While doing the dsptrks, you will see

"Major - Tx VBR Cells Dropped

but no swerr.

Conditions:

The cells are dropped when you are adding the connections from BPX node, and the cell routing field reads "No". The QBIN queue got assigned incorrectly.

Workaround: using the cnfcon to configure the connection's cell routing filed

to "Yes".

CSCdk21381

Symptom:

SWerror 1417 might be logged after comm break clears and there have been topology changes on the node which was in comm break with other nodes.

This bug will NOT cause any problem except for logging swerr 1417 which should not be logged under these circumstances, anyway.

CSCdk21854

Symptom:

cnfrsrc command on BPX allows user to change the number of PVCs on a Y-red BXM trunk to be greater than maximum number of PVC allowed.

Conditions:

On a Y-red pair of BXM trunks, if the user invokes the cnfrsrc command when the secondary card is active, the system does not validate the PVC ranges properly. As the result, the user is allowed to configure total number PVC per card to be greater than the channels available on the card.

Note that this problem occurs only on a Y-red pair and the cnfrsrc is entered while the secondary card is active. This command works properly if the command is invoked while the primary card is active or when there is no Y-red pair.

Workaround:

Use cnfrsrc on Y-red pair only when the primary card is active.

CSCdk23623

Symptom:

LOS is not cleared on a UXM y-red pair.

Conditions:

On a UXM y-red pair, if there is faulty cable or port failure on the backcard such that an integrated alarm is detected after y-red switch occurred. If user perform another y-red switch back to the original card, the intergrated alarm may not be cleared. This problem only occurs if user invokes resetcd on an active card. If user perform y-red switch by invoking dncd command, then the problem does not occur.

Workaround:

Always use dncd and upcd to perform y-red switch. Avoid using resetcd on the active card.

CSCdk23724

Symptom:

UXM does not clear backcard mismatch condition.

Conditions:

If the user swaps the backcard of an active UXM card (e.g. while there is active trunks or lines), the system reports backcard mismatch after all the active trunks or lines are deactivated.

Workaround:

Avoid swapping UXM backcards while the card is active. It the problem occurs, reset the NPM card to cause a node rebuild.

CSCdj52771

Symptom:

4208 and 2064 swerrors got logged on the Standby in the VNS lab.

The following events can lead to the above problem:

delete a connection - set a stby update bit for this vc. (note that only updt bit is set, the update is not sent here but will be sent later when Stby_Updt_ST runs).

add a connection - a_vc() allocates a vc, vc_exists bit is set, but none of the other fields are initialized. They are initialized after a_vc() returns, so it is possible that after the execution of a_vc() and before the fields in VC are initialized, Stby_Updt_ST can run and send a partially initialized VC to the Standby.

Standby seeing that vc_exists field is set, assumes it's a valid VC, where as it is just partially initialized VC. This leads to 4208 and 2064 SW errors on the standby.

CSCdj58729

Symptom:

Could not burn fwrev from HCH to HCL with SuperUser level access

Conditions:

Customer was upgrading software and needed to go to HCL

Workaround:

Get StrataCom level access and burn firmware

CSCdj79566

Symptom:

dsptrkstats does not update the screen when the command is invoked on AIT/BTM/ALM trunk.