cc/td/doc/product/ong/15216/216edf
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Release Notes for Cisco ONS 15216 EDFA3 Release 1.1

Contents

Closed Software Caveats

Caveats

Operations Guide Caveats

Hardware Caveats

Open Software Caveats

Obtaining Documentation

Cisco.com

Obtaining Documentation

Documentation Feedback

Obtaining Technical Assistance

Opening a TAC Case

TAC Case Priority Definitions

Obtaining Additional Publications and Information


Release Notes for Cisco ONS 15216 EDFA3 Release 1.1


June, 2004

Release notes address caveats and new features for the Cisco ONS 15216 EDFA3. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to the Cisco ONS 15216 EDFA3 Operations Guide.

Cisco also provides Bug Toolkit, a web resource for tracking defects. To access Bug Toolkit, visit the following URL:

http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl

Contents

Closed Software Caveats

Caveats

Operations Guide Caveats

Hardware Caveats

Open Software Caveats

General:

TL1 Related:

SNMP Related:

Obtaining Documentation

Obtaining Technical Assistance

Obtaining Additional Publications and Information

Closed Software Caveats

CSCed08016: Invalid Longitude/Latitude

Configuration: Any

Reproducibility: 100%

Description: When setting Longitude and Latitude values from SNMP with special characters such as a double quote ("), additional input characters will not be handled properly and will cause an unintended reported value from TL1.

>RTRV-NE-GEN:::sW;
EDFA168 2003-11-21 10:39:37 M sW COMPLD "EQPT:NAME=EDFA168,DESCR=ONS15216EDFA,LONGITUDE=C,LATITUDE=\C\";\"\C:\C:\C:\C :,IPADDR=10.92.27.168,IPMASK=255.255.255.0,DEFRTR=10.92.27.1,MACADDRESS=00059A3D EB01,ACTIVESW=ONS15216Edfa3-0.4.9-003K-13.13,STANDBYSW=ONS15216Edfa3-0.4.7-003J- 27.18,SNMPSETREQ=ENABLE" ;

This issue is resolved in Release 1.1.

Csced12167: System can be Brought to A Situation Where No RWA User is Present

Configuration: Any

Reproducibility: 100%

Description: It is possible to demote the last RWA user to RW, resulting in a need for a password recovery procedure if you wish to perform RWA restricted operations such as INIT-SYS, RTRV-USER-SECU, or ENT-USER-SECU.

Steps to reproduce:


>rtrv-user-secu::all:sss;

EDFA3-237 2003-12-01 13:53:32
M sss COMPLD
"CISCO15:,RWA:LOGGEDIN=YES,NUMSESSIONS=1"
;
> ED-USER-SECU::CISCO15:xxx::,,,RW;

EDFA3-237 2003-12-01 13:56:39
M xxx COMPLD
/* ED-USER-SECU */
;

This issue is resolved in Release 1.1.

CSCed75200: GenericStandingCondnTimeStamp Not Sent in Traps

Configuration: Any

Reproducibility: 100%

Description: cerent15216EdfaGenericStandingCondnTimeStamp is not sent by the ONS 15216 EDFA3.


Trap: cerent15216EdfaGenericEdfa3PwrFailLowThresholdChangedLine1Tx Variable Bindings Binding #1: sysUpTime.0 *** (timeticks) 2 days 04h:27m:01s.65th
Binding #2: cerent15216EdfaGenericStandingCondnType *** (oid) cerent15216EdfaGenericEdfa3PwrFailLowThresholdChangedLine1Tx
Binding #3: cerent15216EdfaGenericStandingCondnState *** (int32) notAlarmedNonServiceAffecting(31)
Binding #4: cerent15216EdfaGenericLogGroup.20.1.20 *** (octets) 07.B2.02.1B.01.1B.04.01 (hex)
Binding #5: cerent15216EdfaGenericStandingCondnVariableOneValue *** (int32) -100
Binding #6: cerent15216EdfaGenericIpAddress *** (ipaddr) 172.28.170.178

Following is the mib definition for this notification:

cerent15216EdfaGenericEdfa3PwrFailLowThresholdChangedLine1Tx NOTIFICATION-TYPE OBJECTS { cerent15216EdfaGenericStandingCondnState, cerent15216EdfaGenericStandingCondnTimeStamp, cerent15216EdfaGenericEdfa3Line1TxPwrThFailLow} STATUS current DESCRIPTION "" ::= { cerent15216EdfaGenericEdfa3Notifications 30 } The OID

CTM can not display traps without this object.

This issue is resolved in Release 1.1.

CSCed79427: StandingConditions Table is Missing OID

Configuration: Any

Reproducibility: 100%

Description: The cerent15216EdfaGenericStandingCondnVariableOneValue attribute is part of the varbind list, but this is not helpful unless it is also known what the attribute is for which the value is -100. The cerent15216EdfaGenericStandingCondnVariableOneOid attribute should also be sent as part of the varbind list. According to the CERENT-15216-EDFA-GENERIC-MIB, if the node sends a trap with 2 varbinds, then X1Oid, X1value, X2Oid and X2Value should be there in the standingConditions table. If there is only one varbind in the trap, then one Oid and its value should be placed in these columns. An example is given below.

/*cerent15216EdfaGenericEdfa3PwrFailLowThresholdChangedLine1Tx* notification received from: 172.28.170.178 at 2/20/2004 2:41:17 PM
Time stamp: 1 days 09h:14m:42s.80th
Agent address: 172.28.170.178
Port: 161
Transport: IP/UDP
Protocol: SNMPv2c
Notification Manager address: 10.77.6.153
Port: 162
Transport: IP/UDP
Community: public
Bindings (6)
Binding #1: sysUpTime.0 *** (timeticks) 1 days 09h:14m:42s.80th
Binding #2: cerent15216EdfaGenericStandingCondnType *** (oid) cerent15216EdfaGenericEdfa3PwrFailLowThresholdChangedLine1Tx
Binding #3: cerent15216EdfaGenericStandingCondnState *** (int32) notAlarmedNonServiceAffecting(31) //* Binding #4: cerent15216EdfaGenericStandingCondnTimeStamp *** (octets) 1970-3-5,17:49:18.1 [07.B2.03.05.11.31.12.01 (hex)] * //*
Binding #5: cerent15216EdfaGenericStandingCondnVariableOneValue *** (int32) -100 *
Binding #6: cerent15216EdfaGenericIpAddress *** (ipaddr) 172.28.170.178/

This issue is resolved in Release 1.1.

CSCed79442: Event and Status Bindings Missing from EventProfileChanged Trap

Configuration: Any

Reproducibility: 100%

Description: The trap that is received from the NE when the severity of any alarm changes is as follows:

cerent15216EdfaGenericEventProfileChanged notification received from: 172.28.170.178 at 2/22/2004 4:27:31 PM
Time stamp: 3 days 11h:00m:55s.00th
Agent address: 172.28.170.178
Port: 161
Transport: IP/UDP
Protocol: SNMPv2c
Notification Manager address: 10.77.6.153
Port: 162
Transport: IP/UDP
Community: public
Bindings (5)
Binding #1: sysUpTime.0 *** (timeticks) 3 days 11h:00m:55s.00th
Binding #2: cerent15216EdfaGenericStandingCondnType *** (oid) cerent15216EdfaGenericEventProfileChanged
Binding #3: cerent15216EdfaGenericStandingCondnState *** (int32) notAlarmedNonServiceAffecting(31)
Binding #4: cerent15216EdfaGenericStandingCondnTimeStamp *** (octets) 1970-3-7,19:35:30.1 [07.B2.03.07.13.23.1E.01 (hex)]
Binding #5: cerent15216EdfaGenericIpAddress *** (ipaddr) 172.28.170.178

From this information, one will not be able to get the alarm for which the severity is changed. The Event and Status binding are missing from this trap.

This issue is resolved in Release 1.1.

CSCed79458: EdfaGenericStandingCondnType OID Has .0 at the End

Configuration: Any

Reproducibility: 100%

Description: While performing a software download, the trap cerent15216EdfaGenericStandingCondnType that is sent contains a value with ".0" at the end of the OID. i.e cerent15216EdfaGenericSoftwareDownloadInProgress.0 or cerent15216EdfaGenericSoftwareDownloadComplete.0

The value should be the row number (or value of cerent15216EdfaGenericStandingCondnIndex).

This issue is resolved in Release 1.1.

CSCed81959: RTRV-ALM-ALL Shows Critical Alarm but StandingCondnTable is Empty

Configuration: Any

Reproducibility: 100%

Description: After a power cycle, it is possible to see one outstanding alarm in the NE using the RTRV-ALM-ALL command:

EDFA3-178 1970-03-12 00:24:11 M 123 COMPLD "1,DWDM:CR,LINE1RXPWRFL,SA,03-11,19-19-58,,:\"Power Fail Low LINE1RX Port\""

However, when retrieving cerent15216EdfaGenericStandingCondnTable through the Mib Browser, the table is empty. This table should contain all outstanding alarms on the NE.

This issue is resolved in Release 1.1.

CSCee08957: Clear Traps do Not Send Variables 1 And 2

Configuration: Any

Reproducibility: 100%

Description: Clear traps do not send variables 1 and 2.

sysUpTime.0 => 450400
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.50.10.0.18
(cerent15216EdfaGenericEdfa3PwrFailLowLine2Rx)
cerent15216EdfaGenericStandingCondnState.1 => 40
cerent15216EdfaGenericStandingCondnTimeStamp.1 => 07 B2 01 01 03 2F 28 01
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

This issue is resolved in Release 1.1.

CSCee08964: Trap Has .0 for Condition Table Entry Index

Configuration: Any

Reproducibility: 100%

Description: When the standing condition table is empty, SNMP sends traps with varbinds 3 and 4 having index ".0." This can be confusing because these two varbinds represent entries in an SNMP table, which conventionally has 1-based indices.

"sysUpTime.0 => 439625
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.50.10.0.25
(cerent15216EdfaGenericEdfa3GainDegradeHighThresholdChanged)
cerent15216EdfaGenericStandingCondnState.0 => 31
cerent15216EdfaGenericStandingCondnTimeStamp.0 => 07 B2 01 01 03 2D 35 01
cerent15216EdfaGenericEdfa3GainThDegHigh.0 => 140
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

This issue is resolved in Release 1.1.

CSCee08975: Variable 2 of Alarm Trap Has Wrong OID

Configuration: Any

Reproducibility: 100%

Description: Variable 2 of alarm trap has wrong OID.

Incorrect behavior:

"sysUpTime.0 => 450067
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.50.10.0.18
(cerent15216EdfaGenericEdfa3PwrFailLowLine2Rx)
cerent15216EdfaGenericStandingCondnState.1 => 100
cerent15216EdfaGenericStandingCondnTimeStamp.1 => 07 B2 01 01 03 2F 1D 01
cerent15216EdfaGenericEdfa3Line2RxPwr.0 => -113
cerent15216EdfaGenericEdfa3Events.0.0 => -300
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

Correct behavior:

"sysUpTime.0 => 450067
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.50.10.0.18
(cerent15216EdfaGenericEdfa3PwrFailLowLine2Rx)
cerent15216EdfaGenericStandingCondnState.1 => 100
cerent15216EdfaGenericStandingCondnTimeStamp.1 => 07 B2 01 01 03 2F 1D 01
cerent15216EdfaGenericEdfa3Line2RxPwr.0 => -113
cerent15216EdfaGenericEdfa3Line2RxPwrThFailLow.0 => -300
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

This issue is resolved in Release 1.1.

CSCee30046: SNMP Trap Task Suspended When Setting Line1/2RxPwrFailLow Thresholds

Configuration: Any

Reproducibility: 100%

Description: SnmpTrap task suspended when setting Line1RxPwrFailLow and Line2RxPwrFailLow thresholds. Exception can be observed on debug port.

This issue is resolved in Release 1.1.

CSCee30055: Some SNMP Traps Have Identical OIDs for Variables 1 and 2

Configuration: Any

Reproducibility: 100%

Description: The following is an example for PwrFailureLowLine1Rx.

"sysUpTime.0 => 7819748
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.50.10.0.12
(cerent15216EdfaGenericEdfa3PwrFailureLowLine1Rx)
cerent15216EdfaGenericStandingCondnState.1 => 100
cerent15216EdfaGenericStandingCondnTimeStamp.1 => 07 B2 01 01 15 2D 3A 01
cerent15216EdfaGenericEdfa3Line1RxPwr.0 => -66
cerent15216EdfaGenericEdfa3Line1RxPwr.0 => 10
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

This issue is resolved in Release 1.1.

CSCee30063: Wrong OIDs, Event Types, and Varbinds un ProfileChanged Traps

Configuration: Any

Reproducibility: 100%

Description: ProfileChanged traps contain wrong OIDs, event types, and varbinds. A few examples are given below:

"sysUpTime.0 => 7833560
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.20.100.0.30
(cerent15216EdfaGenericEventProfileChanged)
cerent15216EdfaGenericStandingCondnState.1 => 31
cerent15216EdfaGenericStandingCondnTimeStamp.1 => 07 B2 01 01 15 30 11 01
cerent15216EdfaGenericEventProfileEvent.2 => 1.3.6.1.4.1.3607.6.31.20.50.10.0.2
(cerent15216EdfaGenericEdfa3PwrAlarmBusB)
2.3.6.1.4.1.3607.6.31.20.20.40.1.30.2 => 60
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

"sysUpTime.0 => 7834360
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.20.100.0.30
(cerent15216EdfaGenericEventProfileChanged)
cerent15216EdfaGenericStandingCondnState.1 => 31
cerent15216EdfaGenericStandingCondnTimeStamp.1 => 07 B2 01 01 15 30 19 01
cerent15216EdfaGenericEventProfileEvent.2 => 1.3.6.1.4.1.3607.6.31.20.50.10.0.2
(cerent15216EdfaGenericEdfa3PwrAlarmBusB)
2.3.6.1.4.1.3607.6.31.20.20.40.1.30.2 => 60
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

"sysUpTime.0 => 7837165
snmpTrap.1.0 => 1.3.6.1.4.1.3607.6.31.20.20.100.0.30
(cerent15216EdfaGenericEventProfileChanged)
cerent15216EdfaGenericStandingCondnState.1 => 31
cerent15216EdfaGenericStandingCondnTimeStamp.1 => 07 B2 01 01 15 30 35 01
cerent15216EdfaGenericEventProfileEvent.0 => 0.0.0.0.0.0.0.0.0.0.0.0.0
(cerent15216EdfaGenericOther)
0.3.6.1.4.1.3607.6.31.20.20.40.1.30.0 => 31
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

"sysUpTime.0 => 7851566
snmpTrap.1.0 => 1.3.6.1.6.3.1.1.5.5
(cerent15216EdfaGenericOther)
snmpTrap.1.0 => 1.3.6.1.2.1.11.4
(cerent15216EdfaGenericOther)
cerent15216EdfaGenericIpAddress.0 => 172.16.30.100"

This issue is resolved in Release 1.1.

CSCee75191: TCP Checks Should Verify ack seq and syn seq

Configuration: Any

Reproducibility: 100%

Description: The remote host has predictable TCP sequence numbers.

This issue is resolved in Release 1.1.

Caveats

Review the notes listed below before deploying the ONS 15216. 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.

Operations Guide Caveats

Recovery of Default Password

A mistake in the Operations Guide was found in Section 14.10 Recover the Default Password, Step 5.

The Guide says:

When the prompt (>) appears, type the following commands:

* RECOVER to set the password (and retrun to the TL1 prompt)

* EXIT to return to the TL1 prompt

It should say: (note the lower case!)

When the prompt (>) appears, type the following commands:

* recover to reset the password, and

* exit to return to the TL1 prompt

Software Upgrade

Step 16 on page 12-4 in the Operations Guide contains a few errors. The following is a corrected version.

Step 16 At the command prompt, enter the COPY-RFILE command, specifying TYPE=SWDL, the FTP parameters (user identifier, password, and IP address of the FTP server), and the filename. Use the syntax in the following example to transfer the file:

> COPY-RFILE:::123::TYPE=SWDL,SRC="ftp://anonymous:passwd@192.168.85.10/ONS15216Edfa3
-01.01.00-004E-21.17",DEST="file://fd1/ONS15216Edfa3-01.01.00-004E-21.17",OVERWRITE=YES;

where ONS15216Edfa3-01.01.00-004E-21.17 is the new filename.

An FTP URL has the following format:

ftp:[//[<userid>[:<password>]@]<ftphost>]/<urlpath>

A file URL (referring to the local system) has the following format:

file://localhost/<urlpath>

Table 12-2 describes the parameters in the FTP and file URLs.

Table 12-2 FTP URL and File URL Parameters

Parameter
Description

<userid>

FTP user identifier

<password>

FTP password for the user

<ftphost>

IP address of the FTP server

<urlpath>

Path in the following format:

<cwd1>/<cwd2>//<cwdn>/<filename>

where <cwd1> and <cwdn> are directory levels and <filename> is the file name.


The ONS 15216 EDFA3 should respond with autonomous messages using syntax similar to the following examples:

EDFA3 2004-04-30 00:57:59
M 123 COMPLD
/* COPY-RFILE */
;
>

EDFA3 2004-04-30 00:57:59
* 1 REPT ALM EQPT
"EQPT:MN,SFTWDOWN,NSA,04-30,00-57-59,,,:\"Software Download In Progress\""
;

EDFA3 2004-04-30 00:57:59
A 2 REPT EVT FXFR
"ONS15216Edfa3-01.01.00-004E-21.17,START,,"
;

EDFA3 2004-04-30 00:57:59
A 3 REPT EVT FXFR
"ONS15216Edfa3-01.01.00-004E-21.17,IP,,"
;

EDFA3 2004-04-30 00:59:15
A 4 REPT EVT FXFR
"ONS15216Edfa3-01.01.00-004E-21.17,COMPLD,SUCCESS,4289798"
;

EDFA3 2004-04-30 00:59:15
A 5 REPT ALM EQPT
"EQPT:CL,SFTWDOWN,NSA,04-30,00-59-15,,,:\"Software Download In Progress\""
;

When the SUCCESS message appears, the file transfer is complete.

COPY-RFILE Command Input Parameter

The input parameter src/dest for the COPY-RFILE command on page 8-10 in the Operations Guide specifies an optional field [:<port>]. This is an error. This field should be dropped or left blank. The command will not work if this field is used or a port is specified. An "Invalid Payload block. Extra parameters." error message will be shown if the [:<port>] field is used.

IP Address in TL1 Commands

In the following section of the Operations Guide, the parameter name associated with setting the IP address of EDFA3 is given incorrectly. In particular, "IPADDRESS=" should be "IPADDR=".

In Example 7-7 on page 7-7: IPADDRESS=129.9.0.6 should be IPADDR=129.9.0.6.

In Input Format of ED-NE-GEN on page 8-17: [IPADDRESS=<ipaddress>] should be [IPADDR=<ipaddress>].

In Output Format of RTRV-NE-GEN on page 8-41: IPADDRESS=<ipaddress> should be IPADDR=<ipaddress>.

MIB File name

Page 10-2, Section 10.1.2 of the Operations Guide uses an incorrect name for the MIB file. The correct file name for "cerentedfa3.mib" is "CERENT-15216-EDFA-GENERIC-MIB.mib."

Configuration of Optical Amplifier Alarm Thresholds

This is the caveat for Cisco ONS 15216 EDFA3 Operations Guide 7.5. - Use TL1 to set the Amplifier Alarm Thresholds.

In order to put the EDFA3 into optical amplification function, the optical amplifier alarm thresholds should be properly configured.

· Retrieve the current optical thresholds setting

RTRV-TH-DWDM:[<tid>]:<aid>:,ctag>::[<thresholdtype>][,][,];

Example of retrieving the default optical threshold setting:

>RTRV-TH-DWDM::ALL:123;
EDFA3 2004-04-26 14:34:09
M 123 COMPLD
"1,DWDM:GAINTHDH,,,23.0dB"
"1,DWDM:GAINTHDL,,,19.0dB"
"1,DWDM:LINE1RXPWRTHFL,,,10.0dBm"
"1,DWDM:LINE1TXPWRTHDH,,,12.0dBm"
"1,DWDM:LINE1TXPWRTHDL,,, 8.0dBm"
"1,DWDM:LINE1TXPWRTHFL,,,-6.0dBm"
"1,DWDM:LINE2RXPWRTHFL,,,-33.0dBm"

Note that GAINTHDH, GAINTHDL, LINE1TXPWRTHDL, LINE1TXPWRTHDH are automatically set by software based on the GAINSP and LINE1TXPWRSP, user cannot set these four thresholds. The default LINE1RXPWRTHFL is 10dBm that is higher than the typical input optical power. It will force the EDFA3 to shutdown. This default setting is for the sake of laser safety.

· Retrieve the current input optical power

RTRV-DWDM::[<TID>]:<aid>:<ctag>[::::];

Example of retrieving the optical parameters:

>rtrv-dwdm::all:123;

EDFA3 2004-04-11 00:01:49
M 123 COMPLD
"1:CTRLMODE=CGAIN,LINE1TXPWR=-60.0dBm,LINE1TXPWRSP=10.0dBm,LINE1RXPWR=-10.0dB
m,LINE2RXPWR=-51.6dBm,LINE2TXPWR=-60.0dBm,PWROFFSET=0.0dB,GAIN=0.0dB,GAINSP=21.0
dB,TILT=15.0dB,TILTSP=0.0dB,TILTOFFSET=0.0dB,DCULOSS=9.0dB,OSRI=OFF,LASSTATUS=OF
F,VOA=0.0dB"

;

In this example, the input optical power LINE1RXPWR is -10.0dBm.

· Set LINE1RXPWRTHFL to be approximately 7dB lower than the LINE1RXPWR

SET-TH-DWDM:[TID]:<aid>:<ctag>::LINE1RXPWRTHFL,<thlev>,,;

Example to set the LINE1RXPWRTHFL to be -17.0 dBm while the LINE1RXPWR is -10.0dBm.

>set-th-dwdm::all:1::LINE1RXPWRTHFL,-17.0;

EDFA3 2004-04-01 00:16:29
M 1 COMPLD
/* SET-TH-DWDM */
;
·Table 1 explains the convention used to map the module parameters related to the First and Second Stage to the TL1/SNMP attributes and alarms/traps.
Table 1: Port definitions.
Module Parameters
TL1/SNMP Identifier
Front Panel Label
Optical Input Power First Stage
LINE1RX
COM-RX
Optical Output Power First Stage
LINE2TX
DC-TX
Optical Input Power Second Stage
LINE2RX
DC-RX
Optical Output Power Second Stage
LINE1TX
COM-TX

Hardware Caveats

There are no hardware caveats for this release.

Open Software Caveats

General:

CSCec47531: EDFA3 Loss of Date Setting after Power Off

Configuration: Any

Reproducibility: 100%

Description: The Date and Time setting are lost after power cycling an EDFA3 module.

Workaround: Set the date and time after the unit is power cycled.

CSCec58393: Alarm Log Files do Not Log Events/alarms if FFS Becomes Full

Configuration: Any

Reproducibility: 100%

Description: When the FFS becomes full (for example, because of more than 3 uploaded software images), the alarm log files, both TL1 and SNMP, are no longer getting updated and do not record any further event or alarm that is raised until a file is deleted in the FFS.


Workaround:

Do not store more than three software images on the FFS. Before uploading a new software version, delete the previous backup software version. The FFS Full alarm will be raised when the FFS is more than 90% full.

CSCec89250: EDFA3: Fast Changes on the Mid-stage Access Loss (MAL)

Configuration: Any

Reproducibility: 100%

Description: When there is a fast change in the DCU, the EDFA3 may not respond properly. This issue has been seen during the stress mal test on first amplifier equipped with 32 channels. The power budget was 3x15dB.

First test:

1. The DCU value was 3.7dB.

2. The MAL insertion loss value had been increased fast (about 10dB in 5 sec), on the first amplifier.

3. The DCU value did not change (3.7dB), and the power output was low (OSNR and Power EOL out of specs).

4. After about 1h the amplifier stayed in the same condition.

5. In order to return at the normal system condition it was necessary to cut the input power.

Second test:

1. The DCU value was 13dB.

2. The MAL insertion loss value was decreased suddently (about 10dB in 5 sec) on the first amplifier.

3. The DCU value did not change, and the tilt output was higher than 10dB.

4. In order to return at the normal system condition it was necessary to cut the input power. The same stress conditions have been applied on the second amplifier with the same results.

Workaround: None.

CSCed17151: Header of Database File Should be Updated with Current Device Values

Configuration: Any

Reproducibility: 100%

Description: The fields reported in the Database file header should be updated, once the restore operation is finished (that is, after the INIT-SYS), with the current value of the device on which the restore took place. For example, if a database restore is performed from NE1 (10.51.125.235) to NE2 (10.51.125.234), and we have NE1 database file header:

ActiveSoftwareName=ONS15216Edfa3-00.04.12-003K-26.18 NodeName=EDFA3-235 IP-Address=10.51.125.235

then, after the database restore is done onto NE2, NE2 database file header should show ActiveSoftwareName=<Active sw on NE2> NodeName=EDFA3-234 IP-Address=10.51.125.234, whereas actually it shows the same data as NE1.

Workaround: Notice that if you perform a second reset the IPaddress is updated correctly.

CSCed27333: DATAFLT Alarm is Not Raised

Configuration: Any

Reproducibility: 100%

Description: DATAFLT alarm should be raised whenever the configuration file has been found corrupted. Then it should be cleared when a correct file is loaded. Actually, if the ConfFile (ONS15216DataBase) in FFS is replaced with a corrupted one through FTP, after an INIT-SYS no DATAFLT alarm is raised. This alarm should be raised in the case where it should signal the abnormal condition so that the user can be aware that the system is working with default settings and take appropriate actions.

Workaround: Use TL1 or SNMP commands to restore database file.

CSCed51490: PWRBUSMODE is Not Restored on Database Restore Operation

Configuration: Any

Reproducibility: 100%

Description: Start with two nodes, NE1 and NE2. NE1 has PWRBUSMODE=Simplex. After configuration file restoration from NE1 to NE2, the PWRBUSMODE for NE2 is set to Duplex following an EDFA3 reset if NE2 is not in the simplex condition (only power feed A is used as power supply).

Workaround: Change power feed connections so that only power feed A is used as a power supply, then change the PUWERBUSMODE to Simplex mode.

CSCed70378: TCP Connections Reset on Running SNMP

Configuration: Any

Reproducibility: Sometimes

Description: Under some conditions, FTP connection and TL1 session through Telnet may drop when UDP packets are intensively sent.

Workaround: Re-establish TCP connections after SNMP stress is finished.

CSCee28970: Time Zone Offset is Zero after Setting

Configuration: Any

Reproducibility: 100%

Description: The time of day offset (timezone) is set to zero after setting, and the offset is applied to the time. That is to say, instead of maintaining an offset value of -4 hours, the time of day is decreased four hours and the offset is zeroed. This is not the correct behavior: the offset value should persist after it is set.

Workaround: None

CSCee54597: TCP Resets Sent on Invalid Seq # Causing TCP Connection Drop

Configuration: Any

Reproducibility: 100%

Description: After a session is established, if a TCP Reset is injected the TCP connection can drop.

Workaround: None

CSCuk50621: Traptable Deleted after 3 Hours of Stress Test

Configuration: Any

Reproducibility: Yes

Description: The traptable gets erased after around 3 hours of stress tests.

Expectation: Stress tests should not create any problem in traptable.

Steps to reproduce: 2 scripts were running in parallel. Script 1: continuous threshold changing of line1rxpwr threshold; Script 2: continuous actions of database backup and restore.

Workaround: Telnet into TL1 port and set the snmp trap table again.

TL1 Related:

CSCec54194: REPT EVT FXFER Message is Not Raised

Configuration: Any

Reproducibility: 100%

Description: REPT EVT FXFER autonomous message should be raised (on any session) whenever a file transfer is performed. Actually, the agent does not raise such an event, nor it is displayed through RTRV-AO command except during the software download.

Workaround: None

CSCec86280: ED-DAT Requires Optional Fields as Mandatory

Configuration: Any

Reproducibility: 100%

Description: As per Telcordia GR-199, syntax for ED-DAT is: ED-DAT:[a]::c::[e][,f]; where [e] and [f] are DATE and TIME. Actually, the agent requires both fields as mandatory when they should be optional:


>ED-DAT:::CTAG::,17-00-00;

EDFA3-220 2002-07-10 16:00:03
M CTAG DENY
IPMS
/* Invalid Payload block. Missing mandatory field. */
;


>ED-DAT:::CTAG::2002-06-10,;

EDFA3-220 2002-07-10 16:00:04
M CTAG DENY
IPMS
/* Invalid Payload block. Missing mandatory field. */
;

Workaround: Enter both Date and Time fields.

CSCed00320: CPY-MEM Should Fail if the Destination File Already Exists

Configuration: Any

Reproducibility: 100%

Description: CPY-MEM should fail if the destination file already exists:


>CPY-MEM:::CT8G; (this creates aologA1.txt as copy of aologA.txt)

edfa3 2003-11-13 15:59:33
M CT8G COMPLD
/* CPY-MEM */
;
>CPY-MEM:::CT8G;

edfa3 2003-11-13 15:59:35
M CT8G COMPLD
/* CPY-MEM */
;

Workaround: Backup aologA1.txt or copy it to another file before CPY-MEM default command.

CSCed11459: RTRV-AO Filters by MSGTYPE Only if ATAGSEQ is Specified

Configuration: Any

Reproducibility: 100%

Description: RTRV-AO filtering by message type (MSGTYPE) seems to work fine only if ATAGSEQ parameter also is specified, whereas, in its absence, it should apply to the latest 20 messages (since ATAGSEQ null defaults to latest 20 messages).


>RTRV-AO:::sss;

<..output cut...>


svt_mz_233 2003-11-25 14:24:38
A 13 REPT EVT EQPT
"PWR-A:PWRBUSA,TC,11-25,14-24-38,,, 0.0,40.0,:\"Power BusA Alarm \""


svt_mz_233 2003-11-25 14:26:26
A 14 REPT EVT EQPT
"EQPT:SEVERITYCHGD,TC,11-25,14-26-26,,,MN,NA,:\"Severity Changed \""


svt_mz_233 2003-11-25 14:26:26
* 15 REPT ALM EQPT
"PWR-A:MN,PWRBUSA,NSA,11-25,14-24-38,,0.0,:\"Power BusA Alarm \""


svt_mz_233 2003-11-25 14:27:26
A 16 REPT ALM EQPT
"PWR-A:CL,PWRBUSA,NSA,11-25,14-24-38,,45.8,:\"Power BusA Alarm \""



*/
;
>rtrv-ao:::sss:::msgtype=evt;

svt_mz_233 2003-11-25 15:55:42
M sss COMPLD
;
>

>rtrv-ao:::sss:::atagseq=11&&13,msgtype=evt;

svt_mz_233 2003-11-25 15:57:54
M sss COMPLD
/*


svt_mz_233 2003-11-25 14:24:38
A 11 REPT EVT EQPT
"EQPT:SEVERITYCHGD,TC,11-25,14-24-38,,,NA,MN,:\"Severity Changed \""


svt_mz_233 2003-11-25 14:24:38
A 13 REPT EVT EQPT
"PWR-A:PWRBUSA,TC,11-25,14-24-38,,, 0.0,40.0,:\"Power BusA Alarm \""


*/
;

Workaround: Use RTRV-AO to retrieve the latest 20 records by specifying the last 20 records in the ATAGSEQ field.

CSCed13258: CPY-MEM does Not Work if Fromfile Not Specified

Configuration: Any

Reproducibility: 100%

Description: CPY-MEM is not working when fromfile is not specified except if none of the other params are specified:


>CPY-MEM:::Af9::,FFS,aologA2.txt;

EDFA3-235 2003-10-21 07:13:08
M Af9 DENY
IDNV
/* INPUT, Data Not Valid */
;
>CPY-MEM:::Af9::,FFS,aologA2.txt;

EDFA3-235 2003-10-21 07:13:21
M Af9 DENY
IDNV
/* INPUT, Data Not Valid */
;
>CPY-MEM:::Af9::aologA.txt,FFS,aologA2.txt;

EDFA3-235 2003-10-21 07:14:01
M Af9 COMPLD
/* CPY-MEM */
;

Workaround: Specify all optional parameters in the CPY-MEM command.

CSCed28597: Inconsistent RTRV-AO Outputs for Hard and Soft Resets

Configuration: Any

Reproducibility: 100%

Description: There is an issue regarding RTRV-AO output after software and hardware reset. The EDFA3 fiber needs to work at a certain temperature. After hardware reset, the fiber temperature may not reach the fiber working temperature. The FTMP alarm might be raised after hardware reset and then cleared in several seconds. For software reset, the fiber temperature control will not be affected, thus no FTMP alarm observed in RTRV-AO command after software reset.

Actually what happens is that the output is different after software reset than it is after hardware reset:


After a HW reset:

>rtrv-ao:::sss;

EDFA3-220 2003-10-11 15:54:54
M sss COMPLD
/*


EDFA3-220 2003-10-11 15:53:02
* 0 REPT ALM EQPT
"EQPT:MN,FTMP,NSA,10-11,15-52-58,,0.0,:\"Fiber Temperature Out of Range\""


EDFA3-220 2003-10-11 15:53:03
*C 1 REPT ALM DWDM
"1:CR,LINE1RXPWRFL,SA,10-11,15-52-58,,-60.0,:\"Power Fail Low, LINE1RX Port\""


EDFA3-220 2003-10-11 15:53:05
A 2 REPT ALM EQPT
"EQPT:CL,FTMP,NSA,10-11,15-53-01,,47.3,:\"Fiber Temperature Out of Range\""

*/
;

After INIT-SYS:

>rtrv-ao:::sss;

EDFA3-220 2003-10-11 15:56:45
M sss COMPLD
/*


EDFA3-220 2003-10-11 15:55:43
*C 0 REPT ALM DWDM
"1:CR,LINE1RXPWRFL,SA,10-11,15-55-40,,0.0,:\"Power Fail Low, LINE1RX Port\""

*/
;

Workaround: None

CSCed29763: Incorrect Error Code for ED-PID Using Wrong Password Format

Configuration: Any

Reproducibility: 100%

Description: The agent returns an incorrect error code and message when ED-PID is used with incorrect password format.


>ed-pid:edfa3:roby12:sss::********,**********;

EDFA3 2003-10-12 14:44:47
M sss DENY
PIUI
/* Privilege, Illegal User Identity */
;
>

Whereas it should return as follows:


>ed-pid::roby12:sss::********,**********;

EDFA3 2003-10-12 14:44:47
M sss DENY
PICC
/* Invalid User Password - Must Conform To TL1 Rules */
;
>

Workaround: None

CSCed32140: RTRV-STATUS Information is Lost if a Reset Occurs

Configuration: Any

Reproducibility: 100%

Description: RTRV-STATUS should return users' connection status for past 1 day period. Actually this is true unless a reset occurs. In such a case, in fact, RTRV-STATUS does not return the information prior to the reset, as shown in the report below.


>rtrv-status:edfa3:2003-10-16,17-16-05:ddd;

EDFA3 2003-10-16 17:16:16
M ddd COMPLD
"2003-10-16,17-16-05:,CISCO15,"
"2003-10-16,17-16-05:,roby12,"
;
>init-sys::eqpt:sss::1;

EDFA3 2003-10-16 17:16:27
A 2 REPT EVT EQPT
"EQPT:SOFTWARERESET,TC,10-16,17-16-27,,,,,:\"Software Reset \""
;

EDFA3 2003-10-16 17:16:28
M sss COMPLD
/* INIT-SYS */
;
>
[10.51.125.220: remote disconnect]


>ACT-USER::CISCO15:login;

EDFA3 2003-10-16 17:21:17
M login COMPLD
;
>rtrv-status:edfa3:2003-10-16,17-16-05:xxx;

EDFA3 2003-10-16 17:21:27
M xxx COMPLD
/* RTRV-STATUS */
;
>

Workaround: None

CSCee16718: EDFA3 does Not Allow Multiple Tl1 Logins with the Same Username

Configuration: Any

Reproducibility: 100%

Description: Multiple TL1 sessions for a single user are not permitted.

Workaround: Create a unique login username for each TL1 session needed.

CSCee38090: Soft Reset Clears the EDFA3 AO Log

Configuration: Any

Reproducibility: 100%

Description: The TL1 Autonomous Output log is cleared if a soft reset is performed on the EDFA3 using the INIT-SYS command. The AO log should be preserved even through a soft reset or power cycle.

Workaround: Retreive the AO log from the FFS before soft reset.

CSCee43774: ED-PID does Not Work for Default CISCO15 User and Blank Password

Configuration: Any

Reproducibility: 100%

Description: ED-PID doesn't work for the default CISCO15 user with blank password. The only way to change the default password is using the ED-USER-SECU command.

Steps to reproduce:

>ED-PID::CISCO15:123::,******;

EDFA3 2003-10-16 00:55:24
M 123 DENY
IPMS
/* Invalid Payload block. Missing mandatory field. */
;

Workaround: None

CSCee56954: RTRV-STATUS does not Retrieve Info of Prior Users after Soft Reset

Configuration: Any

Reproducibility: 100%

Description: When the command RTRV-STATUS is executed after a soft reset to the EDFA3, the command does not return user information of users connected prior to the reset. This behavior is not intended.

Workaround: Use RTRV-STATUS before soft reset to get the connected users.

CSCuk47379: RPT EVT FXFR does Not Output the File Name Transferred

Configuration: Any

Reproducibility: 100%

Description: The RPT EVT FXFR is not providing the filename of the file transferred.

Expectation: The RPT EVT FXFR should output.

Steps to reproduce: Open a TL1 session in order to listen to the TL1 events. Issue a software download by SNMP with correct source and destination file locations. The TL1 will display the events of start and end of software download but the file name is not present.

Workaround: None

CSCuk49967: RTRV-USER-SECU: No Error Message or Wrong Description

Configuration: Any

Reproducibility: 100%

Description: The following cases illustrate the issue.

First case: Login with user pippo1 and privilege RW. Type rtrv-user-secu::jsmith:ooo; where jsmith is an existing userid (different from pippo1) with RWA privilege. The Error Message description is null.

>rtrv-user-secu::jsmith:ooo;

EDFA3_168 2004-04-13 04:27:25
M ooo DENY
PIUC
/* */
;
>

- type rtrv-user-secu::all:ppp; The Error Message description is null.

>rtrv-user-secu::all:ppp;

EDFA3_168 2004-04-13 04:27:45
M ppp DENY
PIUC
/* */
;
>

Second case: Login with user pippo1 and privilege RW. Type rtrv-user-secu::jsmith:ooo; where jsmith is a nonexistant user

>rtrv-user-secu::jsmith:ooo;

EDFA3_168 2004-04-13 08:47:08
M ooo DENY
PIUC
/* PRIVILEGE, Illegal User Code */
;

Create the jsmith user with RWA privilege in another session.

>rtrv-user-secu::jsmith:ooo;
EDFA3_168 2004-04-13 08:47:57
M ooo DENY
PIUC
/* 12 */
;
>

The Error Message contains an incorrect description.

>rtrv-user-secu::pippo1:ooo;

EDFA3_168 2004-04-13 08:48:40

M ooo DENY

PIUC

/* 12 */

;

>rtrv-user-secu::pippo1:ooo;

EDFA3_168 2004-04-13 08:52:18

M ooo DENY

PIUC

/* */

;

>

After repeating the rtrv-user-secu command twice, the Error Message contains a null description. >rtrv-user-secu::pippo1:ooo;

EDFA3_168 2004-04-13 08:52:25

M ooo DENY

PIUC

/* */

;

>

Workaround: None

SNMP Related:

CSCed38871: Default Value of cerent15216EdfaOprnSrcFileLoc Should Not Show a FQDN

Configuration: Any

Reproducibility: 100%

Description: Default value of cerent15216EdfaGenericOprnsSrcFileLoc shows a Fully Qualified Domain Name (FQDN), instead of an IP address (whereas the MIB describes it correctly specifying an IP address). Thus the user could think that entering a domain name, such as ftp.cisco.com, could be acceptable whereas it needs be an IP address.

Workaround: Use an IP address for the SrcFileLoc.

CSCed76891: Execution of SNMP Commands Might be Delayed

Configuration: Any

Reproducibility: Sometimes

Description: The EDFA3 might take a long time to respond to good packets sent after bad packets through SNMP commands. The response time can be up to 2 minutes.

Workaround: None

CSCee27759: EDFA3 SoftwareDownloadFailed Trap does Not Have Trailing 0.

Configuration: Any

Reproducibility: 100%

Description: cerent15216EdfaGenericSoftwareDownloadFailed trap does not come with trailing 0. like cerent15216EdfaGenericSoftwareDownloadFailed.0.

Workaround: None

CSCuk46631: Source File Location is Not Correctly Inserted

Configuration: Any

Reproducibility: 100%

Description: It is not possible to set the source file location with the correct format for the object CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericOprnsSrcFileLoc. The same issue is present also on the object cerent15216EdfaGenericOprnsDestFileLoc.

Expectation: The user should be able to set the source file location with the format specified in the MIB file.

Steps to reproduce:

Set CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericOprnsSrcFileLoc.0 "ftp://ctmsvt:ctm123!@jodie.cisco.com/ONS15216Edfa3-0.4.1-003H-22.21"

The set fails, but it should succeed.

Workaround: Use two forward slashes between the user ID and the file name.

Set CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericOprnsSrcFileLoc.0 "ftp://ctmsvt::ctm123!@jodie.cisco.com//ONS15216Edfa3-0.4.1-003H-22.21" CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericOprnsSrcFileLoc.0: Passed

CSCuk47036: SNMP:Log Table Entries Change Time with Software Download and Cutover

Configuration: Any

Reproducibility: 100%

Description:

After software upgrade and cutover, the event log entries change the time stamp (nlmLogDateAndTime). As nlmLogDateAndTime is the date and time of the event when it occurred, it should always be the same across rebooting and software download + cutover.

Steps to reproduce:

snmpwalk on the nlmLogTable - software download and cutover, then wait for the NE to come up. snmpwalk on the nlmLogTable compare the entries for nlmLogDateAndTim; they will be different. See below:


(before)
NOTIFICATION-LOG-MIB::nlmLogTime."".1 = Timeticks: (197) 0:00:01.97
NOTIFICATION-LOG-MIB::nlmLogTime."".2 = Timeticks: (199) 0:00:01.99
NOTIFICATION-LOG-MIB::nlmLogTime."".3 = Timeticks: (199) 0:00:01.99
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".1 = STRING: 2003-10-21,17:43:24.1
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".2 = STRING: 2003-10-21,17:43:24.1
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".3 = STRING: 2003-10-21,17:43:24.1
NOTIFICATION-LOG-MIB::nlmLogEngineID."".1 = ""
NOTIFICATION-LOG-MIB::nlmLogEngineID."".2 = ""
NOTIFICATION-LOG-MIB::nlmLogEngineID."".3 = ""
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".1 = Hex-STRING: 0A 5C 1B A8
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".2 = Hex-STRING: 0A 5C 1B A8
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".3 = Hex-STRING: 0A 5C 1B A8
NOTIFICATION-LOG-MIB::nlmLogEngineTDomain."".1 = OID: SNMPv2-TM::snmpUDPDomain
NOTIFICATION-LOG-MIB::nlmLogEngineTDomain."".2 = OID: SNMPv2-TM::snmpUDPDomain
NOTIFICATION-LOG-MIB::nlmLogEngineTDomain."".3 = OID: SNMPv2-TM::snmpUDPDomain
NOTIFICATION-LOG-MIB::nlmLogContextEngineID."".1 = ""
NOTIFICATION-LOG-MIB::nlmLogContextEngineID."".2 = ""
NOTIFICATION-LOG-MIB::nlmLogContextEngineID."".3 = ""
NOTIFICATION-LOG-MIB::nlmLogContextName."".1 = STRING: public
NOTIFICATION-LOG-MIB::nlmLogContextName."".2 = STRING: public
NOTIFICATION-LOG-MIB::nlmLogContextName."".3 = STRING: public
NOTIFICATION-LOG-MIB::nlmLogNotificationID."".1 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericEdfa3PwrAlarmBusA NOTIFICATION-LOG-MIB::nlmLogNotificationID."".2 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericEdfa3PwrAlarmBusB NOTIFICATION-LOG-MIB::nlmLogNotificationID."".3 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericEdfa3PwrFailureLowLine1Rx

(after)
NOTIFICATION-LOG-MIB::nlmLogTime."".1 = Timeticks: (197) 0:00:01.97
NOTIFICATION-LOG-MIB::nlmLogTime."".2 = Timeticks: (199) 0:00:01.99
NOTIFICATION-LOG-MIB::nlmLogTime."".3 = Timeticks: (199) 0:00:01.99
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".1 = STRING: 2003-10-21,17:56:14.1
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".2 = STRING: 2003-10-21,17:56:14.1
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".3 = STRING: 2003-10-21,17:56:14.1
NOTIFICATION-LOG-MIB::nlmLogEngineID."".1 = ""
NOTIFICATION-LOG-MIB::nlmLogEngineID."".2 = ""
NOTIFICATION-LOG-MIB::nlmLogEngineID."".3 = ""
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".1 = Hex-STRING: 0A 5C 1B A8
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".2 = Hex-STRING: 0A 5C 1B A8
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".3 = Hex-STRING: 0A 5C 1B A8
NOTIFICATION-LOG-MIB::nlmLogEngineTDomain."".1 = OID: SNMPv2-TM::snmpUDPDomain
NOTIFICATION-LOG-MIB::nlmLogEngineTDomain."".2 = OID: SNMPv2-TM::snmpUDPDomain
NOTIFICATION-LOG-MIB::nlmLogEngineTDomain."".3 = OID: SNMPv2-TM::snmpUDPDomain
NOTIFICATION-LOG-MIB::nlmLogContextEngineID."".1 = ""
NOTIFICATION-LOG-MIB::nlmLogContextEngineID."".2 = ""
NOTIFICATION-LOG-MIB::nlmLogContextEngineID."".3 = ""
NOTIFICATION-LOG-MIB::nlmLogContextName."".1 = STRING: public
NOTIFICATION-LOG-MIB::nlmLogContextName."".2 = STRING: public
NOTIFICATION-LOG-MIB::nlmLogContextName."".3 = STRING: public
NOTIFICATION-LOG-MIB::nlmLogNotificationID."".1 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericEdfa3PwrAlarmBusA NOTIFICATION-LOG-MIB::nlmLogNotificationID."".2 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericEdfa3PwrAlarmBusB NOTIFICATION-LOG-MIB::nlmLogNotificationID."".3 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericEdfa3PwrFailureLowLine1Rx

Workaround: None

CSCuk47292: EDFA3 does Not Reboot after Changing IP Address by SNMP

Configuration: Any

Reproducibility: 100%

Description: The EDFA3 does not reboot upon changing the IPaddress setting with the object cerent15216EdfaGenericIpAddress.0

Expectation: The behavior should be the same as in TL1; in other words, the EDFA3 should reboot upon changing the IP address.

Steps to reproduce: Set up the EDFA with the current IP address of 10.51.100.240. Issue the following command: snmpset -v 2c 10.51.100.233 cerent15216EdfaGenericIpAddress.0 = IpAddress: 10.51.100.233 then the command snmpget -v 2c 10.51.100.233 cerent15216EdfaGenericIpAddress.0 returns the just set value. So, the SNMP set succeeds but the EDFA3 does not reboot.

Workaround: Issue the reboot command after changing the IP address.

CSCuk47321: cerent15216EdfaGenericEdfa3DataIntegrityFault Trap is Not Raised

Configuration: Any

Reproducibility: 100%

Description: cerent15216EdfaGenericEdfa3DataIntegrityFault is not raised upon rebooting with a wrong ONS 15216 database file.

Expectation: After having replaced the ONS 15216 database with a faulty one and rebooted the EDFA, the NE should recognize the faulty database and emit the trap.

Steps to reproduce: ftp to the EDFA, get the ONS 15216 database file. Edit the file and change it, reducing its size. ftp again on the EDFA and put the newly created ONS 15216 database reboot the EDFA. The EDFA reboots. Get the Logtable. There will not be any entry corresponding at the trap cerent15216EdfaGenericEdfa3DataIntegrityFault.

TL1: Same issue stands for TL1. DATAFLT alarm is not raised.

Workaround: When EDFA3 boots up with wrong database, the EDFA3 will start with default configurations.

CSCuk47329: the Counter for Snmpouttoobigs does Not Increment Properly

Configuration: Any

Reproducibility: 100%

Description: The counter for snmpOutTooBigs does not increment properly.

Steps to reproduce: Simple Tester automated script snmpOutTooBigs.

Workaround: None

CSCuk47330: the Counter for Snmpinbadcommunityuses does Not Increment Properly

Configuration: Any

Reproducibility: 100%

Description: The counter for snmpInBadCommunityUses does not increment properly.

Expectation: The counter value should increment at least by the number of SNMP-Set requests sent with a community name not valid for the same operation.

Steps to reproduce: Automated script for snmpInBadCommunityUses.

Workaround: None

CSCuk47512: Software Download Fails with ftp Port Specified in OprnsSrcFileLoc

Configuration: Any

Reproducibility: 100%

Description: Software download fails when, on cerent15216EdfaGenericOprnsSrcFileLoc, the format string contains an ftp port number. Because the ftp port number can be different from the default one, the string must accept a port number, as defined in the specifications.

Steps to reproduce:

Set cerent15216EdfaGenericOprnsSrcFileLoc.0 = "ftp://ctmsvt:ctm456%@144.254.170.138:21/ONS15216Edfa3-0.4.7-003J-27.18"
Set cerent15216EdfaGenericOprnsDestFileLoc.0 =
"/fd1/ONS15216Edfa3-0.4.7-003J-27.18"
Set cerent15216EdfaGenericOprnsMode.0 = 4

With this sequence the software download is not even initiated. If a user inputs the string without the ftp port. As an example below, the software download succeeds.:

Set cerent15216EdfaGenericOprnsSrcFileLoc.0 = "ftp://ctmsvt:ctm456%@144.254.170.138/ONS15216Edfa3-0.4.7-003J-27.18"
Set cerent15216EdfaGenericOprnsMode.0 = 4

Workaround: Download succeeds with the default ftp port and without specifying it on the cerent15216EdfaGenericOprnsSrcFileLoc object.

CSCuk47855: SNMP linkUp and linkDown Traps are Logged Twice

Configuration: Any

Reproducibility: 100%

Description: The linkUp and linkDown traps are logged twice in the nlmLogVariableID and nlmLogVariableOidVal objects.

Expectation: Only one instance of the traps should be logged for the same event.

Steps to reproduce: Generate a linkDown linkUp traps by disconnecting and reconnecting the Ethernet cable. Issue an snmpwalk operation. Part of the output for snmpwalk on nlmlog will be something like:


NOTIFICATION-LOG-MIB::nlmLogVariableID."".20.1 = OID: IF-MIB::linkDown.0.0.0.0 NOTIFICATION-LOG-MIB::nlmLogVariableID."".21.1 = OID: IF-MIB::linkDown.0.0.0.0 NOTIFICATION-LOG-MIB::nlmLogVariableID."".22.1 = OID: IF-MIB::linkUp.0.0.0.0 NOTIFICATION-LOG-MIB::nlmLogVariableID."".23.1 = OID: IF-MIB::linkUp.0.0.0.0

Workaround: None

CSCuk47891: DownloadInProgress Trap Should Not be in ProfileTable

Configuration: Any

Reproducibility: 100%

Description: The trap cerent15216EdfaGenericSoftwareDownloadInProgress corresponds to an event and so it should not be in the cerent15216EdfaGenericEventProfileTable.

Steps to reproduce: Issue an snmpwalk on cerent15216EdfaGenericEventProfileTable. The result gives, among other lines CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericEventProfileEvent.23 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSoftwareDownloadInProgress.0 This entry should not be there, as it is an event.

Workaround: None. The Download in Progress trap is always an event and cannot be changed.

CSCuk47912: the User Cannot Set entPhysicalAlias.1 Object

Configuration: Any

Reproducibility: 100%

Description: It is not possible to set the entPhysicalAlias.1 object.

Steps to reproduce:


bash-2.03$ snmpset -v 2c -d 10.51.100.233 entPhysicalAlias.1 = test

Sending 51 bytes to 10.51.100.233
0000: 30 31 02 01 01 04 06 6E 69 63 6F 6C 61 A3 24 02 01.....edfa3Ј$.
0016: 04 4F 54 C3 33 02 01 00 02 01 00 30 16 30 14 06 .OTГ3......0.0..
0032: 0C 2B 06 01 02 01 2F 01 01 01 01 0E 01 04 04 74 .+..../........t
0048: 65 73 74 est


Received 51 bytes from 10.51.100.233
0000: 30 31 02 01 01 04 06 6E 69 63 6F 6C 61 A2 24 02 01.....edfa3ў$.
0016: 04 4F 54 C3 33 02 01 00 02 01 00 30 16 30 14 06 .OTГ3......0.0..
0032: 0C 2B 06 01 02 01 2F 01 01 01 01 0E 01 04 04 74 .+..../........t
0048: 65 73 74 est

ENTITY-MIB::entPhysicalAlias.1 = STRING: test

It seems that the value has been correctly inserted, but with an snmpget...

bash-2.03$ snmpget -v 2c -d 10.51.100.233 entPhysicalAlias.1

Sending 47 bytes to 10.51.100.233
0000: 30 2D 02 01 01 04 06 6E 69 63 6F 6C 61 A0 20 02 0-.....edfa3 .
0016: 04 36 B1 49 5F 02 01 00 02 01 00 30 12 30 10 06 .6±I_......0.0..
0032: 0C 2B 06 01 02 01 2F 01 01 01 01 0E 01 05 00 .+..../........


Received 57 bytes from 10.51.100.233
0000: 30 37 02 01 01 04 06 6E 69 63 6F 6C 61 A2 2A 02 07.....edfa3ў$*.
0016: 04 36 B1 49 5F 02 01 00 02 01 00 30 1C 30 1A 06 .6±I_......0.0..
0032: 0C 2B 06 01 02 01 2F 01 01 01 01 0E 01 04 0A 74 .+..../........t
0048: 65 73 74 6C 61 31 32 33 25 estla123%

ENTITY-MIB::entPhysicalAlias.1 = STRING: testla123%

Workaround: None

CSCuk47975: Node Time does Not Approximate Correctly to the First Decimal Digit

Configuration: Any

Reproducibility: 100%

Description: By SNMP, retrieving the object cerent15216EdfaGenericNodeTime.0 returns a value that always has the first decimal digit set to 1.

Steps to reproduce:

bash-2.03$ snmpwalk -v 2c 10.51.100.233 edfa | grep Time CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericNodeTime.0 = STRING: 2003-12-15,12:0:30.1 CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSoftwareTimeStamp.1 = STRING: 2003-12-15,9:20:14.1 CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSoftwareTimeStamp.2 = STRING: 9-6-20,9:20:14.1 another time bash-2.03$ snmpwalk -v 2c 10.51.100.233 edfa | grep Time CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericNodeTime.0 = STRING: 2003-12-15,12:13:0.1 CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSoftwareTimeStamp.1 = STRING: 2003-12-15,9:20:14.1 CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSoftwareTimeStamp.2 = STRING: 9-6-20,9:20:14.1 and again bash-2.03$ snmpwalk -v 2c 10.51.100.233 edfa | grep Time CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericNodeTime.0 = STRING: 2003-12-15,12:13:19.1 CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSoftwareTimeStamp.1 = STRING: 2003-12-15,9:20:14.1 CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSoftwareTimeStamp.2 = STRING: 9-6-20,9:20:14.1

Workaround: None

Obtaining Documentation

Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation on the World Wide Web at this URL:

http://www.cisco.com/univercd/home/home.htm

You can access the Cisco website at this URL:

http://www.cisco.com

International Cisco web sites can be accessed from this URL:

http://www.cisco.com/public/countries_languages.shtml

Obtaining Documentation

You can find instructions for ordering documentation at this URL:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

You can order Cisco documentation in these ways:

Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/en/US/partner/ordering/index.shtml

Registered Cisco.com users can order the Documentation CD-ROM (Customer Order Number DOC-CONDOCCD=) through the online Subscription Store:

http://www.cisco.com/go/subscription

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.

You can e-mail your comments to bug-doc@cisco.com.

You can submit your comments by mail by using the response card behind the front cover of your document or by writing to the following address:

Cisco Systems

Attn: Customer Document Ordering

170 West Tasman Drive

San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

For all customers, partners, resellers and distributors who hold valid Cisco Service Contracts, the Cisco Technical Assistance Center (TAC) provides 24-hour a day, award-winning technical support services, both online and over the phone. Cisco.com features the Cisco TAC website as an online starting point for technical assistance. If you do not hold a valid Cisco Service Contract, please contact your reseller.

Cisco TAC Website

The online Cisco TAC Case Open Tool provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The Cisco TAC website is available 24 hours a day, 365 days a year. The Cisco TAC website is located at this URL:

http://www.cisco.com/tac

Accessing all the tools on the Cisco TAC website requires a Cisco.com user ID and password. if you have a valid Service Contract but do not have a user ID or password, register at this URL:

http://tools.cisco.com/RPF/register/register.do

Opening a TAC Case

Using the online TAC Case Open Tool is the fastest way to open P3 and P4 cases. (P3 and P4 cases are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Case Open Tool automatically recommends resources for an immediate solution. If your issue is not resolved using the recommended resources, your case will be assigned to a Cisco Engineer. The online TAC Case Open Tool is available at this URL:

http://www.cisco.com/tac/caseopen

For P1 or P2 cases, (cases in which your production network is down or severely degraded) or if you do not have Internet access, contact TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to keep your business operations running smoothly.

To open a case by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)

EMEA: +32 2 704 55 55

USA: 1 800 553-2447

For a complete listing of Cisco TAC contacts, go to this URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

TAC Case Priority Definitions

To ensure that all cases are reported in a standard format, Cisco has established case priority definitions:

Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Priority level 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operations are negatively affected by inadequate performance of Cisco products.You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Priority level 3 (P3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit full-time resources during normal business hours to restore service to satisfactory levels.

Priority level 4 (P4)—You require information or assistance with Cisco product capabilities, installation, or configuration. there is little or no effect on your business operation.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

Cisco Marketplace provides a variety of Cisco books, reference guides and logo merchandise. Go to this URL to visit the company store:

http://www.cisco.com/go/marketplace

The Cisco Product Catalog describes the networking products offered by Cisco Systems as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:

http://www.cisco.com/en/US/products/products_catalog_links_launch.html

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these materials. For current Cisco Press titles and other information, go to Cisco Press online at this URL:

http://www.ciscopress.com

Packet magazine is the Cisco quarterly publication that provides the latest in networking trends, technology breakthroughs and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are network deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information and links to numerous in-depth online resources. You can access Packet magazine at this URL:

http://www.cisco.com/en/US/about/ac123/ac114/about_cisco_packet_magazine.html

iQ Magazine is the Cisco monthly periodical that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:

http://business.cisco.com/prod/tree.taf%3fasset_id=44699&public_view=true&kbns=1.html

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in the design, development, and operation of public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html

Training—Cisco offers world-class networking training, with current offerings in network training listed at this URL:

http://www.cisco.com/en/US/learning/le31/learning_recommended_training_list.html


hometocprevnextglossaryfeedbacksearchhelp

Posted: Sun Apr 2 01:00:10 PST 2006
All contents are Copyright © 1992--2006 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.