0-3999 connections

Polling Rate: 5 Minutes (or higher)

4000-8000 connections

Polling Rate: 10 Minutes (or higher)

8000-12000 connections

Polling Rate: 15 Minutes

0

0,1

Hardware revision

1

2,3

Backplane Type (usually 0x65=101 decimal)

2

4,5

Backplane version (0x0000:old 0x0001:new)

3

6,7

Backplane serial number in ASCII - MSB

4

8,9

"

5

A,B

" LSB

6

C,D

Board FAB number, in ASCII - MSB

7

E,F

"

8

10,11

"

9

12,13

"

A

14,15

"

B

16,17

" LSB

C

18,19

Unused

D

1A,1B

Unused

E

1C,1D

Unused

F

1E,1F

Checksum bytes - CURRENTLY NOT SUPPORTED

CSCdi85160

Symptom:

Occasionally, when burning firmware, the process does not complete successfully. An error message is logged in the event log.

Workaround:

Since the process of burning firmware usually works, just try again. If the node is unstable due to problems in the network, wait until things settle down.

CSCdj89081

Symptoms:

The VC queue threshold at a via node trunk uses a high default value 0xcfc95 and is not changeable by the value provisioned at the end point. Thus the thresholding mechanism using the VC queue at a via node most likely is not effected. Note that the VC queue at the trunk on the first hop is programmed correctly.

Conditions:

When there are multiple connections that go through the same trunk, ideally the VC queue thresholds specified at the ingress endpoints should be used at the via. Thus the VC queue thresholds are not effected at the via which could cause unfairness in traffic usage.

Workaround:

None.

CSCdk19125

Symptom:

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

Conditions:

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

Workaround:

None.

CSCdk21160

Symptom:

Interval statistics on the Cisco WAN Manager 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

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

FRelay 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

CSCdk28347

Symptom:

Connection to a FastPAD failed when the remote FastPAD 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.

CSCdk29716

Symptom:

Discrepancy in the "dspchstats" when comparing the two 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

CSCdk33721

Symptom:

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

Condition:

During graceful upgrade the software error 614 was seen.

Workaround:

None.

CSCdm42754

Symptom:

1) The active, or standby has non-zero interval statistics counts (as displayed by dspstatparms) thereby indicating that TFTP interval stats are enabled. However, TFTP interval stats are not enabled as indicated by dspstatparms' "Object Count" field showing zero objects, and the "Interval Stats:" field indicates DISABLED. This is being referred to as stats being partially enabled.

2) The standby controller card logs a software error 2000000 and then resets itself once.

3) The standby controller card logs the software error 2000000 and then resets itself at the regular interval of 5, 10, 15, 30 or 60 minutes.

4) After a controller card switch over, the new-active controller card logs the software error 2000000 and then reset itself.

5) After a controller card switch over, the new-active controller card fills the software error log with software error 136's.

Conditions:

The steps leading up to the various symptoms listed above are similar, but not quite the same. They are explained as follows:

1) The partial enabling of TFTP stats will occur if:

a) The customer has a redundant controller card.

b) TFTP interval statistics are enabled.

c) The active controller card does a hitless rebuild

At this point the standby will have TFTP interval stats partially enabled, when they have actually been disabled.

d) A controller card switch over is done.

At this point both the active and the standby will have TFTP interval stats partially enabled, when they have actually been disabled.

2) The single 2000000 and standby rest will occur if:

a) The customer has a redundant controller card.

b) TFTP interval statistics are enabled.

c) The active controller card does a hitless rebuild

d) A controller card switch over is done.

e) The same set of TFTP interval statistics are enabled, as done in step b.

When the active creates its TFTP interval stats file at the end of its file interval, it will send a message to the standby to do the same. However, when the standby stumbles across some of the TFTP interval stats that where partially enabled (see FURTHER PROBLEM DESCRIPTION below), the 2000000 is logged and the standby controller card is reset.

However, when the standby resets all of the partially enabled TFTP statistics are deleted.

Note that the active has its global stat data structure indicating that stats are enabled, so when the standby update mechanism enables the stats on the standby it will obtain acceptable initializers from the stat global and the problem "corrects itself".

CSCdm42754 - continued

3) The standby "2000000 and reset" scenario will occur if:

a) The customer has a redundant controller card.

b) TFTP interval statistics are enabled.

c) The active controller card does a hitless rebuild

d) A controller card switch over is done.

NOTE: Stats where not re-enabled. In this case the active has its global stat data structure cleared, but it incorrectly has stats enabled (See FURTHER PROBLEM DESCRIPTION below).

Periodically, the active will send an update to the standby to roll its stat buckets. At this time, the incorrectly initialized stats will log a software error 2000000 and then restart the standby.

These restarts will occur at approximately the bucket interval rate. We say approximately, because it generally takes longer than 5 or 10 minutes for the secondary card to become fully updated.

4) The scenario for the active controller card logging a software error 2000000 and then resetting itself will occur under the following conditions:

a) The customer has a redundant controller card.

b) TFTP interval statistics are enabled.

c) The active controller card does a hitless rebuild

d) A controller card switch over is done.

e) Prior to a statistics bucket interval completion, another controller card switch over is done.

Prior to the last switch over the standby has incorrectly initialized statistic. Some of the initialized values are zeros. When we switch over, the card starts using some of the fields and logs the 2000000 and then restarts.

However, after the restart, the situation has cleaned itself up.

5) The scenario for the active controller card filling its log with 136's is the same as for scenario 4.

The difference here is that symptom 4 was discovered in an earlier release, but the root cause was not tracked down, so instead preventative code was added to avoid the 2000000 and restart, and simply log a 136 and continue.

This scenario will not clean itself up. The 136's will be logged at a high frequency until the work around is enacted.

Workaround:

1) Symptoms 1, and 3 can be resolved by doing the following:

a) Enable stats

b) Disable the stats. At this point, dspstatparms should indicate that interval stats are disabled, and the stat tally counts should also be zero.

c) Reset the standby controller card. Realistically the standby should have disabled all of these stats, but to make absolutely certain I recommend that the standby controller card be reset.

2) Symptom 2 corrects itself, however, I would still recommend following work around #1 to be absolutely certain.

3) Symptom 4 also corrects itself. However, to avoid symptom 4 from occurring in the first place. The following preventative steps can be done.

a) After any hitless rebuild, validate that the standby agrees with the active regarding the stat of statistics.

If the standby has a non zero stat count, while the active has a zero stat count, then follow the steps for work around #1.

b) Prior to doing a manual controller card switch over, follow the instructions for step a) above.

CSCdk48816

Symptom:

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

Conditions:

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

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

Workaround:

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

CSCdk53502

Symptom:

ASI-T3 or ASI-E3 cards using T3-3 or E3-3 backcards show lines as Clear-OK when the line actually should show LOS. (No loopback or other line attached)

Workaround:

Use cnfbkcd to change the backcard to a T3-2 or E3-2 and the line will show LOS status correctly.

CSCdk55887

Symptom:

dspport command is not available to level 6 user ids.

Conditions:

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

Workaround:

Increase user privilege.

Further Problem Description:

The privileged level of the dspport command was changed in release 8.1 to level 2 from level 6.

This difference was first noticed by 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.

CSCdk65743

Symptom:

Software error 52 in dspswlog with VT_1 as running process

Conditions:

One-time occurrence of a watchdog timeout on a BCC while VT'd in from another node

Workaround:

None

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:

1000003 abort in SNMP process.

Conditions:

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

Workaround:

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

CSCdk80347

Symptom:

NPM 2 restarted due to a Watchdog Timeout

Conditions:

Happens when you run resetsys command to reset all the cards (except the active NPM card) on an IGX node with lot of active connections. When the standby NPM comes up, the event log mentions that:

"NPM 2 Restarted due to a Watchdog Timeout" where 2 refers to the slot number of the standby NPM card.

Workaround:

This does not affect any functionality except for the above log. Instead of running the resetsys command, individually reset the cards using resetcd command.

CSCdk85068

Symptom:

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

Conditions:

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

Workaround:

None.

CSCdk89002

Symptom:

A BPX switch experienced unreachabilities with all Axis feeder trunks.

Conditions:

Unknown

Workaround

:switchcc

CSCdk93423

Symptom:

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

Conditions:

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

Work around:

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

CSCdk93626

Symptom:

atmEndptMCR is out of range.

Conditions:

When a connection is ended on a BXM port and MCR is less than 6.

Work Around: Don't set MCR less than 6 if a connection is ended on a BXM port.

. Range:

. ASI/BNI

T3: 0-96000

E3: 0-80000

OC3: 0-353208

. BXM/UXM

T3: 6-96000

E3: 6-80000

OC3: 6-353208

CSCdm00711

Symptom:

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

Conditions:

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

Workaround:

Set the SNMP Get community string to NOACCESS.

CSCdm02866

Symptom:

xlat database says that there exist a vlcon entry for a ltrk and number of conids usage needs to be decremented. But the topo information sees that number of conids used by this trunk is already zero.

Conditions:

This problem happens when there is lot of activities going on and some of the nodes go in comm failure. This problem is reproducible on BPX using the configuration specified in CSCdm87860.

Only problem that this bug causes is "Filling of dspswlog screen"

Workaround:

None. Just do clrswlog.

CSCdm04262

Symptoms:

The OAM loopback test may be failing on a DAX conn with endpoints at 2 cards on the same node. When the OAM capability is disabled on one card, the OAM loopback failure condition is also cleared at the other card which still has the OAM capability enabled.

Conditions:

This happens only on a DAX conn using 2 cards.

Workaround:

None

CSCdm05391

Symptom:

LCN is autodeleted. But Xlat database is not cleaned up properly. This will result in software error 370

Condition:

This problem happens when a connection (VC/LCON) is autodeleted due to VC_DB/LCON database verification. The original bug is due to AUTO_DEL_VC/AUTO_DEL_LCON.

Workaround:

None. Do clrswlog to clear software errors.

CSCdm06027

Symptom:

UXM Cards in Y-red occasionally fail Self Test.

Condition:

dspcds show card state as Statndby-F

Workaround:

Reset the standby card to clear the failure

CSCdm06555

Symptom:

dsptrks on BNIs show Loss of Pointer. This results in comm. failure on trunks.

Condition:

Software is wrongly displaying the type of Alarm. Actually this is Out of Frame. When there is a OOF Alarms, comm. failure will happen.

Workaround:

Check the cables and backcards. Make sure that they are all properly connected. Do Loopback tests and make sure that physical layer is good.

CSCdm08470

Symptom:

Return traffic on a CBR connection is not limited to its configured PCR rate.

Example: A CBR connection configured for 5000/50 will not limit the return traffic to 50 cps.

Workaround:

Unknown

CSCdm10372

Symptom:

When a VSI controller is deleted using delctrlr command, the object 6 in the 0x61 CBUS message is set to 1.

Effects:

Hence when a VSI controller is deleted, traps may not be sent to the controller.

Workaround:

This functionality is used by the PNNI controller which is not available in the 9.2 release. Hence this bug will not create any problems in this release.

CSCdm10703

Symptom:

A software error 514 is generated after downing an ALM-B trunk.

Condition:

This problem is not readily reproducible. To date it has occured only a few times and each time it was on an ALM-B trunk. Analysis of the defect suggests that perhaps a UFM was in this slot prior to the ALM-B.

When the trunk was downed, the 514 was logged.

Workaround:

None.

Impact:

The 514 is logged, but the memory is still freed. There should be no other side effects of this defect, other than the logging of the 514.

CSCdm12876

Symptom:

Software error 324 is logged during re-routing of connections.

Condition:

During the process of routing connections on a via node, the routing state machine logs this error because it encounters an Via CON which contains Xlate Ids which point to Xlate entries that do not exist.

WorkAround:

Full rebuild or switchcc on the via node will fix this problem.

CSCdm13482

Symptoms:

1) dsplm shows fail "F" in the "LC "column.

2) This is due to inconsistent VLCONS. There exist dangling VLCONS, which have not got cleaned up.

Conditions:

1) When the command xlat_verify is executed, software error 332 (BD_XLAT_INDX) is logged complaining about the dangling entries.

2) These errors do not cause any corruption or damage.

Workaround:

1) Switchcc will cleanup.

2) The errors if logged can be cleared.

CSCdm13495

Symptoms:

Sometimes after burning firmware, the card seems to disappear.

Workaround:

None needed. Usually, burning firmware seems to work fine. The problem was probably due to some particular circumstance. It is not clear whether may have been a configuration problem, or user error, since it is not being seen.

CSCdm14446

Symptom:

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

Condition:

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

Workaround:

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

CSCdm15589

Symptom:

Software error 3103 (RR_GRP_CNTR_ERR) occurred on IGX node. This occurs if there is a discrepancy in the LCON list and an internal counter maintained for the number of connections to be rerouted in this reroute group. The LCON list maintains the list of connections which are to be rerouted in the reroute group.

Condition:

This bug was logged 3 days after the actual occurrence of the problem. The user is not sure exactly what kind of activity was going on when the software error was logged. "dsplog" does not go all the way to the time of the occurrence of this problem. (Maybe burning of UXM firmware was going on).

Workaround:

Potential workaround is the command rbdrrgrps. This workaround could not be tested since this problem was seen only once till now.

CSCdm16353

Symptom:

Software error 9082 (Channel Config Bad Command Error) reported after issuing switchyred (or resetcd) on BXM card with redundancy.

Conditions:

- BPX with 2 BXMs (YRED)

- LMI protocol is implemented by the BXM card.

- There are a lot of connections (e.g. 1600) between the AXIS and the BPX.

- A switchyred occurs (either due to a reset on the active BXM card or the switchyred command).

The YRED BXM card will become active and all channels have to be reprogrammed by the BCC. Before the BCC has a chance to finish the programming, the Axis is already sending status to those channels that have not yet been re-programmed on the BXM card. The BXM reports this error which will then be translated into software error 9082.

Workaround

None

CSCdm17732

Symptoms:

Software error 355 is logged.

Conditions:

This error is seen after switchcc because one conid is being used by two xlat entries. No corruption is caused.

Workaround:

switchcc may fix this problem.

CSCdm17748

Symptom:

The fields UpdtStatus Rx, UpdtStatus Tx, Status Ack Tx, Status Ack Rx on dsplmistats increment when the LMI protocol is moved from BCC to the BXM but not when the protocol is moved back from BXM to BCC.

Conditions:

This is observed when LMI protocol is moved from BXM to BCC.

Workaround:

None

Further Description: When the protocol is moved from BCC to BXM, BXM sends out the update status for all the connections. But this is not done when the protocol is moved from BXM to BCC. This means if something goes wrong with the BXM implementation of the protocol we cannot move the protocol to BCC and clear the problem.

Customer Impact:

The impact is minimal. This is more of an enhancement issue.

CSCdm18381

Symptom:

CMGUI can not see the ports on a primary BXM card after the Y-red switch over.

Workaround:

None

CSCdm18555

Symptom:

For the following conditions, the user either cannot add yred or is reported with false mismatch alarm. The user does not get any benefit by upgrading to the enhanced UXM card because of the mismatch.

Condition:

1. Cannot configure yred for mixed UXM cards if in standby mode. Cannot configure yred if in active mode and the primary card is enhanced while secondary is non-enhanced.

2. The switch issues false mismatch alarm under any of the following conditions:

* For standby yred UXM card pair, when change the secondary card from non-extended card to extended card.

* For mixed yred UXM card pair, when upgrade from release 9.1 to release 9.2.

* For active non-yred card, when change from extended card to non-extended card.

* For active yred card pair, when change the secondary card from extended card to non-extended card.

Workaround:

None

CSCdm19535

Symptom:

(1) When adding a new VT on a BXM port already supporting VTs, some unnecessary channel programming takes place.

(2) When deleting a VT on a BXM port the still supports other VTs, the directed networking channels get assigned to the VI of the deleted trunk. If this VI gets reassigned to a different port, Comm Breaks could happen.

(3) A direct routing loop is not stopped for BXM VTs, as a VT transmitting a specific VPI/VCI can also receive it. This will fill up the VT with hipri traffic, when a routing loop is created where the neighbor sends this VPI/VCI back.

Conditions

(1) addtrk of multiple VTs on a single BXM port.

(2) deltrk of one of several VTs of a single BXM port, and reassigning the VI to another port by dntrk of the VT and uptrk and addtrk of a new trunk on a different port of the same card.

(3) Inconsistency of topology information of two neighbor nodes.

Workaround

(1) None, but the problem is not serious.

(2) Resetting the BXM card

(3) The operator can resolve this situation by removing the routing loop. Routing loops occur when nodes do not have the same topology information. The topology information can be made consistent by use of the updates 1 or the recovertopo command.

Another note for (3) There exists a theoretical chance of a trunk loopback generating a large stream of cells. However, so far all attempts to demonstrate this have failed.

CSCdm20508

Symptom:

Software error 447 gets logged

Condition:

Standby card is reset

Workaround:

None. The node logs software error because it does not expect this kind of message from the Standby and discards it. No harm is done, as the Standby is resetting anyway.

CSCdm20593

Symptoms:

A request to block ATFR connections between UXM endpoints.

Conditions:

None

Workaround:

None

CSCdm22255

Symptom:

Performing switchcc while in boot locks up the NPM cards.

Effects:

The NPM cards have to be physically reset by pulling them out of the IGX chassis and re-inserting them.

Workaround:

Doing switchcc in the boot is normally done by the development team for doing upgrades. This is not a recommended procedure for performing upgrades. The recommended procedure is to use loadrev command or to use TFTP to upload dnld.sw file with relevant upgrade information.

CSCdm22648

Symptom:

A card error was reported.

Conditions:

This happened while downing the 31th trunks.

Workaround:

None

CSCdm24020

Symptoms:

1.) A hitless rebuild was done on a slave node while the master rerouting some connections.

2.) There is a remote chance that, when the rebuild occurs slave has not finished routing on its side. The connections remain as derouted on the slave side but are routed on the master.

Conditions:

1.) Rebuild the slave when connections are being routed from the master side.

Workaround:

1.) The command rrtcon will fix it.

CSCdm24031

Description:

If old 9.1 firmware is burned into a new enhanced BXM card, then the card will not function.

Solution:

The user interface should be able to verify that the version of firmware is correct for the card before allowing it to be burned.

Workaround:

Be care choosing the correct version of BXM firmware before burning it.

CSCdm24313

Symptoms:

1.) Software error 612 logged, when a switchcc was done.

2.) What this error means is that the VC was sent to the standby but the LCON was not yet. Switchcc occurred at this time. When verification is done the orphaned VC is deleted.

Conditions:

1.) Switchcc when CM updates are pending.

Workaround:

None

CSCdm24749

Symptom:

During y-red switchover OR card reset there will be multiple messages going to the standby cards. This may cause RSRC to hog cpu for some duration.

Conditions:

Node has Y-red configuration, y-red switchover OR CC switchover occurs.

Workaround:

None.

Further Information:

This is NOT going to cause any operational problem to customer.

CSCdm25862

Symptom:

Software error 9082 logged with MC10 firmware and 9.2 software.

Condition:

This problem happens when firmware rejects the Bframe Header for some LCNs during channel programming. It happens only with MC10

Workaround:

Use MDA or later version of firmware.

CSCdm26145

Problem:

swlog 9000 with second line code of 09B2 occurs in software log. Additional sw 105 errors may occur afterwards, connection programming may be affected on a small number of cons.

Configuration:

UXM trunk card with 1 thousand connections, 750 of which are gateway connections, when a hitless rebuild is performed on the main processor.

Frequency:

Varies, some days it cannot be reproduced, other times the failure will occur 2 out of three times.

Workaround:

Reset the UXM card

CSCdm28610

Symptom:

Software error 1415 is logged on the Standby after a network trunk is deleted meaning it was already deleted on the Standby.

Workaround:

None

Impact:

None. Software error shows that some updates from the Active indicating the existence of this trunk did not reach the Standby. This error was observed when several switchcc were executed within a short time interval which probably accounts for the loss of the updates.

CSCdm36041

Symptom:

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

Workaround:

None.

CSCdm36631

Symptom:

APS activated alarm trap #20101 seen for T3 trunk.

Conditions:

A T3 trunk was modified using cnfrsrc command.

Workaround:

None

CSCdm37694

Symptom:

Software error 9082 was seen after upgrade

Condition:

A race condition - the channels on the card were not reorganized the 9.2 way before reprogramming messages were sent to the card.

Workaround:

Not needed

CSCdm37796

Symptom:

tstcon works for 2 segment connection. But tstdelay does not work. Traffic goes through ok.

Condition:

On 2 segment connection. Connection terminates on UFMU. BTM feeder trunk.

Workaround:

None

CSCdm39210

Symptom:

A cnfrsrc on the trunk connecting a TSC to BPX does not allow the MAX PVC LCNs to be more than 10.

Condition:

1) disable vsi partition on trunk 3.3

2) dntrk 3.3

3) uptrk 3.3

4) cnfrsrc 3.3

Got "PVC Channels (256). Can not exceed (10)" message

Workaround:

None

CSCdj15839

Symptom:

False power supply over voltage or under voltage alarms reported

Condition:

A bogus minor alarm is generated on IGXs running 8.2.10 for power supplies with hardware revisions AR and AS. The commands dspalms and dsppwr show the problem.

Workaround:

Run the command 'off2 8'. This will disable all monitoring of the power supply, not just voltage. Fail status, temperature, and voltage will not be collected if "Power Supply Monitor" is disabled.

Another workaround is to downgrade to a power supply with a hardware revision below AM (but NOT AM).

Additional Information:

With this fix in place, voltages and alarms are properly reported for nodes with PEMs installed in all PEM slots; however, a minor alarm will be reported for an empty PEM slot. Please see DDTS document CSCdm14418 for further information.

CSCdj31366

Symptom:

The clrcnf command does not utilize a double confirmation prompt prior to acting on the users instructions. The warning message is also based on an understanding of the node/switch management operations.

Workaround:

Do not issue the clrcnf command unless there is the desire to erase the database and cause the node/switch to be removed from operations.

Correction:

An enhanced display screen with flashing lights and detailed operational messages in used in conjunction with a double confirmation prompting input request.

CSCdk21503

Symptom:

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

Conditions:

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

Work Around: None.

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

CSCdk29850

Symptom:

The protocol type value for an FRP port in the Cisco Wan Manager database is 0.

Conditions:

Whenever a FRP port is added to the node, the Cisco Wan Manager 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)

CSCdk32046

Symptom:

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

Conditions:

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

Workaround:

Issue cnfclnsigparm 9 N to disable: 9 CDP & CIP Condition CCS Lines? [YES]

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.

CSCdk47079

Symptom:

Software tries to access the invalid memory entry cause the ABORT when user executes the dth command.

Condition:

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

Workaround:

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

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.

CSCdk56688

Symptom:

When trying to execute the command hipri, get the error messages. Correct the earlier error and then execute it, it may come up with another error and so on.

Conditions:

Need to execute the hipri command when it's supposed to work.

Workaround:

Login into the control port with the proper privileged level and then execute the command hipri as the first command immediately after login. This really isn't the workaround, just the way it's supposed to be.

CSCdk69440

Symptom:

'dspprf' shows IDLE very low when many UVM cards in IGX chassis with switch software 9.1.04

Conditions:

'dspprf' is as low as 27%

Workaround:

When turning off either 'off2 1' or 'off2 10' or 'off1 16' parameters the idle time rises to over 70%.

Disabling Modem Test (off1 16) will disable modem upgrade detection capability on the node.

CSCdk69498

Symptom:

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

Conditions:

Environment is not an issue as this happens on the customers network and in the LAB with just a single node. This problem has only been seen on 9.1.03 and 9.1.04, although it is suspected in all releases of 9.1, 8.2 and 8.5 have been tested and work correctly.

Workaround:

None

CSCdk72199

Symptom:

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

Conditions:

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

Workaround:

Three possible workarounds are available:

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

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

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

CSCdk74438

Symptom:

The job does not take 8/8 option.

Conditions:

N/A

Workaround:

Manually create the connection.

CSCdk82927

Symptom:

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

Conditions:

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

Workaround:

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

CSCdk83511

Symptom:

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

Conditions:

BPX switch software: 9.1.04

BXM firmware: M.B.Y

'tstconseg' on a connection endpoint

Workaround:

None

Further Problem Description:

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

CSCdk87005

Symptom:

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

i.e.

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

Shouldn't need the starts for optional parameters.

Condition:

Always happens

Workaround:

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

CSCdk91395

Symptom:

A vague error message ("BW PARAMS: Unknown response (xx)") is returned to user when a connection's remote PCR value is configured to a value higher than the maximum port speed.

Condition:

This happens when the cnfcon command is executed.

Workaround:

None

CSCdk92892

Symptom:

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

Conditions:

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

Workaround:

dncon and then upcon.

Further Problem Description:

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

CSCdm05373

Symptom:

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

Conditions:

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

Workaround:

Reconfigure the channel again.

CSCdm07825

Symptom:

When the customer enables TFTP interval statistics with an invalid configuration the switch logs a 2065 and the SCM receives the following error string:

Node=l2a Undefined TFTP Error num=28 text=021, Bucket interval (5m/300s) is not a multiple of Invalid obj type polling interval(900s)

Condition:

This will occur when the customer attempts to enable statistics with an invalid bucket interval. Bucket intervals must be a multiple of the switches largest polling interval.

i.e If the switches largest polling interval is 15 minutes and 5 minute buckets are enabled, then that would trigger this error.

Impact:

This has minimal customer impact. The switch is logging a software error because it cannot correctly formulate the return error string. This then means that instead of telling the customer which object type has the largest polling interval it will say "Invalid obj type". However, it still specifies how large the largest polling interval is, therefore the customer still has enough information to correct the problem.

Workaround:

None

CSCdm10020

Symptom:

Both the BPX routing node and the IGX feeder node are at 9.1 level. After upgrading the IGX feeder node to 9.2, the LMI communication between the 9.1 BPX routing node and 9.2 IGX feeder node is broken.

Conditions:

The problem only occurs when the feeder node is a 9.2 IGX and the routing node is a 9.1 BPX.

Work around:

Upgrade the BPX routing node to 9.2 before upgrading the IGX feeder node to 9.2.

CSCdm13012

Symptom:

Upping the 32nd log interface results in BXM cards going into failed state.

Condition:

BXM supports only 31 Log Interfaces per card. But software allows 32 logical interfaces (31 virtual trunk and 1 port). Bringing up the 32nd log interface will result in card going into failed state.

Workaround:

Bring down the last port/trunk which was upped and reset the card. Make sure that we do not configure more than 31 log interface per card.

CSCdm15043

Symptom:

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

Conditions:

There are two conditions when this may happen:

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

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

Workaround:

Switchcc will clean up the dangling lcns.

CSCdm16904

Symptom:

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

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

Workaround:

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

CSCdm17109

Symptoms:

Software error 526 appears in the error table.

Description:

This can be caused by running certain user commands, such as dsptrkerrs. The problem occurs when the command is run on a trunk or physical line with a long address, so the address does not fit in the space available. This causes a minor alignment problem in the display.

Workaround:

The software error 526 is not an indication of any problem beyond the display misalignment. Just clear the error table.

CSCdm17582

Symptom:

"dspcmi l 2" command shows value of 0 for "CdRed Chan:" for BXM card following a graceful upgrade.

Conditions:

This is seen after a graceful upgrade from Rel. 9.1 to Rel 9.2.

Workaround:

None

Problem Description:

This will not be a service affecting problem. It is only seen in an upgrade from 9.1 to 9.2. The APS feature uses CdRed Chan and APS did not exist in Rel. 9.1 so CdRed Chan is defaulted to 0. When card redundancy is added to 2 BXM cards, the CdRed Chan is computed at that time based upon how many channels the card supports. The default value is not used for this computation.

CSCdm20480

Symptom:

Incorrect card state

Conditions:

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

Workaround:

Remove the card and plug the card back in.

CSCdm20716

Symptom:

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

Conditions:

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

Details:

VPCs may have conids that are duplicates of conids assigned to VCCs. The VPC conid space is managed separately from the VCC space. Trunk translate verification of the neighbor update message currently tries to match the trunk xlat entry from the VCC space against the con info for the VPC. This inevitably does not match, and the VCC con is rerouted. When there is no VCC con with a conid matching the VPC, no con is rerouted, though a swerr 331 occurs if the Neighbor Update Debug switch is on.

Cons appear to recover properly after the reroutes.

Workaround:

None

CSCdm22316

Symptom:

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

Conditions:

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

Workaround:

There is no workaround for this.

CSCdm23206

Symptom:

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

Condition:

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

Workaround:

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

CSCdm23489

Description:

After a graceful upgrade from 9.1 to 9.2, connections throughout the network were manually downed and then upped using the UI commands dncon and upcon. Most of these tests completed successfully. However, on one node, not all of the conns were successfully upped, and a software error 514 was logged.

Workaround:

It is not clear whether there could be a problem with either the dncon or upcon command. Use them only when necessary.

CSCdm23669

Symptom:

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

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

Workaround:

None

CSCdm24282

Symptom:

Software error 1000003 logged.

Condition: Command cnfch was executed for a BNI trunk.

Workaround:

None

CSCdm25268

Symptom:

After upgrading from 9.1 to 9.2 The feeders are in loop.

Conditions:

The problem only happens after an upgrade from 9.1 to 9.2 on a BPX/IGX node with feeder(s) attached.

Workaround:

None

CSCdm25595

Symptom:

Upon upgrade (9.1.09 to 9.2.0J) some connections were seen by the dspcons command but not seen using the dspcon command.

Conditions:

None

Workaround:

If the problem is that of dangling logical endpoints. They can be deleted by deleting and re-adding the connection

CSCdm26897

Symptom:

Free the memory for IP relay message.

Condition:

This problem is seen when Cisco Wan Manager continuously ping the SES feeder over an UXM feeder trunk. The memory allocated for these message was not free correctly.

Workaround:

The problem will not occur if there is no ping message from Cisco Wan Manager to the SES feeder.

CSCdm27681

Symptom:

YRED UXM/IMA trunk cards came up as mismatch after graceful upgrade from 9.1 to 9.2.

Conditions:

UXM cards are burned with 9.2 UXM firmware before the upgrade.

IMA compliance is a new attribute in 9.2. When the switch is gracefully upgraded to 9.2, only non YRED IMA trunk cards inherit the new attribute while the YRED pair will flag the mismatch condition.

Work Around:

Delete the YRED pair before the graceful upgrade Re-add YRED after the graceful upgrade.

CSCdm28561

Symptom:

Software error 4225, 614, 534, 612, 4208, and 3058 are logged. As mentioned in the Eng-note and Description, the 4225 error caused the rest of the errors to be logged.

Condition:

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

WorkAround:

None

CSCdm28721

Symptoms:

Software error 532 logged.

Conditions:

Run deltrk with invalid slot number between 16 and 32

Workaround:

None

CSCdm29043

Symptom:

Card error 0x25010022 appears.

Conditions:

A BXM with APS 1+1 trks/lines configured reports card errors when node rebuilds.

Work around.

None needed, should self correct, and program correctly when active card is configured.

Description: The standby card is being configured and programs the active card's card redundancy channel before that card is ready, causing card errors.

CSCdm29706

Symptom:

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

Workaround:

Delete all the connections, down the port, change the parameter, up the port, and readd all the connections.

CSCdm30018

Symptom:

The "Trunk cell routing restriction" may not be prompted for ATM connections when executing the addcon command.

Condition:

This happens only on IGX and occurs intermittently (may or may not happen).

Workaround:

If connection is being added between IGX-BPX, execute the addcon from the BPX side.

For an IGX-IGX connection, there is no workaround. The trunk cell routing restriction will be set to FALSE except for VPC connections.

CSCdm30262

Problem:

When we have vtrk up on one port and then we up a trunk (vtrk) with multiple ports grouped i.e. IMA trunk, we can add the above port and IMA port group by "cnftrk" command. This should not be allowed as the port where we upped the vtrk before upping an IMA trunk, belongs to different trunk.

Workaround:

Do not add ports in "cnftrk"-> IMA port group option, with vtrks

upped on those ports and are not part of this IMA group.

CSCdm30359

Symptom:

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

Condition:

Tried to add a dax path connection as follows:

>addcon a.b.c.* <node_name> x.y.z.*

Where a connection such as x.y.c.d already existed where c is not equal to z and d can have any value.

Workaround:

- Delete the connection x.y.c.d if possible or

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

CSCdm30608

Symptom:

Software error 55 (BAD_CD_TYPE), after using addalmslot on an ARM card. There are more subtle problems, such as line statistics not being polled / responded to properly, and other statistics related errors occurring. The database becomes corrupted for a slot (usually 4, but could be 12,20, or 28) The corruption can be seen by doing dspcmi l <slot>

Workaround:

Don't use addalmslot; or, don't use above mentioned slots. If those slots must be used, then activate the slots after addalmslot has been done.

CSCdm31674

Symptom:

In a T1 (CCS) environment, IGX cannot notify PBXs of a connection failure within the network.

Conditions:

In a T1 (CCS) environment -- in which T1 channels do not use Robbed Bit Signalling (RBS), and channels status information is conveyed between PBXs in a d-channel -- IGX cannot notify the PBXs of a connection failure within the network since the d-channel is carried transparently through the IGX network.

Workaround:

None

Further Problem Description:

In a voice E1 CCS environment, there is an super-user IGX command to handle this situation: cnfclnsigparm, option 9. If the option is enabled, IGX generates an alarm for a whole circuit lines if any channel connection in that line is failed in the IGX network.

CSCdm32384

Symptom:

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

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

Workaround:

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

CSCdm33967

Symptom:

After upgrading from 9.1 to 9.2.00 some BXM trunks go briefly into Comm Fail.

Conditions:

There is definitely a race condition here. Otherwise the rule is that a trunk s.p goes into Comm Fail, if trunk s.(p-1) exists.

Workaround:

None

Further Problem Description:

All Comm Fails are caused by data mismatches due to a change in 9.2 that moves up transparent channel programming by one channel.

CSCdm34282

Symptom:

The maximum route cost of a connection could be incorrect after a graceful upgrade from release 9.1 to 9.2.

Conditions:

This problem only happens during 9.1 to 9.2 graceful upgrade.

Work around:

Re-configure the maximum route cost of a connection by using the CLI cnfrtcost.