Release Notes for Cisco ONS 15216 EDFA3, Release 1.0

Table Of Contents

Release Notes for Cisco ONS 15216 EDFA3 Version 1.0

Contents

Caveats

Hardware Caveats

Software Caveats

Open Software Caveats

Obtaining Documentation

Cisco.com

Ordering Documentation

Cisco Optical Networking Product Documentation CD-ROM

Documentation Feedback

Obtaining Technical Assistance

Cisco TAC Website

Opening a TAC Case

TAC Case Priority Definitions

Obtaining Additional Publications and Information

Release Notes for Cisco ONS 15216 EDFA3 Version 1.0

February, 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

Caveats

Obtaining Documentation

Documentation Feedback

Obtaining Technical Assistance

Obtaining Additional Publications and Information

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.

Hardware Caveats

There are no hardware caveats for this release.

Software Caveats

Open Software Caveats

CSCec47531: EDFA3 loss of date setting after power off

•Configuration: Any

•Reproducibility: 100%

•Description: The Date and Time setting are lost after power cycle EDFA3 module.

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

CSCec54194: REPT EVT FXFER message is not raised

•Configuration: Any

•Reproducibility: 100%

•Description:

REPT EVT FXFER autonomous message is supposed to 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 the software download.

•Workaround: None

CSCec58393: Alarm log files do not log events/alarms if FFS gets full

•Configuration: Any

•Reproducibility: 100%

•Description:

When the FFS gets full (e.g. because of more than 3 uploaded sw images), the alarm log files, both TL1 and SNMP stop getting updated and do not record any further event or alarm that is raised, until some 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.

CSCec86280: ED-DAT requires optional fields as mandatory

•Configuration: Any

•Reproducibility: 100%

•Description:

As per 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 whereas 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.

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

•Configuration: Any

•Reproducibility: 100%

•Description:

The problem was 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 has been decreased fast (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

CSCed00320: CPY-MEM should fail if destination file already exists

•Configuration: Any

•Reproducibility: 100%

•Description:

CPY-MEM should fail if 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 */
;
>rtrv-rfile:::ss;

edfa3 2003-11-13 15:59:41
M ss COMPLD
"EQPT:ONS15216DataBase,10456"
"EQPT:aologA.txt,180000"
"EQPT:aologB.txt,9433"
"EQPT:aologA1.txt,180000"
"EQPT:snmpNotifyLogA,71932"
"EQPT:ONS15216Edfa3-0.4.9-003K-13.13,4257706"
"EQPT:snmpNotifyLogB,200704"
"EQPT:ONS15216Edfa3-0.4.7-003J-27.18,4181038"
;

A-enclosure: Added 031209 by qddts

Not properly fixed in 0.4.13: completes with default parameters, does not if they are specified:

>CPY-MEM:::CT8G:;

EDFA3-234 2003-12-07 05:40:55
M CT8G COMPLD
/* CPY-MEM */
;
>CPY-MEM:::CT8G:;

EDFA3-234 2003-12-07 05:40:58
M CT8G COMPLD
/* CPY-MEM */
;

>CPY-MEM:::CT8G::aologA.txt,FFS,aologA1.txt;

EDFA3-234 2003-12-07 05:43:19
M CT8G DENY
SROF
/* STATUS, Request Operation Fail, To File Already Exist */
;
>

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

rtrv-AO for default latest 20 record, then specify the last 20 records instead of default in ATAGSEQ field.

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, hence arises the need for password recovery procedure if a user wants to perform RWA restricted operations such as INIT-SYS or RTRV-USER-SECU or ENT-USER-SECU etc.

•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 */
;

•Workaround: Soft reset the EDFA3, and use user recovery procedure to create the CISCO15.RWA user.

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: The TL1 automessages are automatically saved into aologA.txt and aologB.txt.

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 (i.e. after the INIT-SYS), with the current value of the device on which the restore took place. For example, if a DB restore is performed from NE1 (10.51.125.235) to NE2 (10.51.125.234), and say we have NE1 DB file Header:

ActiveSoftwareName=ONS15216Edfa3-00.04.12-003K-26.18 NodeName=EDFA3-235 IP-Address=10.51.125.235 then, after the DB restore is done onto NE2, NE2 DB 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 the user performs a second reset the IPaddress is updated correctly.

CSCed25027: RTRV-TRAPTABLE may complete even if the entry is not present

•Configuration: Any

•Reproducibility: 100%

•Description:

In some conditions RTRV-TRAPTABLE completes without the relevant entry being present (whereas it should fail with message Invalid Access Identifier).

•Steps to reproduce:

>RTRV-TRAPTABLE::10.10.10.10:lk;

EDFA3-234 2003-12-13 07:48:57
M lk DENY
IIAC
/* Invalid Access Identifier (AID) */
;

[CORRECT, the entry is not present]

>ent-traptable::20.20.20.20:sss::;

EDFA3-234 2003-12-13 07:49:15
M sss COMPLD
/* ENT-TRAPTABLE */
;
>RTRV-TRAPTABLE::10.10.10.10:lk;

EDFA3-234 2003-12-13 07:49:21
M lk DENY
IIAC
/* Invalid Access Identifier (AID) */
;

[CORRECT, the entry is not present]

>dlt-traptable:::sss;

EDFA3-234 2003-12-13 07:49:30
M sss COMPLD
/* DLT-TRAPTABLE */
;
>RTRV-TRAPTABLE::10.10.10.10:lk;

EDFA3-234 2003-12-13 07:49:33
M lk COMPLD
/* RTRV-TRAPTABLE */
;
>

[INCORRECT, the entry is not present, it should be a DENY, as above]

Notice that the situation does not change even after an INIT-SYS

•Workaround: None

CSCed27333: DATAFLT alarm is not raised

•Configuration: Any

•Reproducibility: 100%

•Description:

DATAFLT alarm is supposed to 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 thru FTP, after an INIT-SYS no DATAFLT alarm is emitted. The question arises as to when this alarm is emitted if not in this 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.

CSCed28597: Inconsistent RTRV-AO/RTRV-ALM-xxx outputs

•Configuration: Any

•Reproducibility: 100%

•Description:

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

Actually what happens is that the output is different after Sw reset than it is after Hw 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 passwd 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

CSCed38871: Default value of cerent15216EdfaOprnSrcFileLoc shouldnt show a FQDN

•Configuration: Any

•Reproducibility: 100%

•Description:

Default value of cerent15216EdfaGenericOprnsSrcFileLoc shows a Fully Qualified Domain Name (FQDN), instead of an IPaddress (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 IPaddress.

•Workaround: Use an IP address for the SrcFileLoc.

CSCed51490: PWRBUSMODE is not restored on DB restore operation

•Configuration: Any

•Reproducibility: 100%

•Description:

Starting with NE1 having PWRBUSMODE=Simplex, after configuration file restoration from NE1 to NE2, the PWRBUSMODE for NE2 gets set to Duplex after 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 power supply, then change the PUWERBUSMODE to Simplex mode.

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 kind of bug 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!@jo die.cisco.com/ONS15216Edfa3-0.4.1-003H-22.21"

The set is successful, whilst it should fail.

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

The set is successful, whilst it should fail.

•Workaround: None

CSCuk47036: snmp:log table entries change time with sw download and cutover

•Configuration: Any

•Reproducibility: 100%

•Description:

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

•Steps to reproduce:

snmpwalk on the nlmLogTable - sw download and cutover, than wait for the ne to come up - snmpwalk on the nlmLogTable compare the entries for nlmLogDateAndTime, they will be different. see below:

(before)
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

(after)
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

•Workaround: None

CSCuk47292: EDFA3 does not reboot after changing ipaddress by snmp

•Configuration: Any

•Reproducibility: 100%

•Description:

The EDFA3 does not reboot upon changing the ipaddress setting by the object cerent15216EdfaGenericIpAddress.0

•Expectation:

The behaviour should be the same as per TL1, i.e. the EDFA3 should reboot upon changing the IP address.

•Steps to reproduce:

Let's suppose to have the EDFA with the current ip address of 10.51.100.240 I issue the following command: snmpset -v 2c 10.51.100.233 cerent15216EdfaGenericIpAddress.0 = IpAddress: 10.51.100.233 than the command snmpget -v 2c 10.51.100.233 cerent15216EdfaGenericIpAddress.0 return the just set value. So, the snmp set succeeeds 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 ONS15216DataBase file.

•Expectation:

After having replaced the ONS15216DataBase 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 ONS15216DataBase file, edit the file and change it, reducing its size. ftp again on the EDFA and put the newly created ONS15216DataBase 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 has not incremented properly

•Configuration: Any

•Reproducibility: 100%

•Description: The counter for snmpOutTooBigs has not incremented properly.

•Steps to reproduce: Automated SNMP test of snmpOutTooBigs counter.

•Workaround: None

CSCuk47330: The counter for snmpInBadCommunityUses has not incremented properly

•Configuration: Any

•Reproducibility: 100%

•Description: The counter for snmpInBadCommunityUses has not incremented 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

CSCuk47379: RPT EVT FXFR does not output the filename 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 as in specs.

•Steps to reproduce:

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

•Workaround: None

CSCuk47512: SW dwnld fails with ftp port specified in OprnsSrcFileLoc

•Configuration: Any

•Reproducibility: 100%

•Description:

SW 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 specified in the specs.

•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 sw download is not even initiated. If a user inputs the string without the ftp port, i.e.:

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

The SW download succeeds.

•Workaround:

Download succeeds with the default ftp port and not 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: 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 has always 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

CSCuk48000: Log table wrongly retrieved after rebooting with faulty Database

•Configuration: Any

•Reproducibility: 100%

•Desription:

The Log Table, from SNMP is wrongly retrieved after the node is rebooted with a faulty ONS15216DataBase, or the traps simply are not issued after reboot. After reboot the nlmLogTable should have at least the coldstart and linkUp traps stored and the database should not influence the log behaviour.

•Steps to reproduce:

Delete a possibly valid ONS15216DataBase from the FFS. Put a new faulty database on the FFS. Reboot the node. After node is rebooted, execute the following command:

bash-2.03$ snmpwalk -v 2c 10.51.100.233 nlmLogTable
NOTIFICATION-LOG-MIB::nlmLogTime."".1 = Timeticks: (18665) 0:03:06.65
NOTIFICATION-LOG-MIB::nlmLogDateAndTime."".1 = STRING: 2003-12-6,11:20:50.1
NOTIFICATION-LOG-MIB::nlmLogEngineID."".1 = STRING: "0x10000e17"
NOTIFICATION-LOG-MIB::nlmLogEngineTAddress."".1 = STRING: ".3d!"
NOTIFICATION-LOG-MIB::nlmLogEngineTDomain."".1 = OID: SNMPv2-TM::snmpUDPDomain
NOTIFICATION-LOG-MIB::nlmLogContextEngineID."".1 = STRING: "0x10000e17"
NOTIFICATION-LOG-MIB::nlmLogContextName."".1 = STRING: nicola
NOTIFICATION-LOG-MIB::nlmLogNotificationID."".1 = OID: CERENT-15216-EDFA-GENERIC-MIB::cerent15216EdfaGenericSystemConfigChanged.0

There is no trap for coldstart and linkup.

•Workaround: None

Obtaining Documentation

Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain 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 websites can be accessed from this URL:

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

Ordering 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 Ordering tool:

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

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

Cisco Optical Networking Product Documentation CD-ROM

Optical networking-related documentation, including Cisco ONS 15216 product documentation, is available in a CD-ROM package that ships with your product. The Optical Networking Product Documentation CD-ROM is updated periodically and may be more current than printed documentation.

Documentation Feedback

You can submit e-mail comments about technical documentation to bug-doc@cisco.com.

You can submit comments by using the response card (if present) 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, 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 Cisco TAC website 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 login 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 TAC engineer. The online TAC Case Open Tool is located at this URL:

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

For P1 or P2 cases (P1 and P2 cases are those in which your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help 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 1 (P1)—Your network is "down" or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Priority 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operation 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 3 (P3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

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

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://cisco.com/univercd/cc/td/doc/pcat/

•Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. 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 networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking 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/packet

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

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

•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/ipj

•Training—Cisco offers world-class networking training. Current offerings in network training are listed at this URL:

http://www.cisco.com/en/US/learning/index.html