circle-info
Release Announcement: NSO 6.6 is here!
Check out the release highlights to see what's newarrow-up-right
search
NSO DevCenterTry NSO

README v1.0.29 2025-12-09

hashtag
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
10. IP-services-feature
   10.1 CRUD operations on services like: L3VPN, L2EVPN, VPLS, VLL and QoS
   10.2 Fetching operational data for network-element and ltps
   10.3 tailf-actions for IP-services-feature (L3VPN and QoS)
   10.4 Choosing how the L3VPN configuration is fetched
   10.5 Partial sync-from support for L3VPN section
   10.6 Interface management feature
   10.7 Partial sync-from support for interface management
   10.8 Partial sync-from support for interface/trunk-members
   10.9 e-trunk section
   10.10 Partial sync-from support for e-trunk
   10.11 Partial sync-from support for ESI
   10.12 Partial sync-from support for route-policy and tunnel-trail
   10.13 CRUD operations on ACL service
   10.14 CRUD operations on DHCP service
   10.15 tail-f action to query locators by nes
11. DWDM-feature
    11.1 create/delete a 'tunnel' list entry
    11.2 create/modify/delete a service ('client-svc-instances') list entry
    11.3 check-sync support
    11.4 Partial sync-from support
    11.5 tail-f action for pre-route calculation
    11.6 tail-f actions to fetch operational data
          10.6.1 action to extract tunnels
          10.6.2 action to extract services
          10.6.3 action to extract networks elements
          10.6.4 action to extract nodes for a specific network
          10.6.5 action to extract links for a specific network
    11.7 Choose how long to wait after a 'client-svc-instance' is going to be created
12. NCE-FAN feature
    12.1 Introduction
    12.2 Add a vlan to a NE(OLT)
    12.3 Associate a vlan to an OLT port
    12.4 Disassociate a vlan from OLT port
    12.5 Create a service-port
    12.6 Modify a service-port
    12.7 Delete a service-port
    12.8 Delete a vlan from an OLT
    12.9 Partial sync-from support
    12.10 sync-from using "product-name" filtering
    12.11 tail-f action to fetch OLTs' status

hashtag
1. General

This document describes the huawei-nce NED.

The NED covers 3 features: IP_services_feature, DWDM_feature and NCE-FAN-feature and only one can be enabled at a time (under the ned-settings section). By default, all 3 features are disabled and before starting to use the NED, the first setting that must be done by the user is to enable one of the 3 features, as below:

  • enable IP-services-feature

  • enable DWDM-feature

  • enable NCE-FAN-feature

Note:

  • in case one of the features is enabled and the user wants to enable other feature, then the current feature must be set of false

Additional README files bundled with this NED package

Common NED Features

Verified target systems

hashtag
1.1 Extract the NED package

It is assumed the NED package ncs-<NSO version>-huawei-nce-<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:

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

hashtag
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: huawei-nce-<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:

hashtag
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

hashtag
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):

  • Finally commit the configuration

  • Verify configuration, using a sync-from.

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

hashtag
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-huawei-nce-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:

hashtag
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)

hashtag
4. Sample device configuration

Create a tunnel for DWDM-feature:

For more examples, please check the specific sections from the README.md file.

hashtag
5. Built in live-status actions

The huawei-nce NED contains lots of actions for IP-services-feature and DWDM-feature.

Examples:

  1. fetching operational platform-data for IP-services-feature

  2. fetching specific tunnels for DWDM-feature

For more details regarding the tail-f actions for IP-services feature, please check 10.2, 10.3 and 10.15 sections from the README.md file.

For more tail-f actions related to the DWDM-feature, please check 11.5 and 11.6 sections from the README.md file.

There is an action for the NCE-FAN feature as well. Please find details at 12.11 tail-f action to fetch OLTs' status section.

hashtag
6. Built in live-status show

NONE

hashtag
7. Limitations

NONE

hashtag
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.

hashtag
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.

hashtag
10. IP-services-feature

hashtag
10.1 CRUD operations on services like: L3VPN, L2EVPN, VPLS, VLL and QoS

The complete list of use-cases covered by NED can be seen below:

Note:

  • 4.3.x.y is the section number as described in the "iMaster NCE V100R020C00 Northbound REST API Guide - 11182020.pdf" manual)

hashtag
10.2. Fetching operational data for network-element and ltps

The customer can choose what method should be used to fetch the platform operational data. By default the "file" method(reading configuration from file) is used.

To change to the "api" method, the steps are:

Note:

  • disconnect/connect operations are required for ned-settings to be taken into account

Example:

Display 'network-elements' from the operational database:

Display 'ltps' from the operational database:

Note:

  • when using get-platform-oper-data live-status action, all the LTPs and NEs will be fetched and written to operational DB (ODB). In case of ODB data update failure (for "ltps/ltp and network-elements/network-element"), the old previous ODB data is re-written. After fetching new data from device, the old data from ODB is stored in a temporary file whose name starts with "huawei-platform-oper" and is found in the default temporary-file directory. On UNIX systems the default directory is usually "/tmp". When the temporary file is not needed anymore, is automatically deleted. The ODB data update is done in 2 steps: delete old data and write the new data. Deleting current ODB data is done after fetching the new data from device.

If the user wants to fetch a single LTP or NE (with/without filters) or maybe a list of them and not all of them, can run the following live-status exec actions:

  1. for LTPs Example:

    where {list of LTPs} can have one of the values: - LTP1 -> a single LTP is fetched and written to ODB - LTP1 LTP2 -> only ltps with ids: LTP1 and LTPs are fetched from device and written to ODB. LTP1 and LTP2 are separated by space. - none -> the corresponding LTP list (platform/query-ltp/ltp) is deleted from ODB

    To display the LTPs entries from ODB please use:

  2. for NEs Example:

    where {list of NEs} can have one of the values: - NE1 -> a single NE is fetched and written to ODB - NE1 NE2 -> only NE1 and NE2 are fetched from device and written to ODB. NE1 and NE2 are separated by space. - none -> the corresponding NE list (platform/query-network-element/network-element) is deleted from ODB

    To display the NE entries from ODB please use:

  3. "get-network-element-data-filters" is an action that can be used to fetch NE with filters like: "name" and "ip-address".

    Examples: 3.1. both filters at the same time

    3.2. just a single filter

    3.3. fetch all the network-elements

    The results for all 3 examples from above are written to ODB.

  4. The following action can be used to fetch all the ltps for a particular ne-id:

    To check the ltps for that particular ne-id:

  5. Query All LTPs with "parent-ltp-id" filter and write them into ODB Example:

hashtag
10.3. tailf-actions for IP-services-feature (L3VPN and QoS)

The below examples have the same section number to the ones found in the "NCE NBI Developer Guide - for PLDT 2.0-20190731.pdf" manual.

Examples:

  1. use-case 4.3.7.23 Delete multi-field classification on device

  2. use-case 4.3.5.54 Create L3vpn svcs detail exporting task

  3. use-case 4.3.5.55 Query L3vpn svcs exporting task status

  4. use-case 4.3.5.56 Download exported L3VPN svc file

  5. use-case 4.3.5.21

  6. use-case 4.3.5.22

hashtag
10.4 Choosing how the L3VPN configuration is fetched

L3VPN configuration can be fetched using APIs or reading the entire L3VPN configuration from a file. The user can choose between the 2 methods by setting the "huawei-nce/fetch-l3vpn-method" leaf from the ned-settings section.

The values for this leaf are:

  • api-> APIs are used to fetch the L3VPN configuration. This is a slower method, since multiple GET requests are required for every single L3VPN service

  • file-> only 3 APIs are necessary to read the L3VPN configuration from the device. This method is much faster.

If the "huawei-nce/fetch-l3vpn-method" leaf is not configured, then the file method ("file") is used. This is the default method.

If for some reason, the user wants to switch to the "api" method, then the following settings should be done:

Note:

  • when file method is used to fetch L3VPN configuration, the user can adjust the time necessary to fetch the file. Sometimes, fetching the configuration of the L3VPN file requires more time if the device has a larger configuration.

The user can control via ned-settings the timeout for downloading a L3VPN file as below:

Please note that the disconnect and connect commands are mandatory, so the ned-setting can be taken into account.

hashtag
10.5 Partial sync-from support for L3VPN section

Starting from the Release 1.0.13, support for the partial sync-from for the L3VPN section has been added. When abort()/revert() methods are triggered, partial sync-from is called before them and can reduce the total time of the rollback process.

huawei-nce NED has support for getTransID() as well. getTransID() is triggered in multiple places:

  • at sync-from() -> after show() method which is called at sync-from(), getTransID() is called

  • at compare-config -> both show() and getTransID() are called

  • at commit() -> here getTransID() is called twice, once before prepare() and once after prepare()

Normally, getTransID() is computed by fetching the entire configuration and applying a hash number on it. This could be very time consuming, in case of generic NEDs when large data configuration is fetched from the device.

The user can disable the getTransID computation and can keep the partial sync feature using the following ned-setting:

hashtag
10.6 Interface management feature

NED has support for the following elements: 10.6.1. Create an interface (4.3.15.1 section from the "iMaster NCE V100R020C00 Northbound REST API Guide - 11182020.pdf manual") Example:

How the payload that will be sent to the device will look like:

10.6.2. Delete an Interface Example:

10.6.3. Modify the NE-side Properties of an Interface Example:

10.6.4. Add a Trunk Member Interface to an Interface Example:

10.6.5. Delete a Trunk Member Interface from an Interface Example:

10.6.6. Add an ESI to an Interface Example:

10.6.7. Delete an ESI from an Interface Example:

Payload to the real device is obtained running the commit dry-run outformat native command:

10.6.8. Modify the Administrative Status of an Interface

The "admin-status" field is now ignored in Yang model. It can be used to create an interface and is modified via live-status action.

Example:

hashtag
10.7 Partial sync-from support for interface management

NED has support for partial sync-from for "Query NE-Side Information About an Interface" (4.3.15.2 section from "iMaster NCE V100R020C00 Northbound REST API Guide - 11182020.pdf" manual).

Examples:

  1. get a specific interface for a specific NE:

  2. get all interfaces for a specific NE called 4cc09f52-4810-11ea-b783-fa163e0659e8

  3. get all interfaces for all NEs

hashtag
10.8 Partial sync-from support for interface/trunk-members

NED has support for partial sync-from support for "Query the Trunk Member Interfaces of an Interface" (4.3.15.5 section from "iMaster NCE V100R020C00 Northbound REST API Guide - 11182020.pdf" manual).

Examples:

  1. get all trunk-members list for a specific interface, called 69758efc-4810-11ea-a974-fa163e480e86, from a specific NE (i.e. 4cc09f52-4810-11ea-b783-fa163e0659e8)

  2. get a specific trunk-member entry for a specific interface

hashtag
10.9 e-trunk section

NED supports READ, CREATE and DELETE operations of e-trunk section. Example:

  1. Create an e-trunk with no bfd

  2. Delete an e-trunk

    Example:

    "no etrunk e-trunk-test-66"

hashtag
10.10 Partial sync-from support for etrunk

NED has support for partial sync-from support for "Query E-Trunk Interface Information" (4.3.16.2 section from iMaster NCE V100R020C00 Northbound REST API Guide - 11182020.pdf manual).

Examples:

  1. get all e-trunk entries

  2. get a specific e-trunk list entry: etrunk-test1

hashtag
10.11 Partial sync-from support for ESI

NED has support for partial sync-from support for "Query the ESI Configurations of an Interface" (4.3.15.10 section from "iMaster NCE V100R020C00 Northbound REST API Guide - 11182020.pdf" manual).

Examples:

  1. get all ESI for all interfaces under a specific NE (4cc09f52-4810-11ea-b783-fa163e0659e8)

  2. get an ESI for a specific interface(320a0e0b-d5e4-4827-9aeb-ae3b8497b07f) from a particular NE(4cc09f52-4810-11ea-b783-fa163e0659e8)

hashtag
10.12 Partial sync-from support for route-policy and tunnel-trail

Examples route-policy:

  1. get all entries for route-policy list

  2. get a single route-policy: NED_TEST

Examples tunnel-trail:

  1. fetch all entries for tunnel-trail list

  2. fetch a single tunnel-trail list entry

hashtag
10.13 CRUD operations on ACL service

Examples: 10.13.1. Create an ACL service

10.13.2. Create a basic ACL service

10.13.3. Update a basic ACL service

10.13.4. Create an ACL service

10.13.5. Create an advance ACL service

10.13.6. Update an ACL service

10.13.7. Delete an advance rule of an ACL service

10.13.8. Delete an ACL service

hashtag
10.14 CRUD operations on DHCP service

Examples: 10.14.1. Create a DHCP service

10.14.2. Update a DHCP service

10.14.3. Create an IP pool section

10.14.4. Delete an IP pool section

10.14.5. Delete a DHCP service

hashtag
10.15 tail-f action to query locators by nes

Example:

hashtag
11. DWDM-feature

hashtag
11.1 create/delete a 'tunnel' list entry

Example create a tunnel:

Example delete a tunnel (only when tunnel is not linked to a service):

NOTE:

  • if a tunnel is linked to a service, then the tunnel and the service must be deleted in the same transaction by the user. In this case, only the "delete" operation for 'client-svc-instance' will be sent to the device by the NED - NCE device will automatically delete the related tunnel as well.

hashtag
11.2 create/modify/delete a service

Example create a service:

Example delete a service

Note:

  • when deleting a service, the NCE device will automatically delete its associated tunnel. Hence the user must delete the tunnel in the same transaction.

Example modify a service

Note:

  • When 'client-svc-title' of a 'client-svc-instance' is modified, then the 'title' of the related 'tunnel' must be modified with the same value, in the same transaction. This is necessary because, the 'title' under 'tunnel', is dynamically changed after 'client-svc-title' is updated or 'client-svc-instance' is created and it would cause "compare-config" diffs.

  • NED will ignore this change, since the 'tunnel' list doesn't accept "Modify" operation.

Example:

hashtag
11.3 check-sync support

hashtag
11.4 Partial sync-from support

Example tunnel:

Example service:

hashtag
11.5 tail-f action for pre-route calculation

hashtag
11.6 tail-f actions to fetch operational data

hashtag
11.6.1 action to extract tunnels

Depending on needs, "all", "none" or particular tunnels can be fetched

Fetch all available tunnels:

Clear operational database(ODB) for tunnels:

Fetch only specific tunnels:

Please note that when you write new values for the tunnel, the previous ones are automatically deleted. So, for example, if you currently have the "all" value for tunnels, and then you want to fetch a "first-tunnel" tunnel, there is no need to delete the current values:

Instead of:

is enough to set only the needed tunnel:

If you want to fetch one more tunnel(there is no need to delete the second-tunnel):

Here, the single fetched tunnel is "second-tunnel" and the previous "first-tunnel" will be kept in the ODB. This operation is seen as an append operation.

To display operational data for tunnels:

hashtag
11.6.2 action to extract the services ("client-svc-instances")

Similar to tunnels, equivalent actions can be used to fetch "all", "none" or specific services.

To display services operational data:

hashtag
11.6.3 action to extract networks elements

11.6.3.1 To extract all networks, the user has 2 modes to do it:

Mode 1.

Mode 2. The same effect as above can be obtained using 3 different actions: Step 1. "get-DWDM-networks-create-task" action to fetch task-id for oper NW data Step 2. "get-DWDM-network-query-task" action to check the task status for action 1 Step 3. "get-DWDM-networks-oper-data-file" action to download the files and write platform/networks to ODB

Example for mode 2: Step 1.

Note: task-id is saved to Operational DB

Step 2.

Note: at this step the file names are automatically saved into Operational DB.

Step 3.

Note: At this step the task-id and file names are read from Operational DB and deleted in the end

11.6.3.2 To ignore fetching network elements and delete the existing ones from operational CDB

hashtag
11.6.4 action to extract nodes for a specific network

A. to extract a single node from a particular network:

B. to extract all nodes for a particular network:

C. to extract multiple nodes for a particular network

hashtag
11.6.5 action to extract links for a specific network

A. to extract a single link from a particular network:

B. to extract all links from a particular network

C. to extract multiple links for a particular network

hashtag
11.7 Choose how long to wait after a 'client-svc-instance' to be created

Depending on the device's connection, sometimes creating a "client-svc-instance" can take more or less time. The parameter "time-provisioning-service-DWDM" param is now modifiable via ned-settings and user can choose how many seconds to wait when creating a "client-svc-instance".

Example:

P.S.: Don't forget to disconnect and connect again to take into account the ned-setting "time-provisioning-service-DWDM".

Another important thing is that user has the possibility to choose if NED should wait for "client-svc-instance" to be up (old method), meaning to reach the "lsp-state-up" state or not (new method). Hence, the user can choose between the old and the new method via ned-settings, using "client-svc-instance-completed-method" parameter: "old-method" and "new-method".

For the "new-method", user can check extra information available into operational DB. If the "client-svc-instance" was completed (has "lsp-state-up" state) during the time set by "time-provisioning-service-DWDM", it will have a "completed" status as below:

... otherwise a timeout will occur and the ervice won't be completed anymore:

When sync-from or compare-config are triggered, the service's status will be updated as below:

  • if the service was existing in ODB (operational DB), but not present on the device anymore, will be deleted from ODB

  • if the service was created outside NED, it will have status "outside"

  • if service had "timed-out" status when it was created from NED, and in the meantime become "lsp-state-up", it will have "completed" status

hashtag
12. NCE-FAN feature

hashtag
12.1 Introduction

A single ned-feature must be enabled at a given time. By default, all ned-features are set on false. To enable the NCE-FAN feature, the user must enable the related ned-setting:

getTransID() is used to know if the NED's CDB and the device are in sync, before applying new configuration. In most cases, getTransID() is computed by fetching the entire configuration and applying a hash number on it. This could be very time consuming, in case of generic NEDs where large data configuration is fetched from the device. For instance, at commit(), getTransID() is called twice, once before prepare() and once after prepare(), meaning double the time of a sync-from command. Since this operation can take hours, the user can disable the getTransID computation and can keep the partial sync-from feature, using the following ned-setting:

If authentication is done using a certificate, the user can set the following ned-settings:

As mentioned above, the sync-from may take several hours if the device contains a large amount of data. For this case, the NED provides a facility to first fetch only the name of the NE(OLTs), and then the user cand decide, using the partial sync-from feature, which OLT configuration to fetch further (please check section 12.9, calls starting from number 2). In order to be able to call partial sync-from on "vlans-ne" or "service-ports" (which are children list of OLT), the name of the NE must be known(i.e. present into CDB).

This can be achieved using the following ned-setting:

Once, the basic sync-from is performed, the user must change the 'get-ne-data' ned-setting to the value: "full". Also, if the sync-from filtering option(please check the 12.10 section) is used, then the 'get-ne-data' parameter must be set to the "full" value as well.

Note:

  • since there are cases when hundreds or thousands of OLTs are present on a huawei-nce controller, the user can disable the sync-from operation and use partial sync-from per OLT.

To disable sync-from:

If the OLT name is not present into CDB(as part of a "light" sync-from), the only partial sync-from operation allowed in this case is the one that fetches the entire configuration of an OLT:

Note:

  • When the sync-from operation is performed, (with or without filtering enabled, i.e. "enable-olt-filtering" enabled, or "get-ne-data" in "full" or "light" format), the related OLTs cards information(product-name and slot) are saved to operational DB. To check those, the user can run the following command:

The user can control which API can be used to fetch the authentication token. Both versions are working fine at this moment.

Note:

  • disconnect/connect operations are required for the ned-settings to be taken into account

hashtag
12.2 Add a vlan to a NE(OLT)

Example: The user must provide the following parameters:

To check how the command that will be send to the device will look like, the user can use the following:

To commit the changes:

Note:

  • currently, there is a bug on the huawei-nce device, and the vlan is not visibile after is added to an OLT.

hashtag
12.3 Associate a vlan to an OLT port

Example: associate VLAN 999 on OLT9002 port 0/9/1

hashtag
12.4 Disassociate a vlan from OLT port

Example: disassociate VLAN 999 on OLT9002 port 0/9/1

hashtag
12.5 Create a service-port

Example:

How the payload that will be sent to the device will look like:

hashtag
12.6 Modify a service-port

Example:

How the payload that will be sent to the device will look like:

hashtag
12.7 Delete a service-port

Example:

hashtag
12.8 Delete a vlan from an OLT

Example: delete vlan 999 from OLT9002

hashtag
12.9 Partial sync-from support

Note: If the filtering operation is enabled, meaning that the "enable-olt-filtering" ned-setting is set on true and the "filter-by-product-name" ned-setting contains a valid "regex", then the partial sync-from operation will be applied only to those entries that meet the above regex pattern. For more details about the filtering operation please check the '12.10 sync-from using "product-name" filtering' section.

Examples:

  1. fetching the entire configuration of an OLT

When partial-sync from is performed for a specific olt, the related cards are saved(or updated) to the ODB. The user can check the cards using the following command:

  1. fetching all the vlans from a specific OLT

  2. feching a specific vlan from a specific OLT

  3. feching all vlan-ports for a specific vlan from a specific OLT

  4. feching a vlan-port for a vlan from a specific OLT

  5. fetching the service-ports configuration from an OLT

  6. fetching a service-port from an OLT

hashtag
12.10 sync-from using "product-name" filtering

The sync-from operation can take a lot of time when there is a large number of NEs(OLTs) devices present on the huawei-nce device. The user can filter which data to be fetched from the device using a regex for "product-name" field. This field is part of the response of the "v2/data/huawei-nce-resource-inventory:cards" API.

In order to enable the filtering operation the user must enable the following ned-settings:

Example:

The NED filters all the entries from "v2/data/huawei-nce-resource-inventory:cards", with the "product-name" that contains the regex above ("H901MPLA.*") and fetches the related frame-number(fn) and slot-number(sn). Since the .* consumes everything after it, the regex will match the entire line. For instance, if the regex has the following format: "H\d{3}OGHK", the match will occur if the product-name contains that string, no matter if is before or after it. Then, at sync-from, the NED fetches configuration("vlans-ne" and "service-ports") from all OLTs that have a product-name matching the regex.

hashtag
12.11 tail-f action to fetch OLTs' status

For situations where there is a large number of OLTs onboarded on the NCE controller, hundreds or even thousands and only a part of them have been fetched to CDB, the user has the option to check which new OLTs have been added in the controller or which OLTs have been removed from the controller, but still exist in the current CDB.

The user can use the following action:

To check the output, the user can verify the data below:

"new-olts" list refers to the OLTS that are not present in the current CDB, but exist in the NCE controller. To fetch a new OLT, the user can call the partial sync-from command as described in the 12.9 section, example 1. fetching the entire configuration of an OLT.

"removed-olts" list refers to the OLTs that exist in the current CDB, but have been removed from the NCE controller. In order to remove an OLT that doesn't exist any more in the NCE controller, the user can issue this command:

PreviousREADME-ned-settingsNexthuawei-vrp

Last updated

Was this helpful?