8.5.09 Version Software Release Notes
Cisco WAN Switching System Software

BCC-32

H.B.J

BCC-3-32

H.C.M

BCC-3-64

H.D.M

BCC-4

H.E.M

NPM-32 (1 M BRAM)
NPM-32B

R.B.M R.E.M

NPM-64 (1 M BRAM)

R.C.M

NPM-64B (4 M BRAM)

R.F.N

NPC-32

B.B.F

NPC-64

B.C.F

0-3999 connections

Polling Rate: 5 Minutes (or higher)

4000-8000 conns

Polling Rate: 10 Minutes (or higher)

8000-12000 conns

Polling Rate: 15 Minutes

CSCdj39755

User is unable to configure the port polling rate for interval statistics on the BPX. No workaround available.

CSCdj42770

Under some timing scenarios, if the number of DS0s configured for a T3/E3 is less than or equal to 32, the number of connections that can be routed through that E3/T3 trunk is reduced to 213 connections, instead of the normally 1771 connections. Workaround: When configuring a T3/E3 trunk, make sure to configure it with 33 or more DS0s.

CSCdj46374

Symptom: On very heavily loaded nodes it is possible to get a watchdog abort on upgrades when operational parameters are not relaxed for the upgrade window.

Work Around:

For the upgrade, set the RSRC process watchdog threshold to at least 120.

CSCdj47677

Abort 1000 or software error 52 (WDT) within hours of adding a new trunk to a network. The nwstats a command on the control card that aborted shows a very high "Rx Pkts w/ Bad Chksm" or "Ident Pkts". The abort(s) are in the "NETW" process. Workaround: Remove or restrict CC traffic on the new trunk. This is typically a bad card adding packets to the muxbus/data lane. Removing the new card may also clear the problem.

CSCdj51915

It has been observed that software error 104 occurs occasionally on BCC switchover when ASI cards are active on the node. No workaround needed. There is no apparent impact from this event.

CSCdj52771

Software errors 4208 and 2064 logged on the Standby in the VNS lab. The problem occurred when adding or deleting connections. 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. No workaround available.

CSCdj53907

Issuing the cnftrk command on a BNI-E3 virtual trunk with a value larger than 1771 for "Connection Channels" may receive an error message indicating an incorrect limit. No workaround available.

CSCdj54371

It was observed that traffic could drop due to oversubscription of the card, with no warning given to the user. The problem can occur on a BXM-8-155 or BXM-2-622 that has more than OC-12 of guaranteed bandwidth configured on the card.

Workaround: Change connection rate or move some connections to another card. The throughput of any BXM card is OC12.

CSCdj55127

NPM switchover can cause temporary communication breaks between nodes. This problem was observed only on heavily loaded nodes (5000 terminated connections). No workaround available. User traffic not impacted.

CSCdj56030

Software error 21 occurred during switchcc. This is not service affecting. No workaround available.

CSCdj59861

Some connections on the slave end(s) do not get rerouted, (i.e. stay in the FAILED state), while their master end(s) show that the connections are routed, and that dsprts shows that these connections have a good path on the master side, while their slave side(s) show(s) that the connections are derouted. These failed connections could not pass data while in this state. Workaround: Run updates 3 from the failed connections' master node(s) to their slave node(s).

CSCdj60325

The BXM port discards all data (user data, AIS, tstcon, tstdelay) at its PVC ingress when dspcon shows PVC has remote segment failure (such as FR LMI failure).

CSCdj61173

FTM card on an IGX node is erroneously shown as FTC in some error messages and log messages.

CSCdj62635

Software error 1000 occurred on an IGX node when switchcc was executed on a neighbor IGX node. It should be noted that the error was caused by a defective BTM card, not necessarily related to the switchcc command. The abort happened when there were no more pSOS message buffers. The network statistics showed lots of rapidly accumulating packets with bad checksum. Many cards were showing card failure events.

Workaround: Monitor network statistics with the nwstats command. Remove any cards which are not shown by the dspcds command.

CSCdj64510

Some abrfst connections that route over virtual trunks don't throttle to reach 100% capacity. No workaround available. Under investigation at time of release.

CSCdj67013

Symptom:

VC conditioning is not correct, i.e., no conditioning when the other end card type supports frame relay and it is in circuit line alarm status.

Condition:

1.Have a BPX connection with the other end supporting FRM or UFM

2.Cause the other end card to have a circuit line failure, e.g. LOS

3.The BPX end of the connection will not condition the connection correctly as a side effect of bug fix CSCdj66856 (which fixes the A-bit status)

An internal card initialization (software) data structure is not set up correctly for frame relay card types. No user access to the data is available.

Workaround:

None

Further Problem Description:

This fix is needed to complete the fix CSCdj66856, which addresses this problem for all other connection configurations.

CSCdj67042

Software error 4208 occurred when repeatedly issuing the prtcons command on a connection from a local CDP to FTC Access Device. No Workaround available.

CSCdj67818

When a job tries to execute cnffrcon command on an Access Device connection, the results are stated to be "Passed", when in fact they were "Failed". While the connection is not modified, job continues to run as though the command was successfully executed.

Workaround: Use cnfadcon command in the job to configure Access Device connections.

CSCdj68707

Symptom:

For ports that have ILMI enabled, sometimes a Trap may not be sent in response to a state change for a conn on that port.

Conditions:

This condition can occur on ports (ASI/BXM) that have ILMI enabled.

Workaround:

None.

CSCdj69179

The dspcds command on an IGX displays a BTM-E2 backcard as an AIT-E2. This is an error in the string displayed, there is no invalid data in the database. No workaround available.

CSCdj71878

It has been observed that the User_ID database can be corrupted due to memory corruption under very rare circumstances. Unable to recover from the problem corruption can lead to two identical entries in the user id update message. Documentation is available to prevent this problem.

CSCdj72605

It has been reported that for release 7.4.06 software, interval statistics reported to the SV+ are erroneous for all nodes in the network. Workaround: None available at this time. No similar problem has been seen on 8.5 software, but the problem is under investigation.

CSCdj72833

Symptom:

ALMA ATM connections can be added to non-ALMA ALMs.

Conditions:

Non-ALMA card at remote end.

Workaround:

Make sure of the remote endpoint before adding ALMA connections.

Further Information:

The ATM connections made between ALMA and ALMB/AIT can not be differentiated at the slave side.

In general, it is the slave side that checks the compatibility between the 2 card types by checking the cd_type field that is sent from the master. Since all these card types map to AIT_CD, it is impossible to differentiate.

Workaround: None available.

CSCdj72907

Symptom:

After a CC switchover (including graceful upgrades), the receive side loading for trunks on that node (where the switchover occurred) show zero (0).

Conditions:

Upgrades and switchovers.

Workaround:

1) For each trunk exhibiting the load inconsistency, use dsptrks command to determine the node on other end of that trunk. From the node at the other end of the trunk issue "updates 2 <node with load = 0)". This will initiate a conditional update which passes the trunk loading information for the node issuing the updates.

OR

2) Wait for the conditional updates to issue themselves. This will occur normally after a switchcc or upgrade, but at a slower rate. The nodeparm #2 dictates the interval between requests for conditional updates, and a different node (in node number order) is requested at each interval. So the load will correct itself after (nodeparm#2) x (#nodes in network).

Further Problem Description:

This is a relatively benign. If a connection fails to route because a node's loading information is not up to date, the nodes which the connection (when routing) determines is "out of synch" automatically issue the loading update to the connection's master node. Therefore, the worse case scenario here is that if connections need to reroute after an upgrade/switchover, they may take multiple tries to reroute.

CSCdj73551

The on-line help command erroneously displays help messages for the commands that are no longer being supported.

CSCdj73568

User can view the connection that is in the process of being deleted using the dspcon command. Workaround: Issue the dspcon command again and the message that the "Connection does not exist" will be displayed.

CSCdj73847

One LDM in a test node running software rev 8.2.33 experienced some background test failures indicating the test packet returned by the LDM contained all 'FF's. No workaround available.

CSCdj73989

If a user enters an illegal option for the command prtcons, the available options are displayed to the user. These are not consistent with the options that are presented when the user enters the help prtcons command.

Workaround: The correct options can be found by typing prtcon -z command. Also, the correct options can be found by typing command help dspcons.

CSCdj77566

UFM-U Measured Clock speed shows an incorrect value according to its configuration on UFM-U HSSI ports. This problem occurs when the UFM-U port speed is not configured in multiples of 1024. Software does not restrict misconfiguration of the port speed.

Workaround: Reconfigure the port speed to a multiple of 1024.

CSCdj78291

The dspchcnf screen displays BW parms for CVM/UVM to FTM Voice Interworking connections as random bad values. There is no workaround except for issuing dspcon or dcct commands to see the bandwidths of the CVM/UVM to FTM Voice Interworking connections.

CSCdj79811

The addfrcons command logs a software error 921 when one of the connection endpoints is a non-existent UFM port. There is no impact on network operation.

Workaround: To avoid the software error, press the Delete key at the prompt message. Create the port (using addfrport) and activate it (using upport), then repeat the addfrcons command. If the software error appears, you can clear it using the clrswlog command.

CSCdj80821

The clrchstats * command doesn't clear the ALMA connections stats. Workaround: Issue the clrchstats separately for the each connection.

CSCdj81576

The value for cnfcmparm #21 was configured to be 500. User observed that during a trunk failure, the connection with a higher COS priority has been re-routed before the lower priority connection can be re-routed.

Workaround: Configure cnfcmparm 21 = 0. This will deroute all the conns in a single block. Conns will then be rerouted using the COS.

CSCdj82050

Symptom:

BXM VI trunk stats (listed below) and UXM VI/Gateway stats (listed below), can have invalid peak data values (too large), or will not be collected at all.

Condition:

I. INVALID PEAK VALUES: This condition can occur if:

1) BXM VI or UXM VI/Gateway statistics are enabled, AND

2) The trunk peak interval is not a multiple of the port polling rate.

This will result in the BXM VI and UXM VI/Gateway statistics, peak data values being incorrect (too large).

II. SPECIFIC STATS NOT COLLECTED AT ALL:

1) BXM VI or UXM VI/Gateway statistics are enabled, AND

2) The port polling state machine is not enabled

Under these conditions, the BXM VI and UXM VI/Gateway statistics will not be collected at all -- they will always report a value of zero.

Work Around:

1) The BXM workaround for condition (I) above is to ensure that the BPX ATM trunk peak interval is a multiple of the port polling rate.

For 8.4, 8.5 and 9.1 the BPX's port polling rate is 5 minutes, because the BXM VI stats are treated internally as port stats, when BXM VI stats are enabled, all BPX ATM trunk statistics' peak intervals will need to be a multiple of the port polling rate.

The UXM workaround for condition (I) above is to ensure that the IGX ATM trunk peak interval is a multiple of the port polling rate.

For 9.1, the IGX's port polling is user configurable to be 5, 10 or 15 minutes. UXM's VI/Gateway stats are treated internally as port stats. When these stats are enabled, all IGX ATM trunk statistics' peak intervals will need to be a multiple of the port polling rate.

The current IGX port polling rate can be determined by doing the following:

Enter the command cnfsysparm 25 Press the <DEL> key.

The screen will now display the "Interval Statistics polling rate for ports" in minutes.

2) During normal operations always have the port polling state machine enabled. The default is for this to be enabled. It is controlled by the on2/off2 options for "Port Stat Sampling".

MORE ON THIS DEFECT:

The statistics that can have these problems are:

8.4, 8.5, 9.1 BXM VI stats

Num Name

40) Number of cells rcvd w/clp 0

8) Number of cells rcvd w/CLP set

41) Number of cells dscd w/clp 0

42) Number of cells dscd w/clp set

43) Number of cells tx w/clp 0

14) Number of cells xmitted w/CLP set

12) OAM cells received count

44) Tx OAM cell count

45) Rx RM cell count

46) Tx RM cell count

CSCdj82050

(continued)

91 UXM VI stats

Num Name

34) VI: Cells received w/CLP=1

36) VI: Cells transmitted w/CLP=1

38) VI: Cells received w/CLP=0

41) VI: Cells transmitted w/CLP=0

40) VI: Cells discarded w/CLP=1

39) VI: Cells discarded w/CLP=0

35) VI: OAM cells received

42) VI: OAM cells transmitted

43) VI: RM cells received

44) VI: RM cells transmitted

91 UXM GATEWAY STATS stats

Num AUTO? Name

39) CGW: Packets Rx From Network

40) CGW: Cells Tx to Line

41) CGW: NIW Frms Relayed to Line

42) CGW: SIW Frms Relayed to Line

43) CGW: Aborted Frames Tx to Line

44) YES CGW: Dscd Pkts

45) CGW: 0-Length Frms Rx from Network

46) CGW: Bd CRC16 Frms Rx from Network

47) CGW: Bd Lngth Frms Rx from Network

48) CGW: OAM RTD Cells Tx

53) CGW: Packets Tx to Network

54) CGW: Cells Rx from Line

55) CGW: NIW Frms Relayed from Line

56) CGW: SIW Frms Relayed from Line

57) CGW: Aborted Frms Rx From Line

58) YES CGW: Dscd Cells

59) CGW: 0-Lngth Frms Rx from Line

60) CGW: Bd CRC32 Frms Rx from Line

61) CGW: Bd Lngth Frms Rx from Line

62) CGW: OAM RTD Cells Rx

63) CGW: OAM Invalid OAM Cells Rx

This problem occurs because internally some of the statistics are treated as port statistics which poll at a different (larger) rate than the trunk statistics. This can then throw off peak calculations, because the incoming peak data point is for an interval larger than the peak interval.

CSCdj82321

The delshelf command is no longer applicable for the IPX/IGX nodes in Release 8.5.

CSCdj82457

Bad device code value (DC = zero) was logged for some voice dax connections after a graceful upgrade from release 7.4.05 to 8.5. No workaround available.

CSCdj82050

BXM's VI trunk stats and UXM's VI/Gateway stats can have invalid peak data values (too large), or will not be collected at all.

Workaround: Detail workaround procedure can be found on CCO Bug Navigator.

CSCdj83869

The command addfrcons does not work for certain tiered net connection segments. The command produces the message "Invalid connection on remote end" and the connections are not added.

Workaround: Use the addcon command to add the connection segments individually.

CSCdj84866

Symptom:

ALM-A only supports 1000 LCNs. Switch software however does not block adding more than 1000 LCNs. The excess connections will be failed and will not pass traffic.

Conditions: Same as above

Work around: None

CSCdj86689

Egress traffic on a frame relay connection is corrupted. It is seen that traffic from 2 connections are merged on 1 connection. This problem was seen when 2 nodes were trying to route connections at the same time. This problem could not be duplicated in the lab.

Workaround: If this problem is seen, find out which path the connection is going across, go to each node along the path, and if the trunk that connection traversed across is a T3/E3 trunk on a IPX/IGX, run the following commands to detect if there are trunk programming problems on the trunk cards:

1) at each node alone the path, enable the hitless switchcc feature e.g. on3 4 - Card Synchronization

2) run synccd -disp <trunk #> on each of these trunks.

3) wait 5 minutes, run dspsyncstats to see if there are any dangling connections on that trunk.

4) if yes, run synccd <trunk #>

5) wait a couple minutes, run dspsyncstats again to verify that the dangling connections are removed. The dspsyncstats command will report the number of dangling conns removed, if it is run after a synccd command without the '-disp' option.

6) if the problem still persists, try switchcc on each node alone the path.

CSCdj87777

This bug fix makes the software more robust against (rarely occurring) hardware failures of trunk cards resulting in a flood of valid cells sent to the processor card. Aborts 1000 were the usual result plus Comm Fails and Comm Breaks.

This bug fix takes care of the Aborts and the Comm Fails. Comm Breaks will still be observed until the defect card is replaced.

CSCdj89199

Software release interoperability support is missing for certain event log messages. Also, a few events are not being properly forwarded to StrataView. In a network with combination of release 9.1 on some nodes and release 8.4 or 8.5 on other nodes, certain event messages would be lost. No workaround is available.

CSCdj89705

It was observed that after burning the firmware boot code version J or higher, BRAM power-up failure may occur. Problem is still under investigation. No workaround available.

CSCdj89784

It was observed that while running release 8.5 software with 1000 Frame relay connections at 8kbps each routed across a T3 trunk, a 1344Kbps NTS connection, and a 256K connection across the same trunk, software ceased to respond to the command prompt. After 5-10 minutes of non-response and unable to 'vt' into the node, pulling the HDM card allowed the node to come up. Problem is still under investigation. No workaround available.

CSCdj89858

The dspnw command overwrites the line that divides the display portion of the screen from the port that echoes the command line.

Workaround: Use the dspsrcn command to get the line back again.

CSCdj89665

Incorrect information displayed in the dsplog screen after an upgrade from release 7.4 to 8.5. No workaround available.

CSCdj89954

When adding a new fr-atm connection with the atm endpoint being an ASI port the value of atmEndPointICRTO can bet set to 10000. However, when the modify is being execute and the same variable is being set to 10000, an error message is displayed indicating "ADTF value out of range (local end). Valid range 62 - 8000."

Workaround: This situation can be avoided, if we do not configure the ADTF value for a local connection from the ASI end the very first time. First time we change it from BXM side, it does restrict the range between 62-8000 and from then on cnfcon command will restrict ASI and BXM endpoint ADTF values.

CSCdj90545

Various CM messages contain a rate index. This value is used to index into the Cm_Rates[] array. If the index is out of range bad values are referenced that can result in negative loads on trunks.

CSCdj91643

The upln command caused database inconsistency if the primary card is removed from a y-redundancy.

Workaround: Make sure the primary card is added.

CSCdj91963

The dspcon command displays "Line info. unavailable" error message for the connections made from a BPX node to slot 16 on an IPX/IGX node. Problem still under investigation. No workaround available.

CSCdj92171

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

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.

CSCdj92302

Symptom:

When `tstdelay' or `tstcon' is run on the 1000th frame relay connection added to a UFM card, the node may stop responding to all user input on the current user session. However, a new telnet session allows user access to the node. The new user interface continues to run slowly after the conclusion of the `tstcon' or `tstdelay' until the connection is deleted. Much of the processor time is shown in FAIL transaction on the `dspprf' screen with little IDLE transaction time available.

Software error 501's or 104's may occur during the unresponsive period.

Condition: Running software release 8.5.F5 or 8.5.G3 [pre-release versions of 8.5.05], 1000 connections between 2 UFM cards were added sequentially from slot.1.100 through slot.8.224 with 125 connections on each of the 8 ports of the UFM. When `tstdelay' is run on the last connection added, the node becomes unresponsive. All connections traverse one hop across an E3 trunk.

When only 999 connections were added, the failure did not occur. Only a `tstcon' or `tstdelay' on the 1000th connection causes the failure.

Work Around:

Limit the maximum number of connections to a UFM to 999 rather than the software limit of 1000.

If the failure occurs, delete the connection which the `tstcon' or `tstdelay' was last executed on. This should restore normal node responsiveness.

A switchcc will also restore the node to normal operating order.

CSCdj92572

The copycons command is not allowed in job mode on the BPX. No workaround available.

CSCdj92704

The tstdelay command may fail for UXM-UFMU atfst connection when the AIT/BTM/ALMB trunk is in the via node.

Workaround: Disable AIT/BTM/ALM 32h Ext2 option using the off3 3 command.

CSCdj93499

Watchdog occurred during switchover on BCC-3 with 6000+ connections (32 meg BBC-3 and watchdog = swerr 52). This problem is likely to occur in heavily loaded BPX with BCC-3 (32meg) and 6000+ connections.

Impact: After switchover to new BCC, node rebuilds.

Workaround: Using StrataCom level access, issue command cnfprf rsrc [e|d] 120, where 120 is the rsrc process watchdog limit in seconds. The rsrc process is taking an inordinate amount of time after the switchover. Setting the watchdog timeout higher will avoid the watchdog until a solution can be found and distributed.

CSCdj93730

When issuing the dsplogcd command, the display may be wrapped to the next line and overwrite "Cnfg Ptr" on that line on the dsplogcd screen, if the value of Rcv Line Rate in LUs is large. No workaround available.

CSCdj93749

Resetting the CVM card on an IPX/IGX node caused the DAX CVM to FTM connections to be in the failed state. This will happen if the user resets the CVM/UVM card manually or pulls the card out and reseats it. It could also happen if the card resets automatically somehow in the switch.

Workaround: Resetting the FTM card on the other end will clear the failure problem.

CSCdj94398

The dspcmi L <slot> command shows card name being empty after a rebuild when there is a card in the logical slot. No workaround available.

CSCdk00299

When issuing the addcon command on the CVM/UVM to FTM voice interworking connections there will not be a warning telling the user that the frame relay port is oversubscribed (i.e., the sum of PIR's is greater than the FTM port speed). No workaround available.

CSCdk02935

Symptom:

Yred mismatch not declared.

Conditions:

BTM cards

Workaround:

None.

CSCdk05596

Symptom:

Software error 514 (memory overwrite)

Conditions:

addrmtlp command entered on CLI for connection on remote node.

Workaround:

addloclp AND addlocrmtlp commands

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.

CSCdk21160

Symptoms:

Interval statistics on the Cisco StrataView Plus are smaller than expected after a clrportstats, clrchstats or a clrtrkstats command is executed.

Conditions:

Whenever any of the commands that clear summary stats are executed: clrportstats, clrchstats or clrtrkstats, software will drop one or more ensuing polls, for ALL statistics (including interval statistics) rather than just for summary stat. The end result is that we will miss one polls worth of information.

Workaround:

None at this time

Impact:

After invoking one of the above commands software will disregard the next statistical poll for all statistics, even though the command is meant only for summary statistics. This result in data loss as explained below.

For releases 8.4 and later the polling rates are:

Frame Relay and ATM connections: User configurable to 5, 10, 15 minutes

All other types of conns: 1 minute

Ports: 1 minute

Circuit Lines: 10 seconds

Packet Lines: 10 seconds

For releases 8.5 and later the following changes apply

Ports(IPX/IGX): User configurable to 5, 10, 15 minutes

One samples worth of data will be lost, so the worst case scenario would be a loss of 15 minutes worth of data for 8.4 FR/ATM connections or 8.5 FR/ATM connections and 8.5 Ports.

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.

CSCdk21381

Symptom:

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 anyway.

Conditions: Same as above

Work around: None

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.

CSCdk23431

Symptom:

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

Conditions:

The `dspports' command on the IGX switch shows inactive ports on the T1/E1 back card 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.

Work Around:

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

CSCdk23859

Symptom:

Software error 508.

Conditions:

8.5/9.1 interop network.

Workaround:

None.

Further Information:

A system process was unable to send a message to another process. Could indicate a message lost to an external interface.

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

CSCdk27691

Symptom:

Software error 901

Conditions:

8.5/9.1 interop network

Workaround:

None.

Further Information:

Indicates that cm rate index is out of range. This is an internally stored value for connection type information.

CSCdk28204

Symptom:

A software error 526 appears if a card failure event log string is longer than 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 reset, card down and up, node rebuild.

Workaround:

Rebuild local end of connection or down and up connection.

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)

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:

There is no work around. However, try to keep the number of connections minimal if there is any.

CSCdk33055

Symptom:

When both the UVM cards in the Y-red pair are not present, and one card is inserted; 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.

CSCdk33290

Symptom:

Software error 372 was produced.

Condition:

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.

CSCdk37257

Symptom:

Connections stay in failed state after upgrade.

Conditions:

Non graceful upgrades to 8.5.06.

Workaround:

1) dncon/upcon to clear state

OR

2) resetcd to fail/clear all connections on a slot.

Further Information: When upgrading to 8.5.06 in non-graceful (sometimes during graceful) manner some conns will be in fail state. This depends on the conn config.

do dcct - and checkout the third page col 2. If the Cdt bit, Hrd field is set - it means that the cons needs conditioning.

WorkAround

1. Reset the card to fix all cons

2. If there are only few cons, upcon / dncon will also work,

CSCdk40766

Symptom:

The modem session for an UVM connection failed.

Conditions:

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

Workaround:

No work-around.

CSCdk45222

Symptom:

Software error 532 is logged.

Condition:

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

Workaround:

None.

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.

Work Around:

Never enable the feature in 9.1 IGX.

CSCdk47079

Symptom:

Software tries to access the invalid memory entry cause the ABORT.

Condition:

While doing the dth command, and the memory is corrupted thus cause the switch abort. Software error 1000003 is logged.

Workaround:

Make sure to clean up the unexpected event first. Do cth then dth.

CSCdk47379

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.

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.

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.

CSCdk55335

Symptom:

BIP8 error Alarm Threshold not triggered

Conditions:

Error rate at 10E-9 on E3 lines

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.

CSCdk56580

Symptom:

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

Conditions:

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

Workaround:

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

CSCdk61619

Symptom:

Low idle time during SNMP retrieval of SNMP real time counter statistics (RTC statistics).

Impact:

The impact is minimal, this is mainly a performance issue. The idle time will be reduced during SNMP retrievals of SNMP RTC statistics. However, it does not starve the command line interface or any other processing, it merely slows it down.

Work Around: None

Further Description: This performance problem is caused because the controller card sends a statistics poll to the line/trunk card for each RTC to be collected from that card. (i.e. if a trunk supports 5 RTC stats, and we do an SNMP walk on all of the RTC stats for that card, then 5 polls are sent down to the card--when one would suffice).

The end result is that the system gets busy, and the SNMP response time is a little slower than it could be.

On the BPX, trunk and line stat polling is card based, meaning one statistics poll sent to the card will handle all of the lines and trunk on that card. So for a BXM card that can support 31 interfaces (lines, trunk or virtual trunks) if we did an SNMP walk for all of the stats on all of the lines and trunks we would generate more than 1000 statistics polls.

Once again, note that this does not starve out other processes. It will not prevent reroutes, or other command line interface commands, it is merely more work for the CPU to do during that time.

CSCdk67128

Symptom:

Port card (UFM-U or FRP-V35) are in yred configuration. Resetting one or both of the cards causes the card to go into mismatch with reason: "Backcard is reserved for Missing"

Conditions:

Yred configuration on port cards. Upped ports and then downed all ports. This causes backcard type of primary slot to be cleared.

Workaround:

Delete yred configuration. Mismatch clears. Re-add mismatch configuration.

CSCdk70370

Symptom:

Discards of between 20-30% of all traffic on atfx channel between an ALM/A and a UFMU in IGX switch network.

Conditions: Same as above

Work around: None

CSCdk71298

Symptom:

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

Conditions:

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

This problem is very rare.

The cause of this is under investigation. This problem may or may not related to CSCdk71860.

Workaround:

* Try to delete and re add the connection.

* A new command "rbldcondb" has been added to BPX/IGX/IPX to rebuild the connection database and check/remove any inconsistencies in between LCON and VC databases. This command does the following things: - Checks the VC_DB against LCON DB and removes any inconsistencies. - Checks the LCON DB against VC DB and removes any inconsistencies. - Checks the via connections and removes the inconsistencies. - Rebuilds all the logical endpoints for all the connections on the node again.

This command should be run only under the following conditions:

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

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

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

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

CSCdk71860

Symptom:

Decreasing number of connections on BXM feeder trunk may cause database inconsistency.

The dspcons may show extra connections while dspcon does not allow user to access such connection.

Conditions:

In 8.4 and 8.5, number of connections on a BXM feeder trunk can be changed using the cnftrk command. In 9.1, the cnfrsrc command is provided.

When user decreases number of connections on a BXM feeder trunk to be the number of channels in use, this will cause database inconsistency.

Work around:

Before changing number of channels on a feeder trunk, user should make sure new number is larger than number of channels currently in use.

Try changing the number of channel back to the old value.

CSCdk75382

Symptom:

The modem upgrade failed. The failure rate may be as low as 10%, or as high as 95%.

Conditions:

This happen randomly.

Workaround:

1. Try again after failure.

2. If the failure rate is very high, try using the Fax Relay feature:

a. Enable fax-relay on the channel or channels with the command cnfchfax.

b. Disable V.25 modem detection on the channels with the command cnfvchparm.

3. Upgrade software to release 9.1.07 or above.

Further Problem Description:

This problem is caused by a race condition in software. It occurs only about 10% of the modem sessions in the lab. In a customer environment the failure rate has been observed as high as 95%.

CSCdk77005

Symptom:

An IGX16 rebuilt within a day after a software upgrade to 8.5.06. The node logged a 1000003 software error.

Conditions: Same as above

Workaround:

No workaround.

CSCdk77462

Symptom:

ATM Port real-time counters are not collected correctly.

Condition:

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

Workaround:

None.

CSCdk78299

Symptom:

Node aborted when upgrading the network.

Conditions:

Same as above.

Workaround:

None.

CSCdk81800

Symptom:

OC3 rate hi-priority traffic circulating on a trunk.

Conditions:

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

Workaround:

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

CSCdk83719

Symptom:

lineChanXmitSigDBit returned xmitTransparent no matter what had been configured

Conditions:

SNMP GET/walk to get value of lineChanXmitSigDBit

Workaround:

Use CLI command dspsigqual to get the configuration

CSCdk83903

Symptom:

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

Conditions:

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

Workaround:

Increase the values returned from SNMP GET/walk by 1

CSCdk85138

CSCdk87876

Symptom:

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

Condition:

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

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

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

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

Work around:

None.

CSCdk88074

Symptom:

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

Conditions: Same as above

Workaround:

A resetcd F should clear up the failed bit. But the polling has stopped after the card fail and will not start again.

command resetcd H will start polling again, but unfortunately it does not declare that the node is out of failed state, even if in actuality, the card has become healthy and responds to all polls correctly.

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

CSCdk89096

Symptom:

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

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

Condition:

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

Work-around:

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

CSCdk89123

Symptom:

Software error 1M3 is logged when dsplog is invoked.

Conditions:

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

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

Work around:

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

CSCdk91662

Symptom:

The debug command `dspstatsinfo' shows ports as failed that are not failed, shows BNI/BXM trunk ports, without clearly specifying that they are feeder trunk ports and does not count BXM-T3 and E3 trunk ports.

Impact:

Very little. This command is used for debugging statistics related problems and its screen snapshots are requested for all defects related to statistics. This information can be gathered from other screen snapshots such as dsptrks, dsplns, dspports, dpcds, dpsnds, dspnode, dnib, dspstatparms, etc.

Work Around:

None

CSCdk93669

Symptom:

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

Conditions:

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

Workaround:

None

CSCdk93924

Symptom:

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

Conditions:

Add voice/data connection from SNMP

Workaround:

Make sure the channel number is valid before addcon from SNMP

CSCdm00105

CSCdm00440

CSCdm00566

CSCdm00585

CSCdm01239

Symptom:

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

Conditions:

Same as above. Happens intermittently.

Workaround:

None

CSCdm01318

CSCdm02017

CSCdm04420

Symptom:

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

Conditions:

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

Workaround:

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

CSCdm05301

Symptom:

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

Conditions:

This requires specific conditions to occur.

1) A BXM feeder trunk must be added.

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

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

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

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

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

Example:

BXM Feeder trunk at slot 12.1.

A dsplogtrk 12.1 indicates the logical trunk number is 2.

A dln 2 indicates the corresponding logical line number is 3.

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

Work Around:

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

You can also structure your node so that this configuration is not possible. Such as:

1) Do not have any BXM - trunk cards in slots larger than any line cards.

Further Description:

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

CSCdm05373

Symptom:

Mostly no specific symptom shows up. Sometime channel configuration may be corrupted.

Conditions:

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

Workaround:

Reconfigure the channel again.

CSCdm06460

Symptom:

This bug will cause a VC of a non-dax connection to point to 2 LCNs. Also, if the slot number of the connection on the IGX side is < 16, then this bug will cause the VC to point to two logical endpoints. That will cause an extra connection to show up when the dspcons command is issued. The dspcon command, however, will not be able to display the extra connection because it really does not exist.

Conditions:

Refer to the Unit Test Plan. Also refer to the Unit Test Plan in bug CSCdk93870.

Workaround:

If this problem occurs, delete the connection and add it from the node where the conn's VC is messed up.

CSCdm06777

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

The active NPM re-initializes 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.

CSCdj49647

Symptom:

Standby controller card gets reset.

Conditions:

Standby Controller card would not be in a steady standby state which is a result of periodic standby resets. These resets could be confirmed from the log (using dsplog command). This should not effect the functionality of the Active.

Workaround:

None

Further Problem Description:

This problem seems to be the result failed communication between the active and the standby. Active keeps all the messages on the standby queue and frees them only when an acknowledgment is received from the standby. Because of the failed communication, lots of these standby messages are getting collected on the queue, resulting in shortage of memory, memory error and memory abort.

The current fix puts a limit on the amount of memory that can be collected on the standby queue and hence we would not encounter memory shortage on the active card.

CSCdj52771

Symptom:

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

Conditions:

Adding or deleting connections.

Workaround:

None. (see below)

Further Information:

The following events can lead to the above problem.

- delete a connection: Set a standby update bit for this VC. (Note that only update 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 software errors on the standby.

Engineer's workaround proposal: Introduce a new field of size 1 bit in VC database vc_just_alloc, that is used to distinguish between a partially initialized VC and a fully initialized VC. It is SET in a_vc() when VC is allocated and CLRed in Padd_db_ccts() when the VC is fully complete. Standby checks this bit, if it is set it considers this update to be a delete update and clears vc_exists bit in it's VC. I used a spare bit in VC_DB.

During upgrades (graceful/nongraceful) and rebuilds, this field is defaulted to CLR.

CSCdj54506

Symptom:

SAR failures as indicated by software error 742 can be difficult to identify with the limited information currently provided by software error 742.

Conditions:

SAR failures can occur at any time.

Workaround:

N/A

Further Problem Description:

The D-comments enclosure specify the SAR information captured by this enhancement. To decode the SAR command and event mailboxes refer to the BCC SAR Firmware Specification available on EDCS.

CSCdj56581

Symptom:

Cannot configure preferred routes for FPAD mm session connections.

Conditions:

Issuing the cnfpref command on FPAD mm session connections.

Workaround:

None.

Further Information:

The remote endpoint information is not processed correctly by the SWSW. This information is essential in identifying certain connections.

CSCdj68190

Symptom:

SAR Failure

Conditions:

Upgrading with BCC-3-32

Workaround:

None. Occurrence of problem is low frequency.

Further Information:

After upgrading a BCC-3-32 to SW 8.4 software, the BCC can experience "SAR Failures" (swerr 742 - selftest failures).

CSCdj70442

Symptom:

User should not be allowed to enter odd numbered CID's for FTC voice interworking CAS signalling endpoints.

User is allowed to enter FTM connections which use the same CID (Connection ID) since the voice interworking FTM connections also reserve CID+1. If the user at this point tries to use CID+1 for a FTM frame relay connection at this endpoint, then both of these connections conflict. The solution is to prevent the user from entering both these connections on a node with adjacent CID's.

Conditions:

Commands which can affect this are addcon and addfrcon. Bug is in 9.1, 8.5 and 8.2.5.

Workaround:

Work around is currently for the user to be smart enough to not enter conflicting connections. If user has entered conflicting connections, then should delete one of the connections and assign to a different CID.

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 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 discards at the trunk due to the aborted frames. The discards are the only value in this message which is processed by the software. The discards 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

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.

CSCdj87214

Symptom:

It was observed that the Addlnrmtlp command may cause continuous aborts and rebuilds on BPX nodes.

Conditions:

Issuing the Addlnrmtlp command on BXM cards.

Workaround:

Do not issue the command.

CSCdj87908

Symptom:

Software error 532

Conditions:

After Upgrade. IPX node.

Workaround: None

Further Problem Description:

This problem was seen only once and upon inspecting the code, we found a suspect code piece that could have caused the problem.

CSCdj89775

Symptom:

UBUs are not allocated correctly following getubus command.

Conditions:

Only upon issuing the getubus debug command.

Workaround:

None.

Further Information:

The HDM and FRM/UFM background tests would steal UBUs that were allocated by the `getubus' command. Since `getubus' is a debug command, customers won't see this problem.

CSCdj90444

Symptom:

Trunk traffic transmitted a rate greater than configured transmit rate.

Conditions:

BXM trunks.

Workaround:

None.

Further Information:

BXM-T3 which is configured as trunk sends out traffic over Transmit Rate.

CSCdj90545

Symptom:

Negative Loading on a trunk

Conditions:

No special conditions.

Workaround:

None.

Further Information:

Various CM messages contain a rate index. This value is used to index into the Cm_Rates[] array. If the index is out of range bad values are referenced that can result in negative loads on trunks.

CSCdj91072

Symptom:

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

Conditions:

Resetting BXM cards.

Workaround:

None.

CSCdj91753

Symptom:

Node unresponsiveness.

Conditions:

During connection deletion scenarios where numerous connections are being deleted at the same time.

Workaround:

None.

Further Information:

The node removes connections 1 at a time as if entered on the command line. When numerous connections are deleted at the same time, it generates internal messaging at each connection removal, and these can build up, causing unresponsiveness due to increased processing demands on the Switch Software.

This fix addresses some of the internal messaging that is generated.

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.

CSCdj92704

Symptom:

When one of the VIA trunk is AIT/BTM/ALM-B, tstdelay won't work.

Conditions:

This happens only when AIT/BTM/ALM-B card is the trunk card in via node for CGW connections.

Work around:

Disable AIT/BTM/ALM 32h Ext2 by using off3 (3)

CSCdj93499

Symptom:

Watchdog during switchover on BCC-3 with 6000+ connections (32 meg BBC-3 and watchdog = software error 52)

Conditions:

Heavily loaded BPX with BCC-3 (32meg) and 6000+ connections.

Impact:

After switchover to new BCC, node rebuilds.

Workaround: (StrataCom level access)

cnfprf rsrc [e|d] 120, where 120 is the rsrc process watchdog limit in seconds.

Further Information:

The rsrc process is taking an inordinate amount of time after the switchover. Setting the watchdog timeout higher will avoid the watchdog until a solution can be found and distributed to the field.

CSCdj93616

Symptom:

The StrataView Plus might show an inconsistent front card types for BXM E3/T3 cards. A BXM T3 8 port card can be shown as 180, 181, 182 or 183. A BXM T3 12 port card can be shown as 184, 185, 186 or 187. A BXM E3 8 port card can be shown as 188, 189, 190 or 191 and A BXM E3 12 port card can be shown as 192, 193, 194 or 195.

Conditions:

When a StrataView Plus is attached to a node with BXM E3/T3 cards then the StrataView Plus database may show inconsistent values for the card types.

Workaround:

Consider card type

Values 180, 181, 182 1nd 183 to all mean that it is a 8 port BXM T3 card.

Values 184, 185, 186, 187 to all mean that it is a 12 port BXM T3 card.

Values 188, 189,190, 191 to all mean that it is a 8 port BXM E3 card.

Values 192, 193,194,195 to all mean that it is a 12 Port BXM E3 card.

CSCdj93749

Symptom:

Symptom is that the DAX CVM/UVM to FTM connection will be set to `FAILED' after reset of the CVM/UVM card. All other settings of the connection database are correct.

Conditions:

This will happen if the user resets the CVM/UVM card manually or pulls the card out and reseats it. It could also happen if the card resets automatically somehow in the switch.

Workaround:

Resetting the FTM card on the other end will clear the failure problem.

CSCdj94277

Symptom:

Node Rebuild.

Conditions:

Issuing a switchcc command right after a resetcd command. Only on BPX node.

Workaround:

Do not issue switchcc while resetting BXM.

Further Information:

switchcc on BPX node after resetcd 9 causes node rebuild.

First, do resetcd 9 h on BPX. While slot 9 was not ready for standby yet, then do a switchcc. It caused a node rebuild.

CSCdj94317

Symptom:

Software aborts (1000003) or no connection continuity.

Conditions:

A processor card (with active configuration) is moved from one node to another node.

Workaround:

Clrallcnf before moving processor cards.

Further Problem Description:

Aborts occurred when processor card attempted to rebuild it's own card information from stored database. Connectivity problems occurred because card types were being rebuilt based on physical card rather than the logical card (the card that had originally allocated resources).

CSCdj94319

Symptom:

1) For UVM-UVM LDCELP connection l16 or l16v is not controlled by the cnfsysparm parameters.

2) For FTM-CVM connection the cnfsysparm 4 or 6 delay parameters are used. This parameter has a maximum of 32ms rather than 64ms. The default is 27ms. FTM-CVM connections over a few hops may fail to route due to this default value being set too low or the MAX value is not big enough for the maximum 7 hops.

Conditions:

UVM to UVM (LDCELP) and FTM to CVM connections.

Workaround:

For problem 2) and maximum is not exceeded, change cnfsysparm option 4 or 7 depending whether VAD or non-VAD respectively.

CSCdj94398

Symptom:

Card Name shows as EMPTY

Conditions:

After a node rebuild, when issuing the dspcmi command.

Workaround:

None.

Further Problem Description:

dspcmi L <slot> shows card name being empty after a rebuild when there is a card in the logical slot.

CSCdj94471

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 M3 207 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 Node B, 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 con 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 doesn't 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.

8.5.x-9.1 (provided the fix didn't 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 doesn't 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.

CSCdj95039

Symptom:

addjobtrig does not support two-part address <slot>.<line> of a line specification.

Conditions:

If a line specified in addjobtrig is on a UFM or UVM card.

Workaround:

None

CSCdj95152

Symptom:

"Failure resolving local endpoint ambiguity" when adding connections.

Conditions:

Adding connections to CVM/CDP cards through SNMP.

Workaround:

None.

CSCdk00550

Symptom:

When node with FR or voice connection to an unreachable access device is rebuild. The connection changed from failed to OK. Connection status will become inconsistent. Traffic continuity is already down hence will not affected.

Conditions:

This bug affects 8.255 and 8.5

Workaround:

Down the connection and then up it again should show the connect connection status. Also use restartad and resetad on the unreachable node will eventually make the connections consistent again.

CSCdk01446

Symptom:

Software error 707 logged

Conditions:

The software error 707 will be logged only if the background test for SDP, LDP or CDP is enabled.

Workaround:

Disable the background test for SDP, LDP and CDP.

CSCdk01526

Symptom:

Software error 2072 appears in the software error log for PROC SNMP.

Conditions:

This problem will occur when the customer has an ASI line up (any back card configuration) and uses SNMP to get the ds3 statistics for that ASI line (this is for ASI lines only)

The specific SNMP addresses that will cause this error are as follows:

1.3.6.1.4.1.351.100.4.5.5.1.1 ds3StatsOofs

1.3.6.1.4.1.351.100.4.5.5.1.2 ds3StatsLoss

1.3.6.1.4.1.351.100.4.5.5.1.3 ds3StatsLcvs

1.3.6.1.4.1.351.100.4.5.5.1.4 ds3StatsCPcvs

1.3.6.1.4.1.351.100.4.5.5.1.5 ds3StatsPPcvs

1.3.6.1.4.1.351.100.4.5.5.1.6 ds3StatsPlcpBcvs

1.3.6.1.4.1.351.100.4.5.5.1.7 ds3StatsAtmCrcs

1.3.6.1.4.1.351.100.4.5.5.1.8 ds3StatsPktCrcs

1.3.6.1.4.1.351.100.4.5.5.1.9 ds3StatsPlcpOofs

Impact:

Statistical alarming has the potential to be cleared more quickly and interval statistics (including StrataView Plus' TFTP interval stats) will be skewed (see example below).

Work Around:

Do not use this SNMP get functionality for these ds3 line statistics.

Further Informations:

As an example, if the user has ASI circuit lines 12.1 and 12.2 as well as other lines on the node.

If the user does a SNMP get for one of the above mentioned snmp stat objects on 12.1 or 12.2, they will receive a 2072 for every stat requested.

Moreover, all interval statistics (including StrataView Plus' TFTP interval statistics) for 12.1 AND 12.2 (both lines, even though only one line was request for the snmp get) will be skewed forward in time by 10 seconds. So all line interval stats on 12.1 AND 12.2 will roll 10 seconds early than the rest of the line interval stats.

This skewing is cumulative for every SNMP get. So if they do another SNMP get for any of these statistics, the skew will now be 20 seconds--the line interval stats rolling 20 seconds earlier than any of the other line interval stats.

The third SNMP get is 30 seconds, the fourth 40 seconds, etc.

CSCdk01714

Symptom:

In the function nw_hp_ptl_bmap where we integrate the high priority CC traffic bit from the other nodes the code doesn't really do any integration... In fact, this may cause potential aborts in the system - the way we are checking the topo_ptr.

Conditions:

Under all conditions

Workaround:

No workaround.

CSCdk01830

Symptom:

Software error 75 logged. No other symptom.

Conditions:

Trying to download standby processor with latest revision. Standby processor failing for some reason. This causes database queues to be flushed out from under the DB_SEND state machine. Need to handle this condition.

Workaround:

No workaround but problem is intermittent and harmless.

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.

CSCdk01970

Symptom:

The commands: cnflnstats, dsplnstathist, cnftrkstats, dsptrkstathist, cnfportstats, dspportstathist do not work correctly with regards to the sample interval. They prompt for a given interval range, but when entering an interval within that range, they indicate it is incorrect, that it has to be at least (5, 10 or 15 minutes) and must be a multiple of (5, 10 or 15 minutes).

Conditions:

The incorrect minimum interval is being used for these commands. They are using the minim interval for connection (cnfchstats and dspchstathist).

The minimum sampling interval for connections depends upon what the user has configured the connection polling rate to be (cnfsysparm option 24).

When the user has configured the connection polling rate to 5 minutes the other stat commands will be limited by "be at least 5 minutes or a multiple of 5 minutes".

When the user has configured the connection polling rate to 10 minutes, the other stat commands will be limited by "be at least 10 minutes or a multiple of 10 minutes".

Likewise for 15 minute connection polling.

Finally, this is only prevalent when they have connections up that are frame relay connections.

This defect may be sporadic, only plaguing some lines, trunk or ports. Based on the corresponding connection our code maps it to, the minimum polling interval may be the frame relay polling rate, or 1 minute.

Impact:

The user will not be able to use the cnfXXXstats or dspXXXstathist commands for the smaller intervals.

Work Around:

None

Relate affect:

This problem is related to CSCdj80395

CSCdk02126

Symptom:

The Front Card type for the Standby card is 0 in the StrataView Plus database when the card actually does not exist.

Condition:

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

Impact:

No, this message is sent specifically for StrataView Plus 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 StrataView Plus database.

Workaround:

None.

CSCdk02410

Symptom:

Very bad symptoms. A CBUS message gets lost. This means that a connection may be active or inactive on the FTM card, where the Switch Software thinks that the connection is in a different state. Also count get port states incorrect, etc....

Conditions:

Happens after deleting either an FTM to FTM CAS Voice connection or a FTM to CVM/CDP/UVM CAS Voice Interworking connection. When deleting this type of connection a 0xF8 (ACM_CMD_FCODE) message is sent and causes a problem where the next CBUS message on that slot is not seen by the FTM card.

Workaround:

No perfect workaround. But for now after deleting an FTM to FTM CAS voice connection or FTM to CVM/CDP/UVM CAS voice interworking connection, don't immediately enter any more commands (especially addcon or port configuration commands). Of course some automatic/sporadic unsolicited events may occur sending a CBUS message to the FTM card which will be ignored (this is still a big problem but a lot more rare than the user says deleting and re-adding connections).

CSCdk03369

Symptom:

Sib (statistics) information block is not initialized on standby processor when connections are added

Conditions:

Since an uninitialized pointer is used in a conditional statement to determine if a sib should be allocated the results are unpredictable

Work Around:

There is no workaround

CSCdk03517

Symptom:

The FTM port will show OK on one end, and the other end (in case of Non-DAX) connection will show a Port Comm fail on the output of the dspcon command.

Conditions:

This condition is only brought about by the user deleting the access device (using the `delad' command) when the FTM port is FAILED.

Workaround:

Once in this condition must set LMI back to none to clear then back to fail to set again. Also can clear by setting LMI to none first, then entering `delad' to delete the access device.

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.

CSCdk04131

Symptom:

Dax connections with VAD on (c32, c24, l16v...) after rebuild lose VAD. Display will not show VAD and connection will not be programmed with VAD.

Continuity will not be affected.

Workaround:

No known workaround.

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 Problem Description:

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.

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, this will not work while the secondary card is active.

CSCdk04940

Symptom:

When the sequence of commands as presented below is executed node aborts. while running software 8.4.18

Next Command: dspprfhist s

Command - f, b, l, r, a, i, q: (option a)

Enter first sample: any number (0-11)

Enter last sample: any number greater then range allows (>= 12)

Conditions:

If a dspprfhist s is issued before a dspprfhist then the system reload.

Workaround:

A dspprfhist needs to be issued before the dspprfhist s and that will avoid the problem

CSCdk05440

Symptom:

Software error 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.

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 (software error, 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 dspcon or dsprts, software error 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 software error, the display will show that the route is pending.

CSCdk06091

Symptom:

Software error 925 (Invalid line 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 software error 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 software log 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 software error 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.

CSCdk06365

Symptom:

Can not transfer data on newly created PVC after rebuild of BPX node. The error message "ASI card shift mode mismatch" is likely to be displayed. (Rebuild is not required for this problem manifestation)

Conditions:

Data transfer was initiated from an ATM broadband test set to the axis port. We see data xfer 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).

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 software error 123 becomes more likely especially for 8.4 and 8.5.

Workaround:

None.

CSCdk07991

Symptom:

Dspcons screen hangs.

Conditions:

When displaying ALM-A/UAM0 connections.

Workaround:

None.

Further Information:

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 occurred (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.

CSCdk08077

Symptom:

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

Conditions:

When DSP_F shown in an UVM connection in both ends. If the master node reset then connection state in master side is in OK bit the other side is DSP_F.

Workaround:

Reset the UVM in master side.

CSCdk08937

Symptom:

Loss of continuity on VPC conns

Conditions:

Occurs sporadically after re-routes

Workaround:

Re-route the connection one or more times until connection passes tstdelay

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 occurred.

Workaround:

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

CSCdk11702

Symptom:

Under specific topology and status conditions, (FRP in slots 2,3,4, and ports in comm fail), a 1M3 abort occurred when upgrading switch software 8.1.19 to 8.4.14.

This does not apply to 8.1.20-8.1.74 revisions upgrading to 8.4.

Workaround:

Do not have FRPs in slots 2, 3, 4,. OR set the LMI such that they do not go into port comm failure.

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.

CSCdk12249

Symptom:

Testcon fails.

Conditions:

When running tstcon from multiple nodes simultaneously.

Workaround:

Do not run multiple tstcon commands concurrently.

Further Information:

This DDTS is to track a system improvement only.

The tstcon * command is modified to specify only connections which are mastered/not mastered at the node where the command is run.

This was an internally motivated enhancement to the system to speed up the testing on continuity in the network.

CSCdk13558

The output of the CLI command "dspcd <slot>" 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.

The indication is changed if the card channel programming activity changes, i.e. channel programming starts or stops.

CSCdk14898

Symptom:

Y-redundant backup UVM/CVM/CDP cards with secondary card active may experience problem with modem downgrade. This potentially is service affecting.

Conditions:

When y-redundant UVM/CVM/CDP card with secondary card active due to a switchover, received fax/modem call. The connection is either upgraded (8.2/8.5/9.1 releases) or fax-relay (for 9.1) becomes active.

Fax/Modem call will go through. However, when call is terminated, the connection should be downgraded to the normal compression type. This bug prevents downgrade for modem which can affect voice continuity. For fax relay, the display will say Fax on one end and normal compression on the other; this does not affect continuity.

Workaround: 1) Switch back so that the primary card is active.

2) Disable modem upgrade for y-redundancy configuration.

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.

CSCdk16126

Symptom:

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

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

Work Around:

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

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:

BPX, software 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.

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 programmed.

Work Around:

Reset BNI card after mismatch state is cleared.

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 user'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.

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

CSCdk20470

Symptom:

After upgrade to 8.4.21, all connections on feeder trunks on port 2 and port 3 will not be visible via dspcon OR dcct command. They will however appear on dspcons. This is on BPX only and only for BNI feeder trunks.

Conditions:

Upgrade to 8.4.21 and if having feeder trunks on port 2 or port 3, and have cons on it. They will not be visible using dspcon OR dcct command.

Workaround:

No easy workaround except to patch memory which is done following steps below:

* dsplogcd 112 slot_number

For example:

Logical Data Base for BNI-T3 card 1 at address 313B45D6

Service 1 Port 2 Typ: PHYSICAL Trk 1 Ylw 0

Slot Number 1 ClkSrc: 2

Need Card Flag 0 Port 3 Typ: PHYSICAL Trk 2 Ylw 0

Need bkcd Flag 0 ClkSrc: 3

Cd LCCB Ptr 30ED3BEC

Ch Cnfg Ptr 30F96C6C

Logep Tree Ptr 00000000

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

Port[1]: 30F9CE6A 30F96C6C 30F97C42 30F98C18 30ED3BF0 00000000

Port[2]: 30F9CF30 30F98D16 30F99CEC 30F9ACC2 30ED3C18 30ED2D6C

Port[3]: 30F9CFF6 30F9ADC0 30F9BD96 30F9CD6C 30ED3C40 30ED2C6C

The memory locations on the following rows are important.

* Port[2] 30F9CF30

* Port[3] 30F9CFF6

Execute dm on Port[2] and Port[3] memory locations. for e.g

dm 30F9CF30

The first row is | |

V V

Counting 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

30F9CF30 00 01 77 00 00 00 00 00 00 00 00 00 00 00 00 03

Check out the 11, 12 byte (Counting from 1). They SHOULD BE ZERO. Patch those locations (11 and 12) to be zero. Patching those locations to 0 should work. But this DOESNOT write it to BRAM. So a rebuild will bring the problem back again.

CSCdk20470

(continued)

IMPORTANT

There is no work around for that! Switchcc will bring the problem back!

* The Patch Memory Command itself

This Command: pm 316deB27

316DEB27 00000060 = 00 <CR>

316DEB28 00000000 = 00 (CR)

316DEB28 00000000 = . (dot)

DO A "dm 316DEB27" to verify that pm was successful.

The. (dot) terminates the patch memory procedure.

CSCdk20874

Symptom:

This CR is the same as CSCdk17822. That CR made 2 requests:

1) There were a couple of commands listed in the spec for the high priority login feature, that were not actually available under high priority login. These are: "dspnode" and "cnfnhparm". These should be added.

2) There was an additional list of commands being requested for availability under high priority login.

The first request is being implemented with this CR. The second is not currently planned for 8.4.

Workaround:

Login at regular priority to run commands that are not available under high priority login.

CSCdk20989

Symptom:

Card information incorrect in dsplogcd command.

Conditions:

Card configured in yred pair.

Workaround:

None.

Further Information:

The dsplogcd for BPX shows the DB pointer based on physical slot. So, if you have a Y-red and the sec. is active, the information related to DB pointers is incorrect.

This is a debug command ONLY. It is a note to the DE who will use this command.

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.

CSCdk21381

Symptom:

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 anyways.

Conditions: Same as above

Work around: None

CSCdk21404

Symptom:

1M3 aborts on the standby processor card during loadrev.

Condition:

Upgrading from Rel841 to Rel85.

Workaround:

None.

CSCdk22783

Symptom:

A BPX node running 8.4.20 may log software abort 1M3 after an axis shelf feeder is deleted or added.

Conditions:

1. Removing an LMI (or ILMI) feeder from a node which has expanded BCCs (64M RAM AND 4M BRAM). An LMI feeder is an axis shelf or an APS (Adjunct Processor Shelf). A stand alone IPX node is not an LMI feeder.

2. The first port (first LMI port added, or the lowest numbered slot/port after a switchcc has:

a. 512 connections if there are 1 to 3 LMI feeder trunks

b. 256 connections if there are 4 to 11 LMI feeder trunks

c. 0 connections if there are 12 or more LMI feeder trunks

Workaround:

Keep the number of LMI feeder trunks less than 12, and the number of connections on the lowest numbered slot/port less than 256.

Further Problem Description:

The abort was due to an invalid address in an array of pointers used for ILMI/LMI status updates. Each pointer is used for a block of 256 channels. The invalid address was the second pointer for logical port 0. Thus this port had more than 256 channels.

The first three pointers for the first LMI port are at risk of corruption due to memory overwrite from the previous data structure. Due to the way the previous structure is indexed for the overwrite, the first pointer will only be corrupted if there are more than 11 LMI feeder trunks. The second pointer may be corrupted if there are more than 4 LMI feeder trunks, and the third pointer may be corrupted if there are any LMI feeder trunks. Thus by keeping the number of feeder trunks less than 12, and the number of connections on the lowest numbered slot/port less than 256, the risk of this overwrite triggering an abort can be minimized. Note that a switchcc should be performed to insure that the "first port" is the lowest numbered slot/port rather than the first port added. Also note that the number of connections may vary based on the provisioning pattern (if 256 connections are added, then another 200 connections are added, then the first 256 connections are deleted, the second index will be used even though there are only 200 connections.

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.

CSCdk23431

Symptom:

The StrataView Plus database does not include inactive ports on UFM/FRM/FTM T1/E1 line cards.

Conditions:

The `dspports' command on the IGX switch shows inactive ports of FRM/FTM/FTC T1/E1 card 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 match on the switch and the StrataView Plus.

Work Around:

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

CSCdk25153

Symptom:

User cannot use cnfcon in a job.

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

Conditions:

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

Workaround:

None.

CSCdk26240

Symptom:

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

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.

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.

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

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.

CSCdk28154

Symptom:

When doing "dspcon xxxx", the "New Conn" will be shown on the screen instead of "OK"

Condition:

When adding the new conn, the problem will be seen right away.

Workaround:

None

CSCdk28204

Symptom:

A software error 526 appears if a card failure event log string is longer than 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.

Further Problem Description:

None.

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.

Work Around:

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.

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.

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

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)

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.

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.

CSCdk32500

Symptom:

Node aborts with 1000003 error in the NETW process.

Conditions:

Some trunks have or had high priority traffic restriction enabled. Following a switchcc, upgrade, clearing of unreachability, database updates are shared between nodes. If a difference in the HP restriction status is detected, the integration of the information can result in this situation.

Work Around:

1. When the node is aborting AND the dspswlog shows that it is the netw AND the program counter is 300161DA - down the trunk cards to that node. The abort should stop.

2. loadrev the standby with 8.4.21 which would be in locked state.

3. switchcc to go to standby.

CSCdk32790

Symptom:

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

Conditions:

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

Workaround:

No workaround.

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.

CSCdk33290

Symptom:

For BXM trunk, if the total number of connections are more than 12000 while trying to add the feeder trunk on the same BXM card. Bad VC_NUM 372 will be seen.

Condition:

Software error 372 was produced.

Workaround:

None.

CSCdk34002

Symptom:

Job Trigger can cause a node abort (1000003)

Conditions:

When setting up a job trigger to re-establish 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.

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.

CSCdk41025

Symptom:

Trunks not correctly cleaned up in NIB.

Conditions:

If muxbus bandwidth is used up and uptrk fails.

Workaround:

None. Node must be clrcnf'd and its configuration restored.

CSCdk41084

Symptom:

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

Condition:

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

Work Around:

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

CSCdk43180

Symptom:

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

Conditions:

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

Workaround:

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

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.

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

CSCdk45918

Symptom:

The customer has a minor alarm remains on the UI screen even though there is no other alarms (dspalms, dspclksrc, dsppwr, dspcds, dsptrk, and so on)

Conditions:

It looks like this is an old bug. It occurs after the network has some trunk problems.

Workaround:

Currently, there is no workaround, but this bug supposed to be fixed on 8.2. You can read it from the release notes.

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.

CSCdk48307

Symptom:

Cannot add trunk due to transmit rate incompatibility.

Conditions:

Fractional T1/E1 trunks using the ds0 map to create fractional speed.

Workaround:

None.

Further Information:

The transmit rate field is not set on cnftrk for E1/T1 trunks. When the DS0 map is changed for a trunk, the transmit rate is not calculated, thus E1 vs. T1 addtrks can have different transmit speeds.

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.

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.

CSCdk50880

Symptom:

Network flooding causes node outages in 8.5.

Conditions:

pre-8.5.09 software

Workaround:

None.

Further Information:

The changes involved in this bug address the network flooding issues found in the 8.4 software and incorporated into the 8.4.21 series of software.

This is a placeholder DDTS for rolling the 8.4.21 changes to release 8.5.

CSCdk53126

Symptom: 1M3 abort.

Conditions: 1) after moving cards around in the cage.

2) after clrallcnf and load new revision.

Work around:

None.

Further Problem Description:

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

CSCdk55887

Symptom:

dspport command not available to level 6 user ids.

Conditions:

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

Work around:

Increase user privilege.

Further Problem Description:

The privileged level of the dspport command was changed in release 8.1 to level 2 from level 6. This difference was first noticed by offsite user after upgrade from 7.4 to 8.5.05. User who running 8.x.x software hasn't noticed this difference until opening of this problem. DE is reported to have promised this to be fixed in 8.5.09

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

CSCdk60350

Symptom:

For Data connections, if the EIA rate at the master node is different that at the slave node, the connection may not reroute.

Conditions:

Same as above

Workaround:

The EIA rate of the connection can be seen using dspchcnf. If they are different, make them the same using cnfcheia command.

CSCdk63497

Symptom:

1. Corruption of VC database, VC parms database, DOWNLOAD space (save/restore/fw)

2. Node Abort (watchdog)

Conditions:

After a cnfdmn command is issued.

Workaround:

None. Databases must be reentered.

Further Problem Description:

The cnfdmn command writes randomly off the edge of the LCON database, which affects the VC, and VCparms databases, and the download area.

CSCdk63502

Symptom:

Software error 1006

Conditions:

Burning Firmware into BXM cards.

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.

CSCdk65207

Symptom:

There are two problems related to this defect in `cnfport' on BPX:

Incorrect error message is given when user changes NNI/UNI port type on a BXM port.

When changing NNI/UNI port type on a BXM port, the changes is applied to all ports on the same card.

Conditions:

The system gives incorrect error message to user when cnfport is used to change the port type of a BXM between NNI/UNI type.

The system does not allow user to change port type if there is at least one connections defined on that port. The message is misleading indicating that all connections must be deleted from the card.

When user change port type from UNI to NNI or vice versa on a BXM card, the changes will be applied to all ports on the same card. For example, if user changes port type from UNI to NNI on port 1, the system will automatically changes the port type from UNI to NNI on all ports on the same card.

This problem is now fixed such that user can change the UNI/NNI on a BXM port independently. The error message is also changed to inform user that the port type cannot be changed if there is at least one connection defined on that port.

Workaround:

None.

CSCdk69912

Symptom:

VCQdepth does not conform to configured values.

Conditions:

Frame Relay connections on UFM cards when non-standard Frame Relay parameters are in use on the switch. (via cnfsysparm)

Workaround:

None.

Further Description: Regardless of the system setting for the use of standard/non-standard FR parameters (via cnfsysparm), the UFM configures the VCQ to 2(be+bc). The SWSW computes the be/bc values internally when the non-standard parameter set is in use.

UFM FW version Y.A.F is also required to fix this issue.

CSCdk71360

Symptom:

Fatal SAR errors. BCC reset.

Conditions:

As a result of Tx-BIP-16 errors

Workaround:

None.

Further Information:

November 20, 1998 Release CT

The SAR detects one Tx BIP-16 errors which it logs as fatal. This causes the BCC to reset. The change was to integrate this Tx BIP-16 errors over a 10 second period. If 4 or more errors are detected then a fatal error is reported.

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 is 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.

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 do not 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.

Workaround: 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).

CSCdk02352

Symptom:

If a BXM Port goes into a Fail State; then the Node is not declared in Minor Alarm Condition. The port itself is in alarm but the Node is not. (The lower right bottom of the console screen does not show "Minor Alarm" in reverse video).

Condition:

Whenever a BXM port is in Fail State (and there are no other Node Alarms) the node will not be declared in Minor Alarm.

Work Around:

None.

CSCdk21404

Abort 1M3 when upgrading FastPAD databases to release 8.5.

Workaround: delete the FastPADs from the network before upgrading.

CSCdk30927

FastPADs are lost when upgrading to release 8.5.

Workaround: none.

CSCdj25584

Memory accumulation observed via the dspprf screens. Possibly software error 3000000 or 501, or software abort 3000000. The problem occurs when a UNIX command <CTRL>-] is issued followed by a <CTRL>-z command. This causes the user side of the telnet session to remain active but don't processes any incoming information.

Workaround: Never put a telnet session to sleep. If you need to use the window for something else, terminate the telnet session first. If memory accumulation has been observed but the node has not aborted, perform a switchcc to free up the memory and terminate the sleeping telnet session.

CSCdj58620

The bus signal count (BusSigCng) accumulates and may cause false bus failures. No workaround available.

CSCdj42353

The command dspprfhist on a BPX node shows incorrect values for SUMM and tick interval. No workaround available.

CSCdj54598

The dspnds command displays wrong data. This problem occurs intermittently. No workaround available.

CSCdj65003

The ESP status displayed on the BPX CLI does not match what's observed on StrataView Plus station.

Workaround: Use the BPX CLI to obtain the correct ESP status.

CSCdj65060

On IPX8/IGX8 nodes, the prtcderrs command prints erroneous information for non-existent slots. Problem occurs whenever prtcderrs is used on an 8-slot chassis. There is no impact to network operations.

CSCdj64536

It was observed that erroneous or inconsistent connection information may be displayed between the following commands: dspcons, dspcon, and dsprts. This problem will occur only if a connection is added to the second port of an ASI card immediately after that port is activated using upln and upport commands.

Workaround: After doing upln on the 2nd line of the ASI, have the user add or delete connections to the first port, before adding connections to the 2nd port. The can be accomplished by performing upln on all the ASI lines before adding any connections. This is also not a problem if connections do not exist on port 1 when port 2 is activated using upln.

Recovery: If the connections become associated with the wrong port, there are steps that can be taken to clean-up the database. Since the connection is being associated with port 1 instead of port 2, the connection can be viewed using the command dspcon slot.1.vpi.vci instead of dspcon slot.2.vpi.vci. In addition, the connection can be deleted using delcon slot.1.vpi.vci instead of delcon slot.2.vpi.vci. At this point, the connection can be re-added and will be displayed correctly. Another option is to do a switchcc or rebuild on that node that has the problem.

CSCdj60364

It was observed that nodes' information were erased from its database. The problem would occur when multiple StrataView Plus workstations subscribed Link0 to the same node, and the multiple SV+ workstations requested the topology at the same time. The gateway node would send partial network information to one StrataView Plus and partial to the other.

Workaround: Restart the StrataView Plus Stations.

CSCdj61458

Software error 513 logged when more than one user simultaneously executes the command dspswlog with any combination of it's options.

Workaround: Avoiding execution of dspswlog from two different screens (user sessions) one with 's' option and one without 's' option will help avoiding occurrence of this problem. For example, if two PCs are being used to run scripts to collect dspswlog information from different nodes, making sure that both the PCs do not share any common nodes that they check is one way to avoid the occurrence of this problem. The other way would be not to run the scripts from both the PCs simultaneously.

CSCdj67294

On a BPX, the display of an atfr connection that has its remote end on an IGX multi-line card (UFM, UXM) may have the incorrect line number. The line number that is displayed is off by one. This bug affects software releases that support the UFM card.

Workaround: There are two work arounds available:

1. vt to the IGX and do the dspcon on the other end of the connection.

2. Since the connection number is displayed correctly, interpret the line number from the connection number. That is, the line number for connection slot.line.dlci is slot.line.

CSCdj68305

The dspcon command for a BPX interworking connection where the other end is a frame relay card with non-circuit line interface displays the port with misleading status like OK even if the card is missing.

Workaround: Do the dspcon on the other end of the connection.

CSCdj66322

Watch Dog Timeout abort occurred after a switchcc or an upgrade. This only happens on a node that has the endpoints (a dax con has 2 end points and other conns have 1) of the order of 20K. But if the connections are in a FAILED state the problem can happen with lesser number of endpoints.

CSCdj67682

Consecutive CVM or UVM to Access Device Voice interworking connections are displayed as a range of connections instead of separate connections. This occurs only seen on CVM or UVM to Access Device Voice Interworking connections with consecutive channels on the Voice Card and the Access Device endpoints being on the same FTM card.

CSCdj67829

After Y-redundancy card switch of two FTM/FTC cards, Access Devices become and stay "UNREACHABLE" as shown by the dspads command. All connections to these Access Devices fails and data continuity is lost. This happens with Access Devices only, FastPADs are unaffected. Workaround: If Access Devices are to be added to the IGX/IPX switch, all FTM/FTC cards should be updated to J.C.A or newer firmware. Definitely do not put into Y-red, old and new firmware versions of FTM/FTC cards.

CSCdj68588

User receives a misleading error message when issuing the cnfpref command on a non-existing ALM-A connection.

CSCdj69799

It was observed that when the delyred command was issued to delete a y-red pair of cards in service, it may cause the primary cards in mismatch state to clear the mismatch.

CSCdj71056

Adding a voice connection between an CDP/CVM/UVM and FTM/FTC could cause an unexpected system reload. This only occurs for a non-dax voice connection in which the card type in the slot number of the remote endpoint(FTM/FTC) is not an FTM/FTC and is active.

CSCdj73620

It was observed that issuing the cnfcon command after a trunk on the connections's path is deleted and downed, software errors 1417 may be logged. Workaround: delete the connection and re-add it.

CSCdj76769

dchst command did not work for UVM card and software error 921 is sometimes logged.

CSCdj79586

Software error 107 occurred when a trunk card was removed while connections were being deleted. In order for the error to occur, at least one of the connections must be routed over the removed trunk.

CSCdj74644

A downed connection (or one in progress of being downed) that is in failed A-bit state can not be displayed via command dspcons -f abit, dspalms, or generate minor alarms for A-bit status changes.

CSCdj75902

The copycon command changes the ATM connection type to atfr when the connections are copied from a BPX to an IGX.

CSCdj67668

When adding CVM-FTM a32, a24 connections or FTM-FTM voice connection, the system does not automatically insert the restrict ZCS flag. This is needed to avoid problem with voice connection quality if connection is routed over trunk using ZCS encoding.

Workaround: When adding connection use the *z option. for example, addcon 8.1 <node name> 3.1.40 *z

CSCdj74092

The cnfuvmchparm screen displays conflicting values when the values are compared to the results shown on the command line prompts. This is a display problem only. There is no impact on network operation. It was also observed that cnfuvmchparm display may be inconsistent with parameter values actually sent to the UVM card. This problem occurs whenever cnfuvmchparm command is issued and one or more of the specified channels are active. The user is misled into thinking that an active channel (i.e., a channel with an associated voice or data connection) has been configured with the values shown in the display, when in fact the channel retains its previous configuration.

Workaround: The user should always specify 'y' in response to the "Reconfigure active channels? (y/n)" prompt. This will ensure that any active channels will receive the specified parameter values.

CSCdj77627

The trunk portion of the dspstatsinfo command is being overwritten by subsequent lines. This then leads to loss of information for this screen.

CSCdj70201

After the primary card being removed from a y-red, uptrk and upln commands both give an error "Missing Front Card" though the secondary card exists and has become active.

CSCdj70553

It was observed that excessive cell drops (approximately 80%) in ATM PVCs, in a BPX ASI--ASI for path connections.

Workaround: This requires the assistance of Cisco staff to identify whether there are channel programming defects at the master and/or slave node for that connections. If there is a defect at the master node, then switchcc at that node. If there is a defect at the slave node, then switchcc at the node on the path just before the slave node. Force reroute the connection afterwards. Run tstdelay at both ends to confirm data continuity.

CSCdj71557

When specifying a connection endpoint on an ALM-A card which already exists in the copycons command, the error message displays the channel address incorrectly. For example, 7.6.7 is displayed as 7.256.6.7.

CSCdj75315

when issuing copycons command with a connection endpoint to an FRP/FRM, an erroneous error message "Invalid port cnfg ptr" is received. No workaround available.

CSCdj72508

When a modem call goes over a voice channel configured for ldcelp, the dsptrkutl screen does not show voice off hook status for ldcelp connections although it does for 32k adpcm connections. This problem is likely to occur in a large network, especially when rerouting occurs during switchcc (or when the deroute/reroute restores the original loading information on the trunk). Workaround: Force update through the updates 2 command.

CSCdj74194

When issuing chklm or dsplm commands, the display screen shows failures on loading and Conid Usage. The failure state remains unchanged until the load changes again or a forced update is issued.

CSCdj75540

Software error 137 (BAD_SDIR)is logged on the standby CC of a BPX node. The BPX is the 2nd segment of a 2 segment connection. This defect can occur for a feeder inter-connection (DAX connection) where one endpoint terminates on a trunk card and the other endpoint terminates on a line card.

Workaround: Always ensure that the connections are added such that the line-endpoint is specified first.

CSCdj75662

Random change in line status during switchover (CC) on logical lines greater than 64.

CSCdj76186

Software error 2060 occurred indicating that there was not enough memory to create a TFTP interval statistics file.

Workaround: Use the command cnfnodeparm to set the parameter to its maximum value. This will fix the problem on the active and the standby CC's. Until this defect is fixed, the maximum value will have to be used, it cannot be modified. Or, if the smaller TFTP partition size is required, then stats must be disabled, and then re-enabled after the secondary CC has reached the Standby state after a switch-over.

CSCdj76228

When trying to execute the addtrk command, The error message "De-activated" is displayed. This problem can be encountered on IPX and IGX nodes running Release 8.2.xx or 8.5.xx.

Workaround:

1. Deactivate the card by deleting the lines and downing the lines via dnln and dntrk commands.

2. Physically remove the effected card from the slot and reinsert it.

3. Re-activate the lines via upln and uptrk commands.

CSCdj76230

VC bandwidth parameter may not go up over 255 VC parameters. Software error 313 may be logged on VC BW parameter removal.

Workaround: For releases 8.5.04 and below, there is none. With the release that has this fix:

1. If the customer has not upgraded to release 8.5 yet, there is no problem.

2. If the customer thinks the node is supposed to have over 255 entries, examine the potential connection that has the incorrect VC DB VC parameter index (dcct, or dvc). If the bandwidth index or parameters are not correct, cnfcon the connection to change the bandwidth to the desired BW parameters.

Impact:

1. A node with 4 Meg BRAM processor cannot handle over 255 VC BW parameter entry correctly unless this is fixed. The VC DB will have invalid VC parameter indices because the supporting routines to allocate the VC BW parameter is returning a ubyte size instead of a word. Hence, the upper byte is discarded. The connection will end up possibly having the wrong bandwidth configuration.

2. Upgrades:

If the VC parameter index is NO_INDEX on the previous release, e.g., 841 or 8255, the field will be upgraded with NO_INDEX as well. Since NO_INDEX is -1 which is the maximum that a ubyte can handle, this was OK. Now, the VC parameter index is 12 bits which a word can handle. The BPX 841 handled this with introducing a new value NO_BW_PARMS (0x1FFF for 13 bits storage) to replace NO_INDEX. In 85 IGX, upgrade code should change the value to NO_BW_PARMS (0x0FFF for 12 bits storage in IGX) if its old value was NO_INDEX.

Since there is no upgrade between Release 85 to Release 85, the vc_parms_indices in the VC database will be initialized to NO_INDEX if it is not in use. It will be later changed to a valid VC Bandwidth parameter index if the allocation is successful. For 1 Meg BRAM processor 255 entries is the maximum. This is not going to be an issue. But for 4 Meg BRAM processor 255 is a valid VC Bandwidth parameter entry and the logic will cause potential problems. For example, when removing a VC Database entry, the VC BW parameter index is checked against an invalid index, which is NO_INDEX which means an invalid BW entry. If it is an invalid entry, the associated VC BW parameter is also removed. In the case of 4 Meg BRAM processor, the BW entry will not be removed if the VC BW parameter index went to as high as 255 or over.

CSCdj78120

A swerr 32 is logged when issuing dsptrkerrs command with <slot>.<line> on a trunk card which belongs to the IMA line group (e.g. UXM/T1 or UXM/E1).

CSCdj76481

Software error 823 occurred when a trunk with de-route delay configured failed.

CSCdj76844

Software errors 1427 and 254 occurred and the command dspnw shows unreachability. This problem only happens in a network with node numbers larger than 63 with a IPX/IGX

Workaround: Delete the trunk that has the IPX/IGX and rnmnd all nodes that have node number larger than 63 to numbers less or equal to 63, and re-add the trunk.

CSCdj77081

Software error 921 and 531 logged due to bad port configuration.

Impact: This will result in port configuration database corruption. Clear the card/port configuration for the UFM card as specified below if possible.

Workaround:

If the node is the state where the card/port configuration DB is corrupted for that UFM, then insert another card type, other than UFM type, like ALM-B. This will clear the card/port configuration "remembered" by the node and it will clear the corrupted UFM database.

How to avoid this:

1. When a UFM-C is active, and you wish to deactivate the card, i.e., down the lines, make sure the card is inserted and not in the failed state.

2. Do not insert a UFM-U with an E1D backcard.

CSCdj77218

Specific reason for tstdelay failure is overwritten with the message "Final parameter validation test failed". This problem will occur when using SNMP to invoke tstdelay, and the connection is not a frame relay/ATM type but a DAX connection, and a feeder and not looped.

CSCdj77258

The tstconseg command fails when executed between an ASI or BXM and a UXM card.

Workaround: Make sure the Loopback Location ID and the Source ID are increased to 16 bytes.

CSCdj77483

Excessive amount of real time taken by Fail Handler process during large amounts of connection additions OR during card events such as line/port failures and rebuilds. No workaround available.

CSCdj77734

The command cnfuvmchparm does not display the 24th/32nd channel on T1 interface.

CSCdj77908

Inserting or resetting a CVM/CDP model C card re-initializes the channel configuration if the logical slot is any model of CVM/CDP. Channel configuration will be lost and the mapping from the channel to the connection will be broken rendering the connection out of service and inaccessible to the user for connection commands such as delcon, dncon, dspcon, etc.

CSCdj77966

After adding a new node to a network, the following system-wide parameters (found in Sys_Parms) may not resolve consistently: fpd_jitter, combining timeouts and VC and port poll rates.

Workaround: Issue the cnfsysparm to propagated new values to rest of the network.

CSCdj78211

Pass Sync parameter is not updated to the standby. If the processor card switches, then the value is still default.
Workaround: re-configure trunk using cnftrk on a switchover.

CSCdj78260

Card alarms for a HDM card in Standby mode on an IPX node are being received every 10 seconds.

CSCdj78679

software error 4230 occurred when adding atfr connections on IGX node and deleting atfr connections on a BPX node. This problem is caused by the use of a incorrect memory address. The incorrect address is actually location 0xC, which is still an address we can read a value from. The logic looks at the value but does not branch incorrectly based on the value read. There is no impact to the network operations.

CSCdj78765

User cannot add a second FastPAD Session connection from the same FTM slot.port. If it is the second from the local end, the user receives the following error message: "Local resources unavailable or Network Expansion not allowed". If it is the second Session connection on the remote end, the user receives this error message: "Unknown response at remote end: 0".

CSCdj79398

After a rebuild or when a line/trunk is first upped, the line/trunk goes into statistical alarm. This is cleared within 30-40 seconds.

CSCdj79727

Software error 50 occurred after a switchcc or node rebuild. This problem would occur if the queue depth values and the corresponding delay values go out of sync. In most of the cases, this would happen only if the maximum available load on the trunk is very small (for example, if on BTM the receive rate is kept to a default of 1000 pps). Even if the values go a little bit out of sync, the difference is very minimal and the difference between the correct queue depth and the incorrect one (caused by this bug) can be at most 1.

CSCdj80139

UVM card l16 or l16v connections with modem upgrade may cause data corruption. When it happens, the corruption can happen to any/all channels on the UVM card.

CSCdj80503

A single connection through the ports of a UFM is looped back at the last port. It was observed that data discards can occur if the following conditions are met:

1) A local connection on a UFM is added from a StrataView Plus station.

2) The CIR and MIR parameters are less than the port speed.

Workaround: Add local FR connections using the CLI rather than SV+ Connection Manager.

CSCdj80549

A software error 1000003 is logged once the FRP/UFM port configuration screen is displayed. If a standby NPM was available, the NPMs would switch and the software error would be logged on the new standby NPM. If only 1 NPM was installed, the node would rebuild and the software error logged on the active NPM.

CSCdj80815

The prtcderrs <slot> command caused the node to go into probe state (Bus error)

Workaround: Type "gs" and the system will come back.

CSCdj81488

The count of the connections in the failed state is inconsistent. The count of the failed connections in the dspalms command counts failed local connections as 2 failed connections and counts failed remote connections a 1 failed connection.

Workaround: If the number of failed connections contains local connections, subtract the number of local failed connections from the amount of failed connections shown when issuing the dspalms command.

CSCdj82094

After a mixed graceful and non-graceful upgrade, voice connections were deleted. Problem is currently being investigated. No workaround available.

CSCdj82434

Added on-line support for BCC-128. Operationally it will behave same as BCC-64. Before this change it was behaving like BCC-32.

CSCdj82438

It was observed that a card in the failed state remains failed, even after it responds normally.

Workaround: The condition can be cleared by either resetting the card via the resetcd command, or by physically removing and reinserting the card.

CSCdj82500

A range of connections is displayed as separate connections when addcon and dspcons command are executed. This problem occurs when there is a range of connections on a CDP, CVM, or UVM card.

CSCdj82643

The dsplog for voice connections display after 7.4.05 to 8.5 on a gracefully upgraded node (in a mix of graceful/ungraceful upgrades) on the network show voice connections getting displayed incorrectly. This is a display problem and will not cause major impact. No workaround available.

CSCdj82656

When a secondary revision changes on a node (by loadrev command, the revision change is not propagated to all the nodes in the network.

CSCdj82820

Software error 532 is repeated entered in the software error log, when a user deletes a connection that is being monitored by the command dsprts or cnfpref.

Impact: The software error log can fill up and potentially mask other software errors that occur because there are only 12 error slots are available. Other than that, there is no customer impact.

Workaround: Don't delete connections while monitoring them with dsprts or cnfpref. If the swerr 532 is occurring, it will occur until the user cancels the dsprts or cnfpref commands by: 1) doing another command, like dspcds or 2) invoking clrscrn command.

CSCdj82878

It was observed that the dspcon command displays O.K status for lines that are in failed state.

Workaround: Use the dsplns command to determine if the line is in failed state.

CSCdj81244

BPX node with feeder(s) has software error 3000000 or 501 (out of memory) logged. The abort profile shows high memory usage by the ILMI process.

Workaround: The aborts are due to a high rate of unknown VPI/VCIs from a feeder (the VPI/VCIs are not for a connection on the feeder and not for a signaling VCC). It may be necessary to remove the feeder(s) to stabilize the node.

CSCdj81254

Software error 532 was observed while the executing the cnfpref command.

CSCdj83863

Software error 526 was logged every time there was a remote trunk failure.

CSCdj86726

Node-by-Node upgrade Compatibility (command cnffunc 9) is enabled after upgrade to Rel85.

CSCdj84063

When adding a connection between an HDM/LDM/SDP/LDP card and a feeder trunk, the addcon command reports an error when the baud rate parameter value is entered. The "Unknown baud rate" error message is displayed and the connection will not be created. No workaround available.

CSCdj74414

Software error 1423 and Software error 1417 appear consecutively immediately after dntrk with a very low probability if the dntrk is issued very quickly after issuing a deltrk command on the same trunk. Workaround: Leaving some time (say 10 seconds) in between issuing the commands deltrk and dntrk would avoid this. Similar time spacing is encouraged between issuing deltrk commands as well in general.

CSCdj84451

Software error 398 occurred when adding connections and configuring trunks to route some of the connections in the network.

CSCdj84952

Software error 513 occurred while running a later version of the switch software.

CSCdj85993

User does not get an error message when specifying an endpoint on a CDP/CVM with a three part address such as <slot>.1.<channel>, whereas the two part address: <slot>.<channel> is required.

CSCdj85362

Port loopback state is re-enabled after node is rebuilt.

CSCdj83599

Line number is shown as "unk", when issuing a dspcon command on a data connection with the endpoint on a UVM card.

CSCdj82751

Software error 419 logged from the FAIL task after renumbering a node.

CSCdj82415

"Automatic switch back" to the original processor occurred following a switchCC command on the nodes with no redundancy configured (but standby CC present) or the secondary rev was different from the primary rev and the standby CC had not this rev installed.

CSCdj84372

It was observed that CVM/UVM dax voice connections with endpoints on the same card will not be re-programmed after rebuild or switchcc. It was also observed that CVM/UVM to FTM interworking voice connections voice card endpoint is not reprogrammed after rebuild or switchcc. In both cases, down and then up the connections should re-establish continuity.

CSCdj85064

Added checksum protection to the code. If a failure occurs the UP firmware will report a card error to switch software.

CSCdj87023

The dspprf t screen shows an incorrect value '3400' for all processes displayed. The process display does not start with the "IDLE" process due to incorrect display options. The incorrect watchdog values and display values can be seen on the cnfprf p screen.

Workaround: After upgrading from Rel841 to Rel85, do 'cnfprf p' to restore the default display and watchdog values for each process. The default values can be obtained from a node that was not upgraded from 8.4 to 8.5, or a node which had its configuration cleared by a user after an upgrade (clrallcnf will restore the default values).

CSCdj87484

It was observed that a corrupted firmware would be burnt into the cards and the cards would fail to come-up. The problem is likely to be seen in a firmware with a larger image size. Probability is more with BXM cards compared to others.

Workaround: Don't interrupt a Firmware download in the middle of downloading. If the firmware image in the node has to be cleared by getfwrev 0.0, do it after the download is complete.

CSCdj87634

Software error 75 occurs when multiple loadrev commands are issued consecutively on the same node in quick succession, with the second command being issued while the first one is still being executed.

CSCdj87889

On frame relay cards that do not support ForeSight, the user will be mislead in cnfport to believe that they can enable ForeSight over the port.

CSCdj80395

cnfchstats command on an HDM connection allows an interval of less than 5 minutes. But when dspchstathist is used to view the statistics collected the display prompts the user for an interval in the range 5-60 minutes.

CSCdj83399

The Node information database is incorrectly upgraded with the wrong external clock source information if ungraceful upgraded from release 8.4.1 to 8.5 is performed.

CSCdj83409

Primary, secondary, or tertiary clock source is not upgraded correctly in the BRAM for 841 upgrade in 85 baseline. If the node does active fail, 84 will lose this information.

Workaround: Reconfigure the clock source

CSCdj83503

The dspcons command shows a T condition indicating Test after upgrading from release 8.1.2x to 8.4.

CSCdj83709

Graceful upgrade from 841 to 85 will have the following problems for the Node Information database: 1) The external clock source and status is not updated correctly 2) There is a potential for aborting with the usage of uninitialized pointers.

Impact: 1) External clock information is not updated correctly on a graceful upgrade scenario 2) Potential abort on the standby.

CSCdj85196

IGX allows max sysparm CDP NTS values of 64. BPX only allows 32. Also, other values that apply to NTS traffic under sysparms only allow 32. This problem occurs when the cnfsysparm command is issued.

Workaround: For the CDP settings, a max delay of 64ms can be applied by configuring from an IGX. There is no workaround for the other NTS related settings. For example, connections added from HDM cards will only allow a maximum incurred delay of 32ms.

CSCdj85631

During some rare scenarios, the Fastpad port database can be corrupted after a graceful upgrade.

CSCdj86280

The first 4 bytes of the firmware image get corrupted because the image is loaded 4 bytes before where it is supposed to be. CRC errors on the loaded image will be reported when this occurs. This was detected in 8.1 when enabling the auto-dial alarm feature on the node when a new boot image was loaded. This is harder to see in releases past 8.1 since the auto-dial feature area is no longer the one immediately before the image download space.

Workaround: In release 8.1, disable the auto-dial feature when doing a firmware download. In releases after 8.1 it depends on number of connections and nodes in the network since that space precedes the firmware download.

CSCdj86796

An upgrade from release 7.4 (or 8.4) to 8.5 on an IGX node or from release 8.4 to 8.5 on a BPX node will incorrectly store NULL Circuit line clock source upon upgrade completion.

Impact: If the circuit line clock source is configured as primary, tertiary, or secondary clock source, upon upgrade, the circuit line clock source would have been set to NULL.

Workaround: Reconfigure the circuit line clock source again.

CSCdj87456

It was observed that when the clrallcnf command is executed after a power failure, the NPM cards will fail BRAM test. The NPM cards remain in the failed state. The dspcds command indicates "empty" reserved for NPCs.

CSCdj87570

Set Node-by-Node-Upgrade parameter default to enable in release 8.5.

Workaround:

The user needs to always set the Node-by-node Upgrade Compatibility parameter in cnffunc to Disabled in release 8.4 when trying to upgrade from release 8.4 to release 8.5. This is a required pre-upgrade procedure for upgrading from release 8.4 to release 8.5.

If the user is trying to upgrade from release 8.5 to release 9.1 or beyond, and the Node-by-node Upgrade Compatibility is set to Disabled, then manually set the parameter in 8.5 to Enabled prior to upgrading to release 9.1 or beyond.

CSCdj88475

The dspprf x command does not display some TFTP processes tasks (i.e., TFX0,TFX2,TFX3 etc.) after an upgrade from release 8.2.55 to 8.5.

Workaround: After upgrading to Rel85, do 'cnfprf x' and set the values to 'enable'.

CSCdj88560

Data base Node information is corrupted or wiped out, i.e., some nodes will be missing, upon active fail test from 84 to 85 upgrade. Software error 1417 is logged upon switchover to the standby which was writing 841 BRAM format from 85 Software.

CSCdj88657

Software error 26 is logged when issuing command dncd or dntrk. This software error is also observed when card failure occurs on an Active NTC/NTM card that does not have a backcard.

CSCdj88699

The dspcons command on a BPX node will not show connections that terminate on IPX/IGX.

CSCdj88908

Fail Handler performance number seem unusually high for the state of the node. Node has HDM/SDP cards with active ports without any terminating devices. Without terminating devices on the HDM ports, the hardware input signals on the ports float. This causes the switch to try and service EIA change on the port.

Workaround: Place terminating devices on the HDM ports.

CSCdj89094

Connection Management GUI displays ATM-FR connections as FR-FR connections.

CSCdj89095

It was observed that some connections were re-routed after upgrading from release 8.2.55 to 8.5.

CSCdj89198

If a node has an upped E1 trunk after an upgrade to release 8.5, and the other end of the trunk is a newly clrcnf or clrallcnf node, after upping the E1 trunk on the remote node, the trunk can not be added. The addtrk command will fail with the following error:

Abandoned because remote node Transmit Trunk Rate setting is different

This problem will also be seen in the case where a node is upgraded to release 8.5, and the E1 trunk is in the added state. If the E1 trunk is then deleted, and wired to a remote that was not upgraded but was created from clrallcnf or clrcnf, the E1 trunk can not be added until workaround specified below is applied.

Workaround: Down the E1 trunk on the upgraded node side, and up the E1 trunk again.

CSCdj89407

When the convulse command is issued with option 1. 4, software errors are logged on the system. This option is not valid at all and cannot be used on the switch.

This is a debug command and will not affect the system performance or operation in any way.

CSCdj89504

The dust command does not work on UVM line 2. This problem exists for all software releases that currently support UVM.

Workaround: To make dchst work on a channel on line 2, make sure the corresponding channel in line 1 exists.

CSCdj91765

Upon attempting to change your password using the cnfpwd command, you discover that the password has not changed to the new value you entered, even though no error message is displayed by the command. This problem may occur during a subsequent login attempt or when displaying the password using the dsppwd command. A second symptom is a user being deleted from the user database after the user's password is changed.

CSCdj91761

After a non-graceful from release 8.4.1 to 9.1, or 8.4.1 to 8.5, both Jobs and Executed Job databases may be corrupted. The same problem may also occur on an active card failure case, where the standby card is in the upgraded state, and the active card failed. In addition, if there more than 2750 connections on a node, the LCONs/VCs above number 2750 can also be corrupted.

Workaround: Remove all jobs on the IPX/IGX before upgrading from release 8.4.1 to 8.5, or 8.4.1 to 9.1, and add them back after the upgrade.

CSCdj91724

One of the following behaviors related to user passwords is observed:

1. Upon entering the correct password at the login prompt, the login is rejected.
2. The dsppwd command displays an incorrect password value.

3. Upon attempting to change a password using the cnfpwd command, the current password is rejected.

4. Upon attempting to enable/disable a software function using the cnfswfunc command, the correct password is rejected.

5. The adduser command does not assign the default password to the new user.

These problems can occur when two users attempt to execute a password-related operation at the same time. However, the chances of this situation occurring are very small.

Workaround: Repeat the operation. If adduser does not assign the default user password, the actual password can be displayed from a login session with higher privilege using the dsppwd command.

CSCdj92608

Inconsistent user data base occurred after a network join. This happens when the union of the two data bases of the subnets contains more than 64 regular users.

Workaround: Type commands updates 2 <nodename> on the node with the lowest node number. <nodename> can be the name of any other node in the network. The command has to be typed after all the conditional updates following a network join have been exchanged.

CSCdj93292

Aborts and connection deletions observed in the network while an active card fails on an 8255 node and the standby is in the 85 upgrade state.

CSCdj93165

Exception handling of swerr log is incorrect. The user stack information associated with the abort is not included in the log.

CSCdj94804

It was observed that some connections were deleted during a graceful upgrade from release 8.2.55 to 8.5. The problem occurred when an active card on a BPX node running release 8.2.55 failed while the standby was loaded with release 8.5.

CSCdj87214

It was observed that the Addlnrmtlp command may cause continuous aborts and rebuilds on BPX nodes.

CSCdj53780

The dsprts command on the IGX takes up to 30-40% CPU time. It was observed the normal IDLE time for an IPX node is 80%. Issuing the dsprts command decreases IDLE with an initial dip to 28%, followed by 40-50% constant IDLE. No workaround available

CSCdj56026

When there are events that cause resetting of an IGX node, some delay in processing the background diagnostic frames may occur. In cases of a heavily loaded IPX or IGX node, a "failure" of the background diagnostic test may be logged.

Workaround: Clear the card errors after a processor switchover or rebuild event. A more drastic workaround is to disable the background test, which may mask real HW errors.

CSCdj52297

A-bit alarm does not clear even if both sides of the NNI connection are upped and in OK state.

Workaround: Down and up the other end of the connection to cause a change of state, i.e., down the connection on the other endpoint node attached to the AXIS.

CSCdj44109

It has been observed that invoking and then canceling the command dspchstats can lead to incorrect bucket values for VC polling. No workaround available.

CSCdj72535

Issuing the dsprts command does not show the routes for data and voice connections. No workaround available.

CSCdj74527

The dspcons command displays connections that do not exist. This problem occurs after upgrading from release 8.4 to 8.5.

Workaround: Do not delete connections when nodes are in the upgrade state.

CSCdj49647

Standby Controller card would not be in a steady standby state which is a result of periodic standby resets. These resets could be confirmed from the log via dsplog command. This should not effect the functionality of the Active.

Workaround: None at this time. This problem seems to be the result failed communication between the active and the standby. Active keeps all the messages on the standby queue and frees them only when an acknowledgment is received from the standby. Because of the failed communication, lots of these standby messages are getting collected on the queue, resulting in shortage of memory, memory error and memory abort. The current fix puts a limit on the amount of memory that can be collected on the standby queue and hence we would not encounter memory shortage on the active card.

CSCdj58601

After a CC switch over due to a valid bus failure, the dspbuses screen shows the failed "Bus Line" to be "CommBus Clk", even if the failure type was "Asynchronous Clock 1 (8 Khz)" or "Asynchronous Clock 2 (192 Khz)". Workaround: Issue the clkdb clear command to clear the COMMBUS failure type. After the dspbuses screen will show only that there was a bus failure.

CSCdj58974

When executing the cnftstparm command, a particular combination of parameters may cause a test failure to be recorded. If a card is considered "failed" as a result, connections on it may be affected.

Workaround: Disable a particular test and change its parameters with two separate command executions. If a card is "failed", the resetcd -f and clrcderrs commands can restore its state.

CSCdj61992

The display of voice connections does not show when a modem is detected. There is no workaround available at this time.

CSCdj64676

The leap year calculation was wrong. It did not account for the fact the years evenly divisible by 400 are leap years (e.g. 2000). The date is off by 1 day starting 1/1/2001 00:00:00. No workaround available.

CSCdj66601

The atmPortQueueEntry object had an index for ABR and VBR, but not for CBR. CBR port queueing parameters were configurable from CLI but not SNMP.

CSCdj67828

The commands dspchstatcnf, dspchstathist and cnfchstats will not work for certain feeder DAX connections, giving the error "cnfchstats is not available for trunk endpoints" even if observing an ASI, line endpoint.

Customer Impact:

dspchstatcnf: User will not be able to observe the exact interval statistics (AUTO, TFTP or USER) that are enabled for the specified channel.

dspchstathist: User will not be able to observe the contents of a specific interval statistics (AUTO, TFTP or USER) that is enabled for the specified channel. NOTE: The TFTP stats will eventually be visible when the TFTP stat files are collected for this switch.

cnfchstats: User will not be able to configure USER interval statistics for the specified connection.

Workaround:

Delete the connection and then re-add the connection in the reverse order. The problem will occur when the customer adds a DAX feeder connection, where the first endpoint terminates on trunk card and the second endpoint terminates on the line card, i.e. addcon (trunk endpt) (node name) (line endpt)......

If they delete this connection and re-add it using the line card endpoint first, there is no problem, and the command addcon (line endpt) (node name) (trunk endpt) will work.

CSCdj67863

TFTP interval statistics are not reported for certain feeder DAX connections.

Customer Impact: User will not receive an TFTP interval statistics from the switch for some feeder DAX connections. The stats are being collected, just not reported to the SV+ Stats Collection Manager.

Workaround: Delete the connection and then re-add the connection in the reverse order.

CSCdj68524

Switch software periodically sends that hot-standby card the 0x50 CB Msg causing self test to abort before it can finish its test suite. Self Test needs a chance to complete the suite when the hot standby card is idle. Any CB Msg will cause self test to abort and return that everything passed. No workaround available.

CSCdj69142

The interval statistics reset functionality does not work correctly for inter-node connections (DAX connections) where the first endpoint (THIS END) is a trunk endpoint and the second endpoint (OTHER END) is a line endpoint. These connections are part of a multi-segment connection. (e.g., the two and three segment connections created by feeders). The reset functionality is enacted when the super user command `rststats' is invoked or when the system time is changed or drifts by more than 10 minutes. For the connection type specified above, the statistics values will not be reset (cleared) thereby contributing to "corrupted" interval statistic values.

Workaround: Delete the connection and then re-add the connection in the reverse order.

CSCdj70195

An intermittent software error was logged during a field-trial. The error number 55 indicated an invalid or unknown card type was found in the switch when displaying a connection status via CLI using the dspcon command. The problem is limited to the display of the connection. The connection display will not be updated. The only problem that remains is that dspcon will show a connection that no longer exists.

Workaround: It is not necessary to have a work around. But if the error arises, it is suggested that the user reissue the dspcon command. In all likelihood, the connection will no longer exist.

CSCdj71004

The status bits for scratch file, as indicated by the name with all zeros (e.g. h1c.0000000000) are not initialized until the this file is actually filled with valid information. When the `dspstatfiles' command displays this information, the status can look strange because it is reflecting whatever values happen to be at those memory location because it is still uninitialized.

Workaround: Ignore the status field for scratch files. This is a file "to-be-created", its information is irrelevant.

CSCdj71802

It was observed that after disconnecting the cable on a BXM trunk, the dsptrkutl command showed the trunk having 2458 PVCs. All connections rerouted successfully but when the cable was reconnected, the trunk stayed in LOS. In addition, software error 21 occurred on the BPX node. It should be noted that both trunks on a Y-redundant BXM and connected to a BPX node. No workaround available.

CSCdj71834

1000003 abort is logged from the NETW task (as can be seen in the error log entry) while testing a newer version of software. There were no known exact conditions for this particular 1M3 abort. There is no workaround for this particular 1M3 abort. If there is a standby on the node experiencing the abort, a processor switchover will occur. If there is no standby on the node in question a rebuild of the node would occur.

CSCdj72213

BCC gets wrong value for the backplane type when it reads from BackPlane NOVRAM. As this value is used only on BCC-4, this bug only effects BCC-4. This problem does not always happen, it only happens on nodes whose backplane NOVRAMs go bad. Even in cases of Bad NOVRAMs, the problem happens with very less probability as it would happen only when a value of 1 is read from word 2 of the BPNOVRAM. No workaround available.

CSCdj72481

The command dspconst can cause the node to undergo an unwanted switchcc when there are more than 8 voice lines up.

Workaround: User should use the dspconst command with the number of the line. Do not use the dspconst command without any parameters. Use the form: dspconst <line_number>.

CSCdj72833

The ATM connections made between ALMA and ALMB/AIT can not be differentiated at the slave side. No workaround available.

CSCdj73432

Software error 20 logged with 0x31 in the last byte of the first line in the error log. Likely to be seen on an IPX/IGX running 8.5 or higher if connected to a node running release 8.4. No workaround available. There is no impact operational due to this software error.

CSCdj73439

Communication Failure alarm seen on un-added trunk or trunk with nothing on the other end using the command dsptrks. Extremely rare to occur. Seen only once when addtrk was issued before the LOS status settled after doing an uptrk command. This problem has no operational impact.

Workaround: The condition can be cleared by issuing a dntrk followed by an uptrk on the un-added trunk which shows a comm fail alarm.

CSCdj73499

During connection reroute process, adding or deleting Frame Relay connections will force a switchcc before standby updates are being completed.

CSCdj73515

When downing a port, SV+ does not receive a port alarm robust message for neither BXM nor UXM ports. There is no noticeable customer impact of this bug. This bug causes the switch to send an extra robust alarm message for the port to the SV+ which the SV+ would not propagate further. This happens when a upport command is executed. No workaround is suggested.

CSCdj73763

ATFST connections between BPX and IPX/IGX do not pass traffic after upgrading to 8.5 from 8.2.55 This happens only on BPX after upgrading from 8.2.55 to 8.5.

Workaround: To correct this problem, issue the cnfcon command to configure the connection with correct foresight parameters.

CSCdj74503

A connection that is mastered on an IGX or IPX is not on a preferred route. Then the preferred route becomes available yet the connection fails to route on to that preferred route only when one of the trunks in the path meets the following criteria: 1) It is both on the current and the preferred route. 2) Without subtracting its current load on the trunk, there is not enough load on the trunk for the connection. No workaround available.

CSCdj74611

There is a discrepancy between the number of connections displayed as being in A-bit failure from the `dspalms' screen, and the actual number of connections that are displayed in a-bit failure via the `dspcons -fabit' screen(s). The accounting mechanisms to determine the count and which connections to display, are different. This discrepancy will only occur when there is a multi-segment voice connection that is in use, has been marked to go down as soon as it is no longer in use, and is in a-bit failure. No workaround available.

CSCdj75803

SNMP, SV+, IP Relay functions seem to hang or do not respond when SNMP managers sending multiple requests to SNMP Agent that have a PDU size of larger than 512 bytes. In some cases this can be caused by sending PDUs of size larger than 256 bytes if more than sixteen requests sent before the SNMP Agent can respond.

Workaround: Use SNMP Managers that do not retransmit after a timeout period.

CSCdj75805

When the user command "freemem" is used, it is possible to cause a 1M3 abort. This can occur sometimes when an incorrect memory address is entered as input to the command.

Workaround: This command is not often used, and is restricted to the highest login privilege level. Avoid using the command, or enter input data carefully.

CSCdj75881

A slow memory leak has been found. An occasional block of memory is found to have not been deallocated. No workaround is needed for this problem.

CSCdj76103

The SV+ gateway node would not respond to additional SV+'s subscription if the BPX node had 10 SV+ workstations directly attached.

Workaround: The IPX/IGX allowed 12 directly attached SV+ workstations, so configure an IPX/IGX as a gateway instead of using the BPX node, then restart the SV+ core.

CSCdj76230

VC bandwidth parameter may not go up over 255 VC parameters. Software error 313 may be logged on VC BW parameter removal.

Workaround: For releases 8.5.04 and below, there is none. With the release that has this fix:

1. If the customer has not upgraded to release 8.5 yet, there is no problem.

2. If the customer thinks the node is supposed to have over 255 entries, examine the potential connection that has the incorrect VC DB VC parameter index (dcct, or dvc). If the bandwidth index or parameters are not correct, cnfcon the connection to change the bandwidth to the desired BW parameters.

Impact:

1. A node with 4 Meg BRAM processor cannot handle over 255 VC BW parameter entry correctly unless this is fixed. The VC DB will have invalid VC parameter indices because the supporting routines to allocate the VC BW parameter is returning a ubyte size instead of a word. Hence, the upper byte is discarded. The connection will end up possibly having the wrong bandwidth configuration.

2. Upgrades:

If the VC's parameter index is NO_INDEX on the previous release, e.g., 841 or 8255, the field will be upgraded with NO_INDEX as well. Since NO_INDEX is -1 which is the maximum that a ubyte can handle, this was OK. Now, the VC parameter index is 12 bits which a word can handle. The BPX 841 handled this with introducing a new value NO_BW_PARMS (0x1FFF for 13 bits storage) to replace NO_INDEX. In 85 IGX, upgrade code should change the value to NO_BW_PARMS (0x0FFF for 12 bits storage in IGX) if its old value was NO_INDEX.

Since there is no upgrade between Release 85 to Release 85, the vc_parms_indices in the VC database will be initialized to NO_INDEX if it is not in use. It will be later changed to a valid VC Bandwidth parameter index if the allocation is successful. For 1 Meg BRAM processor 255 entries is the maximum. This is not going to be an issue. But for 4 Meg BRAM processor 255 is a valid VC Bandwidth parameter entry and the logic will cause potential problems. For example, when removing a VC Database entry, the VC BW parameter index is checked against an invalid index, which is NO_INDEX which means an invalid BW entry. If it is an invalid entry, the associated VC BW parameter is also removed. In the case of 4 Meg BRAM processor, the BW entry will not be removed if the VC BW parameter index went to as high as 255 or over.

CSCdj76354

The dspusertasks command does not indicate that telnet/SV+ session is in use if a telnet/SV+ session is established but NO user has logged in yet. Currently, dspusertasks command displays "none" if there is a telnet session. No workaround available.

CSCdj76710

Software error 1427s occurred when there is a topology change (including trunk status change) and a routing request letter is sent to the network handle. No workaround available. There is no operational impact when this software error occurs.

CSCdj77027

While executing addcon, the connection being added is not displayed while waiting for confirmation. No workaround available.

CSCdj77550

If a router attached as a CPE to the IGX has ELMI protocol enabled, the SV+ station connected to the network will not show the protocol type for that port as ELMI. There is no noticeable impact on the availability of the port or any connections on that port. The only impact is that the SV+ database entry for that port shows incorrect protocol type. No workaround available.

CSCdj64418

All ATM connection types can be added in the middle segment of a 3-segment connection on the hub node. In fact only CBR should be allowed for voice/data over I/P. No workaround available.

CSCdj56856

Software errors 1122, 105, and 21 occurred on IGX after running 8.5.00 image.

CSCdj60607

Connections that were passing traffic prior to the switchcc or graceful upgrade may experience the following problems after the switchcc or graceful upgrade: a) connection no longer pass traffic, or b) connection traffic is being multiplied, more data is received than is passed in, data original from no source. Workaround: Downing and upping the trunk card will cause the trunk card to be reprogrammed.

CSCdj61833

The dspnw shows nonexistent trunks on a node, which appear to be leftover from a previous node's trunks.

CSCdj62262

Software error 254 appears on all nodes after a non-graceful (single controller card) upgrade from 8.4.1 to 8.5.

CSCdj62525

When a node comes back from being unreachable a software error 332 can be logged.

CSCdj63056

After upgrading from 8255 to 85, some event logs (e.g. line events) will have incorrect description. Workaround: Clear the event log (via clrlog command) before performing an upgrade.

CSCdj63247

The use of the tstcon command with the -nolp option can cause problems for voice or data segments in a tiered network. After the test is completed, the LDM or HDM card may fail subsequent background diagnostic tests. The voice channel configuration for voice segment may not be correctly reconfigured after the test.

CSCdj63585

The addfrcons command allowed access device to be connected to FastPAD non-dax connection.

CSCdj65875

bw_oe_clp_enable and bw_oe_upc_enable are set to match the local bits rather than upgraded.

CSCdj66314

During 8.5 loop testing, noticed that the addloclp slot.port command did not work for BXM ports. It worked OK on the ASI port. Issuing the addloclp command will receive the error message "Invalid Connection Address".

CSCdj67238

When creating ATM PortQs through SNMP on a network running software release 8.4.11 on BPX routing nodes and IPX feeders; 4.0.05 on axis feeders and 8.4.07 StrataView Plus, both get/set attempts fail on the BXM, but are successful on the ASI.

CSCdj67684

Deleting voice connections after resetting an active FTM card causes software errors 532 and 382 to be logged.

CSCdj67712

Resetting CVM cards caused voice connections to be in the failed state.

CSCdj67823

Trunk errors are not collected from BNI cards. When trunk errors exist the dsptrkerrs screen shows no errors, and minor or major alarms are not generated. Workaround Manually enable trunk error statistics collection on the BNI card. This workaround must be repeated after a BNI card reset. The problem is due to the initialization of the line type attribute for BNI cards. This attribute defaults to "no line" rather than the line type. This prevents SW from requesting some error statistics from the BNI card. Trunk errors which are not reported by the BNI will not generate trunk errors. The initialization of the line type can be verified by using the dspcmi p slot # command.

CSCdj67825

The UBR connections that were added using SNMP (StrataView or SNMP script) may be incorrectly formed and routed as ABR connections. When these connections are upgraded to the software release 8.5, the dspcon command will show them as ABR connections instead of UBR connections.

CSCdj67954

Connections don't route on 64K channel BXM card. No workaround available.

CSCdj68009

The cnfpref screen for an ALM-A connection showed an port number for the ALM-A end point.

CSCdj68050

Data discontinuity observed in a connection between two remote BXM cards with BNI trunk.

CSCdj68684

The dspcon screen shows erroneous data for CVM dax connections.

CSCdj69145

Downing a VC and a VP connection will result in a ILMI trap being sent only for one of those connections.

CSCdj69338

Inconsistent data displayed when comparing two end points via dspcon, dcct or cnfcon commands.

CSCdj69380

Most Robust Alarm messages sent from the IGX/IPX/BPX to StrataView have an alarm type field of Major, Minor, or Clear. A few card alarms have been added that are Info. These do not have the trap type set correctly. This should not effect most customers. However, if a customer is subscribed to receive SNMP Traps from StrataView's RTM Proxy, then they may see an occasional trap with an unexpected value.

CSCdj69644

Traffic discontinuity noticed on ATFR connections after a non-graceful upgrade from 8.4 -> 8.5.

CSCdj69968

Inconsistent data displayed for DAXCON connections when comparing two end points via dspcon, dcct or cnfcon commands.

CSCdj69977

Event log messages in the StrataView event log sometimes show the wrong card type.

CSCdj70198

Software error 921 occurred on a BPX node while running software release 8.5.02.

CSCdj70403

BTM firmware attributes are not updated correctly on an 8.4->8.5 upgrade.

CSCdj70916

E1 line signalling on unframed lines shows `ABAB' instead of `None' when you upgrade from 82-85 or 841-85, the line signalling on an E1 unframed line shows up as `ABAB'.

CSCdj73398

During graceful upgrade from 8.4.1 to 8.5, random circuit lines may display CRC Errors or other alarms, which are not reflected in traffic loss or disruption, and which clear on their own.

CSCdj74506

Software error 4228 occurred during a graceful upgrade from 8.4.1 to 8.5.

CSCdj67013

Incorrect VC conditioning occurs on the BPX connection when the connection is made with the other end card type supporting FRM to UFM and is in a `circuit line alarm' status (circuit line failure).

CSCdj62636

BTM trunk failure and FRM port failure after upgrade from 8.2.56 to 8.5.01. SW not correctly upgrading card attributes which apply to upgraded firmware on BTM. Hence, attributes are incorrectly set in upgraded release and cause cards to be removed and reinserted by the SW. The correlation of this issue to the failures seen is still being investigated.

CSCdj62849

Software 2000000 abort occurs when the 68040 receives the "transfer error ACK" (TEA) signal. The problem is with interrupt latency during a switchover.

CSCdj62525

Software error 332 logged on BPX during trunk failure/recovery testing. Trunk was \Qdowned' and then \Qupped' when this error was logged.

CSCdj63591

Problem with storing FPAD_ADDR values in user endpoint.

CSCdj43128

Upgrade of memory regions can copy too many regions. Only applies to 8.2.56 -> 8.5 upgrades (BPX).

CSCdj64464

Connections failed to route after rebuild of IGX node -- no CGW Lcns on BTM trunk. This is not an issue for connections that terminate on the node that rebuilt. It was a problem for some BPX connections that routed through the IGX that performed the rebuild.

CSCdj60745

Unable to change muxbus utilization for UFM slots.

CSCdj65875

Unknown OE CLP enable and OE UPC enable bits are not upgraded correctly.

CSCdj61151

Not all the requested TFTP statistics are being enabled.

CSCdj40551

No alarm generated when FRP/AIT cards were removed.

CSCdj46114

It was observed that during a rebuild, Switchcc or upgrade, all the connections on the Max_Slot may either get deleted or left hanging without being recognized.

CSCdj59263

Software error 532 occurs when deleting connections.

CSCdj62504

Software does not support trunk status 133-140 on ALM but does on BTM.

CSCdj64824

Circuit lines or packet lines in the last slot of a 16 or 32 card IPX/IGX are not appearing for the summary screen when dspcderrs or dsplns commands are issued.

CSCdj63165

This bug applies to pass-through configuration where 3 UVMs are used to support 48 LDCELP connections on two T1 lines. When a fax call is originated on port B of the secondary UVM card, the connection upgrades to p, but does not downgrade after the fax call ends. This would potentially causing some trunk congestion.x56 Message not sent down to Port 2 of UVM card during Pass-through Connection.

CSCdj62982

User can not add a port with port number 250 on an UFM-C T1.

CSCdj61181

Processors with at least 32 Mb have extended regions. These regions are not supported by the scanrgn command. The latter only supports the basic regions - DYNM, STAT, STTC, and POOL.

CSCdj43344

On the BPX, Line alarms and errors set or cleared only for the first 100 lines. I.e., Alarms do not work for lines with a logical line number greater than 100. This is not a problem for trunks, only for lines. Even if the cable is removed from the interface the Port LED stays green and the dsplns command shows the "Current Line Alarm Status" for the line is "Clear - OK", when it should show Loss of Signal.

CSCdj62226

A software error 21 is logged from an LDM card after a NPM switchover.

CSCdj61022

Software error 925 if dnln command is executed when the line status is "Bad Clock Path" in the "Current Line Alarm Status" field of the dsplns command display.

CSCdj68870

Software error 30 occurs when trying to configure a trunk in the preferred route.

CSCdj68885

Software error 4208 occurs when trying to configure a trunk in the preferred route.

CSCdj68076

A frame relay connection using a non-circuit line interface may be erroneously flagged as hardware failure.

CSCdj68296

The interworking BPX connection where the other end is a frame relay card with non-circuit line interface may be erroneously conditioned.

CSCdj28429

BTM/AIT Rx Spacer Queues are not configured properly.

CSCdj69569

The addcon command does not support adding Frame Relay connections with PVC parameters.

CSCdj66885

Software error 614 occurs for all Frame Relay local connections (dax connections) on graceful upgrade from 8.4.1 to 8.5. Incorrect other end line number is displayed for atfr connections.

CSCdj66856

ATM connections are auto-deleted after the addcon command is issued. This may result in software error 614 being logged.

Workaround:

1) Clear the circuit line alarm.
2) down the connection.
3) up the connection.
4) the a-bit alarm will clear for the connection.

CSCdj65828

After upgrade, configuration of E1 voice lines changes to framing OFF and signalling ABAB instead of CAS.

CSCdj65305

Software errors 4225, 614, 4206, 3058, 50, 921, 612 occurred the after graceful upgrade of an IPX or IGX from 8.4.1 to 8.5. Some connections may be deleted.

CSCdj58101

While removing and inserting BTM cards, the NPM may restart and pause indefinitely. Workaround: Use the "dncd" command to down the BTM before removing the card.

CSCdj58626

Several nodes in a 6-node network with 5000 connections per node experienced switchovers and unexpected system reloads due to memory exhaustion. This problem has been seen in networks with 5000 conns per node. Workaround: None

CSCdj62599

After graceful upgrade from 8.4.1, the dsprrst command on some nodes reveals rerouting of certain conns. Network interworking conns are affected. Connections appear to reroute successfully, immediately. Network interworking connections (atfr, atfst) that terminate on or pass through an IGX routing node will not pass data after this upgrade. Workaround: Delete and re-add the network interworking connections.

CSCdj62273

ATM connections don't reroute after mixed upgrade were performed on a network (e.g., graceful some nodes, ungraceful others). No workaround available.

CSCdj61167

On a non graceful upgrade, all feeder info is lost. As a result, ALM-A lines which are UNI feeder types, do not upgrade.

CSCdj60745

Unable to change muxbus utilization for UFM slots.

CSCdj40551

No alarm generated when FRP/AIT cards were removed.

CSCdj43344

On the BPX, Line alarms and errors set or cleared only for the first 100 lines. I.e., Alarms do not work for lines with a logical line number greater than 100. This is not a problem for trunks, only for lines. Even if the cable is removed from the interface the Port LED stays green and the dsplns command shows the "Current Line Alarm Status" for the line is "Clear - OK", when it should show Loss of Signal.

CSCdj61022

Software error 925 if dnln command is executed when the line status is "Bad Clock Path" in the "Current Line Alarm Status" field of the dsplns command display.

CSCdj58429

The connection deroute delay timer may not get cancelled due to invalid logic in the code. This may result in software error 923 being logged. Workaround: Do a switchcc to reset the trunk delay timers of all the trunks in the node.

CSCdj56646

cnftrkparm updates parameter 19 with an invalid value whenever parameter 9 is changed. Parameter 9 is the Yellow alarm I/O and parameter 19 is the High CLP for CBR traffic. This problem occurs on both BNI and BXM trunks. Workaround: Use the cnftrkparm command to correct the bad value for parameter 19.

CSCdj57674

After the command clrallcnf is issued, the establishment of VNS SVC call could cause the switch to reset. As the user has not begun to provision the services, resetting the switch initializes the data structure properly and clears the problem itself.

CSCdj60759

A scanrgn of the dynamic region (RGN2) showed about 80 permanent allocations out of nw_assgn_rsmb(), which allocates memory for received network messages. No workaround available.

CSCdj50128

Software error 2051s appear in software log and/or the SV+ complains that the tftp interval file is incorrect as it is too short.

CSCdj55201

When Y-cable redundancy for frame relay ports is used with Release 8.5.00 software, the use of the secondary slot may cause the ports to be displayed as FAILED, instead of ACTIVE. No workaround available.

CSCdj55993

The addyred command erroneously allows the user to use an active BXM card as the YRED Secondary card. This is not a problem for BNI and ASI cards. Workaround: Use delyred and switchcc commands to restore database values are recommended.

CSCdj56632

After adding Y-cable redundancy to an active card, both the primary and the secondary cards are in the standby state. Workaround: Before adding Y-cable redundancy, make sure that the active card s not failed (e.g. Active-F). If the card is failed, clear the failure before adding the redundancy.

CSCdj56802

Voice and data connections can not be added from an IGX feeder node thru a switching node to another IGX feeder node using the Command Line Interface (CLI) on the feeder nodes.

CSCdj23296

Software errors 4206 and 3058 occurred when adding connections via GEIS bundle.

CSCdj48253

tstdelay command does not work properly for connections with an ALM-A endpoint. Execution of the command will either cause time out or result in a user error message. This only applies to connections with ALM-A endpoints. No workaround available.

CSCdj49377

The tstdelay command failed for UXM to ALM-A connection.

CSCdj50222

Interval statistics are disabled on the active but not on the standby, after a new enable attempt is made.

CSCdj50992

The cnfsysparms command prompts for adjusting the port and connection interval polling rates are misleading.

CSCdj51215

Inconsistent load occurred for both ends of connection made from CVM to FTC.

CSCdj51523

FTM FastPad channel address displayed incorrectly when issuing the dspcons command.

CSCdj51854

voice and NTS connections can not be routed over paths that have a cumulative delay exceeding the limit of 32 ms.

CSCdj52048

The clrallcnf command does not clear all the configuration in the BRAM.

CSCdj53321

After 8.4.1 upgrade to 8.5, approximately 300 (out of 15000) connections were rerouted due to inconsistent load calculation.

CSCdj54006

the software does not check the vc poll rate at the remote end of the connection, which raises the possibility of overburdening the system real-time with stats collection.

CSCdj54794

The dspcon command displays incorrect remote line for connections after the 8.4.1 to 8.5 upgrade.

CSCdj55021

The dspcon command displays incorrect port number for ATF connections when executed from the BPX endpoint.

CSCdj54902

The CVM card is not returning channels to idle 54h when the connections have been deleted.

CSCdj54927

Cannot execute provisioning commands when enabling TFTP interval statistics.

CSCdj56274

It was observed that when a failure on a BXM port occurred due to LMI or ILMI signalling and the failure is cleared by disabling the protocol, a switchcc would result in a port failure on the newly active port even though the signalling protocol has been turned off.

CSCdj56499

Software error 21 occurred when VPI value is greater or equal to 4096 on NNI connections.

CSCdj57164

After an ungraceful upgrade from Release 7.4 to Release 8.5, all nodes continuously aborted with the 1000003 software error.

CSCdj57246

Software error 925 occurred on a standby UVM during rebuild.

CSCdj58094

BPX software does not allow the configuration of DS3 or SONET loopbacks via SNMP set-requests.

CSCdj58338

Software error 886 occurred after a processor card switchover.

CSCdj58447

Software error 2056 appears after the Stats Collection Manager (SCM) enables TFTP interval statistics with an invalid connection peak interval.

CSCdj59313

Software error 55 occurred when configuring a non-existent connection on an NTC card.

CSCdj59818

After a switchcc or software upgrade, an IGX card removes itself. 'dspcds' shows the slot is empty. Approximately ever 10seconds, a software error 21 is reported for the empty slot.

CSCdj59981

User can't communicate with StrataView Plus after an ungraceful upgrade from release 7.4 to 8.5, if the node involved is the gateway node to StrataView Plus.

CSCdj60515

Software error 1057 occurred while resetting a UFM card with 1K connection.

CSCdj60608

Software error 925 gets logged on displaying CDP voice connections with line interface upon upgrade from 841 to 8.5.C9.

CSCdj61294

When clearing the channel stats for a specific channel, the screen displays misleading numbers in the counter field before clearing the counters.

CSCdj61384

Standby update queue up faster than they can be serviced, as indicated by an overgrowing 'Standby CC Update' field for the dspqs screen.

CSCdj61454

The command dspmemblk will helps to indicate memory fragmentation by calculating the largest allocatable block of memory. However, it only does these calculations on 2 regions, static and dynamic. Code modified to perform the calculations for all of the available regions.

CSCdj34394

When attempting to re-add the connections deleted by the autodelete command (see CSCdj33379), software error 4205 occurred for every attempt.

CSCdj36826

Incorrect values in the physical card attribute table cause AXIS shelves to become unreachable after loading the software release 8.4.08 image.

CSCdj37318

Resetting the BXM-DS3 Y-redundant card causes communication failure on the DS3 trunk to occur.

CSCdj38707

Executing Node-by-Node upgrade process from software release 8.1.50 to release 8.4.09 resulted in a node unreachability.

CSCdj38337

It was noted that during a Node-by-Node upgrade, CLEAR_MSG messages are queued but not dumped to the network. The would potentially cause nodes to become unreachable when the messages are finally dumped.

CSCdj38922

There was no data continuity after adding a new ASI connection. It was noted that during the card verification process, the ASI back card is being reset, but never cleared. This will result in channel configuration message not being sent to the card.

CSCdj39341

During an upgrade, it was noted that a rebuild problem could likely occur on the node number 64.

CSCdj39402

Abort 1000003 occurred while a batch job reset all cards every 0.5 hour.

CSCdj40425

BXM card with 32K or greater LCNs would use up to 50% of the processor time even if no channels are set.

CSCdj40257

Data discontinuity observed with connections routed over virtual trunks.

CSCdj39700

During a Flash upgrade from software release 8.2.04 to release 8.4.09, software error 21 occurred on two nodes (one IPX, one IGX). A subsequent non-graceful upgrade resulting in data discontinuity.

CSCdj35538

The expected mismatch messages were not displayed when replacing one of the Y-Redundant BXM cards with a card having different PVC counts (i.e., 32K vs. 16K).

CSCdj36677

The tstdelay command reports `test passed' results even when the link being tested is down.

CSCdj36834

The tstdelay command does not work on VP connections added between two ports of the same ASI card.

CSCdj37348

The reroute state machine is not re-enabled after a Node-by-Node upgrade ends.

CSCdj38335

Invoking the nwupgrade switch command can cause the node to downgrade unexpectedly.

CSCdj38228

The dsplog command displays erroneous alarm status.

CSCdj36932

After the reset of a BXM-622 card, a software error 1000 was logged. This indicates a shortage of memory buffers for inter-process message transmission. This occurs on heavily loaded systems.

CSCdj39028

The following event log strings need to have a corresponding Robust Alarm Trap:

1. BCC n Restarted due to a System Reset

2. BCC n Restarted due to a Powerfail

3. CC Redundancy Alarm in slot n

4. Y Redundancy Alarm in slot n.

CSCdj19597

Software errors (45, 3016, 364) occurred while executing a batch job, which reset cards at a 10-minute interval.

CSCdj39701

The SNMP routine returns an incorrect index value for Frame Relay ports.

CSCdj39969

Software error 424 occurred after removing an active BCC card during a Node-by-Node upgrade.

CSCdj39627

A Robust Alarm Message needs to be generated for a Communication Break event.

CSCdj32934

Handling of error conditions in Utility Processor is not correct, which could cause a Bus Error.

CSCdj33231

The delcon command does correctly delete the channel information from the other end of the connection. This is for BPX-BPX connections.

CSCdj34045

The execution of an addtrk command caused 1M3 abort (Bus Error) and a software error 1117 (Too many topology messages).

CSCdj35421

Memory is lost if a switched virtual circuit is deleted before the routing of the connection has been completed.

CSCdj35151

Comm failure occurred between AXIS and BPX after switchcc on a BPX node.

CSCdj36220

When attempting to clear a comm failure with a manual switchcc, the comm failure continued to occur on the port.

CSCdj36276

Software error 4206 is reported on the standby BCC of a BPX node after the node has recovered from a power failure.

CSCdj36282

Software error 52 (watchdog timer timeout) occurred on a BPX node after failure recovery from a power failure.

CSCdj33379

Software error 614 occurred on a BPX node after invoking a switchcc command.

CSCdj34394

When attempting to re-add the connections that had already been deleted, software error 4205 occurred for every connection addition attempt.

CSCdj36826

AXIS shelves become unreachable after the lanbtld command was invoked.

CSCdj28245

There was no communication between two BCC3s in Boot.

CSCdj32495

The cnfbpnv and dspbpnv commands did not display backplane NOVRAM content correctly.

CSCdj32843

Invoking the cbstats clear command did not clear the value in the DROPPED MSGS category.

CSCdj34949

Invoking the clrlnerrs command caused software error 1000003 and a switchcc.

CSCdj34754

BPX takes too long to revert to the primary clock source.

CSCdj33696

Invoking the nwupgrade end * command caused software error 3333 and 1427 to occur.

CSCdj29008

Software error 2064 occurred when VNS bulk calls are being provisioned.

CSCdj34724

Deroute Delay Maximum needs to be raised to 600 seconds.

CSCdj33772

Software error 4205 occurred when running VNS Bulk Call provisioning.

CSCdj35917

Software error 1417 occurred when deltrk and dntrk commands are issued.

CSCdj34821

A switchcc during firmware download caused the target card to fail.

CSCdj36148

Parity errors are not cleaned up correctly on the BPX node.

CSCdj35538

BXM does not report mismatch message when a new Y-redundant card is inserted which has a different max PVC count configured.

CSCdj36677

The tstdelay command reports erroneous test results.

CSCdj36834

The tstdelay command fails on VP connections added between 2 ports on the same ASI card.

CSCdj37649

Logical Endpoint allocation takes lot of time during rebuilds.

CSCdj37348

Connection rerouting was not re-enabled after a Node-by-Node upgrade ends.

CSCdj33667

The clrlnerrs command does not work when the port number is greater than 2.

CSCdj35764

The dspalms command does not display any alarm status even though the node is in major alarm due to problems after a switchcc.

CSCdj31909

When invoking the clrportstats command, user may not be allowed to specify the "all ports" option via use of ala *.

CSCdj36568

The cnfclnsigparm and cnfclnsigparm commands do not work correctly.

CSCdj37070

When attempting to issue dsputl command before the stats areas have not been created for the IPX/IGX node, an error message `Line currently being monitored' is displayed even though there is only one user on the system.

CSCdj25851

It was observed that, at the completion of a burnfwrev command on a BXM-155, the active BCC switched to the standby BCC due to watchdog timeout.

CSCdj25121

Software error 52 occurred and followed by a system abort when routing was turned-on after switchcc is completed.

CSCdj24913

tstdelay command may not working properly when BTM trunk is in the path.

CSCdj27193

Virtual trunks stopped working after upgrade from 8.2 to 8.4.0 release.

CSCdj27713

Due to a database mapping problem, the trunks configurations were lost on an IGX node and hence the connections configured on those trunks received failed status. This problem occurred during the upgrade testing (from 8.2.07 to 8.4.0 release) and was after completion of the power failure test.

CSCdj28302

Due to an error in trunk alarm checking, the alarm counters was incremented even though the ILMI task has stopped sending node status message to SAR when a the trunk or port is in a Major Alarm status. This may have caused an AXIS node to become unreachable.

CSCdj28234

BPX nodes could not be recovered after power failure in the lab.

CSCdj26349

After switchcc on a BPX node, the node continued sending out LMI messages for ASI and BXM ports and would not allow users to telnet or vt to the node for 10-11 minutes. This causes ATM ASI/BXM port failure.

CSCdj29233

It was observed that when routing more than 1500 connections through a BNI-OC3 trunk, communication failure on the trunk would occur.

CSCdj31042

After upgrading the node from release 8.1.19 to 8.4.0, a slow memory depletion (leak) was observed.

CSCdj33231

While investigating tstdelay time-out problem on BXM-T3 to ASI-T3 connections, when the connection were attempted to be deleted from the master side, the VPCs were deleted, but not from the other end. There was software error 3017 generated at the slave end on each delcon.

CSCdj25962

After a Node-by-Node upgrade (from 8.1.50 to 8.4.0), it was observed from an BPX node within the same group to be upgraded that two IPX nodes were not shown status as being upgraded even though the upgrade was successfully completed.

CSCdj25826

Time for ILMI port stats was incremented incorrectly, causing the time polling cycle to restart every 48 seconds rather than every 60 seconds.

CSCdj22859

Due to a mapping problem, an inconsistent status would be shown on the Standby card. This problem occurred during an upgrade from 8.1.xto 8.4.x and the NIB standby update message were processed.

CSCdj24120

It was observed that duplicate "file not found" events were logged by the TFTP Client code and would potentially fill up the event log.

CSCdj26257

When configuring a Frame Relay class on an IPX node, the PIR value was displayed as *.* but interpreted as 19.2/19.2.

CSCdj17569

On a BXM-T3 Y-Redundant trunk, the active BXM card was reset while the standby card was in a failed state due to a fatal hardware error. Invoking the dspcds command after the card reset showing BXM backcard in a mismatch state.

CSCdj25075

Software error 1000 occurred on a BPX node when deleting a trunk that: 1). splits the network (i.e. the last trunk to a node, or the only trunk connecting two sub nets); 2). has 2500+ connections routed across it to a single node.

CSCdj32686

The clock source was configured on a virtual trunk port BNI-OC3 on a BPX node. When invoking the dspcurclk command on an remote IPX node, the display showed incorrect trunk port value.

CSCdj24948

Connections were added from FRSM-HSSI to FRP and FRM. FRSM-HSSI is configured in DTE mode and traffic is being pumped at the rate of 20Kbps on those connections. The connections are configured with CIR=MIR=PIR=100kbps. Invoking dspchancnt command on both FRP and FRM showed that all frames are received in excess of CIR. It was noticed that bc (Committed Burst) for IPX was set to 0 when it should be set to 65535. FRP/FRM tagging all frames as received in excess of CIR.

CSCdj28594

When issuing a cnfcon command to change the EPD (FBTC) value from disabled to enabled for BXM card, only the ingress of the ports and trunks was enabled. The egress remains as EPD disabled.

CSCdj29291

Memory leak occurred during execution of the FRP background test.

CSCdj24118

BCC stays at DnLder status after switchcc and can only be recovered by removing and putting back the card for it become active.

CSCdj12410

Inconsistent connection status between two endpoints occurred when the master node was not informed of an error found at the completion of connection re-route on the endpoint node.

CSCdj29001

Software error 532 occurred when invoking VNS voice SVC calls.

CSCdj29677

Changing the receive rate using the cnftrk command following a addtrk command caused some neighbor nodes to become unreachable.

CSCdj07631

An TFTP error 22 indicating that the peak value was invalid occurred when enabling statistics for a BPX node through the Statistics Manager GUI.

CSCdj31320

Changes to the maximum channel count for a trunk were lost after a switchcc. If the channel count was changed at the remote end of a trunk, the local end would not update its standby CC correctly. A subsequent switchcc at the local end would wipe out the new configuration.

CSCdj27042

Due to the changes made to the ADTF value range, a preferred route could not be configured for the connections that has ADTF value equal to 10.

CSCdj33370

Software error 2117 occurred on a BPX node when burning FW is interrupted by a "getfwrev 0.0" command.

CSCdj31439

When attempting to add an AXIS to a BPX node, communication breakdown message occurred. The AXIS shelf can not be added.

CSCdj30470

Software error 2065 occurred on a BPX node approximately 20 minutes after a switchcc. Further investigation indicated that the root cause of this problem was an invalid boundary check on the active, which created a flawed update message for the standby.

CSCdj25547

Background test failure was reported on an ASI Y-Redundant card when congestion on the port occurred and software error 105 were logged.

CSCdj26583

PVCs were in an in-and-out of Alarm state when deltrk was issued or a trunk is in a fail state.

CSCdj29493

Software error 4209 occurred on BPX nodes while the BCC was in standby status.

CSCdj31105

Even though the dnln command was issued for ASI-155E card the front LED stayed on active. It appeared as though the card was active when it wasn't.

CSCdj32843

When trying to clear cbstats using cbstats clear command, the DROPPED MSGS category were never cleared.

CSCdj31091

When a clrlnerrs command was issued, it caused 1000003 abort and a switchcc.

CSCst96798

Switch software sets shelfCnfgRebuildStatus object as REBUILD when switchcc occurs. DNS software interprets this as the node went down and deletes all SVCs associated with that node. This will cause calls to be dropped.

CSCdj24114

A 1000003 abort occurred when attempting to add more than 12,000 connections.

CSCdj26862

A software error 4209 occurred while adding connections due to the local resources unavailability.

CSCdj28579

Remove debugging code that logged software error 7777.

CSCdj27744

BXM feeder trunks weren't being programmed during the card configuration process.

CSCdj19652

The dspclksrcs command shows invalid clock source information, The primary, secondary, and tertiary sources are incorrect.

CSCdj03075

A virtual path connection could not be added because the support for BNI-E3 cards is missing.

CSCdj21794

A software error 614 (LCON automatically deleted) due to the logical endpoint VC index did not agree at each end.

CSCdj22424

Routing virtual trunk traffic through a BXM via trunk does not work.

CSCdj23350

IPX feeder nodes cannot use the trunk as a timing source. The "pass sync" option is not allowed on feeder trunks. Packet lines which pass sync are not allowed to be clock sources.

CSCdj27532

When nwip_on is asserted in the ~svplus/config.sv file, the savecnf operation does not work from an IPX feeder.

CSCdj23570

Multiple problems after performing a switchcc on a BPX with many connections: the problems are all caused by comm failures due to inefficient programming of the BXM cards.

CSCdj27129

A 100003 abort occurred when handling an error condition returned by the SAR which indicated that an invalid command was received.

CSCdj27059

Software error 514 occurred on a heavily loaded BPX node.

CSCdj19165

There is a 10-15 second delay in traffic continuity after a port Y-redundant switchover.

CSCdj19637

Incorrect trunk number is shown as the clock source when using the dspcurclk command.

CSCdj19512

The dspports command only displays the first 96 ports of a BPX node.

CSCdj20069

Standby Y-redundant cards can still drive the clock bus.

CSCdj15103

Software error 4208 (Bad connection address type) occurred on a BPX node.

CSCdj21070

Invoking dspcons with a starting channel number as the only argument fails to display the appropriate connections.

CSCdj20682

A BPX event log indicates that there are BFrame parity errors and Rx Invalid Port errors, but the StrataView Plus HPOV event log does not indicate any of these.

CSCdj22346

After a graceful upgrade from 8.1.50, trunk number 32 is missing.

CSCdj21369

The cnfswfunc feature 6 on a BPX, ABR standard with VSVD, becomes disabled when any IPX or IGX routing node rebuilds.

CSCdj23566

Using dspport or dspports with only a slot number as the argument incorrectly displays Speed as "UNKNOWN" and Interface as "EMPTY".

CSCdj26131

The cnfclksrc command allows a trunk to be a primary clock source while it is passing sync.

CSCdj25301

On the BXM, Early Packet Discard (EPD) and/or Frame Discard is not enabled.

CSCdj26827

On an ASI-T3 card, the 1000th connection on the card is not programmed correctly.

CSCdj27511

Software error 618 occurred on a heavily loaded BPX node.

CSCdj15795

Software error 1406 (indicating a bad checksum on a network topology update message) floods the error log.

CSCdj16467

For BXM-DS3 terminated connections, Virtual Path Connections do not operate when the other end terminates on an AXIS shelf in NNI mode.

CSCdj16162

After a Y-Redundant switchover between a pair of BXM cards, it has been observed that a software error 105 (CBUS buffers full) was logged. This is due to multiple connections being re-configured within one CBUS message, which results in a much longer than expected execution time. This will be addressed in the next release where appropriate message throttling will be inserted. At this time, BXM port and trunk cards should not be configured in Y-redundant pairs.

CSCdj14719

The BPX is constantly re-routing connections due to the failure of topology updating, which caused an incorrect view of the topology to exist.

CSCdj18088

There is network topology corruption caused by a node, whose number is set to 64, when that node rebuilds.

CSCdj19179

After a Node-by-Node upgrade, there are cases where the battery backed up RAM is not being rewritten properly.

CSCdj15047

The dspnwip command repeatedly displays the same node's information, rather than all the nodes.

CSCdj09736

There is an intermittent condition where a self-test timeout occurs on the BCC-32. This is not a true indication of a problem with the BCC.

CSCdj12314

When rerouting connections that terminate on AXIS shelves due to the establishment of a preferred route, failure status is reported because an A-bit alarm is being sent by the BPX.

CSCdj15594

Multiple software errors 21 were logged on a BPX.

CSCdj15999

The addcon command cannot be used in jobs on the BPX. An infinite loop results.

CSCdj15226

After a node rebuilds, messages indicating that the time of day is changing is flooding the event log.

CSCdj11989

After a switchcc command is issued, the event log is formatted after the switch, and thus the switchcc even will not be reported to StrataView Plus.

CSCdj17569

A BXM-DS3 trunk card in y-redundant configuration indicated a backcard mismatch after being reset. At the time, the standby card was in failed state.

CSCdj18216

Invoking the dsptrkstats commands on virtual trunks shows incorrect BFrame cell count values.

CSCdj09369

On the cnftrk command, for BNI-OC3 trunks the Payload Scramble option cannot be set to "No" because it results in an Out Of Frame alarm. The software must prevent the user from making this setting.

CSCdj19165

There is a 15 second delay/interruption of traffic on BXM port cards after a Y-redundant switchover occurs.

CSCdj19637

An incorrect trunk number is displayed as the clock source when running the dspcurclk command.

CSCdj19512

The dspports command displays only the first 96 ports of a node.

CSCdj13934

The dspports command works on IPX nodes but not on BPX nodes.

CSCdj10363

The Deroute Delay Timer value used always varies 2 seconds from the configured value.

CSCdj17869

During an upgrade from 8.1.5, multiple node unreachabilities were encountered, along with software errors 254 and 526.

CSCdj15833

CSCdj16479

A feeder shelf cannot be deleted. When the delshelf command is issued, the message "Resources Low---Interface Shelf not changed."is returned.

CSCdj16874

During an upgrade from 8.1.5 to 8.4.0, the standby BCCs on all the BPX nodes keep toggling between the upgrading and upgraded/(clear) state.

IMATM F/W

C

4.0.17

4.0.04

IMATM Boot

N/A

4.0.01

4.0.01

ASC F/W

M

4.0.19

4.0.04

ASC Boot

N/A

4.0.04

4.0.03

BNM-E3

B

N/A

N/A

FRSM-4T1

C

4.0.17

4.0.04

FRSM-4T1 Boot

N/A

4.0.00

4.0.00

SRM T1E1 (B)

B

N/A

N/A

CESM-4T1/E1

C

4.0.13

4.0.04

CESM Boot

N/A

4.0.00

4.0.00

AUSM-4T1E1

B

4.0.17

4.0.04

AUSM Boot

N/A

4.0.00

4.0.00

FRSM-8T1

A

4.0.17

4.0.04

FRSM-8T1 Boot

N/A

4.0.01

4.0.00

FRSM-HS1

A

4.0.14

4.0.04

FRSM-HS1 Boot

N/A

4.0.00

4.0.00

AUSM-8T1/E1

A

4.0.18

4.0.04

AUSM-8T1/E1 Boot

N/A

4.0.01

4.0.00

BCC (model B) boot

K

HBJ

HBH

BCC3-32 (model C) boot

K

HCM

HCH

BCC3-64 (model D) boot

K

HDM

HDM

BCC4 (model E) boot

K

HEM

HEM

BCC4-128 (model H) boot

K

HHM

HHM

ASI 155

H

WHC

WHB

ASI 155 E

E

WEC

WEB

ASI-1 2T3/C

D

UCF

UCA

ASI-1 2T3/B

D

UBK

UBH

BNI 3T3/C

F

TCM

TCK

BNI 3E3/B

F

TCM

TCK

BNI 155 E

E

VDR

VDN

BNI I55

EOL

VBR

VBN

ASM

B

GAC

GAC

BXM 4P

A

MBY

MBM

BXM 8P

A

MBY

MBM

NPC Boot

BAF

BAF

NPC 32 Boot

BBF

BBF

NPC 64 Boot

BCF

BCF

NPM Boot

RAP

RAM

NPM 32 Boot

RBP

RBM

NPM 64 Boot

RCP

RCM

NPM 32B Boot

REP

REM

NPM 64B Boot

RFP

RFM

ALM-A

CAE

CAA

ALM-B

CBH

CBB

BTM Model A

IAF

IAE

BTM Model B

IBL

IBK

BTM Model D

IDC

IDA

CVM Model A

DAF

DAF

CVM Model B

DBD

DBC

CVM Model C

DCA

DCA

FRM Model D

FDZ

FDX

Avoid Rev. FDU & FDV

FRM Model E

FEZ

FEX

Avoid Rev. FEU & FEV

FRM Model H

FHB

FHB

FRM-2

FFD

FFD

FTM Model B

JBJ

JBF

FTM Model C

JCB

JCA

HDM

SCF

SCF

LDM

LCB

LC3

NTM

NEK

NED

NTM (B)

NFH

NFD

Recommend using NFF or above

AIT Model A

IAF

IAE

AIT Model B

IBL

IBK

CDP Model A

DAF

DAF

CDP Model B

DBD

DBC

CDP Model C

DCA

DCA

FRP(M) Model D

FDZ

FDX

Avoid Rev FDU & FDV

FRP(M) Model E

FEZ

FEX

Avoid Rev FEU & FEV

FRP(M) Model H

FHB

FHB

FRM(B)

FTC Model B

JBJ

JBF

FTC Model C

JCB

JCA

NTC

NEK

NED

SDP

SCF

SCF

UFM-C

ZAM

ZAB

UFM-U

YAF

YAA

UVM

DAD

DAA

UVM-B

DBD

DBA

UVM-C

DCA

DCA

UVM-D

DDE

DDA

SwSw 8.5.09

Sys S/W IPX

8.5.09

Sys S/W IGX

8.5.09

Sys S/W BPX

8.5.09

BCC (Model B) Boot

J0

B

HBJ

BCC3-32 (Model C) Boot

M0

C

HCM

BCC3-64 (Model C) Boot

M0

D

HDM

BCC4 (Model E) Boot

M0

E

HEM

NPC Boot

F0

A

BAF

NPC 32 Boot

F0

B

BBF

NPC 32 Boot

F0

C

BCF

NPM Boot

P0

A

RAP

NPM 32 Boot

P0

B

RBP

NPM 64 Boot

P0

C

RCP

NPM 32 B Boot

P0

D

RDP

NPM 64 B Boot

P0

F

RFP

SV 9.0.05

StrataView Plus

9.0.05

StrataView Plus SCM

9.0.05

SNMP

9.0.05

AXIS 4.0.19

IMATM F/W

A0

4.0.17

4.0.17

IMATM Boot

N/A

4.0.01

4.0.01

ASC F/W

A0

4.0.19

4.0.19

ASC Boot

A0

4.0.05

4.0.05

BNM-E3

N/A

N/A

N/A

FRSM-4T1

A0

4.0.17

4.0.17

FRSM-4T1 Boot

N/A

4.0.00

4.0.00

FRSM-8T1

A0

4.0.17

4.0.17

FRSM-8T1 Boot

N/A

4.0.01

4.0.01

FRSM-HS1

A0

4.0.14

4.0.14

FRSM-HS1 Boot

N/A

4.0.00

4.0.00

SRM T1/E1 (B)

N/A

N/A

N/A

CESM-4 T1/E1

A0

4.0.13

4.0.13

CESM Boot

N/A

4.0.00

4.0.00

AUSM-4 T1/E1

A0

4.0.17

4.0.17

AUSM-4 T1/E1 Boot

N/A

4.0.00

4.0.00

AUSM-8 T1/E1

A0

4.0.18

4.0.18

AUSM-8 T1/E1 Boot

N/A