Release Notes for Cisco ONS 15454 Release 2.2.2

Release Notes address closed (maintenance) issues, caveats, and new features for the Cisco ONS 15454. For detailed information regarding features, capabilities, hardware, and software, refer to Cisco ONS 15454 User Documentation, Release 2.2.1.

Changes to the Release Notes

This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15454 Release 2.2.2 since the production of the Cisco ONS 15454 System Software CD for Release 2.2.2.

Changes to Caveats

Resolved Field Service Bulletins

These field service bulletins (FSBs) were addressed and closed in Release 2.2.2:

Maintenance Issues Closed in Release 2.2.2

JRE Updates

Cisco ONS platforms ship with a Java Runtime Environment (JRE) from Sun Microsystems. Occasionally Sun releases maintenance releases to the JRE. The Sun Microsystems website lists JRE maintenance releases and the issues resolved for each. Cisco recommends that you review these listings to determine if the issues resolved in any given JRE maintenance release warrant a JRE upgrade for your particular network. Cisco tests only with the specific JRE actually shipped with the ONS software CD.

Line Cards

DDTS # CSCds50463

E100 and E1000 improperly filter IS-IS Hello frames, preventing dynamic routing in IS-IS networks. This issue is resolved in Release 2.2.2.

DDTS # CSCdt03823 and # CSCdr94635

CV-Ls and the associated PMs (ES-L, SES-L, and UAS-L) can fail to count on EC1-12 or OC-3 cards. This issue is resolved in Release 2.2.2.

Synchronization

DDTS# CSCdr03214

During software upgrades, line-timed network elements (NEs) can lose connectivity to their primary reference source. Connectivity loss forces the NEs into hold-over or causes a switch to the secondary reference source, but does not affect traffic. This issue is resolved in Release 2.2.2.

Maintenance and Administration

DDTS # CSCdt73033

In previous releases, if you were supporting a proxy ARP-based SDCC interconnected network and the network required redundant gateway network elements (GNEs), you could lose management network connectivity due to lack of ability to provision such redundancy. This issue is resolved in Release 2.2.2. You can now have redundant GNEs on the same network span.

DDTS # CSCct01212: Daylight Savings Time

The CTC clock daylight savings time activation for October, which sets the clock back one hour, occurs at 4:00 a.m. (0400) rather than at 2:00 a.m. (0200). This issue is resolved with Release 2.2.2.

DDTS # CSCct02396: Time Zone Display

The CTC time zone is shown as Pacific Time regardless of the setting chosen. This issue is resolved in Release 2.2.2, and time zones display correctly for all locations.

DDTS # CSCds71355: Timing Pane

The timing pane in the Maintenance tab of the node view does not refresh in real time. This issue is resolved in Release 2.2.2.

DDTS # CSCds71415: Inventory Pane

The inventory pane does not refresh in real time. This issue is resolved in Release 2.2.2.

DDTS # CSCds91623: Provisioning Screen

The advice displayed on the provisioning screen for protect cards can be confusing to some users, because it might not make it clear that users should not attempt to provision a protect card. This issue is resolved in Release 2.2.2. The text of the advice has been edited for clarity. To enforce the advice on the screen, the user is no longer allowed to enter provisioning data for a protect card.

DDTS # CSCdr24052: Unidirectional STS-3c Circuits

Provisioning unidirectional STS-3c circuits with Release 2.2.1 is not recommended. These circuits will carry traffic but might not report path-level alarms. This issue is resolved in Release 2.2.2.

DDTS # CSCdr98353

Physically pulling a card to switch traffic back to a working card might have affected traffic. This issue is resolved for optical cards in Release 2.2.2.

DDTS # CSCds79099

On a Windows 2000 system, CTC did not start from a browser. This issue is resolved in Release 2.2.2.

DDTS # CSCds86889

Prior to Release 2.2.2, the node view of a recently inserted or soft-reset TCC card might have prematurely shown that the card moved from loading to standby. This issue is resolved in Release 2.2.2.

Ethernet Functionality

DDTS # CSCds87459

Adding a VLAN to a port with an existing VLAN might have caused traffic outages in excess of ten seconds. This issue is resolved in Release 2.2.2. This type of outage can now only occur when a card's VLAN set is changed where a single-card Etherswitch is added to a multicard Etherswitch Group. This addition causes Spanning Tree to re-configure resulting in a traffic interruption of approximately 45 seconds. Once the single-card Etherswitch is added into a circuit carrying a particular VLAN, you can add or remove it from any single port and expect to see traffic interruptions of less than ten seconds.

DDTS # CSCdr94172

Multicast traffic can cause minimal packet loss on the E1000-2 boards. If packet loss occurs, it is expected to be less than 1%. This issue is resolved for broadcast in Release 2.2.1, and for broadcast, OSPF, and low-rate BPDU multicast in Release 2.2.2. Line-rate multicast traffic is not supported.

DDTS # CSCds46919

Low-rate multicast traffic can cause unicast frame loss if multicast frames are followed immediately by unicast frames. This issue is resolved in Release 2.2.2 for the most commonly-used frame types, including broadcast, OSPF, and BPDU multicast.

DDTS # CSCds07778

Excessive Ethernet traffic on the TCC/TCC+ management port might have reset the TCC/TCC+. You can retrieve a LAN Overflow alarm with the RTRV-ALM-ALL TL1 command. (After the traffic has passed you can also see this alarm in CTC.) This issue is resolved in Release 2.2.2. Interrupts are now limited so that the TCC CPU cannot be overwhelmed by a broadcast storm or a unicast attack.

SONET

DDTS # CSCdr12777

When changing the mode from SONET to SDH or vice versa on an OC-N card (OC-3 only, in Release 2.1.3) in a 1+1 linear APS group, perform the following procedure in CTC to ensure correct 1+1 linear switching:

Caveats

Review the notes listed below before deploying the ONS 15454. Caveats with DDTS tracking numbers are known system limitations that are scheduled to be addressed in a subsequent release. Caveats without DDTS tracking numbers are provided to point out procedural or situational considerations when deploying the product.

Note As of Release 2.2.0, CMS (Cerent Management System) is entitled CTC (Cisco Transport Controller). If you are working with a pre-2.2 software release and see the term "CTC," you can assume the reference is to CMS.

Software Upgrades

Transport Management Compatiblity

Upgrading to a new CTC release can create limitations to your ability to use the Cisco Transport Manager (CTM). If you are using CTM, before you choose to upgrade to a new CTC release you should check the latest CTM Release Notes for any possible compatibility issues. The CTM Release Notes can be found at:

System Software Upgrades

Minor traffic disruptions in excess of 50 ms might occur when upgrading software to Release 2.2.2 from a previous release. You should perform software upgrades during a maintenance window.

Note You are limited to two concurrent CTC sessions when performing a software upgrade. This limitation will be resolved in a future release.

Traffic Protection

Caution

With Release 2.2.2, when powering a up a new node, or if an XC/XCVT must be rebooted (for example, upon replacing an XC/XCVT), perform a TCC/TCC+ switch (reset the active card) after the cross connect card boots to ensure proper initialization. This issue will be resolved in release 3.0. (For reference, the bug number is DDTS # CSCdu14682.)

Deleting Protection Groups

Delete protection groups only after traffic that switched to the protection card reverts back to the working card. If the protection group is deleted after a protection switch and traffic is carried on the protection card, perform the following steps:

Protection During Upgrades

When upgrading from Release 2.0.0 to a newer release, temporarily remove any 1:N protection groups prior to the upgrade. If empty slots are present on the side of the shelf that has a 1:N protection group defined, traffic can be lost for all cards on that side of the shelf. This caveat is restricted to systems that are upgrading from Release 2.0.0 to newer releases. This limitation does not apply when upgrading to new releases from Release 2.0.1 or subsequent releases.

TCC Protection Switching

When performing a manually-initiated TCC protection switch, Cisco recommends resetting the TCC card through CTC or the TL1 interface. All TCC switches conform to protection switching standards for BER counts that are not in excess of E10-3 and where completion time is less than 50 ms, which results in minimal traffic interruption. Switch errors will be resolved in a future release.

Active TCC/TCC+ Removal

The removal of an active TCC/TCC+ is supported in this release, but might result in traffic hits. If you must remove the active TCC/TCC+, perform a protection switch to the standby TCC/TCC+ (follow the instructions provided in the "TCC Protection Switching" section). This issue will be resolved in a future release.

Line Cards

DDTS # CSCct03114

SONET section data communication channel (SDCC) is supported on Ports 1 and 3 of the four-port OC-3 card. SDCC from either an ONS 15454 node or another vendor's product is not supported on Ports 2 and 4 of the OC-3 card. Therefore, when using an OC-3 card as a transport span between ONS 15454 nodes, you must use Ports 1 and 3 to ensure CTC visibility across nodes. Also, when subtending another vendor's product from an OC-3 card, the other vendor's SDCC is supported on Ports 1 and 3 only. This limitation will be resolved in a future release.

DDTS # CSCds34584: E1000-2 Only

When provisioning VLANs, you cannot provision the same VLAN on more than one port at a time. Each port must have a separately-provisioned VLAN. When you initially provision the cards, set the VLAN membership before enabling the port.

E1000-2/E100T

Do not use the repair circuit option with provisioned Ethernet circuits. This issue will be resolved in a future release.

Single-card EtherSwitch

From Release 2.2.1 forward, each E100/E1000 card can be configured as a single-card EtherSwitch configuration to allow STS 12c of bandwidth to be dropped at each card. The following scenarios for provisioning are available:

When configuring scenario 3, the STS 6c must be provisoned before either of the STS 3c circuits. This issue will be resolved in a future release.

Single-card and Multicard EtherSwitch

When deleting and recreating Ethernet circuits that have different sizes, you must delete all STS circuits provisioned to the EtherSwitch before you create the new circuit scenario. (See the preceding section, "Single-card EtherSwitch," for details.) This issue will be resolved in a future release.

DDTS # CSCds02031 E1000-2/E100T

Whenever you drop two 3c multicard EtherSwitch circuits onto an Ethernet card and delete only the first circuit, you should not provision STS-1 circuits to the card without first deleting the remaining STS-3c circuit. If you attempt to create an STS-1 circuit after deleting the first STS-3c circuit, the STS-1 circuit will not work and no alarms will indicate this condition. To avoid a failed STS-1 circuit, delete the second STS-3c prior to creating the STS-1 circuit. This issue will be resolved in a future release.

Maintenance and Administration

Note Whenever a proposed change occurs, the "Are you sure" dialog box appears to warn you that the action can change existing provisioning states or can cause traffic disruptions.

Note Changing the AIP card might cause some circuits to become incomplete. In CTC, repair each circuit, one node at a time, using the Repair button from the Circuits tab. Some circuits might still erroneously appear as incomplete. After completing the repair operation, you must relaunch CTC.

DDTS # CSCdt90247 and CSCdu58071 Fast Start Synchronization (FSTSYNC) Alarms

Timing offsets can generate fast start synchronization alarms. These alarms can remain uncleared for up to a few minutes, depending on the degree of the offset. They do not indicate any instability of the ONS 15454's timing, and this is expected behavior.

DDTS # CSCds15889: Add Node Feature

The Add Node feature is only supported when you add a new, isolated node (one not already participating in a network) in either BLSR or UPSR configuration. If a node is already part of a network, the Add Node feature is not supported. This issue will be resolved in a future release.

DDTS # CSCdt57008: Database Provisioning

Do not reset TCC cards for at least one minute after database provisioning. If you change the database and reset the TCC card within one minute of the change, the database synchronization process might not have time to complete and the provisioning will be lost. This issue will be resolved in a future release.

Interoperability

DDTS # CSCds13769: Fujitsu FLM-150 and Nortel OC-3 Express

You cannot provision the FLM-150 and OC-3 Express in 1+1 revertive switching mode. The problem occurs when the ONS 15454 issues a user request in revertive mode to the protect channel. When the user request is cleared, the ONS 15454 issues a No Request. However, the FLM-150 and OC-3 Express issues a Do Not Revert, which causes traffic to remain on the protection channel. According to Telcordia standard GR-253, section 5.3.5.5, the FLM-150 and the OC-3 Express should respond with a No Request.

SONET/SDH

DDTS # CSCct04091

You must provision all circuits as bidirectional. Unidirectional circuits are not supported. If a unidirectional circuit is provisioned, loss of signal (LOS) alarms are generated. This will be resolved in a future release.

Ethernet Functionality

DDTS # CSCdt73033

DDTS # CSCdu05982

Clearing the MAC address table by VLAN results in corruption of the static multicast MAC addresses. To avoid this problem, use Clear All or Clear by Port.

Note If you have over one hundred VLANs, you should use Clear by Port, only, to avoid possibly having to clear addresses more than once.

UPSR Functionality

DDTS # CSCct03852

When a UPSR or BLSR protection switch occurs, no alarm is reported to indicate that the protection switch occurred. An event is reported in the event log, but not as a standing alarm. The ability to make this event an alarm is being considered for a future release.

Note Once a UPSR circuit is created, the ONS 15454 does not support converting UPSR spans to 1+1 or BLSR. The event is reported in the event log but not as a standing alarm. A protection switch on the 1+1 or BLSR span can cause a traffic outage.

BLSR Functionality

BLSR Database Restore

Step 1

To isolate the failed node, issue a Force switch toward the failure node from the adjacent east and west nodes.

Step 2

If more than one node has failed, restore the database one node at a time.

Step 3

After the TCC has reset and booted up, release the Force switch from each node.

DDTS # CSCct03919

When provisioning a BLSR you must ensure that the span STS channel number is the same for all spans from the source node to the destination node. This is true for all STS circuits. For VT circuits, the span STS channel number and the VT number within must also be the same from source to destination. Either auto-routing or manual routing can be used to route BLSR circuits, as long as the above constraints are met. This constraint also applies for VT tunnels. If these constraints are not followed, squelching will not work as expected in a node-isolation scenario.

Documentation

Spanning Tree

In section 7.6, Spanning Tree, of the Cisco ONS 15454 User Documentation, Release 2.2.1, paragraph 1, line 1, the reference to "IEEE 802.1Q STP" should read "IEEE 802.1D STP." This will be corrected in Release 3.0

Alarms

In section 9.71 and 9.72 of the Cisco ONS 15454 User Documentation, Release 2.2.1, the references to "SDBER" and "SFBER" should read "SD" and "SF," respectively. This will be corrected in Release 3.0.

In section 9.74 of the Cisco ONS 15454 User Documentation, Release 2.2.1, the reference to "Minor" should read "NR." This will be corrected in Release 3.0.

In section 9.51 of the Cisco ONS 15454 User Documentation, Release 2.2.1, the reference to "Critical and Minor" should include "Major." This will be corrected in Release 3.0.

In section 9 of the Cisco ONS 15454 User Documentation, Release 2.2.1, the FSTSYNC, ST3, TRMT, AUTOSW-UNEQ, AUTOSW-AIS, AIS and DUS alarms are not included. This will be addressed in Release 3.0.

UPSR and BLSR

For the BLSR and UPSR "drop a node" procedures, insert the replacement text below in the following locations of the Cisco ONS 15454 User Documentation :

"One circuit at a time, delete and recreate any circuits that ingressed and egressed through the deleted node on different STSs. For example, if the circuit arrives at the node on STS 1 and leaves the node on STS 2, you need to perform this step."

System Reset

The following updated procedure will be added to the Cisco ONS 15454 User Documentation :

Procedure: Perform a Soft Reset

Note This procedure is also used to switch traffic from the primary to the secondary TCC.

Step 3

Click Reset Card (see Figure 1). The "Are You Sure" dialog box appears.

Note

To ensure that all temporary alarms have cleared, allow a minimum of 3 minutes to pass before performing Step 5.

Step 7

Click Reset Card (see Figure 1). The "Are You Sure" dialog box appears.

Step 8

Click Yes. The "Lost Connection to Node, Changing to Network View" dialog box appears.

Resetting, Removing, and Replacing XC/XCVT Cards

The following updated procedure will be added to the Cisco ONS 15454 User Documentation :

Procedure: Remove XC/XCVT Cards While In-Service

Caution

The removal of any active traffic-bearing card from the ONS 15454 could result in traffic interruption. Use caution when replacing traffic-bearing cards and verify that only inactive or standby cards are being replaced. If the active card needs to be replaced, follow the steps below to switch the XC/XCVT card to standby prior to removing the card from the node.

Step 1

Determine the active XC/XCVT card. The ACT/STBY LED of the active card is green. The ACT/STBY LED of the standby card is yellow.

Note

You can also place the cursor over the card graphic to display a tooltip identifying the card as active or standby.

Note

A minor alarm appears on the manually-switched slot. After the active XC/XCVT goes into standby, the original standby slot becomes active. This causes the ACT/STBY LED to become green on the former standby card.

Step 8

Insert the replacement XC/XCVT card into the empty slot. The replacement card boots up and becomes ready for service after approximately one (1) minute.

TL1

Commands not Supported as of Release 2.2

•

DLT-<MOD2>, ENT-<MOD2>, RMV-<MOD2>, and RST-<MOD2> do not apply to DS1, STS1, STS3C, STS12C, STS48C, VT1

False Positives

Although the system responds with COMPLD for each of the following commands, the operation requested by the command does not occur.

Commands Removed as of Release 2.2

The RTRV-ALM-LOG command is no longer supported. It has been replaced with the RTRV-LOG command.

Cross-Connect Types for ENT-CRS Commands

The Release 2.2 and Release 2.2.1 user manual sections on TL1 do not include possible values for cct (type CCT_SUB) in ENT-CRS-<STS_PATH>. These will be included in Release 3.0. The acceptable values are:


CCT Values	Description
1WAY	A unidirectional connection from a source tributary to a destination tributary
2WAY	A bidirectional connection between the two tributaries
MON	Monitored cross-connection
UPSR	Bidirectional UPSR entrance/exit
UPSR-DC	UPSR multicast drop with 2-way continue
UPSR-DROP	UPSR unicast drop
UPSR-EN	UPSR multicast End Node with 1-way continue
UPSR-HEAD	UPSR uni/multicast ring entrance
UPSR-UPSR	Single-node UPSR interconnect

The Release 2.2 user manual section on TL1 does not include possible values for cct (type CCT_SUB) in ENT-CRS-VT1. These will be included in Release 3.0. The acceptable values are:


CCT Values	Description
1WAY	A unidirectional connection from a source tributary to a destination tributary
2WAY	A bidirectional connection between the two tributaries
MON	Monitored cross-connection

Caution

Using any of the UPSR cct types from CCT_SUB (for example, UPSR, UPSR-DC, UPSR-DROP, UPSR-EN, UPSR-HEAD, and UPSR-UPSR) is blocked with Release 2.2.2. However, trying to delete CTC-created VT UPSR circuits using TL1 can cause the TCC to reboot. This only applies to VT circuits and will be corrected in Release 3.0.

Deletion of UPSR Circuits

In the case where a UPSR circuit is created from S1&S2 to D1 (for example, ENT-CRS-STS1::S1&S2,D1:::UPSR;), this entire UPSR circuit is created as one unit within the ONS 15454. A command to delete a portion of the circuit deletes the entire unit. Thus, the command DLT-CRS-STS1::S1,D1; or DLT-CRS-STS1::S2,D1; deletes both the S1-D1 and S2-D1 connections.

Using the full UPSR circuit identification in the delete command, for example, DLT-CRS-STS1:: S1&S2,D1; results in an IIAC /*AID List Length Mismatch */ error message.

Creation of UPSR Circuits

Using the S1&S2,D1 parameter order, for example, in the ENT-CRS-STS1::S1&S2,D1:::UPSR; command, works correctly and sets up a 2WAY UPSR circuit.

Using the S1&S2, D1&D2 parameter order, for example, in the ENT-CRS-STS1::S1&S2,D1&D2:::UPSR; command, yields UPSR circuits between S1&S2 and D2. Thus, ENT-CRS-STS1::S1&S2,D1&D2:::UPSR; and ENT-CRS-STS1::S1&S2,D2:::UPSR; function identically.

If the second parameter is invalid, for example, in the ENT-CRS-STS1::S1&S2,D1&BAD_VALUE:::UPSR; command, a UPSR circuit between S1&S2 and D1 is created.

Use of the S1,D1&D2 parameter order, for example, in the ENT-CRS-STS1::S1,D1&D2:::UPSR; command, is rejected with an SDBE /*Cannot Create UPSR Crossconnect */ error message.

As a workaround to create the same two-way UPSR cross-connect, list the two-parameter portion of the circuit first (for example, ENT-CRS-STS1::D1&D2,S1:::UPSR;).

New Features and Functionality

Software

Microsoft Windows 2000 Support

As of Release 2.2.2, CTC is fully supported for use with the Microsoft Windows 2000 operating system.

Java Runtime Environment Compatibility

Release 2.2.2 supports web browsers running Java Runtime Environment (JRE) 1.2.2 and JRE 1.3.0.

Note A workstation running JRE 1.3.0 cannot log into an ONS 15454 running Release 2.2.1 or prior.

Warning Message on Circuit Switch

If you attempt a Manual or Force switch, you receive a warning message stating that if a failure condition exists the action might not be taken immediately, in which case the request will be queued. This message is designed to alert you to the fact that the action might be delayed pending cleared conditions. The CTC might not complete a Manual switch if conditions are present that can result in traffic loss.

Database Restore Warning Added

As of Release 2.2.2, a dialog box warns you of possible traffic loss before allowing a database restore from another node or a database restore from a prior release on the same node.

Default User Name Change

The default user name of CISCO15 (case sensitive) has been added to the list of users in the security panel. When a Cisco ONS 15454 has been upgraded with software release 2.2.1 or greater, both the old and new default user names appear. A new ONS 15454 with software release 2.2.1 only supports the CISCO15 default user name only. The CISCO15 user, by default, has a security level of superuser and cannot be deleted or have its security level changed; however, a new password can be assigned for either default user name.

Software Revert

New to Release 2.2.1, the ONS 15454 introduces software revert. The provisioning database stores all system-provisioning data including cross-connects, I/O card types, port states, timing information, and SDCC settings. The node name, IP address, subnet mask, and default gateway are stored in the system database and will remain intact after a software revert.

In prior software releases, software reverts required a backup to upload the former software load. Although a copy of the former software load is stored in memory, Cisco recommends creating a backup with every software upload.

When upgrading to a new software load, a copy of the former software load (that is, a snapshot of the software load and provisioning database) is stored in the standby sector of memory. If the provisioning database has been updated after a software upload, a software revert will not revert the updates to the provisioning database.

Note Reverting to a provisioning database requires a TCC+ rather than a TCC because of the additional memory required to store a copy of the previous provisioning database.

Single-Card EtherSwitch Over UPSR

You can now configure single-card EtherSwitch circuits over a UPSR and enable UPSR type protection for the Ethernet circuit under this configuration. The UPSR circuits can be provisioned as you would a SONET circuit.

Caution

You can configure multi-card EtherSwitch circuits over UPSR spans, but only if no UPSR span is provisioned touching a node that is an Ethernet drop. This precludes provisioning end-to-end UPSRs (disallowed in Release 2.2.2). Also, when you configure multi-card EtherSwitch over a UPSR, you must provision the spans manually and ensure that all of the arrows on each UPSR span point in the same direction.

Subnet IDs

CTC now supports the setting of a subnet field (or ID) to all zeros or all ones.

CTC has not previously supported IP addresses having the value 0 or -1 (all zeros or all ones) for any of the <Host-number>, <Network-number>, or <Subnet-number> fields. Disallowing all-one or all-zero field values forces you to use fields that are at least two bits long. However, the International Organization for Standardization (IOS) supports subnet fields with all zeros or all ones.

TL1

Commands Changed

•

In the DLT-CRS-<STS_PATH> and DLT-CRS-VT1 commands, <to> was added to comply with Telcordia standard GR-199.

•

In the ED-FFP-<OCN_TYPE>, ED-FFP-EQPT, ENT-FFP-<OCN_TYPE>, ENT-FFP-EQPT, RTRV-FFP-<OCN_TYPE>, and RTRV-FFP-EQPT commands, the order of the <RVTT> and <RVTM> parameters was changed.

•

The INIT-SYS: command only resets equipment. We do not support the phase parameter in this release.

•

The OPR-LPBK-<OCN_TYPE>, OPR-LPBK-DS1, OPR-LPBK-EC1, OPR-LPBK-T1, OPR-LPBK-T3, RLS-LPBK-<OCN_TYPE>, RLS-LPBK-DS1, RLS-LPBK-EC1, RLS-LPBK-T1, and RLS-LPBK-T3 commands no longer use the <location> parameter.

•

In the OPR-PROTNSW-<OCN_TYPE> command, the <cc> and <dirn> parameters were removed and the <dnfield> parameter was added.

Response Changes

In response to the RTRV-LOG command, the Release 2.1.x system replied with a logtype (for example, REBOOT). As of Release 2.2, the system replies with the response:

"<aid>,<seq>:CURRENT=<current>,PREVIOUS=<previous>,<condition>,
<serv_eff>,TIME=<time>,DATE=<date>:[<desc>]"

As of Release 2.2.2, alarm messages have been improved to include the type (path or line) for BER Threshold Alarms, in addition to the other information given.

Access Identifier Additions

In the ALL_THR parameter table, the T-CVS, T-ESS, T-SESS, T-PJNEG-GEN, and T-PJPOS-GE values were added.

New Conditions

MEM-GONE indicates that software operations exceed the memory capacity of the TCC/TCC+ card.

MEM-LOW indicates that data generated by software operations is close to exceeding the memory capacity of the TCC/TCC+ card.

RMON-RESET indicates that RMON histories and alarms have been reset because of chipset reboot.


Condition	Alarm Description	Type
SD-L	BER Threshold exceeded for Signal Degrade	Line
SD-P	BER Threshold exceeded for Signal Degrade	Path
SF-L	BER Threshold exceeded for Signal Failure	Line
SF-P	BER Threshold exceeded for Signal Failure	Path

Changed Conditions

Language	E-mail Address
English	tac@cisco.com
Hanzi (Chinese)	chinese-tac@cisco.com
Kanji (Japanese)	japan-tac@cisco.com
Hangul (Korean)	korea-tac@cisco.com
Spanish	tac@cisco.com
Thai	thai-tac@cisco.com

Table Of Contents