Release Announcement: NSO 6.6 is here!
Check out the release highlights to see what's new
NSO DevCenterTry NSO

README v1.9.22 2025-07-29

Table of contents

1. General
   1.1 Extract the NED package
   1.2 Install the NED package
       1.2.1 Local install
       1.2.2 System install
   1.3 Configure the NED in NSO
2. Optional debug and trace setup
3. Dependencies
4. Sample device configuration
5. Built in live-status actions
6. Built in live-status show
7. Limitations
8. How to report NED issues and feature requests
9. How to rebuild a NED

1. General

This document describes the ciena-mcp NED.

QUICK SUMMARY - Current Design (ESM vs BSM vs TSM)

[IMPORTANT] CURRENT DESIGN GENERAL CONSIDERATIONS:

  • The NED was initially designed to interact with the device only through a set of live-status actions or rpc calls.

  • The initial design is enabled under ESM config mode of the NED, and it enables only the live-status commands in that mode.

  • Over time it has evolved based on requests, with focus and specific behavior especially for two modes of working, BSM and TSM.

To choose the mode NED operates in, NED can be configured in ned-settings under config path ../device<deviceName>/ned-settings/ciena-mcp/mcp-service-model-api:

Ex.: admin@ncs(config-device-netsim-0)# ned-settings ciena-mcp mcp-service-model-api ? Description: Define latest max API vers supported by the NED; Warning! Customer dependent selection! Possible completions: VERSION_1_ESM_PROVISION VERSION_4_BSM_L2SERVICE VERSION_6_TSM

  1. VERSION_1_ESM_PROVISION :

    • Allows only live-status commands to be used for provisioning operations'

  2. VERSION_4_BSM_L2SERVICE :

    • It is the default current mode the NED is delivered with, for legacy reasons.

    • It enables the NED config model under the config path: /devices/device<deviceName>/config/services/

    • It is used for very specific, customized resourceTypes, behaving in a Ciena MDSO like configuration of the device.

  3. VERSION_6_TSM :

    • It enables the NED config model under the config path: /devices/device<deviceName>/config/tsm/

    • It is used for very specific, customized resourceTypes, behaving in a Ciena MDSO like configuration of the device.

BSM mode specific - config data model

For BSM mode, we can find the config data implemented under services NED config tree '/devices/device/config/services/ *':

YANG Schema Tree structure of the BSM mode enabled config model:

Supported operations on the BSM config data model:

The BSM NED config/services data model supports the following operations:

  • Sync-from

  • Create

  • Delete

There is NO or very limited support for Update or Modify operations on the existing attributes of the BSM config data.

The Ciena MCP/MSDO device is not supporting any direct updates of these elements by design. For more details go to chapter 7. below.

TSM mode specific - config data model

------------------------------_

For TSM mode specifics, refer to 'README.TSM'

For TSM mode, we can find the config data implemented under '/devices/device/config/tsm/*':

Additional README files bundled with this NED package

Common NED Features

Verified target systems

1.1 Extract the NED package

It is assumed the NED package ncs-<NSO version>-ciena-mcp-<NED version>.signed.bin has already been downloaded from software.cisco.com.

In this instruction the following example settings will be used:

  • NSO version: 6.0

  • NED version: 1.0.1

  • NED package downloaded to: /tmp/ned-package-store

  1. Extract the NED package and verify its signature:

  2. In case the signature can not be verified (for instance if no internet connection), do as below instead:

  3. The result of the extraction shall be a tar.gz file with the same name as the .bin file:

1.2 Install the NED package

There are two alternative ways to install this NED package. Which one to use depends on how NSO itself is setup.

In the instructions below the following example settings will be used:

  • NSO version: 6.0

  • NED version: 1.0.1

  • NED download directory: /tmp/ned-package-store

  • NSO run time directory: ~/nso-lab-rundir

A prerequisite is to set the environment variable NSO_RUNDIR to point at the NSO run time directory:

1.2.1 Local install

This section describes how to install a NED package on a locally installed NSO (see "NSO Local Install" in the NSO Installation guide).

It is assumed the NED package has been been unpacked to a tar.gz file as described in 1.1.

  1. Untar the tar.gz file. This creates a new sub-directory named: ciena-mcp-<NED major digit>.<NED minor digit>:

  2. Install the NED into NSO, using the ncs-setup tool:

  3. Open a NSO CLI session and load the new NED package like below:

Alternatively the tar.gz file can be installed directly into NSO. Then skip steps 1 and 2 and do like below instead:

Set the environment variable NED_ROOT_DIR to point at the NSO NED package:

1.2.2 System install

This section describes how to install a NED package on a system installed NSO (see "NSO System Install" in the NSO Installation Guide).

It is assumed the NED package has been been unpacked to a tar.gz file as described in 1.1.

  1. Do a NSO backup before installing the new NED package:

  2. Start a NSO CLI session and fetch the NED package:

  3. Install the NED package (add the argument replace-existing if a previous version has been loaded):

  4. Load the NED package

1.3 Configure the NED in NSO

This section describes the steps for configuring a device instance using the newly installed NED package.

  • Start a NSO CLI session:

  • Enter configuration mode:

  • Configure a new authentication group (my-group) to be used for this device:

  • Configure a new device instance (example: dev-1):

TSM_MODE: GENERAL CONSIDERATIONS

!!! Warning: !!!

  • Please make sure the mcp-service-model-api ned-setting is set to 'VERSION_6_TSM' to use config/tsm section:

  • i.e.: admin@ncs(config-device-ciena-lab1)# ned-settings ciena-mcp mcp-service-model-api VERSION_6_TSM

TSM_MODE Features

  • visible under devices device <deviceName> ned-settings ciena-mcp

-> LAG Management <-

  • Enables config management under /config/tsm/networkConstructs{neName}/ethernetPortMgmt/lag{*}

  • Make sure you enable managed-lag flag before running sync-from.

TSM_MODE: Initial config / setup example

TSM_MODE: Config data models

  • Addresses only the resources managed under the path:

    • devices device / config / tsm / *

  • In this build version you should be able, on top of using the live-status actions for various provisioning tasks, to sync, create and delete MPLS Tunnels, E-LINE and EPL/EVPL Services, L1 Services, TDM Circuits

  • After configuring the NED instance as above presented, run a sync-from and check:

    • ../config/tsm/mplsTunnels

    • ../config/tsm/eLineServices

    • ../config/tsm/l1Services

    • ../config/tsm/tdmCircuits

    • ../config/tsm/L0ServiceIntentFacade

    • ../config/tsm/L1OTNSwitchingProtService

    • ../config/tsm/L1OTNSwitchingService

  • if ned-settings/ciena-mcp/managed-lag == true, check also:

    • ../config/tsm/networkConstructs

  • For the above, the transactions supported widely are SYNC, CREATE, DELETE.

  • For some of the resources, partial EDIT/UPDATE is also possible, but generally it is very limited in this config mode.

  • For LAG management:

    • top level is READ ONLY, SYNC-ONLY ALLOWED: /../config/tsm/networkConstructs{*}

    • SYNC, CREATE, DELETE LAGs at level: /../config/tsm/networkConstructs{*}/ethernetPortMgmt/lag{*}

    • Update possible via live status; complex provisioning flow

TSM_MODE: NED /config/tsm/mplsTunnels model:

  • Handles Resources of type: ifd.v6.resourceTypes.MplsTunnelIntentFacade

TSM_MODE: NED /config/tsm/eLineServices model:

  • Handles Resources of type: ifd.v6.resourceTypes.L2ServiceIntentFacade

TSM_MODE: NED /config/tsm/l1Services model:

  • Handles Resources of type: ifd.v6.resourceTypes.L1NCPClientServiceIntentFacade

TSM_MODE: NED /config/tsm/tdmCircuits model:

  • Handles Resources of type: ifd.v6.resourceTypes.TDMServiceIntentFacade

TSM_MODE: NED /config/tsm/L1OTNSwitchingProtService model:

  • Handles Resources of type: ifd.v6.resourceTypes.L1OTNSwitchingProtServiceIntentFacade

TSM_MODE: NED /config/tsm/L1OTNSwitchingService model:

  • Handles Resources of type: ifd.v6.resourceTypes.L1OTNSwitchingServiceIntentFacade

TSM_MODE: NED /config/tsm/networkConstructs model:

  • Used for handling Ethernet Port management LAGs:

  • Usable only when ned-settings ciena-mcp managed-lag is enabled!

  • Node networkConstructs and information at same level is READ ONLY

  • LAG under networkConstructs/ethernetPortMgmt/lag/* supports: SYNC, CREATE, DELETE;

  • LAG update/edit assumes adding or removing primaryPorts or protectionPorts only. It is currently doable only via live-status commands.

  • Complete LAG provisioning can be achieved using a combination of live status commands and below data tree model.

TSM_MODE: NED /config/tsm/L0ServiceIntentFacade model:

  • Used for handling resources of type: ifd.v6.resourceTypes.L0ServiceIntentFacade

  • Finally commit the configuration

  • Verify configuration, using a sync-from.

If the sync-from was not successful, check the NED configuration again.

2. Optional debug and trace setup

It is often desirable to see details from when and how the NED interacts with the device(Example: troubleshooting)

This can be achieved by configuring NSO to generate a trace file for the NED. A trace file contains information about all interactions with the device. Messages sent and received as well as debug printouts, depending on the log level configured.

NSO creates one separate trace file for each device instance with tracing enabled. Stored in the following location:

$NSO_RUNDIR/logs/ned-ciena-mcp-gen-1.0-<device name>.trace

Do as follows to enable tracing in one specific device instance in NSO:

  1. Start a NSO CLI session:

  2. Enter configuration mode:

  3. Enable trace raw:

    Alternatively, tracing can be enabled globally affecting all configured device instances:

  4. Configure the log level for printouts to the trace file:

    Alternatively the log level can be set globally affecting all configured device instances using this NED package.

The log level 'info' is used by default and the 'debug' level is the most verbose.

IMPORTANT: Tracing shall be used with caution. This feature does increase the number of IPC messages sent between the NED and NSO. In some cases this can affect the performance in NSO. Hence, tracing should normally be disabled in production systems.

An alternative method for generating printouts from the NED is to enable the Java logging mechanism. This makes the NED print log messages to common NSO Java log file.

$NSO_RUNDIR/logs/ncs-java-vm.log

Do as follows to enable Java logging in the NED

  1. Start a NSO CLI session:

  2. Enter configuration mode:

  3. Enable Java logging with level all from the NED package:

  4. Configure the NED to log to the Java logger

    Alternatively Java logging can be enabled globally affecting all configured device instances using this NED package.

IMPORTANT: Java logging does not use any IPC messages sent to NSO. Consequently, NSO performance is not affected. However, all log printouts from all log enabled devices are saved in one single file. This means that the usability is limited. Typically single device use cases etc.

SSHJ DEBUG LOGGING For issues related to the ssh connection it is often useful to enable full logging in the SSHJ ssh client. This will make SSHJ print additional log entries in $NSO_RUNDIR/logs/ncs-java-vm.log:

3. Dependencies

This NED has the following host environment dependencies:

  • Java 1.8 (NSO version < 6.2)

  • Java 17 (NSO version >= 6.2)

  • Gnu Sed

Dependencies for NED recompile:

  • Apache Ant

  • Bash

  • Gnu Sort

  • Gnu awk

  • Grep

  • Python3 (with packages: re, sys, getopt, subprocess, argparse, os, glob)

4. Sample device configuration

SUMMARY on the NED usage for Service config handling (BSM Mode)

It is enabled only when setting mcp-service-model-api ned-settings to VERSION_4_BSM_L2SERVICE:

  • /ned-settings/ciena-mcp/mcp-service-model-api VERSION_4_BSM_L2SERVICE

BSM_CONFIG_1 : L2 service config provisioning

  • Deployed under /config / services / l2Service

    • Supported operations: create | delete | sync

    • Update operation NOT SUPPORTED.

Sample config loaded in the CDB:

BSM_CONFIG_2 : L2 service live check:

  • Added enhancements to show live status services by label too, or in bulk, all services

  • Added provisioningStatus parameter display in the results

i.e. getting a single service status by label:

or just fetching all live statuses for all existing services:

BSM_CONFIG_3 : L2 service update:

  • showing existing config on a particular existing service:

  • only very few certain elements are updatable (mainly bwp params):

  • device will reject updates if updates requested are not allowed or will revert any update requests if they go through.

  • device basically overwrites any update attempts, with minor exceptions, such as the bwp param, even if the REST api call response is succcessful and the request is accepted by the device.

  • overall, updates of the services in BSM mode are not recommended.

Example update for:

  • properties/serviceEndPointList/interfaceType{A_ENNI}/bwp/ebs to 1234

  • Commit dry run to show pending ops:

  • Commit dry run native to show exactly what's going to the device:

  • Commit changes:

BSM_CONFIG_4 : L2 service delete:

Delete example:

TSM_MODE: NED config handling under TSM Mode

It is enabled only when setting mcp-service-model-api ned-settings to VERSION_6_TSM:

  • i.e.: admin@ncs(config-device-deviceName01)# ned-settings ciena-mcp mcp-service-model-api VERSION_6_TSM

TSM_CONFIG_1 : Sync-from & check schema structure:

TSM_CONFIG_1.2 : MPLS Tunnel

  • addresses resources of type : ifd.v6.resourceTypes.MplsTunnelIntentFacade

TSM_CONFIG_1.3 : E-Line Services

  • addresses resources of type : ifd.v6.resourceTypes.L2ServiceIntentFacade

TSM_CONFIG_1.4 : l1Services

  • addresses resources of type : ifd.v6.resourceTypes.L1NCPClientServiceIntentFacade

TSM_CONFIG_1.5 : TDM Circuits

  • addresses resources of type : ifd.v6.resourceTypes.TDMServiceIntentFacade

TSM_CONFIG_1.6 : L1OTN Switching Service

  • addresses resources of type : ifd.v6.resourceTypes.L1OTNSwitchingServiceIntentFacade

TSM_CONFIG_1.7 : L1OTN PROT Switching Service

  • addresses resources of type : ifd.v6.resourceTypes.L1OTNProtSwitchingServiceIntentFacade

TSM_CONFIG_1.8 : LAG management

  • Complicated flow used for provisioning;

  • Combo of live-status commands + NED config data can be used for full lifecycle/provisioning of ethernet port LAG management resources.

Example of full provisioning of a LAG for 6500 network Element type:

TSM_CONFIG_1.8.1 : 6500 NE LAG MANAGEMENT :

PRE-REQUISITES:

a) LOAD LATEST NED BUILD + PACKAGES RELOAD b) SYNC-FROM c) COLLECT NETWORK ELEMENT DETAILS NEEDED from device config (NE6500 IN THIS EXAMPLE):

ex:

  • params that we will use in all the live status requests:

TSM_CONFIG_1.8.1 : Part 1: get ethernet port status:

TSM_CONFIG_1.8.1 : Part 2: disable port 24/3 / 24/4

TSM_CONFIG_1.8.1 : Part 3: enable ports:

TSM_CONFIG_1.8.1 : Part 4: resync components:

  • managementSessionId is sessionid from the device config

TSM_CONFIG_1.8.1 : Part 5: create 6500 LAG:

TSM_CONFIG_1.8.1 : Part 6: get ALL interfaces for 6500-0101:

TSM_CONFIG_1.8.1 : Part 6.1 get interface IP-IF_LAG-001:

TSM_CONFIG_1.8.1 : Part 7 create interfacemanagement:

TSM_CONFIG_1.8.1 : Part 7.2 get interfacemanagement IP-IF_LAG-230 details:

TSM_CONFIG_1.8.1 : Part 7.2 get all interfacemanagement IP-IF_LAG-230 details:

TSM_CONFIG_1.8.1 : Part 7.3: resync components:

  • managementSessionId is sessionid from the device config

TSM_CONFIG_1.8.1 : Part 8 UPDATE interfacemanagement IP-IF_LAG-2305 vlan to 1721:

TSM_CONFIG_1.8.1 : Part 8.1 UPDATE interfacemanagement IP-IF_LAG-2305 - DISABLE interface:

TSM_CONFIG_1.8.1 : Part 8.2 UPDATE interfacemanagement IP-IF_LAG-2305 - ENABLE interface:

TSM_CONFIG_1.8.1 : Part 8.3 UPDATE interfacemanagement IP-IF_LAG-2305 - DISABLE interface:

TSM_CONFIG_1.8.1 : Part 9.1 DELETE interfacemanagement v1 : short name:

TSM_CONFIG_1.8.1 : Part 9.2 DELETE interfacemanagement v2 : long name (row id):

TSM_CONFIG_1.8.1 : Part 10: disable ports 24/3 / 24/4

TSM_CONFIG_1.8.1 : Part 11. remove ports from LAG

TSM_CONFIG_1.8.1 : Part 12. delete LAG:

TSM_CONFIG_1.8.1 : Part 13. additional commands - VIRTUALSWITCH :

  • to get VS info, use operation get

  • to delete virtualswitch use operation delete:

TSM_CONFIG_1.9 : L0ServiceIntentFacade

  • Market resources provisioning

  • Discovered services are pushed as FREs

  • Complex handling TPE-FRE relationship.

5. Built in live-status actions

Live-status commands - actions

Summary and conventions

  • Juniper style CLI: % request devices device *device-name* live-status exec **command** *arg* *argValue*

  • Cisco style CLI: # devices device *device-name* live-status exec **command** *arg* *argValue*

The custom response consists of two separate sections, RESULT and RESPONSE sections, as following:

1. result section, which is modeled under 'grouping exec-result-container result' container in the ciena-mcp-stats yang module:

This section will ALWAYS be populated within all the responses of the actions performed, as a general rule of thumb.

This section will be used as a first status check reference.

Most important elements of the result section are:

  • requestStatus

  • resultString

  • errorMessage

Example:

2. response section, which is modeled under 'grouping exec-result-container result' container in the ciena-mcp-stats yang module:

  • response section, which is modeled under each 'response' container in the ciena-mcp-stats yang module:

    • This section is customized for each and every action request.

    • This section is available ONLY when a successful response is available to be parsed

    • The parsed elements will be displayed as per the content designed within ciena-mcp-stats yang module.

    • Shall a request fail or not meet the expected response timeline, this section will not be populated.

    • In general, it consists of either a leaf of type string, containing a full json object string result extracted from the device response, or a container with 'data' or 'items' arrays or direct json decomposed content extracted.

Most common Live status command used in BSM MODE:

Top commands used in BSM mode:

Audit commands used in BSM mode:

L23 Services provisioning commands used in BSM mode:

Some of these live status actions presented below:

get-network-construct-id : Fetch the Network Construct element id

Usage:

get-network-element-availability : Verify the port status of the Network Construct element

  • RETURNS TPEs RELATED DATA

Params:

Usage:

get-network-element-content : Verify the port status of the Network Construct element

Params:

Usage:

upload-custom-script : Push custom configuration script

Params:

[WARNING] ATTENTION!

For example, taking following input for scriptContent parameter:

Should be passed to scriptContent leaf as the following one line compact string:

  • Failing to do as instructed above will lead in getting the script content truncated at the first new line or at the first unescaped double comma within the string.

  • Providing both scriptContent and scriptFile, will result in overwriting the scriptFile with the given scriptContent.

Usage:

Scenario I, when scriptContent will be available from file:

a) Providing both scriptFile and scriptName, without scriptContent:

b) Providing just the scriptFile without a scriptName, will result in extracting the scriptName from the scriptFile given at input.

c) Providing just the scriptName without a scriptFile, will result in creating the scriptFile at the path defined in 'mcp-scripts-folder' under ned-settings. % request devices device live-status exec upload-custom-script protocolType <tl1|cli> typeGroup <Ciena6500|Waveserver> scriptName <script.txt>

Scenario II, when scriptContent will be available from input:

[WARNING] Regardless the input combinations from scenario I, the content of the scriptFile resulted will be overwritten with the content within scriptContent

This is why it is very important that the scriptContent is correctly formatted at input.

or

or

upload-empty-profile : Push empty configuration script

Params:

Usage:

push-mcp-configuration : Push Configuration to MCP server

NOTE:

** For this command, either one of the params can be set, but AT LEAST ONE has to be provided. > if a file path is given, file is read and content is pushed as data. > if the json content is given directly, it is pushed as data and file read is omitted

[WARNING] ATTENTION!

Params:

Usage:

or

show-constructs-elements-ids : Show all network constructor element names

Params:

Usage:

  • % request devices device <device-name> live-status exec show-constructs-elements-ids networkConstructId <networkConstructId> or

  • % request devices device <device-name> live-status exec show-constructs-elements-ids networkConstructId any

get-network-element-userLabel : Get userLabel of a Network Construct element if set

Params:

Usage:

  • % request devices device <device-name> live-status exec get-network-element-userLabel constructId <constructId> elementName <elementName>

get-jobId-status : Get jobId details and parse data Description and Conditioning Type if present

Params:

Usage:

  • % request devices device <device-name> live-status exec get-jobId-status jobId <jobId>

L23 service provisioning - BSM specific:

==============================================================================

  • Live status actions added to enable L23 service provisioning:

get-resources-nodes : Get resources nodes to identify labels for fetching port later on:

get-resources-nodes-ports : Get resources node PORTS by the label fetched at 4.1

get-services : Get all L2 services

get-services : Get specific L2 service by label

get-service-profiles : Get all L2 service profiles

get-service-product-id : Get all L2 service PRODUCT ID

create-service-profile : Create service profile

create-service : Create service

!!!! DEPRECATED since ciena-mcp NED version 1.5.4 !!!!

  • Logic is present under config, no reason to keep separate action to interact with config.

delete-resource : Delete service or service profile or any other /resource by given ID.

!!! WARNING !!! DO NOT USE THIS API TO DELETE L2SERVICES! Services are managed in config starting with NED version 1.5.4

In case the resource is already deleted, we get explicit messages from the device:

AUDIT REPORTS HANDLING (BSM Mode)

> audits get-compliance-reports : Get Compliance reports

Get custom reports by resourceType, expected (modeled***) for:

  • {cxDependent}.resourceTypes.NonCompliant

  • {cxDependent}.resourceTypes.NonComplianceReport

  • Any other existing resourceTypeId can be used, the outputs will be populated with minimal info, without properties content

    admin@ncs(config)# devices device live-status exec audits get-compliance-reports ? Possible completions: id OPTIONAL: id; Id of resource to get the report detail for; Default: all resourceTypeId OPTIONAL: resourceTypeId of the report type to get; expects {cxDependent}.resourceTypes.NonCompliant or ComplianceReport defaults to type: {cxDependent}.resourceTypes.NonCompliant

Examples of usage on different combinations

> audits get-compliance-reports : Get all NonCompliant type reports (default values, no id or resourcetype needed, gets all reports)

> audits get-compliance-reports : Get particular NonCompliant type report detail (resource id required, Resourcetype defaults to NonCompliant)

> audits get-compliance-reports : Get all compliance custom type reports (Resourcetype required)

> audits get-compliance-reports : Get custom type report detail (Resourcetype and id required)

audits get-schedule : Get Schedule reports [EPTConfig]

Get all Schedule Audit reports by resourceType, expected (modeled) for {cxDependent}.resourceTypes.Audit

audits get-schedule : Get all scheduled reports of type {cxDependent}.resourceTypes.Audit

audits get-schedule : Get Schedule reports [EPTConfig]

Get all scheduled reports of other type, different of {cxDependent}.resourceTypes.Audit Sample output for: {cxDependent}.resourceTypes.Audit

audits update-schedule : Update audit schedule properties (no entire object needed)

Update audit schedule properties (no entire object needed)

  • (modeled) for properties of {cxDependent}.resourceTypes.Audit

audits update-schedule : Update audit schedule properties only for type {cxDependent}.resourceTypes.Audit

audits execute-audit : Execute AUDIT operation [Audits]

Execute audit operation on given resource id, expected (modeled) for: {cxDependent}.resourceTypes.Audit

*** One can refer to section 5.2.2*** to fetch the {cxDependent}.resourceTypes.Audit ids available for current section.

Service provisioning (BSM Mode)

l23-service provision-service : Command to request L2Service provisioning to MCP by service id

l23-service unprovision-service : Command to request L2Service un-provisioning to MCP by service id

TSM_MODE: Most common Live status command used in TSM MODE:

  1. tsm get-networkconstructs Command to get Network Constructs using given inputs filtering;

  2. tsm get-equipment Command to get Equipment under a particular network construct using given inputs filtering;

  3. tsm get-fres Command to get Network Constructs FREs using given inputs filtering;

  4. tsm get-tpes Command to get TPEs using given inputs filtering;

  5. tsm get-service-intent Command to get resources Service Intent using given inputs filtering;

  6. tsm get-service-topology Command to get Service Topology of a given id

  7. tsm get-ne-profiles Command to get NE Profiles for a given typeGroup

  8. tsm get-market-resources Command to get market resources as filtered

  9. tsm commit-route Command to commit routes

  10. tsm delete-resource-id Command to delete L2Service or Service profile or any other resource by id

  11. tsm get-relationships Command to get relationships targetID by facadeId

  12. tsm request-routes Command to request routes for retreiving Resources ID

  13. tsm get-requested-routes Command to get requested routes options

  14. tsm get-tsm-products Command to get all products to fetch ids or for a particular type

  15. tsm search Command to search and get various Service Topologies: tpes|fres|nwConstructs

  16. tsm test-pseudowire Command to test EPL service

  17. tsm get-ethernet-port-status Command to Retrieve Ethernet Management Port Status (NM Server API)

  18. tsm get-performance-metrics Command to get Performance Metrics

  19. tsm test-benchmarkOperations Command to run a benchmark test using reflectorTpe

  20. tsm node-upgrade COLLECTION: Node Upgrade commands

    1. check-ne-upgrade-details Command to start firmware download

    2. disable-docs Command to disable docs

    3. get-node-backups Command to get backups for node

    4. get-node-docs Command to start firmware download

    5. get-shelf-config Command to get shelf config for node

    6. resume-upgrade Command to resume upgrade

    7. retrieve-upgrade-state Command to start firmware download

    8. schedule-node-backup Command to schedule node backup

    9. search-nodes-doc Command to get node docs

    10. start-firmware-download Command to start firmware download

    11. suspend-upgrade Command to suspend upgrade of the given network element node

    12. upgrade-state Command to start firmware download

  21. tsm node-enrolment COLLECTION: Node Enrolment commands

    1. tsm node-enrolment backup-schedule Command to schedule backup

    2. tsm node-enrolment clear-and-deEnroll Command to clear and de-enroll NE managementSessions

    3. tsm node-enrolment create-group Command to create a group

    4. tsm node-enrolment delete-group Command to delete planned group

    5. tsm node-enrolment delete-networkConstructs-groups Command to delete Group from All NCs

    6. tsm node-enrolment get-configmgmt-profiles Command to run Node Reconnect

    7. tsm node-enrolment get-management-sessions Command to get management sessions for node enrolment

    8. tsm node-enrolment get-ne-maintenanceDetails Command to get backup schedules for network elements

    9. tsm node-enrolment get-ne-managementSessions Command to get NE managementSessions

    10. tsm node-enrolment get-node-upgrade-details Command to get Node Upgrade Details

    11. tsm node-enrolment get-resource-serviceTopology Command to get Optical Details - serviceTopology for optical FRE Id

    12. tsm node-enrolment get-schedules Command to get schedules for node enrolment

    13. tsm node-enrolment lldp-link-tag Command to patch LLDP Link Tag with TDM-Project tag or to clear it

    14. tsm node-enrolment node-reconnect Command to run Node Reconnect

    15. tsm node-enrolment patch-ne-managementSessions Command to PATCH NE management Sessions

    16. tsm node-enrolment patch-networkConstructs Command to PATCH NE management Sessions - network constructs

    17. tsm node-enrolment run-enrolment Command to run enrolment

    18. tsm node-enrolment run-node-backup Command to run node backup

    19. tsm node-enrolment search-networkConstructs Command to search Parent Group

    20. tsm node-enrolment search-parent-group Command to search Parent Group

    21. tsm node-enrolment session-pre-enrolment Command to request session pre enrolment

    22. tsm node-enrolment trigger-group-creation Command to trigger the creation of group

  22. tsm otn-* Intermediate OTN Links (OTU P-Links)

    1. otn-create-otm-facility Command to CREATE : OTN (OTM 1-4) Facility, OOS, NDP, GCC, etc

    2. otn-create-otm2-facility Command to CREATE : OTN (OTM2) Facility, OOS, NDP, GCC, etc

    3. otn-delete-facility-params Command to DELETE OTN (OTM2) Facility

    4. otn-get-equipment-facility-submenus Command to get OTN Facility Submenus

    5. otn-get-equipment-information Command to get OTN Equipment information

    6. otn-patch-fre Command to Modify OTN Service FRE

  23. tsm manage-service-operations Command to Manage Market Resources Services Operations

  24. alarms

    1. tsm get-alarms Command to get filtered or correlated Alarms

  25. create-virtual-pLink Command to get Optical Details - serviceTopology for optical FRE Id

  26. get-configmgmt-script-job Command to get Script Output job id

  27. delete-configmgmt-script-job Command to get Script Output job id

  28. get-configmgmt-scripts Command to GET config management scripts by type

  29. delete-configmgmt-scripts Command to GET config management scripts by type

  30. get-fre-ccstatus Command to retrieve ccStatus (Continuity Check)

  31. delete-fres-expectations Command to delete FRES expectations for stuck in Scheduled state

  32. delete-tpe Command to delete TPEs using given tpe id

  33. get-equipment-information Command to get Equipment information

  34. get-equipment-topology-planning Command to retrieve Available A-End ports for the rate selected

  35. get-lag-details Command to Retrieve LAG details.

  36. get-tpe-expectations Command to get TPE tpeExpectations using given tpeExpectations.serviceIntent.id

  37. get-jobId-status-response Command to fetch the status and data available for a previously scheduled jobId

  38. get-resource-operation-state Command to get Market Resources Service Operation state

  39. get-service-intent-facade-id Command to get relationships targetID by facadeId

  40. get-tdc-pageLoad Command to Run test enabling/disabling tdmLoopback

  41. get-test-pseudowire-result Command to test EPL service

  42. manage-eline-attributes Command to retrieve Available A-End ports for the rate selected

  43. sync-network-elements Command to get resync Network Elements

  44. test-lspOperations Command to run a E-Tree service test from root-to-leaf or leaf-to-root

  45. test-tdmOperations Command to Run test enabling/disabling tdmLoopback

  46. upload-script Command to upload custom script

  47. upload-script-profile Command to upload scriptProfiles

  48. wavelength COLLECTION: Wavelength commands

    1. get-adj-values Command to get Optical Details - serviceTopology for optical FRE Id

    2. update-adj-values Command to get Optical Details - serviceTopology for optical FRE Id

  49. manage-lag COLLECTION: LAG management commands

    1. create-interfacemanagement Command to Create LAG InterfaceManagement entry

    2. create-lag-entry Command to Create LAG entry

    3. delete-lag-entry Command to Delete LAG entry

    4. get-interfacemanagement-values Command to get interface management values

    5. get-lag-values Command to get LAG values

    6. resync-components Command to resynchronize all components of a NcManagementSessionId

    7. update-lag-entry Command to Update LAG entry

    8. show-all-ne-lags Command to get all LAGs associated with any or the network element specified

    9. delete-interfacemanagement Command to Delete LAG InterfaceManagement entry 10. execute-any-request Generic command; execute any API callback, mentioning details 11. manage-virtualswitch-entry Command to get or delete ethernetConnectivity VirtualSwitch values 12. update-interfacemanagement Command to Update LAG InterfaceManagement entry

  50. search-all-networkConstructs Command to get all or filtered networkConstructs

  51. search-tunnel-endpoints Command to get Optical Details - serviceTopology for optical FRE Id

  52. update-ethernet-port-state Command to update Ethernet port state to disabled or enabled

Live status actions

All TSM related actions will be found under:

  • Each action has its own inputs and outputs. See stats yang model in the NED for more details.

  • Based on the input combinations we will call one api or another.

  • COLLECTION refers to a group of commands used for a common purpose.

1. tsm get-networkconstructs Get NetworkConstructs:

Sample callbacks from the live status command:

*** Get network constructs with enforced v1 api: ***

*** Get network constructs by network element name - works only with v4: ***

*** Get network constructs with v6 api (default option): ***

*** Get network constructs with v6 api (enforced option): ***

*** Get network constructs with v6 links: ***

*** Get network constructs with v6 links: ***

*** Get network constructs with v6 physicalLocation: ***

*** Get network constructs with physicalLocation: ***

*** Get network constructs with id ! works only with v1 or v4 !: ***

2. tsm get-equipment Get Equipment

Sample callbacks from the live status command

*** GET all equipment for NetworkConstructID : ***

*** GET all equipment for NetworkConstructID and Include Expectations ***

3. tsm get-fres Get FREs

Sample callbacks from the live status command

*** GET FRE With Network Construct ID forTunnels : ***

*** GET FRE With Network Construct ID And TPEs : ***

*** GET FRE With FREID And TPEs : ***

*** GET FRE With EthernetService using NetworkConstructID and TPEs : ***

*** GET FRE With Network Construct ID : ***

*** GET FRE with FRE-ID: ***

*** GET FRE with FRE-ID with ServiceIntentID: ***

4. tsm get-tpes Get TPEs

Sample callbacks from the live status command

*** GET TPE with Network Construct ID : ***

*** Get TPE Using TPEID : ***

*** GET TPEs : ***

*** GET TPEs for a Network ConstructID and Include Expectations : ***

5. tsm get-service-intent Get Service Intent

Sample callbacks from the live status command

*** Get Service Intent with MPLSTunnel Intent : ***

admin@ncs(config-device-ciena-bharti-lab1)# live-status exec tsm get-service-intent resourceTypeId ifd.v6.resourceTypes.MplsTunnelIntent

*** Get Service Intent Using IntentID : ***

admin@ncs(config-device-ciena-bharti-lab1)# live-status exec tsm get-service-intent resourceId 5deb992c-ced4-457e-ac03-4da471f17449

6. tsm get-service-topology Get Service topology

Sample callbacks from the live status command

*** Get Service Topology : ***

7. tsm get-ne-profiles Get NE Profiles

Sample callbacks from the live status command

*** Get NE profiles ***

  • Latter is defaulting typeGroup to 'Ciena6500'

8. tsm get-market-resources Get market-resources

9. tsm commit-route Commit route

  • Where $rawJson should be full updated routes body for the API, with the following strict syntax, containing "interface" param and inputs.routes[] as the desired routes, i.e:

  • To collect the routes to commit, run the live status command no 13. tsm get-requested-routes

    • Collect response.outputs.routes[] and use them as needed as input for this command.

  • Please note that the json object composed to have the above expected structure must be escaped/quoted when being passed to the live status command as the rawData parameter

    • For example:

  • Example of a full route json object:

10. tsm delete-resource-id Delete resource by given id:

!warning! if you delete any resource potentially affecting config cdb, run a sync-from afterwads!

11. tsm get-relationships Get relationships by facadeId

12. tsm request-routes Command to request routes for retreiving Resources ID

13. tsm get-requested-routes Command to get requested routes options

14. tsm get-tsm-products Command to show all products to fetch ids or for a particular type

  • resourcetypeId refers to object type, i.e. ifd.v6.resourceTypes.L2ServiceIntentFacade

15. tsm search Command to show Service Topology of a given id by node type

  • Then choose a combination of filters for searching for that node type:

  • example GET Network Constructs. Retrieve Available Z-End NE Ports - tpes

    admin@ncs(config-device-ciena-lab1)# live-status exec tsm search node tpes include expectations namedQuery portsL2ApplicableEPLUniWithMcLag sortBy data.attributes.locations networkConstructId <$networkConstruct.id>

16. tsm test-pseudowire Command to test EPL service

  • Single segment pseudowire services have one pseudowire end-to-end on top of one LSP.

  • Multi-segment pseudowire services have multiple pseudowires stitched together over multiple LSPs to provide end-to-end service.

  • Inputs given offer a range of customization on the request body needed for the API to trigger the right segment:

Sample callbacks :

  • i.e.: test pseudowire Multi segment traceroute

    • <$localTpeId> : format sample :

      • 12345678-1234-1234-1234-123456789012::TPE_1_CTPServerToClient_EQPTGRP_9_PW{$NAME}PW_3

  • i.e.: test single segment ping :

17. tsm get-ethernet-port-status Get Ethernet Port Status - operLink

  • Inspect ports and states of the given input parameter

  • Returns ports and operLink states

Sample callback:

18. tsm get-performance-metrics Get performance metrics

  • Check for traffic on a particular endpoint before deleting the service

Example of minimal inputs callback with all the param values (displayName, facilityNameNative, parameterNative)

  • displayName, facilityNameNative, parameterNative can be passed individually, or in combinations, with values, defaulting the comparator to '='

Example of direct callback to fecth directly the nextInterval /pm/api/v3/query/metrics?start=1619656140000&end=1619659680000&cursor=0

19. tsm test-benchmarkOperations Command to test benchmark

  • Inputs given offer a range of customization on the request body needed for the API to trigger the right segment:

    • testParameters can be used with simple Json Object string content, or broken down into decomposed parameters.

Using testParameters as a quoted string value of a valid json with the needed parameters:

Using testParameters broken down with te same parameters used in the json string:

20. tsm node-upgrade NODE UPGRADE COMMANDS

20.1 tsm node-upgrade check-ne-upgrade-details

20.2 tsm node-upgrade disable-docs

20.3 tsm node-upgrade get-node-backups

20.4 tsm node-upgrade get-node-docs

20.5 tsm node-upgrade get-shelf-config

20.6 tsm node-upgrade resume-upgrade

20.7 tsm node-upgrade retrieve-upgrade-state

20.8 tsm node-upgrade schedule-node-backup

20.9 tsm node-upgrade search-nodes-doc

20.10 tsm node-upgrade start-firmware-download

20.11 tsm node-upgrade suspend-upgrade

20.12 tsm node-upgrade upgrade-state

21. tsm node-enrolment NODE ENROLMENT COMMANDS BEGIN :

  • Collection of new live status commands and extension of existing commands used to run node enrolment ** *** The command collection is ordered as per the deployment process for node enrolment to exemplify usage ***

21. NODE ENROLMENT END ^

22. Intermediate OTN Links (OTU P-Links) : live status commands

22. Intermediate OTN Links (OTU P-Links) : live status commands END^

23. tsm manage-service-operations Manage service operations

24. ALARMS

25. create-virtual-pLink Command to get Optical Details - serviceTopology for optical FRE Id

26. get-configmgmt-script-job Command to get Script Output job id

27. delete-configmgmt-script-job Command to get Script Output job id

28. get-configmgmt-scripts Command to GET config management scripts by type

29. delete-configmgmt-scripts Command to GET config management scripts by type

30. get-fre-ccstatus Command to retrieve ccStatus (Continuity Check)

31. delete-fres-expectations Command to delete FRES expectations for stuck in Scheduled state

32. delete-tpe Command to delete TPEs using given tpe id

33. get-equipment-information Command to get Equipment information

34. get-equipment-topology-planning Command to retrieve Available A-End ports for the rate selected

35. get-lag-details Command to Retrieve LAG details.

36. get-tpe-expectations Command to get TPE tpeExpectations using given tpeExpectations.serviceIntent.id

37. get-jobId-status-response Command to fetch the status and data available for a previously scheduled jobId

38. get-resource-operation-state Command to get Market Resources Service Operation state

39. get-service-intent-facade-id Command to get relationships targetID by facadeId

40. get-tdc-pageLoad Command to Run test enabling/disabling tdmLoopback

41. get-test-pseudowire-result Command to test EPL service

42. manage-eline-attributes Command to retrieve Available A-End ports for the rate selected

43. sync-network-elements Command to get resync Network Elements

44. test-lspOperations Command to run a E-Tree service test from root-to-leaf or leaf-to-root

45. test-tdmOperations Command to Run test enabling/disabling tdmLoopback

46. upload-script Command to upload custom script

47. upload-script-profile Command to upload scriptProfiles

48. wavelength COLLECTION: Wavelength commands

48.1 get-adj-values Command to get Optical Details - serviceTopology for optical FRE Id

48.2 update-adj-values Command to get Optical Details - serviceTopology for optical FRE Id

49. manage-lag COLLECTION: LAG management commands

49.1 tsm manage-lag create-interfacemanagement :

  • Command to Create LAG InterfaceManagement entry

  • Varies based on the resourceType value:

5142 Example:

5171 Example:

6500 Example:

49.2 tsm manage-lag create-lag-entry

  • Command to Create LAG entry

49.3 tsm manage-lag delete-lag-entry

  • Command to Delete LAG entry

49.4 tsm manage-lag get-interfacemanagement-values

  • Command to get interface management values

49.5 tsm manage-lag get-lag-values

  • CommCommand to get LAG values

49.6. tsm manage-lag resync-components

  • Command to resynchronize all components of a NcManagementSessionId

49.7 tsm manage-lag update-lag-entry

  • Command to Update LAG entry

49.8 tsm manage-lag show-all-ne-lags

  • Command to get all LAGs associated with any or the network element specified

  • networkElement is optional.

49.9 tsm manage-lag delete-interfacemanagement

  • Command to Delete LAG InterfaceManagement entry

49.10 tsm manage-lag execute-any-request

  • Generic command; execute any API callback, mentioning details

49.11 tsm manage-lag manage-virtualswitch-entry

  • Command to get or delete ethernetConnectivity VirtualSwitch values

49.12 tsm manage-lag update-interfacemanagement

  • Command to Update LAG InterfaceManagement entry

  • Depending on the resource type, there will be multiple parameter variations:

Example : resourceType == 5142:

Example : resourceType == 5171:

Example : resourceType == 6500:

50. search-all-networkConstructs

  • Command to get all or filtered networkConstructs

51. search-tunnel-endpoints

  • Command to get Optical Details - serviceTopology for optical FRE Id

52. update-ethernet-port-state

  • Command to update Ethernet port state to disabled or enabled

6. Built in live-status show

NONE

7. Limitations

BSM mode : Show Partial - partial-sync-from

-> NED V 1.8.9 onwards

  • To synchronize only a single list entry or a single list under the BSM specific configuration one can now use show partial command

BSM_SHOW_PARTIAL_1: Partial sync-from an entire list; i.e. config/services/l2Service list:

BSM_SHOW_PARTIAL_2: Partial sync-from a given list entry; i.e. config/services/l2Service{l2Service-Name} list entry:

BSM_SHOW_PARTIAL_3: Partial sync-from on deeper levels; i.e. config/services/l2Service{l2Service-Name}/properties/... :

  • available from NED version 1.8.10 onwards

OR

etc.

NOTE:

Requests like the ones above, either generated by NSO or by the end-user, will automatically generate at NED level a search up the tree for the first node that can be fetched using a device REST API available.

Taking the above two examples, finest search level is on the top list entry, i.e. l2Service{l2Service-Name} level, so requesting anything beneath that level, will result in a search on the $l2Service-Name resource at the MSDO level.

8. How to report NED issues and feature requests

Issues like bugs and errors shall always be reported to the Cisco NSO NED team through the Cisco Support channel:

The following information is required for the Cisco NSO NED team to be able to investigate an issue:

Do as follows to gather the necessary information needed for your device, here named 'dev-1':

  1. Enable full debug logging in the NED

  2. Configure the NSO to generate a raw trace file from the NED

  3. If the NED already had trace enabled, clear it in order to submit only relevant information

    Do as follows for NSO 6.4 or newer:

    Do as follows for older NSO versions:

  4. Run a compare-config to populate the trace with initial device config

  5. Reproduce the found issue using ncs_cli or your NSO service. Write down each necessary step in a reproduction report.

  6. Gather the reproduction report and a copy of the raw trace file containing data recorded when the issue happened.

  7. Contact the Cisco support and request to open a case. Provide the gathered files together with access details for a device that can be used by the Cisco NSO NED when investigating the issue.

Requests for new features and extensions of the NED are handled by the Cisco NSO NED team when applicable. Such requests shall also go through the Cisco support channel.

The following information is required for feature requests and extensions:

  1. A detailed use case description, with details like:

    • Data of interest

    • The kind of operations to be used on the data. Like: 'read', 'create', 'update', 'delete' and the order of the operation

    • Device APIs involved in the operations (For example: REST URLs and payloads)

    • Device documentation describing the operations involved

  2. Run sync-from # devices device dev-1 sync-from (if relevant)

  3. Attach the raw trace to the ticket (if relevant)

  4. Access to a device that can be used by the Cisco NSO NED team for testing and verification of the new feature. This usually means that both read and write permissions are required. Pseudo access via tools like Webex, Zoom etc is not acceptable. However, it is ok with access through VPNs, jump servers etc.

9. How to rebuild a NED

To rebuild the NED do as follows:

When the NED has been successfully rebuilt, it is necessary to reload the package into NSO.

PreviousREADME.TSMNextciena-saos_nc

Last updated

Was this helpful?