9.1.16 Version Software Release Notes
Cisco WAN Switching System Software

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.

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!

Further Problem Description: This will have no impact on traffic as long as the circuit lines remain in an un-failed condition. If the conditions described in this report are met, then failure of circuit line# X will result in all nodes who have a connection which terminates on card# X reporting that these connections have failed. The local node will not flag the connections as failed.

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 AXIS 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:

Adding a new feature: CAC Override Option for Ports (BXM/ASI) on the BPX baseline.

Introduction to CAC Override:

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 axis port. We see data transfer from the axis port being looped back at the bpx feeder trunk but fail to see it reaching the bpx feeder trunk to the axis 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 AXIS 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 command, 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 command, configure the connection's cell routing field 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.

Conditions:

The dsptrkstats is supported on UXM trunks, however, the implementation was not completed for AIT/BTM/ALM trunk. Thus, when user invokes such command on the AIT/BTM/ALM trunk, the command is not rejected. The screen always shows zero on all statistics.

Workaround

Do not invoke this command on non-supported trunks. Use dsptrkutl instead.

CSCdj85198

Symptom:

An auxiliary port configured as an alarm collector port does not collect and log alarm messages.

Conditions:

Applies to IPX, IGX, and BPX platforms.

Workaround:

There is no workaround available.

Further Problem Description:

Before the AUX port accepts a character, system software must first validate the port's operating mode (e.g. VT100, autodial modem port, etc.). An AUX port configured as an alarm collector port was not properly validated, which caused the port to reject character input.

CSCdj91072

Symptom:

If SV+ is being updated while BXM cards are in the process of being reset, the SV+ will show incorrect card types for the cards in the process of being reset.

CSCdj92171

Symptom:

After a switchcc from a 64M DRAM, 4M BRAM BCC to a 64M DRAM, 1M BRAM BCC, configuration will be lost.

Conditions:

None of the BCCs should have 64M DRAM and 1M BRAM, but because of a manufacturing problem a few such cards were shipped. If such cards are inserted as Standbys to 64M/4M BCCs, the switch software doesn't catch this mismatch and a configuration loss happens.

Workaround:

If it is possible, 64M cards that are going to be inserted as Standbys should first be verified for 4M BRAM. This can be done by inserting them as Active and dumping 0xd00 memory. 0xd00..0xd03 gives DRAM size and 0xd04..0xd07 gives BRAM size.

CSCdj94277

Symptom:

switchcc on BPX node after resetcd 9 causes node rebuild.

Workaround:

Do a resetcd 9 h on BPX. While slot 9 was not ready for standby yet, I did a switchcc. It caused a node rebuild.

CSCdj94810

Symptom:

After rebuild/switchcc, some cards may not be assigned any UBU if the UBU is oversubscribed on a node.

Conditions:

If a node has many high bandwidth cards such as UXM-OC3, the bus bandwidth of the node may be oversubscribed which may cause this problem when node rebuild or switchcc.

This problem will not occur if the bus bandwidth is not oversubscribed.

Workaround:

When UBU in a node is fully consumed by the cnfbusbw command, a warning message indicating that a number UBUs were less allocated is displayed. The user shall lower the bus bandwidth assignment to the card by the cnfbusbw command so that the bus bandwidth oversubscription will not occur.

CSCdk01897

Symptom:

The y-red pair of BXMs were simultaneously reset from a swerr 123.

Conditions:

The problem happened on a node with a large number of CC restricted BXM trunks.

Workaround:

Problem has only been observed on BXM cards. The problem is much more likely to happen when more than two of these trunks go to the same neighbor or are restricted to CC traffic.

Further Problem Description:

The problem was an overflow in the CBus queue of messages to program networking channels. These queues were especially long because trunks not selected for transmit for CC traffic (for example those with CC restricted on or duplicate trunks to the same neighbor) had all their channels reprogrammed. Because BXM cards could have up to 12 trunks and only one channel per Cbus message is supported, and node resets generate for BXM trunks up to 4 events to start reprogramming, the Cbus queues could grow pretty fast.

The fix reduces the amount of programming, as now trunks not being used for transmit, are not programmed, and on the other trunks only the channels changed are programmed.

A fix to delay the programming when the queues look full was not added due to the longer time required to test this modification.

The implemented fix protected the test network from 123 errors even when 6 nodes around a test node (node was completely isolated from network) were reset.

CSCdk02104

Symptom:

SWERR 378 will be logged when connections are routed over BXM trunks. No side effects as result of this error in this particular case.

Conditions:

The problem is in 8.4.19. It has been fixed in 8.4.21

Workaround:

These errors can be deleted. They do not cause any inconsistencies.

CSCdk02126

Symptom:

The Front Card type for the Standby card is 0 in the SV+ database, when the card actually does not exist.

Conditions:

This situation occurs after the initial sending of Robust messages when a SV+ connects to a node.The Standby Card Robust object message is sent at that time.

Impact:

There is no customer impact because of this. This message is sent specifically for SV+ to be able to receive a CC Redundancy alarm if Redundancy is configured (via the cnfnodeparm command) and the standby card is not present. The card type if not relevant for this particular alarm (as its purpose is to inform the customer of a missing Standby CC when CC Redundancy is configured.) In case a Standby CC were to be physically present then the correct card type is indeed available in the SV+ database.

Workaround:

None.

CSCdk02492

Symptom:

When requesting the sonetIfType, a SNMP MIB variable, of a UXM OC3 backcard, value 7 is returned in the SNMP get response. The number is not defined in the Switch MIB.

Conditions:

This occurs on a SNMP get response of a UXM OC3 back card.

Workaround:

None.

CSCdk03040

Symptom:

New functionality is being added to allow high priority login through the Control Port.

CSCdk03499

Symptom:

When configuring "atmTrunks" on BXM/BNI trunks using SNMP, the parameter "Statistical reserve" is set to an incorrect value. Every set of atmTrunks will corrupt "atmTrkStatRes" on the trunk.

Conditions:

This occurs when configure ATM trunk using SNMP or SV+.

Workaround:

Don't configure ATM trunk in SNMP, using CLI instead.

CSCdk04032

Symptom:

Incorrect connection ID (slot.line.chan) was printed to the maintenance printer.

Conditions:

The bug may occur when adding an UVM connection. This bug prints incorrect UVM connection ID which causes confusion but does not cause any functional error.

Workaround:

None

CSCdk04050

Symptom:

On a UXM card or an ALM card, when the dntrk command is issued to down a trunk, there will not be a message in the event log to indicate that the physical line has been deactivated.

Impact:

Minor. This does not affect actual operation, other than the event/message being missing from the log.

Workaround:

None

CSCdk04291

Symptom:

BCC switch over after using the cnfpref * command. Software error log shows a 1M3 (1000003) abort.

Conditions:

Using the cnfpref * on a BPX running release 8.4.14 software. Specific information about the BPX node that experienced this problem is unknown (such as the number of connections on the node and BRAM size).

Workaround:

Avoid using the cnfpref * command to configure preferred routes. There should not be a problem using the cnfpref command without the wildcard ("*") argument.

Further:

There is a pointer which may not be initialized when the wildcard argument ("*") is used with the cnfpref command on a BPX. The uninitialized pointer is for a structure which has a pointer to a second structure. The BCC aborted because the second pointer was to an address which was outside the memory address range for the BCC. If the second pointer had been to a valid memory address the BCC would not have aborted and the preferred routes would have been correctly configured. The wildcard option will usually work because the second pointer is usually "0" (a valid address for read access), but should be avoided due to the risk of an abort.

The memory access is for a memory read (not write), thus there is no risk of memory corruption.

CSCdk04327

Symptom:

The command dspnode may display the same trunk twice in a y-redundancy configuration.

Conditions:

This only applies to trunks that are in y-redundancy when the secondary trunk is the active trunk.

Workaround:

This is a display problem. Realize that there is only one active trunk with the same trunk number. No information is missing and the trunk number that is displayed in dspnode is correct.

CSCdk04383

Symptom:

An SNMP get request returns unknown (1), if atmPortIfType is queried on UXM T1/E1.

Impact:

Don't know UXM T1/E1 atmPortIftype.

Workaround:

If "get atmPortIfType" returns unknown (1), NMS can query other object slotBackType to determine if interface type is actually T1 or E1. uaiT1(43) and uaiE1(44) of slotBackType are used for UXM T1/E1.

CSCdk04998

Symptom:

Control traffic consisting of coerced messages do not have a throttle on the receiving end. Excessive coerced messages can lock up the network handler due to the time spent processing the received messages.

Conditions:

Coerced messages are normally sent at a very low rate. During abnormal conditions, such as network message floods due to bad hardware, the increased coerced message rate can lock up the network handler due to processing of every message. At worst, node system resources can be exhausted.

Workaround:

No workaround. This is a very unique situation in which coerced messaging is abnormally sent through the network at extremely high rates. Stopping the source of the coerced messages will end the network handler lock up.

CSCdk05205

Symptom:

When a UXM port fails, the node should be declared to be in Minor Alarm if it is configured as a UNI port, or in Major Alarm if it is configured as an NNI port.

Impact:

User will not know if a UXM port fails via the normal alarm reporting mechanism.

Workaround:

If it is suspected that traffic terminating on a UXM port is being lost, the dspportstats command can be run on that port to determine if the port is actually failed.

CSCdk05249

Symptom:

Virtual Path Identification (VPI) assigned to VPC connections that are routed UXM trunk always use default values starting at VPI of value 2. The starting VPI value should be offset with the VPI address assigned to that UXM trunk.

Conditions:

Occured if user modify the VPI Address to be other than default value (1) in cnftrk of the UXM trunk.

Workaround:

None

CSCdk05440

Symptom:

swerr 513 is logged and possibly a 1000003 abort

Conditions:

This problem is related to a bug in tftp event handling when an unrecognized tftp event is received.

The specific unrecognized event here is caused by deletion of statistic file using the cnfnodeparm command in a network with several 8.4 images. The TFTP events handled by these images are different.

Workaround:

None.

Additional notes: The fix here does more than making sure the proper TFTP events are handled. It also prevents the 513 and 1000003 abort if somehow an unrecognized TFTP event is received.

CSCdk05545

Symptom:

Networking channels on BXM cards are now sent to the firmware in groups of up to 5 instead of 1 as before.

In case of full scale reprogramming of a 12 trunk BXM card in a network of 200 nodes the task should now take about 8 seconds compared to 30 to 35 seconds before.

CSCdk05859

Symptom:

Unexplained symptoms during periods when allocated memory is not available. Possible memory corruption of allocated memory in a region that has run out of or is low on space.

Conditions:

System low on region memory. Use dspprf t r and dspmemblk to determine available region memory. Unexpected events occur during this period (swerrs, unexplained failures).

Workaround:

No workaround. Processor switchover may allow for better utilization of region memory in the case of fragmentation. Processor rebuild would certainly help.

CSCdk05920

Symptom:

In configuring routes with cnfpref or displaying routes with dspconor dsprts, swerr 1423 can arise.

Conditions:

This condition can occur if a trunk becomes unavailable due to trunk failure or trunk deletion.

Workaround:

There is no workaround. However the problem is not serious as a result of the swerr, the display will show that the route is pending.

CSCdk05952

Symptom:

CAC - Connection Admission Control is not supported.

Impact:

Cannot use the feature.

Workaround:

None.

CSCdk06091

Symptom:

Swerr 925 (Invalid lline number) logged on node.

Conditions:

Lots of upping and downing of the same line or trunk (usually simultaneously via multiple UI or via jobs). The swerr is logged during the handling of the upln or uptrk event when it finds that the line or trunk does not exist.

Workaround:

No workaround, but symptom is harmless except for the use of the swlog space. The handling of the upln or uptrk event should be ignored if the line or trunk does not exist. Currently it is ignored, but the swerr is logged as well.

Problem is not likely to occur unless excessive testing is being done on upping and downing lines in large numbers in succession.

CSCdk06428

Symptom:

If a user logs into a node through telnet, an event log message may be logged incorrectly saying that the user logged in as a high priority login.

Workaround:

There is not workaround. Just ignore the high priority login event log message.

CSCdk06748

Symptom:

If a firmware burn has been started, then installing/removing any other cards in the node, or resetting any cards, then it is possible that the firmware burn operation will stop. It will then have to be restarted.

Conditions:

This is a problem only when a firmware burn is in progress

Workaround:

While any firmware burn is in progress, do not install/remove any other cards, or reset any cards in the node.

CSCdk06763

Symptom:

Too many VPCs (Virtual Path Connection) are routed over UXM UNI trunk.

Conditions:

When a UXM trunk is configured as UNI interface, total number of VPC connections routed over this trunk should not be greater than 255 connections.

Workaround:

Do not route VPC connections when a UXM trunk is configured as UNI interface attached to a Public network. Use cnfpref to avoid the UXM UNI trunk.

CSCdk06823

Symptom:

The swerr 347 happens when the SW tried to program the device code/chan address which has been used by another connection already.

Conditions:

The problem will happen when the switch are rerouting a lot of connections, and in the same time the Active PCC failed. The node will do a switch over due to the failed PCC. Because this is abnormal switch over, we could lose update information (e.g. dc/ch) after this situation.

Workaround:

Rebuild the node to force rerouting those connections will solve this problem if you don't know what are those connections that having the problem. 2. Reroute those connections which have the problem.

CSCdk06880

Symptom:

Networking channels are being programmed multiple times when the card is reset or during switchcc.

Conditions:

For BXM cards, this amounts to 2400 cbus messages on 12 trunk cards with 200 nodes on the net.

Calling the function twice within the same second causes another 2400 Cbus messages to be queued up. Besides wasting a lot of time a swerr 123 becomes more likely especially for 8.4 and 8.5.

Workaround:

None

CSCdk07110

Symptom:

dspcd on standby processor card does not show the BOOT ID or the BRAM size on all IGX node.

Conditions:

The detailed card display of the standby processor card does not show the BOOT ID or the BRAM size.

Workaround:

From active processor card, use VT STBYPCC to the standby processor card and enter dspcd. The detailed card display shows proper information.

CSCdk07613

Symptom:

Software error 513 is logged when adding a UVM to UVM connection.

Conditions:

The above software log occurs after user adds a voice connection between tow UVM cards. This problem is related to display only. The connection is added properly.

Workaround:

CSCdk07894

Symptom:

dsppwr displays "Present" instead of the actual power supply type on an IGX.

Conditions:

CSCdk07991

Symptom:

The screen gets messed up when dspcons with an endpoint on an ALM-A card or a feeder trunk whose VCI is out of range (0 to 255).

CSCdk08069

Symptom:

The UVM voice connection state is in DSP_FAIL even receiving the NO_ERROR event from the card.

Conditions:

When UVM has resource error (DSP_ERROR) the connection is failed as DSP_F. When the problem cured (NO_ERROR event is reported) the connection state is not update to OK state.

Workaround:

Reset the UVM card to force the rebuild of the connection state.

CSCdk08193

Symptom:

Networking channels may not be reserved properly for UXM card with UAI-4T1/E1-IMA back card.

Conditions:

This problem is encountered only if the UAI-4T1/E1-IMA back card is used as a trunk card and user plan to change UAI-4T1/E1-IMA back card to UAI-8T1/E1-IMA back card in the future.

When UAI-4T1/E1-IMA back card is installed, the system should reserve enough networking channels for user to be able to upgrade from UAI-4T1/E1-IMA back card to UAI-8T1/E1-IMA back card. Currently, the system reserves only enough networking channels for 4 ports. User may have some problem when changing the back card from 4 ports to 8 ports.

Workaround:

To avoid the problem in the future, if user is currently installing a UAI-4T1/E1-IMA back card, it is recommended that user should enter cnftrkport to set the maximum number of trunks allowed on this slot to 4 prior to uptrk command.

CSCdk09235

Symptom:

ATM connection class parameters are starting with 9.1 used by IGX/IPX nodes also. This bug fix resolves inconsistencies that could have been between BPX switches and IGX/IPX switches, however while there are still 8.4/8.5 nodes in the net there could be inconsistencies when the lowest number node is not a 9.1 BPX and there are (routing) IGX switches in the net:

The reason is that 8.4 BPX switches do not accept atm class updates from IGX/IPX switches. 9.1 IGX/IPX switches therefore don't even send those updates to 8.4 nodes. 8.4 BPXs don't send these updates to IGX/IPX switches either.

Inconsistencies can only arise, when two network with different connection class parameters are joined.

In the following 8.4/8.5 IGX/IPX switches are not considered when determining the lowest numbered node.

If the lowest numbered node is a 8.4/8.5 BPX, the BPX switches will all be consistent, and IGX switches do not support UXM cards in a mixed net, therefore any inconsistency between BPX switches and IGX/IPX switches are not relevant. They will be resolved when the lowest numbered node upgrades.

If the lowest numbered node is an IPX/IGX running 9.1, the BPX switches running 9.1 will use its values, and the 8.4/8.5 BPX switches will use the values of the lowest numbered BPX in the net. If there is an inconsistency, it could be resolved by a cnfcls command on a BPX.

Workaround:

When joining two networks with a resulting network with 8.4/8.5 and 9.1 nodes that have different connection class parameters, the preferred configuration is to have a 9.1 BPX be the lowest node number. The next best is a 8.4/8.5 BPX. The other case is an IGX/IPX to have lowest node number. For the two cases with possible inconsistencies, work arounds have been described above.

CSCdk09359

Symptom

:The UFM background test for the standby card of a y-red pair was failed if some UBUs were previously allocated by the getubus command.

Conditions:

This problem only occurs when an UFM is configured as y-redundant and when it is in standby state with some UBUs allocated by the getubus command. If the standby UFM does not have allocated UBUs by the getubus command then this problem will not be occured.

Workaround:

Do not allocate any UBU to the standby UFM by the getubus command.

CSCdk10051

Symptom:

The cnfrsrc command allows multiple partitions to be enabled on the same port.

Conditions:

In 9.1, only one partition is supported. Having multiple partitions results in a failure of communication between the VSI master and the slave.

Workaround:

Avoid enabling partition id 2 on the same port.

CSCdk11923

Symptom:

Command dspprf s which display the system performance of the standby processor card may cause unpredictable result in other area.

Conditions:

When user enter the above command, there is an error in the code such that incorrect parameters are passed to the calling routine which may cause unpredictable result. The dspprf screen itself may be correct, however, other data area in the system may not be correct.

Workaround:

Avoid using parameter `s' of the above command on the standby processor card.

CSCdk12849

Symptom:

Memory leak in RSRC process as displayed by dspprf t m command.

Conditions:

This occurs when downing and then upping UXM cards. (UXM cards only). Card selftest on Standby UXM cards.

Workaround:

Turn of UXM card selftest using the cnftstparm command.

CSCdk13122

Symptom:

Swlog 116 (BAD_OBJ_RESP) seen on node.

Conditions:

UXM card only. Have UXM card that has a line upped but no port is upped.

Workaround:

Up the port associated with the upped line on the UXM. Another workaround (not as recommended) is to turn off port stat polling using command off2 11.

CSCdk14493

Symptom:

Swerr 526 (NEG_FILL_REQ) logged on BPX node.

Conditions:

dspport command issued on a port that is part of a y-redundant configuration.