|
|
The 8.4.12 software release supports the existing Cisco StrataCom switch family (including the Cisco StrataCom IGX and Cisco StrataCom BPX) and introduces the following features:
Although the BCC-4 card is supported in this release, its availability is limited at this time.
If you are upgrading from an earlier version of 8.4 (8.4.08 or earlier), you MUST perform a non-graceful upgrade. See the next section.
If new BCC cards are to be installed as part of the upgrade to Release 8.4, then the physical card upgrade procedure described below must be completed as a separate activity from the Switch software upgrade.
Statistics collection must be disabled prior to and during the software upgrade process.
Before upgrading to this release, if there are any ABR connections with an MCR value set to 0, it is highly recommended that the MCR value for each of these connections be set to 1. This is to insure that the Load Module will be correct after an upgrade. This addresses a problem in earlier releases which did not handle Load Module calculations correctly for connections having MCR=0.
See the Compatibility Matrix document for the tested/supported versions of other firmware and software which work with this release.
Consult Customer Advocacy for any additional Software Upgrade procedural issues.
All BCC cards must be configured with a minimum of 32 MB of RAM.
The NPC (and the NPM) must be configured with 32 MB of RAM when used within a network of more than 63 nodes.
As specified below, the correct version of BCC boot firmware must be installed on the cards prior to a software upgrade to Release 8.4.
| BCC Type | Firmware |
|---|---|
| BCC-32 | H.B.J |
| BCC-3-32 | H.C.M |
| BCC-3-64 | H.D.M |
| BCC-4 | H.E.M |
Each redundant pair of BCC cards in a given BPX node must be of the identical type and memory configuration. That is, for example, if the active card is a BCC-3-32, then so must be the standby. BCC-3 cards with 32MB of RAM cannot be mixed with BCC-3 cards with 64MB of RAM.
This is a requirement for all software upgrade and downgrade procedures. It does not apply to the physical card upgrade procedure, as described below.
Step 1 Remove the current standby BCC front and back card.
Step 2 Replace with new BCC front and back cards.
Step 3 Wait for the standby updates on the newly installed standby BCC to complete.
Step 4 Issue a switchcc command to utilize the newly installed BCC.
Step 5 Verify that the network is stable.
Step 6 Remove the current standby BCC front and back card.
Step 7 Replace with new BCC front and back cards that are identical to the current active BCC.
Step 8 Wait for the standby updates on the newly installed standby BCC to complete.
The BCC physical upgrade is now complete.
Software upgrades have been tested from and are supported from the following versions of switch software:
Software upgrades are also supported from any earlier release in the 8.1.50, 8.1.70, and 8.2.07 switch software product streams.
Node-by-Node upgrades are supported from the following version of switch software:
During the upgrade mode, the chklm and dsplm commands are not supported. These commands should not be executed while the Node-by-Node upgrade is in progress.
During the upgrade mode, all the gateway nodes should be switched as part of the first group of nodes upgraded. If not, then software error 938 may be reported on the 8.1.50 gateway nodes. This error indicates that a large message is being sent from an 8.4 node through an 8.1.50 gateway to StrataView Plus.
No provisioning can occur while a Node-by-Node upgrade is in progress.
If a connection fails during Node-by-Node upgrade, it will not be re-routed until the upgrade process is completed.
The SNMP IPX/IGX/BPX switch SNMP MIB is being provided with the delivery of Release 8.4.00 Switch Software. The MIB is in standard ASN.1 format and is located in the ASCII text files switch.m, swtraps.m, and errors.m which are included in the same directory as the Switch Software images. These files may be compiled with most standards-based MIB compilers.
None
Virtual Trunks on any BXM cards.
The following cards are not supported in this release:
Grouped Connections are not supported, unless they existed prior to the upgrade to this release. In that case, they are carried forward as part of the upgrade. Grouped connections can no longer be created in this release. Existing grouped connections can be modified with the cnfcon command.
Priority Bumping is no longer supported.
Structured Networks are not supported.
The maximum number of ports on the BPX that can be configured with LMI enabled is 38. Note that the total number of ports is 72 (for 32MB BCC) or 100 (for 64MB BCC), although only 38 of these can have LMI enabled. This is due to the polling that must be done for the LMI enabled ports.
Virtual Path Connections with cells whose VCI values are above 4095 will be transmitted correctly if and only if the path is exclusively through BXM trunks and terminate at BXM ports.
The feature of CIR=0 for Frame Relay connections is not supported for connections terminating between FRP /FRM cards in IPX/IGX nodes and FRSM cards in an AXIS shelf.
SVC Connections are derouted after decreasing the allocated bandwidth (increasing Stat Reserve). It is the design intent that increasing the statistical reserve will cause SVC conns to derouted and not be rerouted.(See bug CSCst92308).
The FRP port does not show the FECN/BECN frames count. FECN and BECN bits are only registered on the egress port or connection, not the ingress. (See bug CSCst96096).
For the loadrev operation, it is important that the StrataView Plus/TFTP buffers are maintained at their default size.
Due to a hardware limitation, the BNI trunk will send 13 -15% more traffic than what it is configured for when the trunk is configured for less speed (cps) than the maximum port speed. This is especially important when the BNI trunk is connected to IM-ATM pairs, which carry less than T3 bandwidth.
When using the shift/no-shift feature on a BPX node's port card, controlled via the cnfport command, the other end of the connection must have the same setting. Otherwise, there will be a loss of continuity.
If using the no shift feature to utilize Virtual Trunks across a Cisco/StrataCom cloud operating an 8.1 release, then the node number "2" must either not be used, or be the node connecting to the cloud.
If using the no shift feature to utilize Virtual Trunks across a Cisco/StrataCom cloud operating any Switch Software release, then the ForeSight feature will not be utilized. In general, any connections which are routed or potentially may be routed through Virtual Trunks must not be configured with ForeSight enabled.
If the Stat Reserve field on a trunk is dramatically increased to a value which represents a significant majority of the total trunk bandwidth, then if connections are present on the trunk, the dspload command will show negative values. This is to signify that the trunk is oversubscribed. The trunk load values will eventually reach 0, or a small positive number after all the necessary connections are routed off that trunk. (CSCdi84878)
When deleting trunks, there is a known limitation with the switch software. The deltrk command should always be executed on the node which remains as part of the network, rather than from the node which ends up being removed from the network. This is to ensure that all the necessary updates are sent to the rest of the network. (CSCdi85134). Also, If the command is not used as recommended here, a software error 419 could occur (CSCdi91285).
Due to Trunk Based Loading, any commands having to do with trunk loading and the load model (dspload chklm dsplm, etc.) need to be done only after waiting a certain period of time. This time is directly a function of the trunk load update interval time (as configurable) plus the conditional update latency time.
The BXM cannot return Foresight Round Trip Delay cells. Thus, as of this release, the ForeSight adjust interval will no longer be a function of the Round Trip Delay calculation for the connection. Instead, all BXM terminated connections will use the maximum adjust interval. This affects all ForeSight endpoints on AXIS, BPX, and IGX. (CSCdi87455)
The external ABR segment control loop on ForeSight (ABRFST) is an option at the User Interface, but is not supported in hardware. The user should not enable this option on ForeSight connections (CSCdi92451). In any case, there is no coupling between the loops.
A problem has been observed, on several instances, where the time to re-route connections may take over an hour. When large numbers of connections are being re-routed, this can be caused by routing collisions, which means that routing attempts being initiated at different nodes collide when they meet a common node at which point one of the routing attempts must be rescheduled. (CSCdi89734)
On a heavily loaded BPX node, during connection re-routing, the status of a particular connection is indicated as OK even though the line status of the other end of the connection is listed as failed. The connection is in fact OK, because the conditioning of the connection (to update the status for both ends) is done by a low-priority process so that the re-routing of the connections can be given high priority. The status will be eventually updated. (CSCdj10762)
A node whose number is greater than 63 cannot have a clrcnf operation performed on it. This is as designed. A clrallcnf can be done, or the node must be renumbered before running clrcnf. (CSCdj14920)
The interface between a BXM feeder trunk and an AXIS feeder is always considered to be an NNI interface. (CSCdj16808)
The Command Line Interface currently allows a standard ABR VSVD endpoint to be configured (with cnfcon) as a non-VSVD endpoint. This should not be allowed because the BXM does not support this. This should not be attempted since it will cause connection continuity failure. (CSCdj08862)
When adding more than 4000 connections on a BPX node, the VC polling rate must be changed to a higher interval, to accommodate the additional time needed to poll for the statistics for each VC. The cnfsysparm command, parameter 24 must be changed according to the following:
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
Given a connection that terminates on an IGX FRM at one end and an ASI on the other end, tstdelay initiated at the FRM end may not work if the ASI firmware is below the appropriate revision and does not support OAM cells as opposed to supervisory cells. This is because the updated BTM on the IGX will always generate OAM cells. Please check the compatibility matrix.
The tstcon command does not work (it indicates continuity failure when it is not the case) when initiated from an FRSM card on an AXIS shelf and the path of the connection passes through an IGX node. (CSCdj23908).
Because the detailed card error event log is not retained within BRAM, this information will be lost should a processor rebuild occur. Therefore, when issuing a dspcderrs command on a particular slot, the display will not show the detailed card error information should rebuild event occur. This functionality has not been modified from previous releases.
The setnovram command can be used on BXM cards to change the number of channel statistics. If this number is set to 0 to increase the number of channels available on the card, dspchstats command will not work properly.
When a physical-layer failure (e.g., LOS) is detected, a Major Alarm is generated, and any connection routed over that port is downed (Fail state). The software sends a command to the remote end of the connection to generate AIS in the egress direction. (CSCdj30543).
Impact:
Since the connection is in a failed state, AIS is generated in the upstream direction (in addition to the downstream direction). Although this does conform to the letter of the I.610 standard, this is not necessarily what a user would expect to see, because it interferes with the RDI response from the end-to-end connection termination point. (A fault in the downstream direction causes a fault in the upstream direction.)
Reason for the current implementation:
The BNI can not generate AIS. If there is a fault at a BNI trunk, the current mechanism is to cause AIS to be generated by the BXM port by downing the connection. Since the BXM can only generate OAM cells from the RCMP, and the RCMP is in the ingress path, the cells must be backward routed to the egress (egress QE). Also, since end-to-end OAM cells are required, the ingress QE must be configured to drop ALL cells in the ingress path. This creates a break in continuity in the opposite direction, and AIS cells must also be generated at the other end of the same connection, in the upstream direction of the original fault.
Future AIS support:
There is a discussion in progress for an improvement, which will apply only to connections that are routed only over BXM trunks (or dax connections).
Two new options are added to cnfcmparm (CSCdj26583):
1) 20 Wait for TBL Updates [ 70] (100 msecs);
2) 21 Max Derouting Bndl (0=all)[ 500] (D)
When you first bring up the image through lanbtld your default values will be 100 for Wait for TBL Updates and 258 for Max Derouting Bndl. This is because some fields in CM_PARMS are being reused. The recommended values for these parameters are 70 (for option 20) and 500 (for option 21). These will be the default values if you do a clear mem or upgrade to 8.4.1. If you don't want this new feature:
1) set option 20 to 0
2) set option 21 to 0 (which means all connections)
These parameters are used for:
1) Wait for TBL Updates will delay failing the connection if it fails to find a path due to no load and no conid available. This delay allows TBL updates to be processed. This value should always be greater than the cnftlparm Fast Interval interval. This will clear some PVC's going in and out of alarm.
2) Max Derouting Bndl works like Maximum Routing Bundle, except it's for the derouting case. Currently we go and deroute all 12,000 connections at one time without giving up the process to handle TBL updates, and other tasks. This value will allow us to deroute x number of connections at a time, then go and try to route. Do remember that as this number goes up, the table updates takes a little longer to be sent out, since the node is busy derouting.
There are problems in the downgrade mechanism which can cause database corruption. If downgrade is performed immediately after upgrading, the Stby_Info revision fields are not yet filled in on the new active CC. They don't get filled in until the upcard response from the new locked CC. This causes restart instead of a switchcc. If the locked CC is reset, then downgrade immediately, a restart will occur instead of a switchcc. (CSCdj30811).
During a conditional upgrade or downgrade in the network that has more than 20 nodes, there is a likelihood for some nodes to receive all the updates before receiving the revision change message (to upgrade/downgrade). Since the standby had the update capacity of approximately only 10 mesg/sec, it may take over 3 seconds for these nodes to finish these updates. The revision change update may not be properly delivered to the standby, and thus causes non-graceful upgrade to occurred on these nodes. (CSCdj32054).
In order to test/simulate the Y-redundant switchover of ASI T3 or E3 pairs the resetcd command must be used, or by pulling out the active card. It will not be correctly simulated by doing a dncd (downcard) on the active card. Using dncd will cause cell discards. (CSCdj08923).
In certain conditions where memory is exhausted, an Abort 3000000 can occur, which is fully recoverable. This is due to an accumulation of memory in the telnet process, and the root cause is the improperly terminated telnet sessions that were originated from a StrataView Plus workstation. To prevent this condition from occurring, exit all SV+ telnet sessions correctly by using the CTRL-] key chord and then typing q. (CSCdi92256).
BXM cards can support 32K PVCs only when no stats are collected. If collecting 4 stats per PVC is desired, the number of PVCs per BXM card drops to 16K. (CSCdj31773).
When connection status logging to StrataView Plus is enabled in the switch (via the cnffunc command), when more than 1500 PVC's exist on a node, an event log entry indicating there is a "comm break on flooding" may occur. This is because the network handler is being flooded with messages due to the per-PVC status updates flowing to the StrataView Plus workstation. This is a recoverable situation. However, PVC status may not be available for all connections. (CSCdj36127)
It is not recommended to combine ABR and UBR PVC's on the same network. ABR and UBR PVC's share the same QBIN (Class of Service Queue) on the BXM card. However, ABR (VSVD) uses a flow control mechanism which ensures that the traffic source slows down when the QBIN usage exceeds the EFCI threshold. However, UBR does not have a mechanism to slow down. Thus, UBR traffic gains an unfair advantage over ABR. This implementation is not considered a problem, since the decision to share a QBIN for ABR and UBR traffic was intentional, since any best-effort service that one would route over UBR can be routed over ABR (VSVD), with the additional benefit of protecting resources in the network. If there is a real requirement to use UBR PVC's instead of ABR (VSVD), then either (1) add all best-effort PVC's as UBR, or (2) isolate the ABR and UBR paths by using cnfpref and separating ABR and UBR endpoints.
Combining FBTC and non-FBTC connections within a Class of Service can cause FBTC connections to not receive a fair share of bandwidth. For example, if VBR connections are added at a terminating port, and some of these VBR connections have FBTC enabled while other VBR connections have FBTC disabled, the VBR connections with FBTC disabled may obtain all of the excess bandwidth before the connections with FBTC enabled receive any of the excess bandwidth. The same holds true for ABR or UBR connections. This only is relevant where FBTC and non-FBTC connections share a QBIN, either at a port or at a trunk.
If a TFTP download has been started, and a fault occurs in the network that interrupts the download, then it is possible to get an software error 513 logged into the software error table. This occurs when there is an attempt to free a memory block that has not been allocated. There is no negative side effect to this attempt, other than the appearance of the error in the table. (CSCdj45311).
There is a problem with node renumbering. Node renumbering (the rnmnd command) should be executed only during a stable network environment and only if absolutely necessary. A stable network environment would be, for example, one in which no connection was added for the past 30 minutes and no topology change was made in the last hour and there are no alarms or node unreachabilities. Node renumbering must only be done when the network is stable to reduce the possibility of certain temporarily blocked messages during the node renumbering process being delivered to the wrong nodes. This would occur after the completion of the node renumbering process.
The settling time for network wide updates can take a long time in certain situations. Specifically, the settling time for updates due to network wide topology changes and connections in a large network when a processor switchover occurs can take a long time. The time is proportional to the number of nodes as well as the number of connections. A general estimate would be 30 seconds per node. During the period of transitions (when the updates are occurring) some network operations such as adding connections might in some cases take somewhat longer to complete.
When using StrataView Plus, there could be a problem with communicating with a node that just had a processor switchover. The problem is within the SPARCstation itself and its caching of EtherNet addresses. It can be solved by execution the following command on the workstation as the superuser: # arp -d <node_name>
Users may not use the command addcon slot.1-24 v to add 24 voice connections to a CDP at once. Instead, they must separate this activity into two or more commands, so that no more than 16 connections are added at once. This is only an issue for voice connections. Data connections can be added using the "1-24" syntax. This also applies when the CDP circuit line is an E1, in which case "1-32" would apply. (CSCdj14319)
After a Node-by-Node upgrade, it has been observed that Load Model inconsistencies may exist on BPX nodes. User should check the current load value. If the load value for MCR=0 is zero, then the MCR value should be changed to MCR=1 before upgrading to 8.4. (CSCdj35064).
Statistics collection must be disabled prior to the start of an upgrade.
Statistics sampling must be disabled prior to the start of an upgrade (using off1/off2).
Care must be taken when changing the Deroute Delay parameter, which is controlled by the cnftrk command. This defaults to zero, but if set to anything but zero, connection re-routing, due to a trunk failure, will be delayed as provided by the parameter.
When a switchcc is executed on a BPX configured with two BCC-4 cards and contains a BXM-622 trunk card, there may be a bad clock path problem reported. It is indicated as a Minor Alarm - bad clock path. This is a transitory problem, although the alarm indication persists. To clear this, execute the clrclkalm command.
When the last trunk to a node is deleted and it has 2500+ connections, it will cause software errors 1000's and 590's. This can be avoided by first deleting all connections across the trunk before deleting the trunk. If the problem occurs a switch over or rebuild will clean up the node. (CSCdj25075).
The software error occurs 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.
Note: These connections do not have to terminate at the two nodes directly connected to the deleted trunk. The trunk being deleted could be connecting two subnets. If those 2500+ connections are on one node in either of the subnets then this problem can occur. If these 2500+ connections are spread about different nodes in the connected subnets there should not be a problem.
EFFECT: Not all connections that should be deleted will be deleted. In addition, memory leak may occur.
WORKAROUND: Prior to deleting the last trunk to a node, determine the connections going across the trunk and manually delete them first.
CLEANUP: If software errors 1000's and 590's are received because the last trunk on the node was deleted AND that trunk had 2500+ connections routed across it. The problem can be cleaned up by:
1) Clear the active CC's software log.
2) Check then clear the standby CC's software log.
3) switchcc
If the network does not have a redundant CC then rebuild the active CC by doing the following:
Clear the active CC's software log.
resetcd
For grouped connections, if and when all connections of a group are deleted, then the connection group itself should be deleted as soon as possible to avoid any possible side effects that could potentially be caused by having empty connection groups. (CSCdj47562)
Prior to Release 8.1.70, with regards to statistics collection, any time period was allowed to be a peak interval. However, those peaks were not gathered correctly. In this release, the peak intervals are controlled to be only those values for which peaks can be accurately collected The rules for peak intervals are as follows:
There are additional commands to control trunk and line loopbacks in this release:
See the Compatibility Matrix document, which is included in this release package.
This release will run with any AXIS Release 4.0.0x, 3.0.x, and 2.1.x
The following is the list of known anomalies in this Switch Software delivery..
| Bug ID | Descriptions |
|---|---|
| CSCdj55787 | When downloading software to a BPX node via loadrev command, the BCC cards may stay in downloader state without responses. User may need to clear the condition with the resetcd command. |
| CSCdj54902 | The CVM card is not returning channels to idle 54h when the connections have been deleted. |
| CSCdj55993 | The addyred command erroneously allows the user to use an active BXM card as the YRED Secondary card. This should not be allowed since the Y-RED Secondary card is required to be in Standby state when the addyred command is executed. This may happen when one of the BXM's is a trunk card and the other BXM card is a line card. This is not a problem for BNI and ASI cards. Symptoms of this problem include loss of continuity on one or both active BXM's, and software error 21 may appear in the dspswlog command. Workaround: Recommend issuing the commands delyred and switchcc to restore database values. |
| CSCdj54601 | Timeout failure occurred for ATFR connections made through virtual trunk when issuing the tstdelay command |
| CSCdj54507 | Timeout failure occurred for BXM-FRSM PVCs when issuing the tstdelay command. |
| CSCdj55305 | During the BNI/ASI Firmware upgrade to TCK, Comm Breaks occurred on BPX nodes after BCC switch over and started to clear immediately. It was noted that there was a node rebuild in the network at the time which lasted for approximately 55 minutes. |
| CSCdj54495 | Resetting a BXM trunk card on a BPX node causes lots of PVC to receive fail status and being rerouted. It was noted that ILMI failure also occurred on the neighbor slot with BXM line card installed. |
| CSCdj52767 | Software abort 1000003 occurred during VNS Bulk Calls testing. |
| CSCdj52769 | Software error 4208 occurred during VNS Bulk Calls testing. |
| CSCdj52771 | Software error 2064 occurred during VNS bulk call testing. |
| CSCdj50288 | BXM clock path error on BPX node. |
| CSCdj53625 | Upgrading from release 8.2.xx to release 8.4.11 may necessitate re-routing of the "path" connections and data discontinuity on some connections. |
| CSCdj47955 | Software abort 1000003 occurs on a BPX node running switch software release 8.4.11 after inserting and replacing BXM cards on the node. |
| CSCdj49422 | It was noted that on an IPX node, the slave dsi for a voice connection is different from the master dsi. |
| CSCdj49647 | Software error 3000000 and 3000000 abort occurred on an IGX node during VNS bulk call testing. |
| CSCdj30407 | BXM receives 'card errors' status when card change status from standby to active. |
| CSCdj32601 | On a BPX node running switch software release 8.4.07, it appears that no slot errors have been collected when the cards was in the standby state. The slot errors appears later after the card is brought to active from the standby state. |
| CSCdj43344 | On a BPX node running switch software release 8.4.09 (and/or 8.4.10) with BXM firmware revision MBM/MBR, it was observed that the port LED stop reporting line errors/alarms when the port number exceeds 100. The LEDs would stay green even if there were no signal inputs (no loop back cable). This problem occurred on BXM-E3/T3. |
| CSCdj45984 | In a network running regression test for switch software release 8.4, it was noted that communication failure occurred on one of the two virtual trunks connected to a BPX node in the network. The failure occurred for a few hours, but later recovered/cleared itself, and the failure condition disappeared. |
| CSCdj48107 | The ESP object message needs to be sent to SV+ whenever the ESP status changes. |
| CSCdj36307 | A BPX node received a network message with a bad function code (software error 104). This condition is recoverable since the incorrect message will not be acknowledged and thus re-transmitted. |
| CSCdj35556 | On a BPX node with a large number of connections, when a switchcc is issued, the control console communication with that node will be interrupted for a certain length of time, up to 10 minutes. During this time, there is no loss of continuity. Also, if a non-redundant BXM port card is reset, control console communication will also be interrupted. In this case, continuity for connections terminating on that BXM is interrupted. |
| CSCdj33896 | No warning is given when the maximum number PVC is reached on a given trunk. When a cnftrk command is issued for a given trunk, the local end can support the new max PVC number, but the remote end cannot. Workaround: Use the cnftrk command on the remote node (for the same trunk) to determine the maximum permissible value (it will be the lower value of the two nodes). |
| CSCdj03022 | When performing a upgrade from 8.1.70 to 8.4.00, it was observed after the loadrev command was issued, one of the BPX nodes remained in the Loaded state. When a dspstby is done, all states are in the clear state. This is not readily reproducible. |
| CSCdj33985 | Software error 445 occurred on a BPX node. |
| CSCdj34226 | Software error 532 will occur when a dspcons command is executed while SVC's or PVC's are being added or deleted from a VNS station. |
| CSCdj08657 | During a Node-by-Node upgrade, after the switch -g command was executed, a software error 938 (an error from the pSOS pNA facility) was logged. This does not adversely affect the upgrade. Workaround: Use the rrtcon command for the failed connections so that they will be routed again, which will correct the problem. |
| CSCdj39811 | On BXM port cards, unfairness and tail discards can exist due to the non-optimal settings of the QBIN, VI, and VC threshold values. |
| CSCdj41103 | After a runrev to the current release is executed, some of the nodes, via the dsprev command may report an older, incorrect version of software running. In actuality, the correct software is running on the node. |
| CSCdj36589 | In some circumstances, after a Node-by-Node upgrade was completed, load model inconsistencies were detected via the dsplm command. |
| CSCdj41235 | The self-test for the BCC-4 processor card may fail in certain (unknown) circumstances. In the observed case, there were 2 failures in 596 passes. This may not necessarily indicate that the card is defective. |
| CSCdj41899 | It was observed during the provisioning of an FRP-ASI connection segment through StrataView Plus that the SNMP agent returned an error indicating that there is a shift-mode mismatch on the ASI card. |
| CSCdj42027 | During stress testing of the VNS application, an Abort 1000003 occurred. This is due to a race condition, which will be fixed in a future release. |
| CSCdj41731 | It was observed on a BPX node with about 5000 terminating connections and about 12000 via connections which was in the process of re-routing connections and performing a switchcc, that all memory was exhausted such that software errors 501, 977, and 3000000 were logged. This was a recoverable situation. |
The following conditions have been corrected with the 8.4.15 version of the software release. In addition, all corrections applied to previous 8.4 releases are included in this release.
| Bug ID | Descriptions |
|---|---|
| CSCdj46387 | IPX IGX BPX werr 129 occasionally is logged A task was in the process of logging a software error when it was interrupted by a higher priority task that logged a software error. This race condition can lead to corruption of the software error table. |
| CSCdj46406 | BPX ASI-T3 Remains on OOF after line failure If two ASI lines are connected each other and the line between them is broken and then remade, the line remains in OOF. |
| CSCdj46536 | IPX IGX SWSW not adding connections when requested by VNS SNMP will now record error descriptions (in the strmErrors table) when an SNMP request for a voice SVC is rejected by the embedded agent. |
| CSCdj49377 | BPX dspportstats become unexecutable after switchcc The dspportstats did not operate as expected after a switchcc and instead of displaying the correct information, the message "specified port already being monitored" was shown on the screen. This happened only if the port was being monitored by the dspportstats command at the time that the switchcc occurred. |
| CSCdj49422 | IPX IGX A voice connection goes to lu (load unit) inconsistent It was noted that on an IPX node, the slave dsi for a voice connection is different from the master dsi. |
| CSCdj50010 | IPX IGX BPX Potential for using an uninitialized local in routine free_vc_sib() An uninitialized variable could possibly be used in an internal routine, and potentially create problems. Some of the possible symptoms are software error 2051 being logged, the Tftp_File_Size is incorrect and the SV+ complains that the file is not parseable. |
| CSCdj50106 | IPX IGX BPX Optimization for clock routing A Clock Routing Simulator has been created that can run on UNIX workstations to analyze clock routing performance. |
| CSCdj54902 | IGX SVC connections do not return the timeslots to idle 54h on deletion The CVM card is not returning channels to idle 54h when the connections have been deleted. This leaves the timeslot in an uncertain state with varying levels of noise. |
| CSCdj55384 | Error 514 while deleting/adding conns through SNMP Software error 514 (from Free_mem call, overwrote block) occured while deleting and adding connections through SNMP. |
| CSCdj56223 | BPX BNI-OC3s generate lots of invalid port errors. The BNI-OC3 generates lots of rx invalid port errors, causing major alarms when the errors are counted. |
| CSCdj57674 | IPX IGX 1M3 abort after clrallcnf in VNS SVC calls. After the command clrallcnf is issued, the establishment of a VNS SVC call could cause the switch to reset. |
| CSCdj57783 | IPX IGX BPX Conns not routed after ungraceful upgrade. After an ungraceful upgrade the constats command reported that some FRP connections were deleted. In addition, dspcons showed that conns are gone. The dcct showed that the conns are still there. SWERRs 384 were being logged continuously. |
| CSCdj64355 | BPX 8.1.72 -> 8.4.12 dspcon shows atm values = 0, dspcons shows type field blank After an upgrade from 8.1.7x to 8.4 some connections would show zero(0) values in all fields of the VC BW Params.
|
The following conditions have been corrected with the 8.4.14 version of the software release. In addition, all corrections applied to previous 8.4 releases are included in this release.
| Bug ID | Descriptions |
|---|---|
| CSCdj47955 | Software abort 1000003 occurs on a BPX node running switch software release 8.4.11 after inserting and replacing BXM cards on the node. |
| CSCdj49422 | It was noted that on an IPX node, the slave dsi for a voice connection is different from the master dsi. |
| CSCdj50812 | Voice connections using ADPCM do not upgrade to fast modem. The connection can pass voice calls normally until a Fast Modem type connection is attempted. At that point, the connection upgrades to Fast Modem mode but does not allow the modems to sync up. After the modems go back on-hook, the connection remains in the Fast Modem state (use "dspconst" command to see this) and can no longer pass voice for some time. |
| CSCdj49647 | Software error 3000000 and 3000000 abort occurred on an IGX node during VNS bulk call testing. |
| CSCdj30407 | BXM receives 'card errors' status when card change status from standby to active. |
| CSCdj32601 | On a BPX node running switch software release 8.4.07, it appears that no slot errors have been collected when the cards was in the standby state. The slot errors appears later after the card is brought to active from the standby state. |
| CSCdj43344 | On a BPX node running switch software release 8.4.09 (and/or 8.4.10) with BXM firmware revision MBM/MBR, it was observed that the port LED stop reporting line errors/alarms when the port number exceeds 100. The LEDs would stay green even if there were no signal inputs (no loop back cable). This problem occurred on BXM-E3/T3. |
| CSCdj45984 | In a network running regression test for switch software release 8.4, it was noted that communication failure occurred on one of the two virtual trunks connected to a BPX node in the network. The failure occurred for a few hours, but later recovered/cleared itself, and the failure condition disappeared. |
| CSCdj48107 | The ESP object message needs to be sent to SV+ whenever the ESP status changes. |
| CSCdj35108 | During a Node-by-Node upgrade, one node went into a non-graceful upgrade. |
| CSCdj36307 | A BPX node received a network message with a bad function code (software error 104). This condition is recoverable since the incorrect message will not be acknowledged and thus re-transmitted.. |
| CSCdj35556 | On a BPX node with a large number of connections, when a switchcc is issued, the control console communication with that node will be interrupted for a certain length of time, up to 10 minutes. During this time, there is no loss of continuity. Also, if a non-redundant BXM port card is reset, control console communication will also be interrupted. In this case, continuity for connections terminating on that BXM is interrupted. |
| CSCdj33896 | No warning is given when the maximum number PVC is reached on a given trunk. When a cnftrk command is issued for a given trunk, the local end can support the new max PVC number, but the remote end cannot. Workaround: Use the cnftrk command on the remote node (for the same trunk) to determine the maximum permissible value (it will be the lower value of the two nodes). |
| CSCdj03022 | When performing a upgrade from 8.1.70 to 8.4.00, it was observed after the loadrev command was issued, one of the BPX nodes remained in the Loaded state. When a dspstby is done, all states are in the clear state. This is not readily reproducible. |
| CSCdj33985 | Software error 445 occurred on a BPX node. |
| CSCdj34226 | Software error 532 will occur when a dspcons command is executed while SVC's or PVC's are being added or deleted from a VNS station. |
| CSCdj08657 | During a Node-by-Node upgrade, after the switch -g command was executed, a software error 938 (an error from the pSOS pNA facility) was logged. This does not adversely affect the upgrade. Workaround: Use the rrtcon command for the failed connections so that they will be routed again, which will correct the problem. |
| CSCdj39811 | On BXM port cards, unfairness and tail discards can exist due to the non-optimal settings of the QBIN, VI, and VC threshold values. |
| CSCdj41103 | After a runrev to the current release is executed, some of the nodes, via the dsprev command may report an older, incorrect version of software running. In actuality, the correct software is running on the node. |
| CSCdj41517 | Software error 21 was observed at an IGX routing node both before and after a non-graceful upgrade from 8.2.04 to the 8.4 release. This did not result in any service outages. |
| CSCdj41077 | After invoking a switchcc from a BCC-3 card in slot 7 to a BCC-4 card in slot 8, it was observed that connection continuity was interrupted for 40 minutes, as most of the existing trunks were in Communication Failure. |
| CSCdj36589 | In some circumstances, after a Node-by-Node upgrade was completed, load model inconsistencies were detected via the dsplm command. |
| CSCdj41231 | The background test for the BXM (port) card fails frequently. This is not necessarily an indication that the BXM card is defective. |
| CSCdj41235 | The self-test for the BCC-4 processor card may fail in certain (unknown) circumstances. In the observed case, there were 2 failures in 596 passes. This may not necessarily indicate that the card is defective. |
| CSCdj41899 | It was observed during the provisioning of an FRP-ASI connection segment through StrataView Plus that the SNMP agent returned an error indicating that there is a shift-mode mismatch on the ASI card. |
| CSCdj42027 | During stress testing of the VNS application, an Abort 1000003 occurred. This is due to a race condition, which will be fixed in a future release. |
| CSCdj41731 | It was observed on a BPX node with about 5000 terminating connections and about 12000 via connections which was in the process of re-routing connections and performing a switchcc, that all memory was exhausted such that software errors 501, 977, and 3000000 were logged. This was a recoverable situation. |
| CSCdj32544 | It has been observed in one particular node that the name of the BCC card was listed as "ASM" rather than "BCC". This did not affect the operation of the switch. |
| CSCdj35108 | During a Node-by-Node upgrade, one node went into a non-graceful upgrade. |
| CSCdj36307 | A BPX node received a network message with a bad function code (software error 104). This condition is recoverable since the incorrect message will not be acknowledged and thus re-transmitted. |
| CSCdj35064 | |
| CSCdj36589 | After a Node-by-Node upgrade, it has been observed that Load Model inconsistencies may exist on BPX nodes. |
| CSCdj35556 | On a BPX node with a large number of connections, when a switchcc is issued, the control console communication with that node will be interrupted for a certain length of time, up to 10 minutes. During this time, there is no loss of continuity. Also, if a non-redundant BXM port card is reset, control console communication will also be interrupted. In this case, continuity for connections terminating on that BXM is interrupted. |
| CSCdj33896 | No warning is given when the maximum number PVC is reached on a given trunk. When a cnftrk command is issued for a given trunk, the local end can support the new max PVC number, but the remote end cannot. Workaround: Use the cnftrk command on the remote node (for the same trunk) to determine the maximum permissible value (it will be the lower value of the two nodes). |
| CSCdj03022 | When performing a upgrade from 8.1.70 to 8.4.00, it was observed after the loadrev command was issued, one of the BPX nodes remained in the Loaded state. When a dspstby is done, all states are in the clear state. This is not readily reproducible. |
| CSCdj33985 | Software error 445 occurred on a BPX node. |
| CSCdj34226 | Software error 532 will occur when a dspcons command is executed while SVC's or PVC's are being added or deleted from a VNS station. |
| CSCdj08657 | During a Node-by-Node upgrade, after the switch -g command was executed, a software error 938 (an error from the pSOS pNA facility) was logged. This does not adversely affect the upgrade. Workaround: Use the rrtcon command for the failed connections so that they will be routed again, which will correct the problem. |
| CSCdj39811 | On BXM port cards, unfairness and tail discards can exist due to the non-optimal settings of the QBIN, VI, and VC threshold values. |
| CSCdj37871 | |
| CSCdj41103 | After a runrev to the current release is executed, some of the nodes, via the dsprev command may report an older, incorrect version of software running. In actuality, the correct software is running on the node. |
| CSCdj40779 | If a telnet session to the Command Line Interface is terminated abnormally, by not using the bye command to return to the Enter User ID prompt before disconnecting using Control-] chord, then a portion of system memory will be lost (not returned to free memory pool). |
| CSCdj41517 | Software error 21 was observed at an IGX routing node both before and after a non-graceful upgrade from 8.2.04 to the 8.4 release. This did not result in any service outages. |
| CSCdj39412 | On IGX and IPX nodes, the cnfpref command will not correctly recognize trunk specifications which include a virtual trunk number that is two digits in length. That is, for example, using "13.2.31/bpx4" will not work. |
| CSCdj41077 | After invoking a switchcc from a BCC-3 card in slot 7 to a BCC-4 card in slot 8, it was observed that connection continuity was interrupted for 40 minutes, as most of the existing trunks were in Communication Failure. |
| CSCdj36589 | In some circumstances, after a Node-by-Node upgrade was completed, load model inconsistencies were detected via the dsplm command. |
| CSCdj41231 | The background test for the BXM (port) card fails frequently. This is not necessarily an indication that the BXM card is defective. |
| CSCdj41235 | The self-test for the BCC-4 processor card may fail in certain (unknown) circumstances. In the observed case, there were 2 failures in 596 passes. This may not necessarily indicate that the card is defective. |
| CSCdj41899 | It was observed during the provisioning of an FRP-ASI connection segment through StrataView Plus that the SNMP agent returned an error indicating that there is a shift-mode mismatch on the ASI card. |
| CSCdj42027 | During stress testing of the VNS application, an Abort 1000003 occurred. This is due to a race condition, which will be fixed in a future release. |
| CSCdj41731 | It was observed on a BPX node with about 5000 terminating connections and about 12000 via connections which was in the process of re-routing connections and performing a switchcc, that all memory was exhausted such that software errors 501, 977, and 3000000 were logged. This was a recoverable situation. |
| CSCdj32544 | It has been observed in one particular node that the name of the BCC card was listed as "ASM" rather than "BCC". This did not affect the operation of the switch. |
| CSCdj24325 | BPX Slot errors are not collected on BNI-OC3 and ASI-OC3 The dspslotalms command did not show if there were any slot errors on BNI-OC3 or ASI-OC3 cards because these errors were not being accumulated. |
| CSCdj34069 | IGX SWERR 532 upon switchcc on IGX routing node A software error 532 (Bad logical card index) was logged on an IGX routing node after a switchcc. |
| CSCdj34168 | IPX IGX BPX Idle time for fail handler is too high The internal FAIL handler has been optimized and the percentage of processor time that it requires has been reduced. |
| CSCdj34220 | IPX IGX sw err 4208 logged when deleting PVCs/SVCs on VNS startup. A VNS was restarted after a non-graceful exit. During the restart and the normal deletion of PVCs and SVCs, a software error 4208 was logged. |
| CSCdj34754 | IPX IGX BPX Nodes take upto 10 min. to revert to ckt line clk srcs after clearing LOS When the Circuit Line clock source on which an LOS is created is on the highest numbered node, it could take upto 10 minutes to switch back to the source on clearing the LOS. |
| CSCdj37700 | IPX IGX BPX Takes too long to add/del an object when stats are enabled Adding a single connections locked the user interface up for a minute or more when there were 1000 or more connections, with several connection stats enabled. |
| CSCdj38564 | BPX After switchcc, event log shows an extra unnecessary bxm inserted event. After a switchcc command was executed on a BPX with BXM cards, the log would have an unnecessary informational message stating that a BXM backcard had been inserted and activated. |
| CSCdj38922 | BPX No continuity after adding a connection 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. |
| CSCdj41999 | BPX T3/E3 back cards mismatch with ASI card T3-3 and E3-3 backcards were not interchangable between ASI and BNI frontcards (this has been the case since the introduction of these cards). The ASI T3/E3 frontcards will now support these backcards |
| CSCdj42027 | IPX IGX VNS Bulk Calls causes SWSW abort During stress testing of the VNS a race condition occurred that resulted in a 1000003 abort. |
| CSCdj42841 | IPX IGX BPX ASM events are reported only to local StrataViews. Event log messages related to the ASM, such as power supply failures and temperature alarms, are logged to locally attached (link0) StrataViews, but are not broadcast to remote nodes that have StrataViews. |
| CSCdj43705 | BPX cnfchstats on daxcon shows wrong stats When the cnfchstats command was executed on the "other end" of a dax connection that terminated on two different cards (BXM and ASI), the statistics where shown for "this end" of the connection. For example, on a connection originating on an ASI and terminating on a BXM within the same node, cnfchstats on the BXM ("other end") endpoint of the connection would show the data from the ASI ("this end") endpoint of the connection. |
| CSCdj46114 | IPX IGX BPX Expensive inserts in add_lcn_sorted() affecting SWITCHCC performance One of the functions performed during a switchcc has been optimized to improve the time required to complete the switchover |
| CSCdj46124 | IPX IGX BPX For VPC conn, if no VPC conid available, other conns will not get routed If routing chose a path which had the shortest hops, but no available VPC conids, the routing attempt failed. The failure did not increment the failure wait count to allow other connections to route. Every time candidate selection ran, the VPC connection was chosen, and the same invalid route was chosen. Other connections waiting to route would never be routed. |
The following conditions have been corrected with the 8.4.13 version of the software release. In addition, all corrections applied to previous 8.4 releases are included in this release.
| Bug ID | Descriptions |
|---|---|
| CSCdj52187 | After upgrading from 8.1.50 to 8.4.11, some connections were found to lose data. On BPX trunks, line stat sampling was turned on and the "cell header mismatch" error was discovered on some trunks. |
| CSCdj52353 | It was observed that if a DACS connection uses LCN 255 on the trunk then the connection will not route traffic properly. |
| CSCdj50311 | Users are allowed to add more connections on a BXM feeder than it have been configured using the cnftrk command. |
| CSCdj50812 | Voice connections using ADPCM will not upgrade to Fast Modem mode while running release 8.4.07 or 8.4.09. |
The following conditions have been corrected with the 8.4.12 version of the software release. In addition, all corrections applied to previous 8.4 releases are included in this release.
| Bug ID | Descriptions |
|---|---|
| CSCdj46535 | When upgrading IPX feeder node from release 8.4.10 to 8.4.11, the nodename changes from what it was under 8.4.10 to NODENAME. Multiple software errors occurred on the standby NPC card running release 8.4.11. |
| CSCdj44714 | An error message indicating 'RIF cannot exceed the peak 50' was received when attempting to modify FR-FR PVCs that don't have RIF parameter. |
| CSCdj44718 | The trap for BCC restart is not generated with right status, severity and reason code. |
| CSCdj38335 | Invoking the nwupgrade switch command can cause the node to downgrade unexpectedly. |
| CSCdj40779 | If a telnet session to the Command Line Interface is terminated abnormally, by not using the bye command to return to the Enter User ID prompt before disconnecting using Control-] chord, then a portion of system memory will be lost (not returned to free memory pool). |
| CSCdj38707 | Executing Node-by-Node upgrade process from software release 8.1.50 to release 8.4.09 resulted in a node unreachability. |
| CSCdj32054 | In a large network containing more than 20 nodes, it is likely that some nodes may take more than three seconds to finish processing the standby update messages during a flash upgrade and thus causing further delay when the command 'runrev *' is issued. |
| CSCdj42590 | Data discontinuity observed on connections that are routed over a BNI virtual trunk. |
| CSCdj32603 | BXM generates AIS(end-end) for both upstream and downstream when it detects LOS,LOF,LOC, etc. According to the standard, it should generate AIS only for downstream. Generating AIS also for upstream could cause the misbehavior of the whole alarm transmission system. |
| CSCdj43640 | Comm failure occurs when issuing the command, dsplmistats |
| CSCdj42923 | Software error 123 occurs on a BPX node when a neighbor feeder trunk is in a 'in-and out of alarm' state. |
| CSCdj42511 | When invoking the tstdelay command, an error message occurs stating that tstdelay is not valid at trunk end point. |
| CSCdj27210 | The tstber command does not work properly when running switch software release 8.4. The tstber is a vital diagnostic command. It is also used by manufacturing for verification of several important BCC functions. |
The following conditions have been corrected with the 8.4.10 version of the software release. In addition, all corrections applied to previous 8.4 releases are included in this release.
| Bug ID | Descriptions |
|---|---|
| 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. |
The following conditions have been corrected with the 8.4.09 version of the software release. In addition, all corrections applied to previous 8.4 releases are included in this release.
| Bug ID | Descriptions |
|---|---|
| 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. |
The following conditions have been corrected with the 8.4.08 version of the software release. In addition, all corrections applied to previous 8.4 releases are included in this release.
| Bug ID | Descriptions |
|---|---|
| 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 stay at DnLder status after switchcc and can only be recovered by removing and putting back the card to 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. |
| Bug ID | Descriptions |
|---|---|
| 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. |
| Bug ID | Descriptions |
|---|---|
| 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. |
| Bug ID | Descriptions |
|---|---|
| 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. |
| Bug ID | Descriptions |
|---|---|
| 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. |
| Bug ID | Descriptions |
|---|---|
| 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. |
| PCB Description | Rev. | Latest F/W | Minimum F/W |
|---|---|---|---|
| IMATM F/W | C | 4.0.05 | 4.0.04 |
| IMATM Boot | N/A | 4.0.00 | 4.0.00 |
| ASC F/W | M | 4.0.05 | 4.0.04 |
| ASC Boot | N/A | 4.0.03 | 4.0.03 |
| BNM-E3 | B | N/A | N/A |
| FRSM-4T1 | C | 4.0.05 | 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.05 | 4.0.04 |
| CESM Boot | N/A | 4.0.00 | 4.0.00 |
| AUSM-4T1E1 | B | 4.0.05 | 4.0.04 |
| AUSM Boot | N/A | 4.0.00 | 4.0.00 |
| FRSM-8T1 | A | 4.0.05 | 4.0.04 |
| FRSM-8T1 Boot | N/A | 4.0.00 | 4.0.00 |
| FRSM-HS1 | A | 4.0.05 | 4.0.04 |
| FRSM-HS1 Boot | N/A | 4.0.00 | 4.0.00 |
| AUSM-8T1/E1 | A | 4.0.05 | 4.0.04 |
| AUSM-8T1/E1 Boot | N/A | 4.0.00 | 4.0.00 |
| PCB Description | Rev. | Latest F/W | Minimum F/W |
|---|---|---|---|
| BCC (model B) boot | K | HBJ | HBH |
| BCC3-32 (model C) boot | K | HCM | HCH |
| BCC3-64 (model D) boot | K | HDM | HDJ |
| BCC4 (model E) boot | K | HEM | HEM |
| PCB Description | Rev. | Latest F/W | Minimum F/W |
|---|---|---|---|
| ASI 155 | EOL | WHB | WHB |
| ASI 155 E | E | WEB | WEB |
| ASI-1 2T3/C | D | UCC | UCA |
| ASI-1 2T3/B | D | UBJ | UBH |
| BNI 3T3/C | F | TCL | TCK |
| BNI 3E3/B | F | TCL | TCK |
| BNI 155 E | E | VDN | VDN |
| BNI I55 | EOL | VBN | VBN |
| ASM | B | GAC | GAC |
| BXM 4P | A | MBT | MBM |
| BXM 8P | A | MBT | MBM |
| PCB Description | Latest F/W | Minimum F/W | Comments |
|---|---|---|---|
| NPC Boot | BAF | BAF | |
| NPC 32 Boot | BBF | BBF | |
| NPC64 Boot | BCF | BCF | |
| NPM Boot | RAN | RAN | |
| NPM 32 Boot | RBN | RBN | |
| NPM 64 Boot | RCN | RCJ | |
| NPM 32B Boot | REN | REJ | |
| NPM 64B Boot | RFN | RFN |
| PCB Description | Latest F/W | Minimum F/W | Comments |
|---|---|---|---|
| ALM-A | CAB | CAA | |
| ALM-B | CBD | CBB | |
| BTM Model A | IAF | IAE | |
| BTM Model B | IBK | IBF | |
| BTM Model D | IDA | IDA | |
| CVM Model A | DAF | DAF | |
| CVM Model B | DBC | DBC | |
| CVM Model C | DCA | DCA | |
| FRM Model D | FDX | FDR | Avoid Rev. FDU & FDV |
| FRM Model E | FEX | FER | Avoid Rev. FEU & FEV |
| FRM (B) | FHB | FHB | |
| FRM-2 | FFD | FFC | |
| FTM Model B | JBF | JBB | |
| FTM Model C | JCA | JCA | |
| HDM | SCF | SCF | |
| LDM | LC3 | LC3 | |
| NTM | NEJ | NED | |
| NTM (B) | NFF | NFD | Recommend using NFF |
| AIT Model A | IAF | IAE | |
| AIT Model B | IBL | IBK | |
| CDP Model A | DAF | DAF | |
| CDP Model B | DBC | DBC | |
| FRP(M) Model D | FDX | FDR | Avoid Rev FDU & FDV |
| FRP(M) Model E | FEX | FER | Avoid Rev FEU & FEV |
| FRP(M) Model H | FHB | FHB | FRM(B) |
| FTC Model B | JBF | JBB | |
| FTC Model C | JCA | JCA | |
| NTC | NEJ | NED | |
| SDP | SCF | SCF | |
| UFM-C | ZAE | ZAB | |
| UFM-U | YAA | YAA | |
| UVM | DAA | DAA | |
| UVM-B | DBA | DBA |
| Release ID | Product | Rev. | Model | Image |
|---|---|---|---|---|
| SwSw 8.4.15 | Sys S/W IPX | 8.4.15 | ||
| Sys S/W IGX | 8.4.15 | |||
| Sys S/W BPX | 8.4.15 | |||
| 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 | N0 | A | RAN | |
| NPM 32 Boot | N0 | B | RBN | |
| NPM 64 Boot | N0 | C | RCN |
| Release ID | Product | Rev. | Model | Image |
|---|---|---|---|---|
| SV 8.4.09 | StrataView Plus | 8.4.09 | ||
| StrataView Plus SCM | 8.4.09 | |||
| SNMP | 8.4.09 |
| Release ID | Product | Rev | Model | Image |
|---|---|---|---|---|
| AXIS 4.0.05 | IMATM F/W | A0 | 4.0.05 | 4.0.05 |
| IMATM Boot | N/A | 4.0.00 | 4.0.00 | |
| ASC F/W | A0 | 4.0.05 | 4.0.05 | |
| ASC Boot | A0 | 4.0.03 | 4.0.03 | |
| BNM-E3 | N/A | N/A | N/A | |
| FRSM-4T1 | A0 | 4.0.05 | 4.0.05 | |
| FRSM-4T1 Boot | N/A | 4.0.00 | 4.0.00 | |
| FRSM-8T1 | A0 | 4.0.05 | 4.0.05 | |
| FRSM-8T1 Boot | N/A | 4.0.00 | 4.0.00 | |
| FRSM-HS1 | A0 | 4.0.05 | 4.0.05 | |
| 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.05 | 3.0.05 | |
| CESM Boot | N/A | 4.0.00 | 4.0.00 | |
| AUSM-4 T1/E1 | A0 | 4.0.05 | 4.0.05 | |
| AUSM-4 T1/E1 Boot | N/A | 4.0.00 | 4.0.00 | |
| AUSM-8 T1/E1 | A0 | 4.0.05 | 4.0.05 | |
| AUSM-8 T1/E1 Boot | N/A | 4.0.00 | 4.0.00 | |
| BPX 8.4.15 | ASI 155 | B0 | B | WEB |
| ASI 155E | B0 | D | WHB | |
| ASI-1 2T3/E3 | C0 | C | UCC | |
| ASI-2 T3/E3 | J0 | B | UBJ | |
| BNI 3T3/E3 | L0 | C | TCL | |
| BNI 155E | N0 | D | VDN | |
| BNI I55 0C3 | N0 | B | VBN | |
| BNI 3T3/E3 | L0 | C | TCL | |
| ASM | A0 | A | GAC | |
| IGX 8.4.15 | BTM | L0 | B | IBL |
| CVM | F0 | A | DAF | |
| CVM Model B | C0 | B | DBC | |
| CVM Model C | A0 | C | DCA | |
| FRM (Model D) | X0 | D | FDX | |
| FRM (Model E) | X0 | E | FEX | |
| FRM -2 | D0 | F | FFD | |
| HDM | F0 | C | SCF | |
| ALM-A | B0 | A | CAB | |
| ALM-B | C0 | B | CBC | |
| UFM-C | E0 | A | ZAE | |
| UFM-U | A0 | A | YAA | |
| UVM | A0 | A | DAA | |
| FTM | A0 | C | JCA | |
| LDM | P2 | C | LC3 | |
| NTM | J0 | E | NEJ | |
| NTM (B) | F0 | F | NFF | |
| IPX 8.4.15 | AIT Model A | F0 | A | IAF |
| AIT Model B | L0 | B | IBL | |
| CDP | F0 | A | DAF | |
| LDP | P2 | C | LC3 | |
| FRP Model D | X0 | D | FDX | |
| FRP Model E | X0 | E | FEX | |
| FTC Model C | 20 | C | JC20 | |
| NTC | J0 | E | NEJ | |
| SDP | F0 | C | SCF |
For service and support for a product purchased from a reseller, contact the reseller. Resellers offer a wide variety of Cisco service and support programs, which are described in the section "Service and Support" in the information packet that shipped with your chassis.
For service and support for a product purchased directly from Cisco, use CCO.
CCO is Cisco Systems' primary, real-time support channel. SMARTnet customers and partners can self-register on CCO to obtain additional content and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously--a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
Please use CCO to obtain general information about Cisco Systems, Cisco products, or upgrades. If CCO is not accessible, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.
|
|