0% found this document useful (0 votes)

13 views95 pages

ELS R1.0 CATP Issue2

The document outlines the Customer Acceptance Test Plan for the Coherent ELS Release 1.0, detailing the purpose, system requirements, and equipment needed for testing. It includes a comprehensive list of test cases and features of the ELS platform, as well as security protocols and logging procedures. The document is marked as confidential and is intended for internal use by Ciena Corporation.

Uploaded by

Salman Akhtar

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

13 views95 pages

ELS R1.0 CATP Issue2

Uploaded by

Salman Akhtar

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

Coherent ELS

Customer Acceptance Test Plan

Release 1.0

What’s inside...
Test cases for ELS

Issue 2
July 2022
Copyright© 2021 Ciena® Corporation
This page is intentionally left blank
Ciena
Coherent ELS
Release 1.0
Customer Acceptance Test Plan

Document release: Issue 2

Date: July 2022

LEGAL NOTICES
THIS DOCUMENT CONTAINS CONFIDENTIAL AND TRADE SECRET INFORMATION OF CIENA
CORPORATION AND ITS RECEIPT OR POSSESSION DOES NOT CONVEY ANY RIGHTS TO
REPRODUCE OR DISCLOSE ITS CONTENTS, OR TO MANUFACTURE, USE, OR SELL ANYTHING
THAT IT MAY DESCRIBE. REPRODUCTION, DISCLOSURE, OR USE IN WHOLE OR IN PART WITHOUT
THE SPECIFIC WRITTEN AUTHORIZATION OF CIENA CORPORATION IS STRICTLY FORBIDDEN.
EVERY EFFORT HAS BEEN MADE TO ENSURE THAT THE INFORMATION IN THIS DOCUMENT IS
COMPLETE AND ACCURATE AT THE TIME OF PRINTING; HOWEVER, THE INFORMATION
CONTAINED IN THIS DOCUMENT IS SUBJECT TO CHANGE.
Copyright© 2021 Ciena® Corporation. All Rights Reserved.
The material contained in this document is also protected by copyright laws of the United States of America
and other countries. It may not be reproduced or distributed in any form by any means, altered in any
fashion, or stored in a data base or retrieval system, without express written permission of the Ciena
Corporation.
Security
Ciena® cannot be responsible for unauthorized use of equipment and will not make allowance or credit for
unauthorized use or access.
For office locations and phone numbers, please visit the Ciena web site at [Link].
Document history:

Date Issue Reason for change Author/

Contributor
July 25th, 2022 2 Added the following new Test case which is LC
supported as of Rel. 1.0.1 (8):
2.2.16 Wayside Channel
October 20th, 2021 1 First official release LC/KS
Table of Contents

1.0 INTRODUCTION........................................................................................1
1.1 Purpose................................................................................................................................. 1

1.2 System requirements........................................................................................................... 1

1.3 Equipment requirements..................................................................................................... 2

1.4 Node Essentials Legends.................................................................................................... 2

1.4.1 Margins.......................................................................................................................... 2
1.4.2 Channel View................................................................................................................ 3
1.4.3 Hysteresis...................................................................................................................... 4
1.4.4 ELS Configuration.......................................................................................................... 4

1.5 Extra information................................................................................................................. 5

1.5.1 Security.......................................................................................................................... 5
1.5.2 CLI View Modes............................................................................................................ 5

2.0 ELS FEATURES........................................................................................6

2.1 Login to ELS Chassis.......................................................................................................... 6
2.1.1 Local access using Chassis RJ45 console port.............................................................6
2.1.2 Local access using using USB-C console port..............................................................7
2.1.3 Serial port auto-detection............................................................................................... 9
2.1.4 Local access using ETH-1 or DCN-1...........................................................................10
2.1.5 Login using DHCP....................................................................................................... 14

2.2 Platform Features............................................................................................................... 15

2.2.1 Commissioning an uncommissioned chassis..............................................................15
2.2.2 Chassis Configuration via Configuration File...............................................................15
2.2.3 Chassis Push Button Operation...................................................................................17
2.2.4 Lamp Test.................................................................................................................... 19
2.2.5 Chassis replacement................................................................................................... 20
2.2.6 Fan tray alarming......................................................................................................... 21
2.2.7 Redundancy operation and power fail alarming...........................................................22
2.2.8 LLDP on ELS Chassis................................................................................................. 22
2.2.9 ELS chassis system clock manually............................................................................23
2.2.10 NTP no authentication............................................................................................. 24
2.2.11 NTP MD5 authentication......................................................................................... 25
2.2.12 NTPv4 Autokey authentication................................................................................27
2.2.13 Alarm attribute editing............................................................................................. 28
2.2.14 Log collection.......................................................................................................... 30
2.2.15 Database Save and Restore...................................................................................31
2.2.16 Wayside Channel.................................................................................................... 34

2.3 Licensing............................................................................................................................ 37
2.3.1 Generating an ELS license file on the Ciena Portal.....................................................37
2.3.2 Downloading and activating a license file locally on the ELS chassis..........................38
2.3.3 Downloading and activating licenses on the ELS chassis using a license server........40

2.4 Security............................................................................................................................... 42
2.4.1 Local authentication - standard and complex password rules.....................................42
2.4.2 Local user account authentication...............................................................................44
2.4.3 Local authentication – Force out of local user.............................................................45
2.4.4 User based intrusion detection....................................................................................47
2.4.5 TACACS+ user account authentication and authorization...........................................48
2.4.6 TACACS+ authentication when TACACS+ servers are unavailable............................51
2.4.7 TACACS+ command level accounting.........................................................................51
2.4.8 TACACS+ command level authorization.....................................................................52
2.4.9 RADIUS user account authentication and authorization..............................................53
2.4.10 RADIUS authentication when RADIUS servers are unavailable..............................56

2.5 Syslog................................................................................................................................. 58
2.5.1 Syslog server provisioning........................................................................................... 58
2.5.2 Log events sent to 3 separate syslog servers..............................................................58

2.6 NBI....................................................................................................................................... 60
2.6.1 SNMP v2c Trap Reporting........................................................................................... 60
2.6.2 SNMP v2c Walk using MIBs........................................................................................61
2.6.3 SNMP v2c Get / Get Bulk Operations..........................................................................62
2.6.4 Enable/Disable of SNMP interface...............................................................................64

2.7 Photonic Features.............................................................................................................. 65

2.7.1 Channel Provision and Connect..................................................................................65
2.7.2 Adding a channel to a ELS system with N channels present without impact...............67
2.7.3 Channel Deprovision and Disconnect..........................................................................67
2.7.4 Channel Alarms........................................................................................................... 68
2.7.5 Line Alarms.................................................................................................................. 70
2.7.6 Express Alarms............................................................................................................ 71
2.7.7 Line Fiber Pinch feature............................................................................................... 73
2.7.8 Express Fiber Pinch feature........................................................................................74
2.7.9 Channel power and visual indication for unprovisioned channels................................75

2.8 Robustness......................................................................................................................... 78
2.8.1 Single fiber cut............................................................................................................. 78
2.8.2 Double Fiber Cut.......................................................................................................... 79
2.8.3 Warm restart................................................................................................................ 80
2.8.4 Cold restart.................................................................................................................. 81
2.8.5 Power Cycle................................................................................................................ 81
2.8.6 Soak and Stability........................................................................................................ 82
1.0 Introduction
1.1 Purpose
This Customer Acceptance Test Plan (CATP) provides laboratory system tests to
be performed on the Coherent ELS Platform Release 1.0 to evaluate all
functionalities being offered.

1.2 System requirements

• The Coherent ELS chassis must be operating the appropriate software
load.
• All test equipment listed in Table 1 are required if all test cases in this
CATP are to be validated.
• Supported Coherent Pluggables/Transponders

1
1.3 Equipment requirements
The test equipment detailed in Table 1 is needed for the execution of the test
cases in this test plan.

Table 1: Test equipment requirements

Description Qty
Optical Power Meter with LC adapter 1
LC attenuator pads ~10
LC and LC Duplex optical fiber patch cord ~10
WS or 6500 pluggables/transponders to feed the ELS Photonic system At least 4 sources
(2 channels)
100GE or 10GE test set to monitor traffic 2
Precision Variable Optical Attenuator (pVOA) with shutoff capability 1
An SFTP server 1
Terminal emulator software (e.g. putty) 1
RADIUS server 1
TACACS+ server 1
Syslog server. 1
Note: A free syslog server for windows version can be obtained here:
[Link]
DHCP server 1
SNMP MIB browser 1

1.4 Node Essentials Legends

1.4.1 Margins

[Link] Line Margins:

Default thresholds:

 For line margins default values where alarms will be raised are:
o Degrade = when margin is less than 3 dB
o Out of Range = when margin is less than -1 dB

2
[Link] Express Margin

Default thresholds:

 For express margins default values where alarms will be raised are:
o Degrade = when margin is less than 1 dB
o Out of Range = when margin is less than -1 dB

1.4.2 Channel View

 The channel powers will be slightly different b/w channels on the same
filter.
 Channel powers are derived by the ELS software based on the:
o Target add channel power provisioned in the Control menu
o The ELS configuration loss
o The FLA1 or FLA2 types being used.
 Therefore, even if the “Target add channel power” is set to -5.0 dBm it
does not mean the required power will always be that value.
 If channel is provisioned then alarms are raised, and ports are colored in
full depending on the channel powers present.
 If channel is not provisioned then alarms are not raised, and ports are
colored on the contour only depending on the channel powers present.

3
1.4.3 Hysteresis
The alarms have a different threshold for raising the alarm and for clearing it.
The difference between these two thresholds is called hysteresis. The alarm
is raised when a parameter crosses the alarm raise threshold, and it clears
when the parameter crosses the alarm clear threshold.

Example of hysteresis in the Degrade High Power alarm:

Thresholds:
 alarm raise threshold: 8 dBm
 alarm clear threshold: 7 dBm
 hysteresis: 1 dB

The Degrade High Power alarm is raised when the optical power level
increases above the "alarm raise" threshold, and the alarm is cleared when
the power level drops below the "alarm clear" threshold.
Example of hysteresis in the Degrade Low Power alarm:
Thresholds:
 alarm raise threshold: -7 dBm
 alarm clear threshold: -5 dBm
 hysteresis: 2.0 dB

The Degrade Low Power alarm is raised when the optical power level drops
below the "alarm raise" threshold, and the alarm is cleared when the power
level increases above the "alarm clear" threshold.

4
1.4.4 ELS Configuration

1.5 Extra information

1.5.1 Security
For security reasons when logging an uncommissioned chassis for the first time it
will automatically ask you to change the default “su” password (Ciena123!).

1.5.2 CLI View Modes

In CLI you can display the output in different views:
 command
 line
 table

The recommend and guaranteed view is “list”.

To change between views the CLI command is:

ELS# display command
ELS# display list
ELS# display table

5
2.0 ELS features
2.1 Login to ELS Chassis
2.1.1 Local access using Chassis RJ45 console port
Objective:
This test case verifies that a terminal (PC, laptop) can be connected locally to a
ELS Chassis RJ45 console port to log into the chassis.

Setup:
A commissioned ELS Chassis and have the required user/password.

If you are using a Mac to connect to the ELS Chassis, it is recommended to

install Minicom for serial port setup. Minicom is available at the Web site:
[Link]

Use the following cables:

 DB9 port, DB9-to-RJ-45
 USB port, USB-to-RJ-45 (Serial Console Adaptor)

Note 1: You can change the baud by disconnecting the cable, changing the
baud on the terminal, and then reconnecting the cable. The RJ-45 port
supports bauds up to 921600 and the default baud is 115200.

Note 2: Auto-baud detection supports these rates: 9600, 19200, 38400,

57600, 115200, 230400, and 460800.

Procedure:
Run these steps if you are using a PC or Laptop terminal:

1. With the terminal emulator, configure the connected terminal with the
following RS-232 settings:
 Speed: 38400
 Data bits: 8
 Stop bits: 1
 Parity: None
 Flow control: None
2. Connect a console port cable to the ELS Chassis RJ45 console port and then
to the terminal.
3. Press any key for auto-baud detection and wait for the prompt
4. Login using the username and password.
o Verify login is successful.
5. Logout by entering exit.
o Verify logout is successful.

6
7
Run these steps if you are using a Mac terminal:

6. Connect a console port cable to the ELS Chassis RJ45 console port and then
to the Mac.
o Verify the presence of the USB cable by searching the /dev folder. Look
for something like [Link].
7. Open a terminal window and connect to ELS Chassis. It is recommended to
use Minicom for the connection.
8. If you are using Minicom, in the terminal window, type minicom -s.
9. Use the arrow keys to scroll to Serial port setup and press Enter to select it.
10. Configure the connected terminal with the following settings:
 Serial Device: USB device noted in previous step by searching the
/dev/cu folder
 Bps/Par/Bits: 38400 8N1
 Hardware Flow Control: No
 Software Flow Control: No
11. Press any key for auto-baud detection and wait for the prompt
12. Login using the username and password.
o Verify login is successful.
13. Logout by entering exit.
o Verify logout is successful.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.1.2 Local access using using USB-C console port

Objective:
This test case verifies that a terminal (PC, laptop, MAC) can be connected locally
to a ELS Chassis using USB-C console port to login into the chassis.

Setup:
A commissioned ESL Chassis.

To connect to a terminal, one of the following cables is required. If your

terminal is equipped with a:
 USB-A port, use a USB-C to USB-A cable
 USB-C port, use a USB-C to USB-C cable

Note:
If you are using a Mac to connect to the ELS Chassis, it is recommended to
install Minicom for serial port setup. Minicom is available at the Web site:
[Link]

8
Procedure:
Run these steps if you are using a PC or laptop:

1. Connect a USB-C or USB-A cable to the ELS Chassis USB-C port and then
to the PC or Laptop terminal.
The terminal detects the cable and automatically installs any required
drivers.

Note: If the drivers do not automatically install, download and install

CP210x USB to UART Bridge Virtual COM Port (VCP) from the website:
[Link]
bridge-vcp-drivers

Note: Disconnect the USB-C cable every time from your terminal when
trying to test different Baud rate (38400,9600,19200 etc.)

2. Open the Device Manager on your terminal and under the Ports (COM &
LPT) section, determine the COM port used to connect to ELS.
3. With the terminal emulator (putty), configure the connected terminal with the
following settings:
 Serial line: COM port noted in previous step
 Connection type: Serial
 Speed: 38400
 Data bits: 8
 Stop bits: 1
 Parity: None
 Flow control: None
4. Press any key for auto-baud detection and wait for the prompt
5. Login using the username and password at the ELS login prompt.
o Verify login is successful.
6. Logout by entering exit
o Verify logout is successful.

Run these steps if you are using a Mac:

7. Connect a USB-C or USB-A cable to the ELS Chassis USB-C port and then
to the Macintosh computer or MacBook terminal.
The Macintosh computer or MacBook terminal detects the cable and
automatically
installs any required drivers.

Note: If the drivers do not automatically install, download and install

CP210x USB to UART Bridge Virtual COM Port (VCP) for Macintosh from
the website:

9
[Link]
bridge-vcp-drivers

8. Restart the Macintosh computer or MacBook.

9. Verify the presence of the USB cable by searching the /dev/cu folder.
10. Open a terminal window and connect to ELS Chassis. It is recommended to
use Minicom for the connection.
11. If you are using Minicom, in the terminal window, type minicom -s.
12. Use the arrow keys to scroll to Serial port setup and press Enter to select it.
13. Configure the connected terminal with the following settings:
 Serial Device: USB device noted in previous step by searching the
/dev/cu folder
 Bps/Par/Bits: 38400 8N1
 Hardware Flow Control: No
 Software Flow Control: No
14. Press any key for auto-baud detection and wait for the prompt
15. Login using the username and password at the ELS login prompt.
o Verify login is successful.
16. Logout by entering exit
o Verify logout is successful.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.1.3 Serial port auto-detection

Objective:
This test case verifies the following auto-baud detection process:

 When connecting to a ELS Chassis console port the ELS chassis

recognizes the baud-rate from terminal and established that
communication.
 A login prompt is only presented once the auto-baud detection is
complete.
 Auto-baud detection supports these rates only:
o USB-C: 921600, 460800, 230400, 115200 (default on ELS
chassis), 57600, 38400,19200 and 9600.
o RJ-45: 460800, 230400, 115200 (default on ELS chassis), 57600,
38400,19200 and 9600.
 Auto-baud detection only supports the following RS-232 configuration: 8
bits, no parity, 1 stop bit (8-N-1).
 It is normal to see a mix of characters appear on the console before and
after the prompt during the auto-baud detection.

10
Setup:
A terminal is required with putty or similar terminal emulator that supports RS-
232.

A ELS Chassis commissioned or uncommissioned.

Procedure:
1. On your terminal, setup the terminal emulator as follows:
 Speed=9600
 Data bits=8
 Stop bits=1
 Parity=None
 Flow control=None
2. Connect the terminal to the ELS Chassis console (putty) and press Enter.
Verify that you have received the prompt of the ELS chassis (which indicates that
the baud rate is auto-detected).
3. Login to the ELS chassis.
o Verify login is successful.
4. Logout of the ELS Chassis (in the putty screen, enter exit).
o Verify logout is successful.
5. Disconnect the Console port from the ELS Chassis and repeat the above with
the other supported auto-baud rates of 921600 (USB-C only), 460800,
230400, 115200 57600, 38400, and 19200.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.1.4 Local access using ETH-1 or DCN-1

Objective:
This test case verifies that a terminal (PC, laptop) can be connected locally to a
ELS Chassis DCN-1/ETH-1 RJ-45 port using IPv6 to log into the chassis.

Setup:
A de-commissioned ELS chassis.

Procedure:
1. DCN-1/ETH-1 is enabled by default and IPv6 ready
2. Connect terminal with RJ-45 to DCN-1/ETH-1

11
3. Disable IPv6 on interfaces on terminal not required to simplify the connection

4. In the CMD prompt window of terminal run the following:

a. ping -6 ff02::02
 Verify that there is a response from a device using IPv6 successfully.

12
b. netsh
c. interface
d. ipv6

5. Retrieve the routable IPv6 address and using the IPv6 address you can either
a. show neighbor

 Verify that there is a IPV6 address available of Type “(Router)”

Note: The “Type” may also indicate Stale instead of Reachable. If you can
ping it then you can still use that entry of IPV6 to login. If want to see
“Reachable” then you will need to restart your terminal.

13
6. Launch the Node Essentials: [Link]

o Verify the Node Essentials login screen is launched.

7. Launch a SSH CLI session using the IPv6 address

o Verify the CLI session login session is launched and has a promt
8. Login to chassis using default User/password = su/Ciena123!
o Verify the interface (CLI or Node Essentials) asks to change password for
uncommissioned chassis.
9. Change the default password for user “su” through the interface.
Note 1: For Node Essentials the change password is done automatically
Note 2: For CLI, here is the command to change the password:
# change-password old-password new-password confirm-new-password
user-name su
10. Login in with new password
o Verify login is successful.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

14
2.1.5 Login using DHCP
Objective:

This test case verifies the ELS chassis could be accessed when DHCP is
enabled on network.

Note: On an un-commissioned ELS chassis, DHCP client is enabled by default.

Test Setup:
 A terminal is required with putty or similar terminal emulator that supports RS-
232.
 A newly un-commissioned ELS chassis.
 DHCP-enabled network
 ELS chassis DCN-1(RJ-45) connection not connected.

Procedure:
1. Connect ELS chassis console port to your Terminal.
o Verify that the DHCP client is enabled
ELS#show dhcp dhcp-client

2. If required to enable DHCP:

ELS# set dhcp dhcp-client interfaces interface if-dcn-1 enabled true
o Verify no valid IP address assigned to the DCN-1 interface
ELS# show interfaces state interface ifp-dcn-1
3. Connect the DCN port to a DHCP network
ELS# show interfaces state interface ifp-dcn-1
o Verify that the IP Address is assigned to chassis via DHCP

4. Login to the chassis using Node Essentials via the network using the DHCP
assigned IP address (e.g., [Link])
o Verify that the login is successful

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

15
2.2 Platform Features
2.2.1 Commissioning an uncommissioned chassis
Objective:
This test case verifies that a chassis can be fully commissioned using a pre-
created configuration file.

Setup:
An uncommissioned ELS chassis.
Have a configuration file ready.
Example:

Procedure:
1. Connect your terminal to ETH-1 and connect via IPv6.
2. Login to ELS chassis (Node Essentials).
3. Click on the drop-down menu in extreme upper right corner of ELS chassis
login session.

4. Click on “Configure NE” option.

5. Click on “Load” for importing a file from a terminal.
6. Select “File import” option from drop down menu from “Load configured by”
7. Select a desired configuration file on your terminal by using “Browse” option.
8. Click on “Confirm”
o Verify that you see a “Operation successful” in “Last Operation Status”
window.
9. Refresh Node Essentials session.
o Verify that the ELS chassis is commissioned with all the parameters in the
configuration file.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.2 Chassis Configuration via Configuration File

Objective:

16
This test case verifies that a configuration file (Comms, Commissioning, Control
or Comms+ Commissioning+Control) of an ELS chassis can be:
 Save to a terminal
 Load from a terminal
 Download to a terminal that was Loaded or Saved previously.

Setup:
A commissioned ELS chassis.

Procedure:
Save:
1. Login in an ELS chassis and launch the Configure NE option. Click on the
drop-down menu in extreme upper right corner.

2. Save the following configuration files to your terminal:

 Comms
 Commissioning
 Control
 Comms+ Commissioning+Control
 Verify the files are available on your terminal.
 Verify in the “Download” section of the Configure NE menu all the 3
files are present.
3. Open the configuration files in a txt viewer:
o Verify each configuration file starts with “batch” and ends with “commit &
quit”
o Verify each configuration file has only specific CLI commands based on
the name of the file.
 Comms: DCN information
 Commissioning: All Network, Site, Group and Member information
 Control: all standard and advanced photonics parameters
 The combo file is all the CLI commands as the individual files.

Load:
4. Open the “commissioning_config_xxx.txt” and change a description
parameter, then save the file with a new name (ex:
commissioning_config_xxx_test.txt)
Example:
set ciena-els-system:system id member id 1 name ELS5001-1
description ELS5001-T48CH-M1-TEST frame-identification Rack01
rack-unit-number 1
5. In the Configure NE menu, click on Load:
o Load configuration by: File import
o Select file: commissioning_config_xxx_test.txt
 Click on confirm

17
o Verify the last operation status is “Operation successful”
 Click on cancel
6. Refresh the Node Essentials and click on Chassis in the menu
o Verify the change was implemented under Member Description.
7. To restore the correct information, we will load back the original file that was
saved from previous step which is still available on chassis:
 In the Configure NE menu, click on Load
o Load configuration by: NE configuration file
o Select file: commissioning_config_xxx.txt
 Click on confirm
o Verify the last operation status is “Operation successful”
 Click on cancel
8. Refresh the Node Essentials and click on Chassis in the menu
o Verify the Member Description has been restored to its original value.

Download:
9. In the Configure NE menu, click on Download.
o Verify that all files that were saved or imported are present on the chassis.
o Verify that any of the files can be downloaded by clicking on the Confirm (
) next to the file name.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.3 Chassis Push Button Operation

Objective:
This test case verifies that the physical push button on the ELS chassis could be
used to
 Cold Restart
 RTFD (Reset to factory defaults).
 Make sure, you are connected to the chassis directly since you will de-
commission the chassis and remove all info and comms.

Setup:
A commissioned ELS chassis, up and running. A pin to press push button
by inserting it into ELS chassis.

Procedure:

Cold restart:

18
1. Initiates cold restart by insertion of a pin in ELS chassis. Insert the pin, hold it,
and wait for ~13seconds or count the “Fail” LED to flash for 13 times and
remove the pin immediately when all the LEDs turn off and back on.
o Verify that traffic is impacted. (On a test set if connected).
2. Wait for chassis to restart before re-login.
o Verify the LED status that “Fail” LED stopped blinking and goes off
During the Cold restart process the following is observed:
o “Rdy” LED starts blinking and then in solid green color
o “InUse” LED solid blue color
o “System” LED solid amber color.
3. Login the chassis via the console (CLI) port or ETH-1 (IPv6) (Node
Essentials)
o Verify the change to ELS commissioning, and all other parameters are the
same.
4. Via the Node Essentials session
o Verify the last restart reason (Login to chassis >>Facilities >> ELS TERM
(Chassis) >> check Last restart reason)

o Verify that traffic was impacted and restored automatically once the ELS
chassis is up and running back. (On a test set if connected).

RTFD:
5. Initiate ELS chassis RTFD by pressing the push button with a pin insertion for
a ~50 seconds. Initially, “Fail” LED starts blinking and no change in all the
other LEDs.
 After ~13 sec from pin insertion, the LEDs (System, Rdy, InUse)
blink once and turn off but “Fail” continuously blinks.
 After ~50 sec from pin insertion, the “System” LED also start
blinking.
 When both the “Fail” and “System” LEDs start blinking, then you
can release the push button by removing the pin.
 Only once the “Fail” and “System” LEDs stop blinking the RTFD
has been completed but not finalized.
o Verify the “Fail” LED continuously blink during whole RTFD process (0-
50sec)
o Verify that traffic is impacted if channel and test set are involved.
o Verify the “Fail” and “System” both LEDs blink together after~50 secs.

19
o Verify that after a period of time (10 to 60 secs) all LEDs turn off except
the Power and Fan which are still reporting.

6. Only when “Fail” and “System” both LEDs stop blinking, then turn off the
power feeds and then turn back on to complete the RTFD process. Wait for
chassis to restart before re-login.
o Verify the LED status during the restart:
 “Fail” LED starts blinking and goes off.
 “Rdy” LED starts blinking and change to solid green color.
 “System” LED solid amber color.
7. Login the chassis via the console port (CLI) or ETH-1 (Node Essentials)
o Verify that the ELS chassis is in a factory default state.
 the prompt (CLI) shows the ELS serial number, and all other
parameters are not filled in.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.4 Lamp Test

Objective:
This test case verifies the lamp test feature on the ELS chassis using Node
Essentials.

Setup:
A commissioned ELS chassis.
Login through Node Essentials.

Note: In case of “Lamp Flash” (Node Essentials)

 System, Fail, Rdy, InUse LEDs will Flash.
 DCN and Console LEDs no change (Remain off unless they are in use)
 Fan, Channel and Line LEDs have No Change

Procedure:
1. Login the ELS chassis via Node Essentials >> Click on Facilities >> Click on
ELS chassis >> Click on bulb symbol having check sign (lamp flash).

20
o Verify that all the 4 LEDs (System, Fail, Rdy and InUse) on the chassis
start flashing.
o Verify the light bulb is displayed on the Node Essentials that flash test has
been activated

2. “Lamp Cancel” to stop the lamp flashing test by clicking on left side bulb
symbol having a “x” sign “Lamp cancel”.

o Verify that all the LEDs on the chassis stop flashing and go back to initial
state.
o Verify that the light bulb is disappeared on the Node Essentials that flash
test has been deactivated.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.5 Chassis replacement

Objective:
This test case verifies that ELS chassis can be replaced.

Setup:

21
A commissioned ELS chassis in a system and an uncommissioned ELS chassis
of the same PEC running the same load.
For the ELS chassis in a system verify all line and express fibers are connected
between the neighboring sites. There may be a channels passthrough or drop on
it.

CAUTION: When replacing the ELS chassis, verify all fibers are labeled and the
channels provisioned on it. Do not forget to switch off the power before starting
the replacement.

Procedure:
1. Retrieve a database back up of the chassis (refer to Test Case 2.2.15)
2. Label all the fibers connections to the ELS chassis and channels provisioned.
3. Turn off the power source AC/DC and then disconnect the power cables from
the chassis.
4. Disconnect all the fibers carefully and cover the disconnected fibers with a
dust cap.
5. Replace the chassis.
6. Reconnect the power cables to chassis and turn on the power.
7. Wait for ELS chassis ““Rdy” LED to turn solid green before connecting via the
ETH-1 port (IPv6). (Refer to test case 2.1.4)
8. Restore the ELS chassis using the database backup file (refer to Test Case
2.2.15).
9. Reconnect the fibers as per labeling and:
o Verify that line and express LEDs are green.
o Verify that traffic status is up.
10. Login remotely or locally.
o Verify all commissioning and provisioning has been restored.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.6 Fan tray alarming

Objective:
This test case is used to verify the fan alarms and hot swappable feature of fan
tray for the ELS chassis.

Setup:
ELS chassis should be up and running. Fan unit working well, fan LED is green,
and no “Fan failed” or “Fan missing” alarm in Node Essentials. Create a “Fan
Missing” alarm by carefully removing the fan unit from the rear side of the ELS
chassis. Fan units can be removed by pulling a latch attached to it at one end.

CAUTION: When replacing the rear fan tray, it must be done in a 60 second
window otherwise it may cause damage to chassis.

22
Procedure:
1. Remove the fan unit from rear side of the ELS chassis by carefully pulling a
latch attached at one end.
o Verify Fan LED on ELS chassis changes from GREEN to RED color.
o Verify you observe a “Fan Missing” alarm in Node Essentials.
2. Insert back the fan unit or replace it with a new one.
3. Wait for some time and monitor, Fan LED on ELS chassis.
o Verify Fan LED on ELS chassis changes from RED to GREEN color.
o Verify the alarms, “Fan Missing” alarm will get clear.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.7 Redundancy operation and power fail alarming

Objective:
This test case verifies that traffic is unaffected when either the A or the B power
feed fails. It also verifies that the “Power failure” alarm is raised.

Setup:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with at least one
channel provisioned and at least one chassis with at least 2 power feeds
connected.
Configured Test set for to check the traffic status.

Procedure:
1. Fail the A feed by turning off the Power Input Module “1” breaker. If using AC
Power Input Module, disconnect the AC power cord.
o Verify that this does not affect traffic.
o Verify that the “Power Feed 1 Failed” alarm is raised In Node Essentials.
o Verify that the “Power OK” “A” LED turn off.
2. Restore the A feed.
o Verify that this does not affect traffic.
o Verify that the “Power Feed 1 Failed” alarm clears.
o Verify that the “Power OK” “A” LED is turn on again.
3. Repeat the above for the “2” feed.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

23
2.2.8 LLDP on ELS Chassis

Objective:
This test case will verify the successful enabling of LLDP on DCN-1 port. LLDP is
also available on other interfaces such as ETH-n, oscl-1 and osce-1

Setup:
A commissioned ELS chassis with DCN-1 connected to the network.

Procedure:
1. Login to the ELS chassis using CLI session
2. Check LLDP status
ELS# show lldp enabled
3. If Admin state is disabled, enable LLDP
ELS# set lldp enable true
4. Check LLDP status on DCN-1
ELS# show lldp interfaces interface if-dcn-1
o Verify mode is tx-rx
5. If mode is mode is not tx-rx on DCN-1 interface, then set it:
ELS# set lldp interfaces interface if-dcn-1 mode tx-rx
o Verify LLDP neighbor on DCN-1 is available
ELS# show lldp state interfaces interface if-dcn-1 neighbors
Example:
ELS5001-Terminal-48CH# show lldp state interfaces interface if-dcn-1 neighbors
lldp:
state:
interfaces:
interface:
- name : if-dcn-1
neighbors:
neighbor:
- id : 1
system-name : Switch-X28Y23-243-7
system-description : "Juniper Networks, Inc. ex4200-48p , version 12.3R6.6 Build date: 2014-03-13 08:38:30 UTC "
chassis-id : 2c:6b:f5:30:bd:00
chassis-id-type : mac-address
port-id : 512
port-id-type : locally-assigned
port-description : ge-0/0/4.0
time-to-live : 120
capabilities:
capability:
- name : mac_bridge
enabled : true
- name : router
enabled : true
management-addresses:
management-address:
- address : [Link]
address-type : IP

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.9 ELS chassis system clock manually

Objective:
Setting the ELS chassis system clock manually.

Setup:
A commissioned ELS chassis.

24
Procedure:
Node Essentials: (can only set UTC time)
1. Login to the ELS chassis using Node Essentials with Admin or higher access
privilege level.
2. Click on the drop-down menu in extreme upper right corner of ELS chassis
login session.

3. Click on NE data & time.

4. Select NTP Disabled
5. Click on Set NE time.
o Verify the NE time (UTC) and Current Time (UTC) are the same now

CLI Session: (can only set UTC time)

1. Login to the ELS chassis using CLI session with Admin or higher access
privilege level.
2. Disable the NTP client:
ELS# set ntp enabled false
3. Set the date and time:
ELS# set system time-config date <Date: yyyy-mm-dd | yy-mm-dd | mm-dd>
ELS# set system time-config time <Time: hh:mm:ss | hh:mm>
o Verify the NE data and time
ELS# show system time-config

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.10 NTP no authentication

Objective:
Configuration of an NTP server on the ELS chassis.

Setup:
A commissioned ELS chassis connected to the network and a NTP server.

Note: to delete the NTP information:

 ELS# delete ntp server
 ELS# delete ntp authentication

Procedure:
1. Login to the ELS chassis using CLI session.
2. Enable the NTP client, set the authentication to disabled, mode and polling
interval:

ntp state server server-list [Link]

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.11 NTP MD5 authentication

Objective:
To configure an NTP server using MD5 authentication on the ELS chassis.

Setup:
A commissioned ELS chassis connected to the network and a NTP server which
has a MD5 Key ID and Key value already established.

Note: to delete the NTP information:

26
 ELS# delete ntp server
 ELS# delete ntp authentication

27
| key-value | 24 |
+-------------------+

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.12 NTPv4 Autokey authentication

Objective:
To configure an NTPv4 server using autokey authentication on the ELS chassis.

Setup:
The following equipment and servers are needed:
 A ELS commissioned chassis connected to the DCN
 An NTP server that expects SHA1 rather than MD-5 for hashing.

Note: to delete the NTP information:

 ELS# delete ntp server
 ELS# delete ntp authentication

ntp state server server-list [Link]

+--------------------------------------------+
| Name | Value |

ntp state authentication autokey

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.13 Alarm attribute editing

Objective:
This test case verifies that the following attributes of an alarm template can be
edited:
 Severity of the alarm
 Enabling or disabling of the alarm
 Cause of the alarm

Setup:
A commissioned ELS chassis.

Procedure:

Severity and Enable/Disable:

1. Use the following CLI command to view the complete list of alarms.
ELS# show defined-alarms
o Verify the complete list of alarms is displayed.
2. Note the alarm severity for the “optical-line-fail” alarm.
3. Change the alarm severity for the “optical-line-fail” alarm to a different value
using the following CLI command:
ELS# set changed-alarms "optical-line-fail" severity <critical, major,
minor, warning>
o Use the show changed-alarms " optical-line-fail" CLI command to verify
that the change has been successful.
o Use the show defined-alarms "optical-line-fail" CLI command to verify that
the change has been successful.
4. Manually create a fiber cut (disconnect the Line IN of this chassis).

29
o Use the show active-alarm CLI command to verify that the “optical-line-
fail” alarm is displayed with the new severity level you provisioned above
using the set changed-alarms CLI command.
5. Disable the alarm using the following CLI command:
ELS# set changed-alarms "optical-line-fail" template-state inhibited
o Use the show changed-alarms " optical-line-fail" CLI command to verify
that the change has been successful.
o Use the show defined-alarms " optical-line-fail" CLI command to verify that
the change has been successful.
o Use the show active-alarm CLI command to verify that the “optical-line-
fail” alarm is no longer displayed.
6. Enable the alarm using the following CLI command:
ELS# set changed-alarms "optical-line-fail" template-state enabled
o Use the show changed-alarms "optical-line-fail" CLI command to verify
that the change has been successful.
o Use the show defined-alarms "optical-line-fail" CLI command to verify that
the change has been successful.
o Use the show active-alarm CLI command to verify that the “optical-line-
fail” alarm is displayed.
7. Manually fix the fiber cut (reconnect the Line IN of this chassis).
o Use the show active-alarm CLI command to verify that the “optical-line-fail”
alarm is no longer displayed.
8. Change the alarm severity for the “optical-line-fail” alarm back to the original
value (major) using the following CLI command:
ELS# set changed-alarms "optical-line-fail" severity major
o Use the show changed-alarms "optical-line-fail" CLI command to verify
that the change has been successful.
o Use the show defined-alarms "optical-line-fail" CLI command to verify that
the change has been successful.
9. Disable the “optical-line-fail” alarm using the following CLI command:
ELS# set changed-alarms "optical-line-fail" template-state inhibited
o Use the show changed-alarms "optical-line-fail" CLI command to verify
that the change has been successful.
o Use the show defined-alarms "optical-line-fail" CLI command to verify that
the change has been successful.
10. Manually create a fiber cut (disconnect the Line IN of this chassis).
o Use the show active-alarm CLI command to verify that the “optical-line-
fail” alarm is not displayed.
11. Enable the alarm using the following CLI command:
ELS# set changed-alarms "optical-line-fail" template-state enabled
o Use the show changed-alarms "optical-line-fail" CLI command to verify
that the change has been successful.
o Use the show defined-alarms "optical-line-fail" CLI command to verify that
the change has been successful.
o Use the show active-alarm CLI command to verify that the “optical-line-
fail” alarm is displayed with the new severity level you provisioned above
using the set changed-alarms CLI command.
12. Manually fix the fiber cut (reconnect the Line IN of this chassis).

30
o Use the show active-alarm CLI command to verify that the “optical-line-fail”
alarm is no longer displayed.

31
Cause:
13. Use the following CLI command to set the chosen alarm name:
set changed-alarms <alarm name> cause “input_string”
Example:
set changed-alarms "fan-failed" cause "Fan Failed – replace module"
o Verify the template has been adjusted:
Show changed-alarms " fan-failed"
14. If applicable, cause the changed alarm to be raised by the ELS and verify that
the cause has been appropriately changed.
o Verify the template has been adjusted on the active alarm
15. To restore original “cause” for alarm that was altered above:
set changed-alarms "fan-failed" cause "Fan Failed"

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.14 Log collection

Objective:
This test case verifies that logs can be collected locally and downloaded to
terminal or sent to a remote server.

Setup:
A commissioned ELS chassis. A remote SFTP server that can be used to receive
logs from the ELS.

Procedure:
Local:
1. Login the ELS chassis via Node Essentials >> Logs >> State dump.
 Type: Local
 File name: TEST123
 Click on Retrieve logs
o Verify in the Status section the Status is “active”
2. Once the Status is “finished”:
o Verify the log file “[Link]” is available in the Local state files
3. In the Local state file section click on the Download ( ) next to the file
“[Link]” and save it to your terminal.
o Verify the file is available on your terminal.

Remote:
4. Login the ELS chassis via Node Essentials >> Logs >> State dump.
 Type: Remote
 File name: TEST456
 Protocol: sftp
 User name: xxxxx

32
 Password: xxxxx
 Destination path:
 Remote server IP: x.x.x.x
 Click on Retrieve logs
o Verify in the Status section the Status is “active”
5. Once the Status is “finished”:
o Verify the log file “[Link]” is present in the remote server directory.
o Verify that the logs are also present on the Node Essentials in the Local
state files.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.15 Database Save and Restore

[Link] Database Save and Restore

Objective:
This test case verifies NE database backup and restore operations and can only
be executed via CLI or other NBIs. Not available in Node Essentials.

Setup:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned the at least one chassis with at least 2 power feeds
connected.

Procedure:
1. In CLI, enter the following CLI command to perform a database backup
operation:
ELS# database-backup add-member-name true add-timestamp true filename
<filename>
Note: It is recommended that the <filename> be the software release running on the chassis. For
example: ELS-xxxx-570
o Verify that the save operation completes successfully.
 Using an SFTP client (like FileZilla FTP client), sftp to chassis port
20022 and verify that the file saved appears in the /backups folder.
o Verify that you can transfer the file to your workstation. This is a tarred file
of many xml files. If you un-tar it, you can see all the xml files inside of it.
Note1: If the filename does not have an extension once downloaded,
add the extension “.tgz” to the filename (Ex: [Link]). Then
unzip and it will create a new file with a “.tar” as an extension. Unzip
this file and it will display all the xml files.
Note2: When saving the database, you can also add the extension
“.tgz” to the filename therefore it will be ready to unzip when
downloaded.

33
2. View the current system site description parameter using the following CLI
command:
ELS# show system id member description
3. Change the system site description parameter to a different value using the
following CLI command:
ELS# set system id member description <new value>
4. Using the show system id member description CLI command, verify that the
description parameter has changed to the new value.
5. In CLI, enter the following CLI command to perform a database restore
operation:
ELS# database-restore filename <the full filename>
Example: ELS5001-1-2021-10-07-15-07-00-ELS5001-570
o Verify that the restore operation completes
6. In CLI, enter the following CLI command to perform a database commit
operation:
ELS# database-commit
And Enter “Y”.
o Verify that the commit operation completes. The CLI session will drop.
7. Wait 10 minutes.
8. Log back into the chassis.
o Verify that the provisioning change (the system parameter change) has
been undone.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

Setup:
A commissioned ELS chassis.

34
Procedure:
1. Take a backup of the current configuration by using the following CLI
command:
ElS# database-backup filename backup
2. Find the backup file under the Ciena-6500r-system object by using the
following CLI command:
ELS# show system backups
o Verify that the following attributes are displayed and accurate:
i. filename
ii. directory
iii. restore-in-progress
iv. chassis type
v. member-name
vi. timestamp
vii. software-version
viii. mac-address
ix. user-name

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

[Link] Invalid backup-restore is rejected

Objective:
This test case verifies that a database restore of an invalid backup file will fail.

Setup:
A commissioned ELS chassis and a backup file from the same chassis from a
different software release.

Procedure:
1. Find the backup file from a previous release under the System Backups
object by using the following CLI command:
ELS# show system backups
o Verify that the software version of the backup is different from the software
currently running on the chassis.
2. Attempt to restore the backup file of different software release, by using the
following CLI command:
ELS# database-restore filename <filename>
o Verify that the restore operation is rejected due to different software
release.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

35
[Link] Database restore operations can be canceled

Objective:
This test case verifies that a database restore can cancelled before the database
commit is performed.

Setup:
A commissioned ELS chassis with a database backup file.

Procedure:
1. View the currently present backup files on the ELS chassis by using the
following CLI command:
ELS# show system backups
2. Use the following CLI command to begin the database restore on the RLS
chassis:
ELS# database-restore filename <backup-filename>
o Verify that a backup is in progress and the “restore-in-progress” parameter
is set to “true” under the system backups object.
3. Cancel the backup by using the following CLI command:
ELS# database-cancel
o Verify that the backup no longer in progress and the “restore-in-progress”
parameter is set to “false” under the system backups object.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.2.16 Wayside Channel

Objective:
This test case verifies that the DCN-2 can carry traffic (wayside traffic) between 2
sites only via the OSC Line.

Setup:
An ELS configuration.

Setup requires minimum release 1.0.1 (8).

Connect a test set that supports 10BT/100BT/1000BT to the ELS DCN-2 wayside
channel as shown below:

36
Procedure:
1. Enable the DCN-2 ports:
 Login into ELS chassis via Node Essentials
 Configuration >> Comms
 Click on ifp-dcn-2 in the Interface/ Sub interface table
 Click on ifp-dcn-2 in the Interface menu (below)
 Click on the Edit ( )
 Set MTU to 1518 and check off Enabled
 Click on Confirm
100BT:
2. Connect a 100BT Ethernet test set (set to Auto Negotiate and advertise Full
Duplex 100BT) to each end of the wayside channel and set the test set to
transmit 64-byte frames with a traffic rate of 12.98% (9.89 Mbps for 64-byte
frames).
o Verify that the DCN-2 (WSC) ports auto-negotiate to “full” Duplex and
Speed of 100M in the Interface table (via Node Essentials).
o Verify that traffic is carried error free with no packet loss.
3. Using the test set, change the Utilization rate to 100%.
o Verify that ELS automatically detects this traffic rate and throttles the
transmission to a traffic rate of about < 10 Mb/s when using 64-byte
frames.
o Verify that packets are being lost when test set is using full 100%
4. Using the test set, change the traffic rate to 12.98% (9.89 Mbps for 64-byte
frames).
o Verify that ELS automatically detects this traffic rate and now allows the
transmission of traffic with no packet loss.
5. Repeat the above tests but this time provisioning the test set to Auto
Negotiate and advertise Half Duplex 100BT. When using Half Duplex mode,
ensure you send test set packets in one direction at a time.
o Verify that the DCN-2 (WSC) ports auto-negotiate to “half” Duplex and
Speed of 100M in the Interface table (via Node Essentials).

1000BT:
6. Connect a 1000BT Ethernet test set (set to Auto Negotiate and advertise Full
Duplex 1000BT) to each end of the wayside channel and set the test set to

37
transmit 64-byte frames with a traffic rate of 1.298% (9.89 Mbps for 64-byte
frames).
o Verify that the DCN-2 (WSC) ports auto-negotiate to “full” duplex and
speed “1G” in the Interface table (via Node Essentials).
o Verify that traffic is carried error free with no packet loss.
7. Using the test set, change the Utilization rate to 100%.
o Verify that ELS automatically detects this traffic rate and throttles the
transmission to a traffic rate of about < 10 Mb/s when using 64-byte
frames.
o Verify that packets are being lost when test set is using full 100%
8. Using the test set, change the traffic rate to 1.298% (9.89 Mbps for 64-byte
frames).
o Verify that ELS automatically detects this traffic rate and now allows the
transmission of traffic with no packet loss.

10BT:
9. Connect a 10BT Ethernet test set (set to Auto Negotiate and advertise Full
Duplex 10BT) to each end of the wayside channel and set the test set to
transmit 64-byte frames with a 100% Utilization rate. (7.619 Mbps using 64-
byte frame)
o Verify that the DCN-2 (WSC) ports auto-negotiate to “full” duplex and
speed “10M” in the Interface table (via Node Essentials).
o Verify that traffic is carried error free with no packet loss.
10. Repeat the above tests but this time provisioning the test set to Auto
Negotiate and advertise Half Duplex 10BT. When using Half Duplex mode,
ensure you send test set packets in one direction at a time.
o Verify that the DCN-2 (WSC) ports auto-negotiate to “half” duplex and
speed “10M” in the Interface table (via Node Essentials).

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

38
2.3 Licensing
2.3.1 Generating an ELS license file on the Ciena Portal

Objective:
This test case verifies that an ELS chassis registration request can be generated
and used to register the ELS on the Ciena licensing portal.

Setup:
An ELS License activation code is required to complete this test case.

Procedure:
1. Using the following CLI command, set the Registration ID of the chassis:
ELS# set license license-client registration-id <REG-ID>
NOTE: Make sure that the registration ID is representative of the specific ELS chassis, because this name will be
present your device on the Ciena Portal for licensing.
o Verify the “license-client registration-id” has been changed in the Node Essentials
>> Configuration >> License, on the top left corner.

2. In the Node Essentials, Configuration >> License menu, generate a device

registration request but clicking on the “ ” in the “License files” section.
o Verify that the request generation was successful, and a file was
generated: <REG-ID>_registration.bin
3. Download the file to your terminal by clicking on the download function next to
the file name:

Another Option to download the file: Open an SFTP session with the ELS
using port 20022, then go to the license folder and transfer the
generated .bin file to your terminal.
4. Login to the Ciena portal as your Company, then under Software >> Software
Licenses, select “Device Management” tab and click “Add Device”.

39
5. Fill in the prompted information and upload the registration request file
generated in step 2.
o Verify that the ELS device now appears under the list of registered
devices on the Ciena portal.
6. Under the “function” column of the registered devices table, select “Add
License” and click “GO”, then enter your license activation code and click
“Find”.
7. Select the desired licenses and click on “Activate License for Selected”.
o Verify that a “.lic” file is generated and downloaded to user terminal.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.3.2 Downloading and activating a license file locally on the ELS

chassis

Objective:
This test case verifies that a license file can be downloaded to the ELS and
activated locally.

Setup:
 An ELS License file is required to complete this test case (see previous test
case).
 An ELS chassis commissioned or uncommissioned that a License Violation is
active, or “licensing-in-commissioning-mode” alarm is present.
 If Chassis has a License violation:
- It will be “Not compliant” in the License menu (next to the Registration ID)
- In License menu, the Client Licenses table will have a 1 in the “In arrears”
column for that missing License.

Procedure:
1. In Node Essentials view the Registration ID of the chassis: Configuration >>
License, top left corner.
o Verify that the chassis has the correct registration-ID (see previous test
case).
2. Place the license file(s) onto an ftp, tftp, sftp, scp, http, or https server.
3. Using Node Essentials, in the Configuration >> License menu, download the
license file from the ftp, tftp, sftp, scp, http, or https server:
 Remote Host
 Download mode
 Login id
 Password
 File Path

40
Then click on add.
o Verify that the downloaded file appears in the list of License files and only
the “<filename>.lic” should be present (no path).

Licensing-in-commissioning-mode
4. Using Node Essentials activate the downloaded license file “Base Software
License” by selecting the file and in the right corner click the Activate icon ( ):

o Verify that licenses successfully activated and appear in the license

inventory
o Verify that the “licensing-in-commissioning-mode” alarm has cleared
o Verify a new license violation alarm is activated and that in the Client
Licenses it will appear as a 1 in the “In arrears”.

License Violation
5. Using Node Essentials activate the downloaded license file by selecting the
file and in the right corner click the Activate icon ( ):

o Verify that licenses successfully activated and appear in the license

inventory
o Verify that the if the license that as activated cleared the license violation
alarm
o Verify in the Client Licenses table, in the “In arrears” column, that license
violation went from a 1 to a 0.
o Verify that if no other License violations are present, that the chassis will
be compliant in the License menu (next to the Registration ID).

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

41
2.3.3 Downloading and activating licenses on the ELS chassis using
a license server

Objective:
This test case verifies that license files can be downloaded and activated to the
ELS using a license server.

Setup:
 An ELS chassis commissioned that has License Violation is active, or
“licensing-in-commissioning-mode” alarm present.
 The Target Add Channel is provisioned to -5 dBm (default) in the Photonic
Controllers.
 If Chassis has a License violation:
- It will be “Not compliant” in the License menu (next to the Registration ID)
- In License menu, the Client Licenses table will have a 1 in the “In arrears”
column for that missing License.
 A licenses server with all 3 necessary licenses:
- ELS Release 1.0.0 Base Software License
- ELS Wavelength Spectrum License
- ELS Low Transmit Power Support License
 License files are required to complete this test case (see test case at the
beginning of this section). The license files have been added to the license
server.

Procedure:
1. Using Node Essentials, in Configurations >> License menu, view the list of
available licenses (Client licenses):
 ELS Release 1.0.0 Base Software License
 ELS Low Transmit Power Support License
 ELS Wavelength Spectrum License

o Verify for each available license, the Source column indicates if the
license is pre-authorized or strict and the Used column indicates if the
license is in use. Only the “ELS Release 1.0.0 Base Software License”
and “ELS Wavelength Spectrum License” licenses should have Used =1.
2. In Node Essentials, Configuration >> License menu, provision the license
server:
 Host Address: IP:PORT
 Protocol: HTT/HTTPS
 Sync interval (min): 15 (Default)
 Click on Add.
o Verify the License server has been added and is connected ( )
o Verify that the “License Violation” alarm(s) clears or the “license-in-
commissioning-mode” alarm clears. You may need to wait up to 15
minutes.
3. View the list of available licenses (Client licenses):

42
o Verify that the compliance-state = compliant. (next to Registration ID)
o Verify that the ArrearsCount=0.
o Verify that the following licenses now have source = server, type = served-
external, state = valid:
• ELS Release 1.0.0 Base Software License
• ELS Wavelength Spectrum License
4. Provision the Photonic Control parameter Target Add Channel to -10 dBm in
the Configuration >> Control menu.
5. Refresh the License menu and looking at the looking at the following license
“ELS Low Transmit Power Support License:
o Verify that the compliance-state = compliant. (next to Registration ID)
o Verify that the ArrearsCount=0.
o Verify that the following licenses now have Used cdoubnt =1, Source =
server, Type = served-external, State = valid
6. Provision the Photonic Control parameter Target Add Channel to -5 dBm
(default) in the Configuration >> Control menu.
7. Refresh the License menu and looking at the looking at the following license
“ELS Low Transmit Power Support License:
o Verify that the compliance-state = compliant. (next to Registration ID)
o Verify that the ArrearsCount=0
o Verify that the following licenses now have Used = 0, Source = pre-
authorized, Type = pre-authorized, state = valid

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

43
2.4 Security
2.4.1 Local authentication - standard and complex password rules

Objective:
This test case verifies that standard and complex password rules can be enabled
on a ELS chassis.

The following requirements are common between all local password rules:
 a password is case sensitive
 a password must have at least 8 characters
 a password must have less than or equal to 128 characters
 a password is a combination of alphabetic (A to Z, a to z), numeric (0 to
9), and/or special characters
o supported special characters are: _ ! $ % - . / = [ ] ^ _ { } ~ # * +
 a password cannot contain a semicolon(;), colon(:), ampersand(&),
comma(,), space( ), question mark(?) or any control characters.";

The following requirements are specific to standard password rules:

 a password must have at least one alphabetic character and at least one
numeric or special character
 a password cannot contain the associated user ID

The following requirements are specific to complex password rules:

 a password must have at least three of the following combinations:
o upper case alphabetic character
o lower case alphabetic character
o numeric character
o special character
 a password must not include UID or Reverse of UID
 a password must not contain more than 3 of the same char consecutively

The following are the Local user ID rules:

 Can be 2 to 40 characters long
 Must be unique, up to 200 local users can be created
 Cannot begin with numeric character or be just numbers, can start with an
alpha character or an underscore “_”
 Are case sensitive
 Only supports the following characters:
o Alpha numeric [a..z][A..Z][0-9]
o Special characters underscore “_” dash “-” period “.”

Setup:
A commissioned ELS chassis.

44
45
Procedure:
1. Login to a ELS chassis with a super user account.
2. Under Security >> Authentication, click on Local:
o Verify that the password-rules parameter is by default set to complex.
3. Next to the “Config”, click on the edit ( ) and change the Local Password
Rules parameter to Standard and then click on the check mark ( ).
o Verify that the password-rules parameter displays Standard.
4. In Security >> Authentication, click on Local, click on the “+” on the far right
and create a new User ID which meets the standard password rules. For
example: User ID = ASMITH and Password = XXYY9494
o Verify that the new User ID is displayed.
5. Click on the User Profile ASMITH User ID, then at the far right click on the
garbage bin ( ), then Confirm to delete the user.
o Verify that User ID is removed
6. Using Node Essentials, create a new User ID which does not meet the
standard password rules. For example: User ID = ASMITH and Password is
the following (try each one):
a. XXYYTRFT
 Error message: Password must contain at least one
numeric/valid special character.
b. ASMITH9494
 Error message: Password cannot contain user name.
o Verify that the User ID is not added, and the correct error message is
displayed.
7. Next to the “Config”, click on the edit ( ) and change the Local Password
Rules parameter to Complex and then click on the check mark ( ).
o Verify that the password-rules parameter displays Complex.
8. In Security >> Authentication, click on Local, click on the “+” on the far right
and create a new User ID which meets the standard password rules. For
example: User ID = ASMITH and Password = XXyy9494$
o Verify that the new User ID is displayed.
9. Click on the User Profile ASMITH User ID, then at the far right click on the
garbage bin ( ), then Confirm to delete the user.
o Verify that User ID is removed
10. Using Node Essentials, create a new User ID which does not meet the
complex password rules. For example: User ID = ASMITH and Password is
the following (try each one):
a. XXYY9494
 Error message: Password must contain 3 of the following:
upper, lower, special, and numeric characters.
b. XXyyTrFt
 Error message: Password must contain 3 of the following:
upper, lower, special, and numeric characters.
c. XXYYTRFT$
 Error message: Password must contain 3 of the following:
upper, lower, special, and numeric characters.

46
d. ASMITHAm94
 Error message: Password cannot contain the user name.
e. HTIMSAAm94
 Error message: Password cannot contain reverse of user name.
f. XXyy9494$TTTT
 Error message: Password cannot contain repeating characters.
o Verify that the User ID is not added, and the correct error message is
displayed.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.2 Local user account authentication

Objective:
This test case verifies local user account authentication.

Setup:
The following is required.
 A commissioned ELS chassis.

With the super user account, you have provisioned the following user accounts:
 A User ID with limited user access level
 A User ID with admin user access level
 A User ID with super user access level

You can use Node Essentials to create the user with different accesses through
the Security >> Authentication, click on Local, click on the “+” at the and create
the user.

Procedure:
1. Log into the ELS chassis using the User ID which has limited user access
level.
o Verify that this user has access to read-only commands like:
 Access to view all parameters in menus that are being displayed
o Verify that this user does not have access to provisioning, maintenance, or
administration of security like:
 In the Facilities menu, no access to edit or perform restarts or Lamp
test.
 In the Services menu, no access to provision or de-provision a channel
 In the Configuration menu, no access to edit/delete or trigger an action
on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop but cannot reset
PMs
 No access to Security or Logs menu

47
2. Logout from the chassis.
3. Log back into the chassis using the User ID which has admin user access
level.
o Verify that this user has access to read-only commands like:
 Access to view all parameters in menus that are being displayed
o Verify that this user has access to provisioning or perform maintenance
like operations:
 In the Facilities menu, this user has access edit facilities, restart-type
warm or cold of chassis, or perform a Lamp Test
 In the Services menu, this user has access to provision, or de-
provision a channel
 In the Configuration menu, this user has access to change or trigger an
action on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop and reset PMs
o Verify that this user does not have access to administration of security
commands like:
 No access to Security or Logs menu
4. Logout from the chassis.
5. Log back into the chassis using the User ID which has super user access
level.
o Verify that this user has access to read-only commands like:
 Access to view all parameters in menus that are being displayed
o Verify that this user has access to provisioning or maintenance like:
 In the Facilities menu, this user has access edit facilities, restart-type
warm or cold of chassis, or perform a Lamp Test
 In the Services menu, this user has access to provision, or de-
provision a channel
 In the Configuration menu, this user has access to change or trigger an
action on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop and reset PMs
o Verify that this has access to administration of security commands like:
 Access to Security or Logs menu with edit functions

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.3Local authentication – Force out of local user

Objective:
This test case verifies that a local superuser can force-out users based on their
session-ID or user privileges.

Setup:
A commissioned ELS chassis.

48
Procedure:
1. Login to a ELS chassis using Node Essentials with a super user account.
2. Login twice more using CLI to the same chassis with the super user account
to create two more sessions.
3. On the original session (Node Essentials), Security >> Active users, to view
the active user sessions.
o Verify that there are 3 active user sessions.

4. On the original user session, attempt to force-out the session-id with interface
“rest” corresponding to itself by clicking on the ID and then clicking on the
Force logout. (e.g. force logout ID 141)

o Verify that the session is not lost, because a user cannot force itself out.
5. On the original user session, force-out the second session by clicking on the
ID and then clicking on the Force logout. (e.g. force logout ID 142)

o Verify that the session is lost.

6. On the original user session, force-out the third session by clicking on the ID
and then clicking on the Force logout. (e.g. force logout ID 149)

o Verify that the session is lost.

7. Create an admin user account following Test Case 2.4.1.

8. Login twice more to the same chassis using CLI with the admin user account
to create two more sessions.

49
9. On the original session (Node Essentials), Security >> Active users, to view
the active user sessions.
o Verify that there are 3 active user sessions.

10. On the original user session, force-out the second session by clicking on the
ID and then clicking on the Force logout. (e.g. force logout ID 154)

o Verify that the session is lost.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.4 User based intrusion detection

Objective:
This test case verifies that all login attempts for a specific limited or admin access
level user are blocked when an intrusion attempt is detected for that user. A
super user will not be blocked if the correct password is supplied.

Setup:
A commissioned ELS chassis.

Procedure:
1. Login as a Super user in the Node Essentials and set the following Intrusion
Attempt parameters under Security >> Intrusion, click on Config ( ) and edit
the following parameters:
 intrusion-threshold to 3
 lockout-duration to 60 (seconds).
2. Using another browser, attempt to log in to a network element using a user ID
with limited or admin access level and the wrong password 3 times for the
same user ID.
 Using the first web browser, verify that the “Intrusion” alarm is raised
(Node Essentials: Alarms >> Current alarms).

50
o Verify in the Security >> Intrusion is indicated that it is blocked ( ) in the
User intruded column.
o Verify that any attempts to log in with the user ID are blocked for 60
seconds.
o Verify that as a Super user you can unblock the user access by clicking on
the user and on the top right of the table you can unblock the user ( )
o Verify that you can log in with the user ID after about 60 seconds.
 Using the first session, verify that the “Intrusion” alarm clears after about
60 seconds.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.5 TACACS+ user account authentication and authorization

Objective:
This test case verifies TACACS+ user account authentication and authorization.
For this release Authentication and accounting is only supported for CLI
commands, not for Node Essentials.

Setup:
The following is required.
 A commissioned ELS chassis
 A TACACS+ server

The TACACS+ server is setup to include the following user groups and
privileges:
 Group1 with privilege level 1 (with limited privilege level)
 Group2 with privilege level 9 (with admin privilege level)
 Group3 with privilege level 15 (with superuser privilege level)

Note: The Local authentication is always enabled and cannot be disabled. When
TACACS+ is enabled then it becomes the first method of authentication.

Procedure:
1. Log into the chassis using a User ID which has super user access level.
2. Provision the state of TACACS+ server:
 Security >> Authentication
 Click on TACACS+:
 click on Edit ( ) next to the Config
o Admin state = Enable
o Authorization admin state = Enabled
o Authentication admin state = Enabled
o Accounting admin state = Enabled

51
o Timeout = 6 (default)
o Key min length (1…128) = 8 (default)
o Click on the to confirm
o Verify all entered fields are enabled.
3. Provision the secret key for TACACS+ server:
 Security >> Authentication
 Secret key:
o click on TACACS+
o click on the “Generate key” ( )
o enter TACACS+ secret key
o click on Confirm
Note: Where key is the same key (or secret) defined on the TACACS+ server and key must be
at least 8 characters.
o Verify Secret key is entered.
4. Provision the TACACS+ server:
 Security >> Authentication (in the Managed servers table)
o Click on the Create ( )
 IP address: x.x.x.x
 TCP port: xxxx
 Admin state: Enabled
 Priority: 1
o Click on Confirm
o Verify server is provisioned in Managed Servers table.
5. Enable TACACS+ server
 Security >> Authentication
o Click on the “Change auth” (top right corner)
 Check off TACACS+
 Click on Confirm
o Verify the “Authentication method” has switched “On”.
6. Repeat the above steps if a second TACACS+ server must be provisioned.
7. Logout from the chassis.
8. Log back into the chassis using a TACACS+ Group1 (with privilege level 1,
limited) user.
o Verify that the user you logged in with has Access level = “limited”,
Authentication method = “tacacs” and Interface = “rest” (Node Essentials).
You will find this in the Security >> Active users menu.
o Verify that this user has access to read-only action like:
 Access to view all parameters in menus that are being displayed
o Verify that this user does not have access to provisioning, maintenance, or
administration of security like:
 In the Facilities menu, no access to edit or perform restarts or Lamp
test.
 In the Services menu, no access to provision or de-provision a channel
 In the Configuration menu, no access to edit/delete or trigger an action
on the Comms, Control, License and Software Maintenance

52
 In the Performance menu, can view, start, and stop but cannot reset
PMs
 No access to Security or Logs menu
9. Logout from the chassis.
10. Log back into the chassis using a TACACS+ Group2 (with privilege level 9,
admin) user.
o Verify that the user you logged in with has Access level = “admin”,
Authentication method = “tacacs” and Interface = “rest” (Node Essentials).
You will find this in the Security >> Active users menu.
o Verify that this user has access to read-only action like:
 Access to view all parameters in menus that are being displayed
o Verify that this user has access to provisioning or perform maintenance
like operations:
 In the Facilities menu, this user has access edit facilities, restart-type
warm or cold of chassis, or perform a Lamp Test
 In the Services menu, this user has access to provision, or de-
provision a channel
 In the Configuration menu, this user has access to change or trigger an
action on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop and reset PMs
o Verify that this user does not have access to administration of security
commands like:
 No access to Security or Logs menu
11. Logout from the chassis.
12. Log back into the chassis using a TACACS+ Group3 (with privilege level 15,
super) user.
o Verify that the user you logged in with has Access level = “super”,
Authentication method = “tacacs” and Interface = “rest” (Node Essentials).
You will find this in the Security >> Active users menu.
o Verify that this user has access to read-only action like:
 Access to view all parameters in menus that are being displayed
o Verify that this user has access to provisioning or maintenance like:
 In the Facilities menu, this user has access edit facilities, restart-type
warm or cold of chassis, or perform a Lamp Test
 In the Services menu, this user has access to provision, or de-
provision a channel
 In the Configuration menu, this user has access to change or trigger an
action on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop and reset PMs
o Verify that this has access to administration of security commands like:
 Access to Security or Logs menu with edit functions.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

53
54
2.4.6 TACACS+ authentication when TACACS+ servers are
unavailable

Objective:
This test case verifies that when TACACS+ authentication is enabled but
TACACS+ enabled servers are unavailable:

 TACACS+ authentication attempts result in denying authentication.

 A backup authentication mechanism (Local) is available for users to login.

Setup:
The following is required.
 A commissioned ELS chassis which has been provisioned to use TACACS+
as the Type Level 1 Authentication Mode. (Refer to test case 2.4.5)
 A TACACS+ server.

Procedure:
1. Disconnect the TACACS+ server or servers from the network. You may
instead stop the TACACS service/process on the server or servers.
2. Wait 5 minutes.
3. Attempt to log into the chassis using a TACACS+ user.
o Verify that the login fails.
4. Log into the chassis using a local user.
o Verify that the login succeeds.
o Verify that the “TACACS Unavailable” alarm is raised.
5. Logout from session.
6. Re-connect the TACACS+ server or servers to the network. You may instead
start the TACACS service/process on the server or servers.
7. Wait 5 minutes.
8. Attempt to log into the chassis using a TACACS+ user.
o Verify that the login succeeds.
o Verify that the “TACACS Unavailable” alarm is not active.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.7 TACACS+ command level accounting

Objective:
This test case verifies that a TACACS+ server will be sent all the ELS accounting
information if TACACS accounting is enabled on the ELS chassis. This only
supported for CLI commands.

55
56
Setup:
The following is required.
 A commissioned ELS chassis which has been provisioned to use TACACS+
as the Type Level 1 Authentication Mode and supports accounting logging.
(Refer to test case 2.4.5)
 A TACACS+ server.

Procedure:
1. Login to the ELS chassis using a CLI Session and the TACACS+ credentials.
o Verify that the Accounting admin state is “enabled”
ELS# show security-aaa tacacs
security-aaa tacacs global-config
+-------------------------------------------------------------------------------+
| Name | Value |
+-------------------------------------------------------------------------------+
| admin-state | enabled |
| operational-state | up |
| authentication-admin-state | enabled |
| authorization-admin-state | enabled |
| accounting-admin-state | enabled |
| timeout | 6 |
| key-min-length | 8 |
| secret | xNj+0Bae1gC2op6aaSDaXA== |
+-------------------------------------------------------------------------------+
2. Any CLI command can be used to verify accounting, but for simplicity use
“show active-alarms”:
o Verify that the user logging is in the TACACS+ server accounting logs.
o Verify that the user commands are in the TACACS+ server accounting
logs.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.8 TACACS+ command level authorization

Objective:
This test case verifies that the TACACS+ server can be used to authorize
specific commands for different users.

Setup:
The following is required.
 A commissioned ELS chassis which has been provisioned to use TACACS+
as the Type Level 1 Authentication Mode and supports command
authorization. (Refer to test case 2.4.5)
 A TACACS+ server.

57
Set some command authorization details on the TACACS+ server config file such
as (this denies a user in the super category from viewing security info):
group = admin{
default service = permit
service = shell {
default command = permit
set idletime = 1
set priv-lvl = 10
script = { if (cmd == "show security-aaa") deny }
}
}

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.9 RADIUS user account authentication and authorization

Objective:
This test case verifies RADIUS user account authentication and authorization.

Setup:
The following is required.
 A commissioned ELS Chassis.
 A RADIUS server.

The RADIUS server is setup to include the following user groups and privileges:
 Group1 with limited privilege level
 Group2 with admin privilege level

58
 Group3 with superuser privilege level

Note: The Local authentication is always enabled and cannot be disabled. When
RADIUS is enabled then it becomes the first method of authentication.

Procedure:
1. Log into the chassis using a User ID which has super user access level.
2. Provision the state of RADIUS server:
 Security >> Authentication
o Click on RADIUS
o Click on Edit ( ) next to the Config
 Admin state = Enable
 Authentication admin state = Enabled
 Timeout = 6 (default)
 Retries = 3 (default)
 Key min length (1…128) = 8 (default)
o Click on the to confirm
o Verify all entered fields are enabled.
3. Provision the secret key for RADIUS server:
 Security >> Authentication
o Secret key
 click on the “Generate key” ( )
 enter RADIUS key
 click on Confirm
Note: Where key is the same key (or secret) defined on the RADIUSD server and key
must be at least 8 characters.
o Verify Secret key is entered.
4. Provision the RADIUS server:
 Security >> Authentication (in the Managed servers table)
o Click on the Create ( )
 IP address: x.x.x.x
 UDP port: xxxx
 Admin state: Enabled
 Priority: 1
o Click on Confirm
o Verify server is provisioned in Managed servers table.
5. Enable RADIUS server
 Security >> Authentication
 Click on the “Change auth” (top right corner)
o Check off RADIUS
o Click on Confirm
Note: If TACACS+ is already checked off then uncheck it and then check RADIUS. ELS
Chassis only supports only TACACS+ or RADIUS, never simultaneously. Local is always
enabled.
o Verify the “Authentication method” has switched “On”.
6. Repeat the above steps if a second RADIUS server must be provisioned.
7. Logout from the chassis.

59
8. Log back into the chassis using a RADIUS Group1 (with limited privilege
level) user.
o Verify that the user you logged in with has Access level = “limited”,
Authentication method = “radius” and Interface = “rest” (Node Essentials).
You will find this in the Security >> Active users menu.
o Verify that this user has access to read-only commands like:
 Access to view all parameters in the menus
o Verify that this user does not have access to provisioning, maintenance, or
administration of security like:
 In the Facilities menu, no access to edit or perform restarts or Lamp
test.
 In the Services menu, no access to provision or de-provision a channel
 In the Configuration menu, no access to edit/delete or trigger an action
on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop but cannot reset
PMs
 No access to Security or Logs menu
9. Logout from the chassis.
10. Log back into the chassis using a RADIUS Group2 (with admin privilege level)
user.
o Verify that the user you logged in with has Access level = “admin”,
Authentication method = “radius” and Interface = “rest” (Node Essentials).
You will find this in the Security >> Active users menu.
o Verify that this user has access to read-only commands like:
 Access to view all parameters in the menus
o Verify that this user has access to provisioning or perform maintenance
like operations:
 In the Facilities menu, this user has access edit facilities, restart-type
warm or cold of chassis, or perform a Lamp Test
 In the Services menu, this user has access to provision, or de-
provision a channel
 In the Configuration menu, this user has access to change or trigger an
action on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop and reset PMs
o Verify that this user does not have access to administration of security
commands like:
 No access to Security or Logs menu
11. Logout from the chassis.
12. Log back into the chassis using a RADIUS Group3 (with superuser privilege
level) user.
o Verify that the user you logged in with has Access level = “super”,
Authentication method = “radius” and Interface = “rest” (Node Essentials).
You will find this in the Security >> Active users menu.
o Verify that this user has access to read-only action like:
 Access to view all parameters in the menus
o Verify that this user has access to provisioning or maintenance like:

60
 In the Facilities menu, this user has access edit facilities, restart-type
warm or cold of chassis, or perform a Lamp Test
 In the Services menu, this user has access to provision, or de-
provision a channel
 In the Configuration menu, this user has access to change or trigger an
action on the Comms, Control, License and Software Maintenance
 In the Performance menu, can view, start, and stop and reset PMs
o Verify that this has access to administration of security commands like:
 Access to Security or Logs menu with edit functions

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.4.10 RADIUS authentication when RADIUS servers are unavailable

Objective:
This test case verifies that when RADIUS authentication is enabled but RADIUS
enabled servers are unavailable:

• RADIUS authentication attempts result in denying authentication.

• A backup authentication mechanism (Local) is available for users to login.

Setup:
The following is required.
 A commissioned ELS chassis which has been provisioned to use RADIUS
as the Authentication Mode.
 A RADIUS server.

Procedure:
1. Disconnect the RADIUS server or servers from the network. You may instead
stop the RADIUS service/process on the server or servers.
2. Wait 5 minutes.
3. Attempt to log into the chassis using a RADIUS user.
o Verify that the login fails.
4. Log into the chassis using a local user.
o Verify that the login succeeds.
o Verify that the “RADIUS Unavailable” alarm is raised.
5. Logout from session.
6. Re-connect the RADIUS server or servers to the network. You may instead
start the RADIUS service/process on the server or servers.
7. Wait 5 minutes.
8. Attempt to log into the chassis using a RADIUS user.
o Verify that the login succeeds.
o Verify that the “RADIUS Unavailable” alarm is not active.

61
Test Case Results:
Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

62
2.5 Syslog
2.5.1 Syslog server provisioning

Objective:
This test case verifies that up to 3 syslog servers can be provisioned on an ELS
Chassis.

Test setup:
Three syslog servers are required.

Procedure:
1. Login to ELS
2. Configure Syslog server #1 using Node Essentials
 Logs >> Syslogs
 Click on Create ( ) in the Collectors table
o Host: x.x.x.x
o RFC: RFC5424
o Admin state: enabled
 Click on Confirm
o Verify that the syslog server is provisioned in the Collectors table.
3. Start a new Node Essentials session and log into the chassis.
o Verify that the syslog server #1 receives syslog events indicating that a
user logged into the chassis.
4. Create an alarm on the chassis.
o Verify that the syslog server #1 receives syslog events for the alarm.
5. Repeat above for Syslog server #2 and #3.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.5.2 Log events sent to 3 separate syslog servers

Objective:
This test case verifies that the ELS chassis can send logs to 3 separate syslog
servers.

Test setup:
Same as previous test case.

Procedure:
1. With 3 syslog servers provisioned and enabled on the chassis, generate an
event. For example, provisioning, login, or logout commands will generate
syslog events.

63
o Verify that the event is sent and reported on all 3 Syslog servers.
2. Delete syslog server #1 on the chassis using Node Essentials:
 Logs >> Syslogs
 In the Collectors table select the server #1
 Click on the delete ( ) icon
 Click on Confirm
o Verify that server #1 is no longer in the Collector table.
3. Generate additional events.
o Verify that syslog server #1 no longer receives events.
o Verify that the event is sent and reported on the Syslog server #2 and #3.
4. Add syslog server #1 back on the chassis using Node Essentials:
 Logs >> Syslogs
 Click on Create ( ) in the Collectors table
o Host: x.x.x.x
o RFC: RFC5424
o Admin state: enabled
 Click on Confirm
5. Delete syslog server #2 on the chassis using Node Essentials:
 Logs >> Syslogs
 In the Collectors table select the server #1
 Click on the delete ( ) icon
 Click on Confirm
6. Generate new events.
o Verify that the event is sent and reported on the Syslog server #1 and #3.
o Verify that syslog server #2 no longer receives events.
7. Delete all 3 syslog servers on the chassis and generate events.
o Verify that syslog server #1, #2 and #3 no longer receives events.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

64
2.6 NBI

Ciena ELS Specific MIBs

CIENA-ELS-CHASSIS-MIB
CIENA-PRO-ALARM-MIB
CIENA-PRO-SOFTWARE-MIB
CIENA-PRO-SYSTEM-MIB

2.6.1 SNMP v2c Trap Reporting

Objective:
This test case verifies that an SNMP v2c agent can be enabled and disabled on
an ELS chassis. When enabled, SNMP traps sent to a remote workstation are
viewed with an SNMP manager or SNMP MIB browser trap viewer and verified to
be consistent with the CLI/Node Essentials alarms list.

Pre-requisites:
No SNMP v2c agent should be currently provisioned on the chassis. To confirm
this, there should be no output in response to the following CLI command:
ELS# show snmp

Procedure:
1. Establish an CLI session with the ELS chassis where the SNMP v2c agent is
to be enabled.
2. Use the following CLI command to enable the SNMP v2c agent. The destination IP
address is the remote workstation where traps are to be viewed, which has an
SNMP MIB browser installed.
ELS# set snmp-options server state enable
ELS# create snmp target ciena tag ciena target-params ciena udp ip
<destination IP> port 162
ELS# create snmp target-params ciena v2c security-name public
ELS# create snmp notify ciena tag ciena type trap
ELS# set snmp community public text-name public
o Verify that the commands are accepted.
o Verify that the SNMP agent is provisioned and that the target IP address,
UDP port and security-name (public) are provisioned using the following
CLI command:
ELS# show snmp
3. Access the remote workstation where the SNMP manager / SNMP client MIB
browser is installed. Download the MIBs from the ELS sftp port 20022 /mibs
folder to the remote workstation.

65
o Verify that the supported MIBs are available for download from the chassis
via the sftp port 20022 /mibs folder.
Note: In this release, the supported MIBs are:
 [Link]
4. On the remote workstation with the SNMP manager/3rd party SNMP v2c MIB
browser, load all MIBs.
o Verify this is successful.
Note: some 3rd party MIB browsers may require that MIBs be compiled,
and the compiled files saved before being loaded.
5. Once the MIBs are loaded, provision a profile on the SNMP manager/3rd party
MIB browser with the following:
 SNMP protocol version v2c
 remote IP of chassis reporting traps (ELS chassis IP address)
 UDP port number (161): traps will be received on UDP port 162)
 community strings: public
o Verify the remote SNMP agent is contacted (e.g. perform a walk using the
private -> enterprises -> ciena > cienaPro -> cienaPro AlarmMIB).
Note: If using a Linux host to receive and view the traps, perform the
following CLI command:
sudo tcpdump -i any -X -nn port 162
6. Access the trap viewer and monitor for autonomous SNMP traps being
reported.
7. At the ELS chassis where SNMP v2c agent was provisioned, and the CLI
session is established, perform a span fiber-cut which will result in an Optical
Line Fail alarm reported at the ELS chassis.
o Verify all raised alarm IDs and corresponding alarm information in CLI are
shown in their corresponding trap notification.
8. Repair the fiber-cut action which will result in the clearing of the alarms at the
ELS chassis.
o Verify SNMP trap notifications are seen for all cleared alarm conditions.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.6.2 SNMP v2c Walk using MIBs

Objective:
This test case verifies that the following new MIBs work correctly (refer to table
under 2.6 NBI).

Setup:
A commissioned ELS system

In addition:

66
 ELS MIBs has already been downloaded from the ELS chassis and have
been compiled in the MIB Browser.
 To get latest copy of the ELS MIBs, using SFTP client, establish an SSH
public port 20022 session, then access the /mibs folder and download the
MIBs
 A 3rd party MIB browser is used for this test case (e.g. MG-Soft MIB
browser)

Procedure:
1. Set up the SNMP on the chassis and the MIB browser. Refer to Test Case
2.6.1 for provisioning.
2. On the SNMP browser, initiate a walk on the following MIBs:
 CIENA-ELS-CHASSIS-MIB
 CIENA-PRO-ALARM-MIB
 CIENA-PRO-SOFTWARE-MIB
 CIENA-PRO-SYSTEM-MIB
o Verify the walk response return correctly.

Example:

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.6.3 SNMP v2c Get / Get Bulk Operations

Objective:
This test case verifies that the SNMP Get /Get Bulk Operation work on single
MIB or at a higher level MIB (refer to table under 2.6 NBI).

Setup:
A commissioned ELS system

In addition:
 ELS MIBs has already been downloaded from the ELS chassis and have
been compiled in the MIB Browser.
67
 To get latest copy of the ELS MIBs, using SFTP client, establish an SSH
public port 20022 session, then access the /mibs folder and download the
MIBs
 A 3rd party MIB browser is used for this test case (e.g. MG-Soft MIB
browser)

Procedure:
1. Set up the SNMP on the chassis and the MIB browser. Refer to Test Case
2.6.1 for provisioning.

2. On the SNMP browser, initiate a SNMP Get operation on the following MIBs:
 CIENA-ELS-CHASSIS-MIB
 cienaElsChassisSerialNumber

3. If there many instances, it will ask to pick one but, in this case, there is only
one instance.
o Verify that the serial number is correct.

Example:

4. On the SNMP browser, initiate a SNMP Get- Bulk operation on the following
MIBs with no instance is selected.
 CIENA-ELS-CHASSIS-MIB
 cienaElsChassisSerialNumber
o Verify that the output shows all the information about the ELS chassis, and
it is correct.

68
Example:

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.6.4 Enable/Disable of SNMP interface

Objective:
SNMP disable and enable will stop and start all SNMP interactions with MIB
browser.

Setup:
Any commissioned ELS chassis with a SNMP MIB setup (refer to Test Case
2.6.1 for provisioning).

Procedure:
1. Perform an SNMP walk on any of the ELS MIBS
o Verify that the walk completes successfully
2. Disable SNMP using the following CLI command:
ElS# set snmp-options server state disable
3. Attempt another SNMP walk on any of the ELS MIBS
o Verify the walk does not complete
4. Re-enable SNMP using the following CLI command:
ELS# set snmp-options server state Enable
5. Perform an SNMP walk on any of the ELS MIBS
o Verify that the walk completes successfully

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

69
2.7 Photonic Features
2.7.1 Channel Provision and Connect

Objective:
Adding a coherent pluggable/transponder to an ELS configuration.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke.

See section 1.4.4 for an example.

 Supported coherent pluggable/transponders. LC-LC Duplex patch chords.

o Whether the source wavelength originates from a:
 Ciena pluggable/ transponder in a Ciena product
 foreign pluggable/transponder in a foreign product
 Ciena pluggable in a foreign product
 A test-set to monitor the traffic status.
 Different PAD attenuators (1,2,3,5…dB etc.) if required for Foreign TX or Rx
 Determine if Rx padding is required for foreign pluggables/transponders and
have them ready, if needed.
o Rx powers at OADMs sites are in the range of 0dBm to +3dBm and at
48-CH terminals in the range of -4 to -7 dBm of power. These are
supported by all Ciena pluggables/transponders and do not require any
further actions except for plug-in and turn-up traffic.
 The required “Target Add Channel power” is properly provision on the ELS
network.

Procedure:
1. Login to ELS chassis at which channel being add/drop. (Node Essentials)
2. Click on the Services menu and check the availability of different bands or
fixed channel frequencies on ELS chassis.
3. Select the band (for 48-CH terminal only) where the channel is to be added.
o Verify that the required Channel is available, and nothing is provisioned on
it.
4. Select the Channel port.
o Verify the Services page refreshes and displays the related information.
5. Take note of the following values:
 Wavelength (nm)
 Frequency (THz)
 Target input power (dBm)
6. Click the Pencil icon in the Transponder address section of the Service menu
o Verify the fields become editable.
7. Update the fields as required:
 Type: Ciena, Foreign

70
Select Ciena if the source wavelength originates from a Ciena
pluggable/transponder in a Ciena product.
Select Foreign if the source wavelength originates from a foreign
pluggable/transponder in a foreign box or from a Ciena pluggable in a
foreign box.

 Tx port (Required): Enter the far-end address of the transceiver.

 Rx port (Required): This field auto-populates with the same information

you entered for the Tx port if you are using a Ciena source.
If the Tx port and Rx port information described below is not provisioned,
then channel alarms will not be raised.
Some Foreign pluggables/transponders have different far-end addresses
for the Tx port and Rx port. If you are using a Foreign source, you can
enter the far end address for the Rx port accordingly.

 Excess loss (dB)

The Excess loss (dB) is the insertion loss between the transceiver and the
ELS chassis. The default is 0.

 Service label
Enter a label if you plan to use MCP. MCP requires this service label. Use
the same at both ends of the connection. Otherwise, leave this field blank.

8. Click on the check/tick mark next to the Transponder Address.

9. Log into the pluggable/transponder and provision the required frequency and
Tx power.
10. Connect the pluggable/transponder to the ELS channel ports, and if padding
is required, add it on the foreign pluggable/transponder Rx.
o Verify that the power received at the ELS chassis port matches the
channel’s “Target Input Power”. Make the necessary adjustments on the
pluggable/transponder Tx. You may need to use pads if the
pluggable/transponder powers cannot be controlled.
o Verify that Channel port is solid green color in the Service menu.
11. Log into the far-end chassis and perform all the above steps.
12. After finishing provisioning and connecting the channel to the ELS system:
o Verify traffic is up and running.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

71
2.7.2 Adding a channel to a ELS system with N channels present
without impact

Objective:
Adding a new channel to a ELS system will not cause any traffic impact to
existing channels carrying traffic.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with at least one
channel provisioned.

See section 1.4.4 for an example.

Procedure:
1. Setup traffic in on existing channels present
2. Select a add/drop location for new channel that will at least enter a filter
where existing traffic is present, and the new channel will run side-by side
with other channels on the system.
3. Following Test Case 2.7.1 to add new channel. When connection new
channel to the ELS system monitor existing traffic.
o Verify that existing traffic is not impacted.
o Verify that new channel has been added can carry traffic.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.7.3 Channel Deprovision and Disconnect

Objective:
Removing and de-provisioning a coherent pluggable/transponder from an ELS
configuration.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with at least one
channel provisioned.
See section 1.4.4 for an example.

Procedure:
1. Login to ELS chassis (Node Essentials)
2. Click on the Services menu and select the channel you want to delete.
3. Click on the “Reset” function ( ) in the “Transponder address”.
o Verify the details in the Tx Port, Rx Port and Service label wiped out.
4. Physically disconnect the modems from the ELS chassis channel ports.

72
5. Refresh the ELS chassis login session by reloading the page.
o Verify channel port color changes from green to grey.
o Verify that traffic is down.
6. Log into the far-end chassis and perform all the above steps.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.7.4 Channel Alarms

Objective:
This test is used to verify the channel alarms on ELS chassis when channel
power goes high or low.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with at least one
channel provisioned with “Transponder Address”

See section 1.4.4 for an example.

Configured Test set to check the traffic status.

Refer to sections 1.4.3 for explanations on Degrade, Out of range and hystersis.

Procedure:
1. Login to the SITE-A and in the “Services” menu click on the channel under
test.
2. Adjust the channel power to the “Target input power (dBm)”.
o Verify no channel alarm present at SITE-A.
o Verify channel port is solid GREEN in the Services menu.
3. Record the Channel port dial count.
4. Increase the pluggable/transponder Tx power (ex: by > 2 dB) to a value that
lies in “Degrade high” margin range and refresh the Services menu.
o Verify channel power is in the upper amber range on the graph in Services
menu.
o Verify channel port is solid AMBER.
o Verify the Channel port dial count Degrade has increased by 1.
o Verify a minor “Degrade High power” alarm is raised on that channel in the
Alarms menu.
5. Increase the pluggable/transponder Tx power (ex: by > 3 dB from previous
step) so that it reaches to “Out of range high” and refresh the Services menu.
o Verify channel power is in the red range on the graph in the Services
menu.

73
o Verify channel port is solid RED.
o Verify the Channel port dial count Out of Range has increased by 1 and
the Degrade decreased by 1.
o Verify a major “Out of Range High Power” alarm is raised on that channel
in the Alarms menu.
6. Return the Tx power of the channel back to the required Target input power.
 If the channel power is in the mixed region (hysteresis), it needs to
clear that region to clear any alarms.
o Verify channel port is solid GREEN in the Services menu.
o Verify the Channel port dial count Out of Range has decreased by 1 and
the Normal increased by 1.
7. Decrease the pluggable/transponder Tx power (ex: by > 2 dB) to a value that
lies in “Degrade Low” margin range and refresh the Services menu.
 Add a PVOA or pad at Tx pluggable/transponder port.
o Verify channel power is in the lower amber range on the graph in Services
menu.
o Verify channel port is solid AMBER.
o Verify the Channel port dial count Degrade has increased by 1.
o Verify a minor “Degrade Low power” alarm is raised on that channel in the
Alarms menu.
8. Decrease the pluggable/transponder Tx power (ex: by > 3 dB) so that it
reaches to “Out of range Low” and refresh the Services menu.
o Verify channel power is in the lower red range on the graph in Services
menu.
o Verify channel port is solid RED.
o Verify the Channel port dial count Out of Range has increased by 1 and
the Degrade decreased by 1.
o Verify a major “Out of Range Low Power” alarm is raised on that channel.
9. Return the Tx power of the channel back to the required Target input power.
 If the channel power is in the mixed region (hysteresis), it needs to
clear that region to clear any alarms.
o Verify channel port is solid GREEN in the Services menu.
o Verify the Channel port dial count Out of Range has decreased by 1 and
the Normal increased by 1.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

74
2.7.5 Line Alarms
Objective:
This test is used to verify the Line alarms on ELS chassis when line power goes
low and Measured loss increases.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned.

See section 1.4.4 for an example.

Configured Test set to check the traffic status.

The default thresholds are provisioned.

Refer to sections 1.4.3 for explanations on Degrade, Out of range and hystersis.

Procedure:
1. Login to both ELS chassis (Node Essentials) under test: SITE-A and SITEB-1.
2. @ SITE-A, in Service menu click on Line port and note down the values for
Measured loss and Margin.
o Verify Line out margin is in Normal range (> 6dB Margin).
o Verify no Line alarm is present in the Alarms menu.
3. Insert a PVOA (@ 0dB of attenuation) on the Line out of SITE-A and wait for
link to re-establish and traffic recovered and note down the values for
Measured loss and Margin.
o Verify Line out margin is in Normal range (> 4dB Margin).
o Verify no Line alarm is present in the Alarms menu.
4. Increase the PVOA so that SITE-A margin decreased to a Degrade (Amber)
range (0 - 3dB Margin).
 Refresh the SITE-A session.
o Verify SITE-A, Line out Measured loss increases, and Margin decreases
from the values recorded above.
o Verify Line out port at SITE-A a minor alarm “Loss Margin Degrade” is
raised in Alarms menu.
o Verify Line in port at SITE-B1 a minor alarm “Neighbor Loss Margin Fault”
is raised in Alarms menu.
o Verify traffic is not impacted when margin is in the degrade.
5. Increase the PVOA so that the SITE-A margin decreased to an Out of range
(Red) range ( -2 < x < -1 dB Margin).
 Refresh the SITE-A session.
 Traffic may or may not be impacted in this range. Depends on
pluggable/transponder performance.
o Verify SITE-A, Line port Measured loss increases and Margin decreases
further from its previous value.

75
o Verify Line out port at SITE-A a major alarm “Loss Margin Fail” is raised in
Alarms menu.
o Verify Line in port at SITE-B1 a minor alarm “Neighbor Loss Margin Fault”
is raised in Alarms menu.
6. Decrease the PVOA so that margin increased to a Degrade (Amber) range (0
- 3dB Margin).
 Refresh the SITE-A session.
 If the line margin is in the -1 to 0 dB, the alarm will not change since it
is needs to clear the hysteresis.
o Verify SITE-A, Line out Measured loss decreases, and Margin increases
from the previous step.
o Verify Line out port at SITE-A a minor alarm “Loss Margin Degrade” is
raised in Alarms menu.
o Verify Line in port at SITE-B1 a minor alarm “Neighbor Loss Margin Fault”
is raised in Alarms menu.
o Verify traffic has recovered if impacted from previous step.
7. Decrease PVOA to 0 dB of attenuation.
 Refresh the SITE-A session.
 If the line margin is in the 3 dB to 4 dB, the alarm will not change since
it is needs to clear the hysteresis.
o Verify SITE-A Line out margin is in Normal range (> 4dB Margin).
o Verify no Line alarm is present in the Alarms menu.
8. Remove PVOA from Line out.
o Verify at Line ports Measured loss and Margin is back to initial value.
o Verify all Line alarms cleared in Alarms menu.
o Verify traffic is restored.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.7.6 Express Alarms

Objective:
This test is used to verify the Express (At OADM sites only) alarms on ELS
chassis when Express power goes low and Measured loss increases.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with at least one
channel provisioned.
See section 1.4.4 for an example.

Configured Test set to check the traffic status.

The default thresholds are provisioned.

76
Refer to sections 1.4.3 for explanations on Degrade, Out of range and hystersis.

Procedure:
1. Login to both ELS chassis (Node Essentials) under test: SITE-B1 and SITE-
B2.
2. @ SITE-B1, In Service menu click on Express port and note down the values
for Measured loss and Margin.
o Verify Express out margin is in Normal range (> 3 dB Margin).
o Verify no Express alarm is present in the Alarms menu.
3. Insert a PVOA (@ 0dB of attenuation) on the Express out of SITE-B1 and wait
for link to re-establish and traffic recovered and note down the values for
Measured loss and Margin.
o Verify Express out margin is in Normal range (> 1 dB Margin).
o Verify no Express alarm is present in the Alarms menu.
4. Increase the PVOA so that margin decreased to a Degrade (Amber) range (0
– 1 dB Margin).
 Refresh the ELS login session by reloading the page.
o Verify at Express out Measured loss increases, and Margin decreases
from the values recorded above.
o Verify on Express out port at SITE-B1 a minor alarm “Loss Margin
Degrade” is raised in Alarms menu.
o Verify on Express in port at SITE-B2 a minor alarm “Neighbor Loss Margin
Fault” is raised in Alarms menu.
o Verify traffic is not impacted when margin is in the degrade.
5. Increase the PVOA so that margin decreased to an Out of range (Red) range
( -2 < x < -1 dB Margin).
 Refresh the ELS login session by reloading the page.
 Traffic may or may not be impacted in this range. Depends on
pluggable/transponder performance.
o Verify at Express port Measured loss increases, and Margin decreases
further from the previous step.
o Verify on Express out port at SITE-B1 a major alarm “Loss Margin Fail” is
raised in Alarms menu.
o Verify on Express in port at SITE-B2 a minor alarm “Neighbor Loss Margin
Fault” is raised in Alarms menu.
6. Decrease the PVOA so that margin increased to a Degrade (Amber) range (0
- 1dB Margin).
 Refresh the ELS login session by reloading the page.
 If the Express margin is in the -1 to 0 dB, the alarm will not change
since it is needs to clear the hysteresis.
o Verify at Express out Measured loss decreases, and Margin increases
from the previous step.
o Verify on Express out port at SITE-B1 a minor alarm “Loss Margin
Degrade” is raised in Alarms menu.

77
o Verify on Express in port at SITE-B2 a minor alarm “Neighbor Loss Margin
Fault” is raised in Alarms menu.
o Verify traffic has recovered if impacted from previous step.
7. Decrease PVOA to 0 dB of attenuation.
 Refresh the ELS login session by reloading the page
 If the line margin is in the 1 dB to 2 dB, the alarm will not change since
it is needs to clear the hysteresis.
o Verify Express out margin is in Normal range (> 2 dB Margin).
o Verify no Line alarm is present in the Alarms menu.
8. Remove PVOA from Line out.
o Verify at Express port Measured loss and Margin is back to initial value.
o Verify all Express alarms cleared in Alarms menu.
o Verify traffic is restored.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.7.7 Line Fiber Pinch feature

Objective:
This test case verifies that EPIC (ELS Photonic Integrated Controller) will make
necessary adjustments to accommodate change in span loss.

Setup:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned.

See section 1.4.4 for an example.

Configured Test set to check the traffic status.

Procedure:
1. Login to both ELS chassis (Node Essentials) under test: SITE-A and SITE-B1.
2. @ SITE-A, in Service menu click Line port and note down the values for
Measured loss and Margin.
o Verify Line out margin is in Normal range (> 10dB Margin).
o Verify no Line alarm is present in the Alarms menu.
3. Insert a PVOA (@ 0dB of attenuation) on the Line out of SITE-A and wait for
link to re-establish and traffic recovered and note down the values for
Measured loss and Margin.
o Verify Line out margin is in Normal range (> 8dB Margin).
o Verify no Line alarm is present in the Alarms menu.
4. @ SITE-A, reset the current PM logs
 Performance>>Current PM>>Reset

78
5. Refresh the SITE-A and SITE-B1 sessions.
6. Capture the following parameters in PMs:
 SITE-A: voa-line/target loss
 SITE-A: pwrmon-line-out-total
 SITE-A: pwrmon-line-out-cband
 SITE-B1: pwrmon-line-in-cband
 SITE-B1: pwrmon-line-in-total
7. Increase the PVOA by 3dB so that at SITE-A, the line “Measured loss”
increases, and “Margin” degrades.
8. Refresh the current PMs at both sites and capture the same parameters as
above. You might have to refresh a couple of times since EPIC will adjust in
increments.
9. Compare the PMs before and after the increase of PVOA:
o Verify voa-line/target loss decreases @ SITE-A.
o Verify pwrmon-line-out-total increases @ SITE-A
o Verify pwrmon-line-out-cband increases @ SITE-A
o Verify pwrmon-line-in-cband should be similar or minor change (<1 dB) @
SITE-B1.
o Verify pwrmon-line-in-total should be similar or minor change (<1 dB) @
SITE-B1.
10. Return the PVOA to its original setting
o Verify if any alarms present now cleared
11. Remove PVOA from configuration.
o Verify Link is returned to its original conditions.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.7.8 Express Fiber Pinch feature

Objective:
This test case verifies that EPIC (ELS Photonic Integrated Controller) will make
necessary adjustments to accommodate change in express loss.

Setup:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned.

See section 1.4.4 for an example.

Configured Test set to check the traffic status.

Procedure:

79
1. Login to both ELS chassis (Node Essentials) under test: SITE-B1 and SITE-
B2.
2. @ SITE-B1, in Service menu click Express port and note down the values for
Measured loss and Margin.
o Verify Express out margin is in Normal range (> 6 dB Margin).
o Verify no Express alarm is present in the Alarms menu.
3. Insert a PVOA (@ 0dB of attenuation) on the Express out of SITE-B1 and wait
for link to re-establish and traffic recovered and note down the values for
Measured loss and Margin.
o Verify Express out margin is in Normal range (> 4 dB Margin).
o Verify no Express alarm is present in the Alarms menu.
4. @ SITE-B1 and SITE-B2, reset the current PM logs
 Performance>>Current PM>>Reset
5. Refresh the SITE-B1 and SITE-B2 sessions.
6. Capture the following parameters in PMs:
 SITE-B1: voa-express/target loss
 SITE-B1: pwrmon-express-out-cband
 SITE-B2: pwrmon-express-in-cband”
7. Increase the PVOA by 3dB so that at SITE-B1, the Express “Measured loss”
increases, and “Margin” degrades.
8. Refresh the current PMs at both sites and capture the same parameters as
above. You might have to refresh a couple of times since EPIC will adjust in
increments.
9. Compare the PMs before and after the increase of PVOA:
o Verify voa-express/target loss” decreases @ SITE-B1.
o Verify pwrmon-express-out-cband increases @ SITE-B1.
o Verify pwrmon-express-in-cband should be similar or minor change (< 1
dB) @ SITE-B2.
10. Return the PVOA to its original setting
o Verify if any alarms present now cleared
o All PMs returned to original values
11. Remove PVOA from configuration.
o Verify Link is returned to its original conditions.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.7.9 Channel power and visual indication for unprovisioned

channels

Objective:
This test is used to verify Node Essentials reports powers and indications for
unprovisioned channels when power goes high or low.

80
Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with an unprovisioned
channel but connected

See section 1.4.4 for an example.

Procedure:
1. Login to the SITE-D and in the “Services” menu click on the channel under
test.
2. Adjust the channel power to the “Target input power (dBm)”.
o Verify no channel alarm present at SITE-D.
o Verify channel port has a green contour in the Services menu.
3. Increase the pluggable/transponder Tx power (ex: by > 2 dB) to a value that
lies in “Degrade high” margin range and refresh the Services menu.
o Verify channel power is in the upper amber range on the graph in Services
menu.
o Verify channel port has an amber contour.
o Verify no alarms are raised in the Alarms menu.
o Verify that the Channel ports dial does not report this channel (no change).
4. Increase the pluggable/transponder Tx power (ex: by > 3 dB from previous
step) so that it reaches to “Out of range high” and refresh the Services menu.
o Verify channel power is in the red range on the graph in the Services
menu.
o Verify channel port has a red contour.
o Verify no alarms are raised in the Alarms menu.
o Verify that the Channel ports dial does not report this channel (no change).
5. Return the Tx power of the channel back to the required Target input power.
 If the channel power is in the mixed region (hysteresis), it needs to
clear that region to clear any alarms.
o Verify channel power is in the green range on the graph in the Services
menu.
o Verify channel port has a green contour in the Services menu.
o Verify that the Channel ports dial does not report this channel (no change).
6. Decrease the pluggable/transponder Tx power (ex: by > 2 dB) to a value that
lies in “Degrade Low” margin range and refresh the Services menu.
 Add a PVOA or pad at Tx pluggable/transponder port.
o Verify channel power is in the lower amber range on the graph in Services
menu.
o Verify channel port has an amber contour.
o Verify no alarms are raised in the Alarms menu.
o Verify that the Channel ports dial does not report this channel (no change).
7. Decrease the pluggable/transponder Tx power (ex: by > 3 dB) so that it
reaches to “Out of range Low” and refresh the Services menu.
o Verify channel power is in the lower red range on the graph in Services
menu.
o Verify channel port has a red contour.

81
o Verify no alarms are raised in the Alarms menu.
o Verify that the Channel ports dial does not report this channel (no change).
8. Return the Tx power of the channel back to the required Target input power.
 If the channel power is in the mixed region (hysteresis), it needs to
clear that region to clear any alarms.
o Verify channel power is in the green range on the graph in the Services
menu.
o Verify channel port has a green contour in the Services menu.
o Verify that the Channel ports dial does not report this channel (no change).

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

82
2.8 Robustness
2.8.1 Single fiber cut

Objective:
This test is used to verify the alarms when a single fiber cut occurs in a network.
It can be between a Terminal to OADM or OADM to OADM chassis.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with at least one
channel provisioned. If possible, provision more Channel to see that there is no
impact for channels not passing through fiber cut.
Configured Test set to check the traffic status.

Procedure:
1. Login to both ELS chassis (Node Essentials), those, in between we want to
test a single fiber cut.
 Initially, both the chassis should have good power levels at Line in,
Line out and at Express in and Express out (OADM only) ports.
 Make sure there are no alarms at Line and Express ports.
2. Create a single fiber cut (wait 1 min to look at alarms since it will correlate
them and provide the necessary alarms) by disconnecting a Line out or Tx
fiber at near end chassis.
o Verify Line LEDs on Chassis Near and far-end will be AMBER
o Verify “INUSE” LED (BLUE one) will be OFF, this means amplifiers are
turned off
o Verify test set will be red, and traffic goes down (If connected)
o Verify at near end chassis major alarms “Loss Measurement Unavailable”,
at line out port and “OSPF Loss of Adjacency”, and “OSPFv3 Loss of
Adjacency”.
o Verify at far end chassis a major alarm “Optical Line Fail” at Line in port.
o Verify that no span loss margin (In & Out) is visible in Node Essentials on
both ELS chassis during this fault.
3. Restore single fiber cut and wait for Line and Express LEDs to turn Solid
Green.
o Verify all alarms are cleared.
o Verify traffic has recovered.
o Verify span margin is available in Node Essentials.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

83
2.8.2 Double Fiber Cut
Objective:
This test is used to verify the alarms when a double fiber cut occurs in a network.
It can be between a Terminal to OADM or OADM to OADM ELS chassis.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned. If possible, provision more Channel to see that there is no
impact for channels not passing through fiber cut.
Configured Test set for to check the traffic status.

Procedure:
1. Login to both ELS chassis (Node Essentials), those, in between we want to
test a double fiber cut.
 Initially, both the chassis should have good power levels at Line In, line
out and Express In, Express Out (OADM only) ports.
 Make sure there are no alarms at line and express ports.
2. Create a double fiber cut (wait 1 min to look at alarms since it will correlate
them and provide the necessary alarms) by disconnecting both line out and
line in or Tx/Rx fibers at near end chassis.
o Verify Line LEDs on Chassis Near and far-end will be AMBER
o Verify “INUSE” LED (BLUE one) will be OFF, this means amplifiers are
turned off
o Verify test set will be red, and traffic goes down (If connected).
o Verify at near end chassis a major alarms “Optical Line Fail” at Line in
port.
o Verify at far end chassis a major alarm “Optical Line Fail” at Line in port.
o Verify that no span loss margin (In & Out) is visible in Node Essentials on
both ELS chassis during this fault.
3. Restore double fiber cut and wait for Line and Express LEDs to turn solid
Green.
o Verify all alarms are cleared.
o Verify traffic has recovered.
o Verify span margin is available in Node Essentials.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

84
2.8.3 Warm restart

Objective:
This test case is used to test the restart without a traffic impact functionality of the
ELS chassis.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned.
Configured Test set for to check the traffic status.

Procedure:
1. For warm restart through Node Essentials, login the chassis then click on
Facilities menu >> ELS (Chassis) > >click on chassis restart >> select
warm>> confirm.

o Verify a prompt show “Chassis restarting”.

o Verify all LEDs on chassis go off and restart.
o Verify at connected far end major alarms are raised.

o Verify test sets are green, and traffic is up and running.

2. Wait for ~3 mins to chassis come up and then re-login.
o Verify the last restart session (user-warm) in facilities menu.

o Verify traffic not impacted and continuously up at test set.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

85
2.8.4 Cold restart

Objective:
This test case is used to test the “restart with a traffic impact” functionality of the
ELS chassis.

Set Up:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned.
Configured Test set for to check the traffic status.

Procedure:
For Cold restart through Node Essentials.
1. Login the chassis in Node Essentials. Then click on Facilities menu >> ELS
(Chassis) > >click on chassis restart >> select cold>> confirm.

o Verify a prompt shows Chassis restarting.

o Verify that all the LEDs on chassis go off and restart.
o Verify at connected far end a major “Optical Line Fail” alarm is raised.

o Verify test sets are red, and traffic is down.

3. Wait for ~3 mins to chassis come up and then re-login.

o Verify the last restart session (user-cold) in facilities menu.

o Verify traffic impacted but restored at test set.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.8.5 Power Cycle

Objective:
This test case is used to test the “traffic restoration time” when a chassis takes a
power restart.

86
Set Up:
A commissioned ELS chassis. A channel passthrough or provisioned on ELS
chassis if you need to check the traffic status. A test set to monitor the traffic
status.

Procedure:
1. Login to ELS chassis (Node Essentials).
 Initially, the chassis should have good power levels at Line in, Line out
and Express in, Express out (OADM only) ports.
 Make sure no alarms are present for accuracy of traffic restoration
time.
2. Disconnect both the power sources if chassis is connected to two power
sources for example power feed A and power feed B.
3. Wait for 15 sec and observe the below expected alarms at other ELS chassis,
which is directly connected to it.
o Verify that you see major alarms “Loss Margin Fail”, and “Optical Line Fail”
at Line and Express ports.

4. Reconnect the power sources and wait for the chassis to restart.
o Verify chassis restarted and all alarms getting clear at neighbor end.
o Verify that traffic restored in ~ 3minutes (e.g.,107sec), in some cases, it
may take 10 mins to get the traffic restored.

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

2.8.6 Soak and Stability

Objective:
This test case is used to verify the stability of ELS network.

Setup:
A commissioned ELS link, either pt-to-pt or hub-and-spoke with a at least one
channel provisioned.

See section 1.4.4 for an example.

Configured Test set for to check the traffic status.

Procedure:
1. Reset all PMs on ELS

87
 Performance >> Current PM
 Click on Stop Monitoring ( )
 Click on Reset ( )
o Aid: ALL
o Monitor Type: ALL
o Interval: ALL
o Click on Confirm
 Click on Start Monitoring ( )
2. Reset all PMs on pluggables/transponder.
3. Run a soak without any interruptions for a period.
o Verify traffic has passed without any hits
o Verify no alarms were raised during the soak.
o Verify PMs of pluggable/transponders for Rx powers on all
pluggables/transponder are with min/max delta of < 1.5 dB

Test Case Results:

Passed: Yes _______ No ______ Verified by _________ Date/Time_________
Comments _______________________________________________________

88
Ciena
Coherent ELS
Release 1.0
Customer Acceptance Test Plan
Issue 2
July 2022

PCI DSS A Pocket Guide Second Edition Alan Calder Ebook Testbank Solutions Downloadable Full Version
100% (3)
PCI DSS A Pocket Guide Second Edition Alan Calder Ebook Testbank Solutions Downloadable Full Version
86 pages
OSSEC for PCI Compliance 2.0 Guide
No ratings yet
OSSEC for PCI Compliance 2.0 Guide
6 pages
Essential Guide to Cloud Detection Response
No ratings yet
Essential Guide to Cloud Detection Response
17 pages
Securing Digital Transformation with HSMs
No ratings yet
Securing Digital Transformation with HSMs
13 pages
PCIe Measurements 4HW 19375 1
No ratings yet
PCIe Measurements 4HW 19375 1
36 pages
An Introduction To PCI Express™ Measurements - Tek PDF
No ratings yet
An Introduction To PCI Express™ Measurements - Tek PDF
36 pages
Damnang's Substack - The War of Light, A Laser Shortage
No ratings yet
Damnang's Substack - The War of Light, A Laser Shortage
40 pages
Ofc 3
No ratings yet
Ofc 3
3 pages
V1 - 7450 ESS and 7750 SR Multiservice Integrated Services Adapter Installation Guide
No ratings yet
V1 - 7450 ESS and 7750 SR Multiservice Integrated Services Adapter Installation Guide
22 pages
Network Security Principles Overview
No ratings yet
Network Security Principles Overview
45 pages
Control Expert & Modicon M580 Overview
No ratings yet
Control Expert & Modicon M580 Overview
50 pages
1830 Photonic Vr70 Cert Eng
No ratings yet
1830 Photonic Vr70 Cert Eng
12 pages
08 PAC Modulos X80
No ratings yet
08 PAC Modulos X80
148 pages
Ciena Waveserver Ai 1.3 Guidance Document
No ratings yet
Ciena Waveserver Ai 1.3 Guidance Document
37 pages
PRISMA
No ratings yet
PRISMA
378 pages
Understanding PCI and Data Security Standards
No ratings yet
Understanding PCI and Data Security Standards
19 pages
Check Point DDoS Protector Overview
No ratings yet
Check Point DDoS Protector Overview
6 pages
O Começo
No ratings yet
O Começo
184 pages
Secure Data Exchange Via HSM
No ratings yet
Secure Data Exchange Via HSM
3 pages
Ebook VCSEL Industry Communication and Sensing The ComSoc Guides To Communications Technologies 1st Edition Babu Dayal Padullaparthi
100% (3)
Ebook VCSEL Industry Communication and Sensing The ComSoc Guides To Communications Technologies 1st Edition Babu Dayal Padullaparthi
167 pages
Csw06 Byres
No ratings yet
Csw06 Byres
6 pages
Piotr Link e
No ratings yet
Piotr Link e
16 pages
SCADA Hacking Basics for Beginners
No ratings yet
SCADA Hacking Basics for Beginners
16 pages
SCADA Penetration Testing Essentials
No ratings yet
SCADA Penetration Testing Essentials
5 pages
NERC-CIP Compliance with Fortinet Solutions
No ratings yet
NERC-CIP Compliance with Fortinet Solutions
33 pages
Aruba ClearPass ISO Download Guide
No ratings yet
Aruba ClearPass ISO Download Guide
40 pages
SNCF 300-701 Chapter1 Study Guide
No ratings yet
SNCF 300-701 Chapter1 Study Guide
12 pages
NDR Buyer’s Guide: Key Features & Insights
No ratings yet
NDR Buyer’s Guide: Key Features & Insights
9 pages
ROSA NMS Configuration Manual
100% (2)
ROSA NMS Configuration Manual
546 pages
Cisco PCI DSS 2.0 Compliance Guide
No ratings yet
Cisco PCI DSS 2.0 Compliance Guide
10 pages
Axis Datasheet Compliance Guide
No ratings yet
Axis Datasheet Compliance Guide
16 pages
Understanding CIS Benchmarks for Cybersecurity
No ratings yet
Understanding CIS Benchmarks for Cybersecurity
5 pages
DDoS Protector X Datasheet
No ratings yet
DDoS Protector X Datasheet
5 pages
Achieving PCI Compliance With Red Hat Enterprise Linux: June 2009
No ratings yet
Achieving PCI Compliance With Red Hat Enterprise Linux: June 2009
13 pages
EDR, MDR, and XDR: Key Differences Explained
No ratings yet
EDR, MDR, and XDR: Key Differences Explained
2 pages
Fiber Optic Link Design Essentials
No ratings yet
Fiber Optic Link Design Essentials
16 pages
European SCADA Security Test Bed Insights
No ratings yet
European SCADA Security Test Bed Insights
16 pages
CISSP Security Assessment Overview
100% (1)
CISSP Security Assessment Overview
110 pages
2021 Delafontaine-Rosenthal Secure-Boot Ewc2021
No ratings yet
2021 Delafontaine-Rosenthal Secure-Boot Ewc2021
5 pages
Microprocessor Based Relaying
No ratings yet
Microprocessor Based Relaying
21 pages
Ismegpcifinal109v2 091014183507 Phpapp01
No ratings yet
Ismegpcifinal109v2 091014183507 Phpapp01
41 pages
NIST Zero Trust Architecture Overview
No ratings yet
NIST Zero Trust Architecture Overview
61 pages
SSD Only Sep 2024 IR ADV IPR Lite Security WhitePaper 3 (1).18 FIPS
No ratings yet
SSD Only Sep 2024 IR ADV IPR Lite Security WhitePaper 3 (1).18 FIPS
56 pages
OPTIX 500 Huawei
No ratings yet
OPTIX 500 Huawei
137 pages
SLS Solutions for Zigbee & USB 2.0
No ratings yet
SLS Solutions for Zigbee & USB 2.0
31 pages
Asset Handover Framework Expanded
No ratings yet
Asset Handover Framework Expanded
3 pages
IT Governance Frameworks and Models
No ratings yet
IT Governance Frameworks and Models
26 pages
Web 3.0 - FAQ
No ratings yet
Web 3.0 - FAQ
49 pages
Quality Assurance Testing Phases Guide
No ratings yet
Quality Assurance Testing Phases Guide
3 pages
Simplifying PCI Compliance For IT Professional
No ratings yet
Simplifying PCI Compliance For IT Professional
9 pages
Business Case for Common Criteria
No ratings yet
Business Case for Common Criteria
34 pages
IT Security Standards - L2
No ratings yet
IT Security Standards - L2
21 pages
Modicon Controller Cybersecurity Guide
No ratings yet
Modicon Controller Cybersecurity Guide
170 pages
cs205 From106 To 150
No ratings yet
cs205 From106 To 150
129 pages
Trust Models in PKI Explained
No ratings yet
Trust Models in PKI Explained
5 pages
10 Swra780a
No ratings yet
10 Swra780a
9 pages
Buyers Guide Telecom Core Endpoint Threat Detection
No ratings yet
Buyers Guide Telecom Core Endpoint Threat Detection
12 pages
STM32 Trust
No ratings yet
STM32 Trust
32 pages
Nature Photonics Technology Focus Optical Fiber Sensor
100% (1)
Nature Photonics Technology Focus Optical Fiber Sensor
20 pages
3.2.11 Lab - Network Sniffing With Wireshark - ILM
No ratings yet
3.2.11 Lab - Network Sniffing With Wireshark - ILM
5 pages
Yahoo Messenger Voice Protocol Analysis
No ratings yet
Yahoo Messenger Voice Protocol Analysis
7 pages
PlantVisor Installation Guide
No ratings yet
PlantVisor Installation Guide
5 pages
Network Security Lab Review IT4260E
No ratings yet
Network Security Lab Review IT4260E
19 pages
Passive Optical Networks
No ratings yet
Passive Optical Networks
7 pages
Nokia 7250 IXR-s Router Datasheet
No ratings yet
Nokia 7250 IXR-s Router Datasheet
8 pages
ExtendAir G2™ Gigabit Microwave Systems
No ratings yet
ExtendAir G2™ Gigabit Microwave Systems
4 pages
Zippyshare File Access Logs
No ratings yet
Zippyshare File Access Logs
4 pages
How To Configure Static IP On CentOS 6
No ratings yet
How To Configure Static IP On CentOS 6
2 pages
Application Layer Security Overview
No ratings yet
Application Layer Security Overview
3 pages
Juniper Apstra Install & Upgrade Guide
No ratings yet
Juniper Apstra Install & Upgrade Guide
59 pages
8.3.1.4 Packet Tracer - Implementing A Subnetted IPv6 Addressing Scheme - ILM EG
100% (1)
8.3.1.4 Packet Tracer - Implementing A Subnetted IPv6 Addressing Scheme - ILM EG
3 pages
Essential Interview Questions for IT Admin
No ratings yet
Essential Interview Questions for IT Admin
12 pages
Huawei CloudEngine S5735I-S-V2 Switches
No ratings yet
Huawei CloudEngine S5735I-S-V2 Switches
22 pages
GLBP Configuration Guide for Cisco IOS
No ratings yet
GLBP Configuration Guide for Cisco IOS
42 pages
GameCenter Startup Log Analysis
No ratings yet
GameCenter Startup Log Analysis
7 pages
Huawei HCIE-R&S H12-261 Exam Guide
No ratings yet
Huawei HCIE-R&S H12-261 Exam Guide
44 pages
Create A Starter GPO
No ratings yet
Create A Starter GPO
2 pages
OnRamp DVB T IP Datasheet
No ratings yet
OnRamp DVB T IP Datasheet
2 pages
Configuring a SOHO Router in Lab 6.1
No ratings yet
Configuring a SOHO Router in Lab 6.1
58 pages
PowerHA 7 1 and Multicast v1
No ratings yet
PowerHA 7 1 and Multicast v1
6 pages
SJ-20120615152640-010-ZXA10 C320 (V1.2.0) Optical Access Convergence Equipment Command Reference PDF
100% (1)
SJ-20120615152640-010-ZXA10 C320 (V1.2.0) Optical Access Convergence Equipment Command Reference PDF
1,447 pages
Network Security Fundamentals Explained
No ratings yet
Network Security Fundamentals Explained
2 pages
OPSWAT DataDiode ComparisonGuide 2021
No ratings yet
OPSWAT DataDiode ComparisonGuide 2021
42 pages
Manual Netgear cg3700 Data PDF
No ratings yet
Manual Netgear cg3700 Data PDF
77 pages
OPPO CPH2495 SDK Initialization Log
No ratings yet
OPPO CPH2495 SDK Initialization Log
61 pages
IPv6 Implementation Lab Answer Key
No ratings yet
IPv6 Implementation Lab Answer Key
10 pages
Websocket Configuration for Node-RED
No ratings yet
Websocket Configuration for Node-RED
1 page
Arbor Networks Help - Ports Used by SP
No ratings yet
Arbor Networks Help - Ports Used by SP
4 pages