- Start
- What's New
- Getting Started
- User Guide
- About
- Basic Operations
- Network Element Drivers and Adding Devices
- Managing Network Services
- NSO CLI
- The NSO Device Manager
- SSH Key Management
- Alarm Manager
- Plug-and-play Scripting
- Compliance reporting
- NSO Packages
- Life-cycle Operations - Manipulating Existing Services and Devices
- Web User Interface
- Network Simulator
- Administration Guide
- Northbound APIs
- Development Guide
- Preface
- Development Environment and Resources
- The Configuration Database and YANG
- Basic Automation with Python
- Developing a Simple Service
- Applications in NSO
- Implementing Services
- Templates
- Services Deep Dive
- The NSO Java VM
- The NSO Python VM
- Embedded Erlang applications
- The YANG Data Modeling Language
- Using CDB
- Java API Overview
- Python API Overview
- NSO Packages
- Package Development
- Service Development Using Java
- NED Development
- NED Upgrades and Migration
- Service Handling of Ambiguous Device Models
- Scaling and Performance Optimization
- NSO Concurrency Model
- Developing Alarm Applications
- SNMP Notification Receiver
- The web server
- Kicker
- Scheduler
- Progress Trace
- Nano Services for Staged Provisioning
- Encryption Keys
- External Logging
- NSO Developer Studio
- Web UI
- Layered Service Architecture
- Manual Pages
- NSO Documentation Home
- NSO SDK API Reference
- NSO Change Log Explorer
- NSO NED Change Log Explorer
- NSO NED Capabilities Explorer
- NSO on DevNet
- Get Support
OUTDATED
OUTDATED
This documentation corresponds to an older version of the product, is no longer updated, and may contain outdated information.
Please access the latest versions from https://cisco-tailf.gitbook.io/nso-docs and update your bookmarks. OK
You can install NSO in production or development use. Understand the different install types to decide which deployment suits your needs.
The installation of NSO comes in two variants, i.e.
-
Local Install
-
System Install
Before proceeding with the installation, decide the install type.
The following sections provide more information on the install types to help you choose between the two.
Local install is used for development, lab, and evaluation purposes. It unpacks all the application components (including docs and examples) and can be used by the engineer to run multiple, unrelated instances of NSO on a single workstation for different labs and demos.
Note
All the NSO examples and README steps provided with the installation are based on Local Install only. Use Local Install for evaluation and development purposes only.
System Install is used when installing NSO for a centralized, always-on, production-grade, system-wide deployment. It is configured as a system daemon that starts and ends with the underlying operating system. The default users of Admin and Operator are not included and the file structure is more distributed.
System Install should be used only for production deployment. For all other purposes, use Local Install.
Note
All the NSO examples and README steps are primarily intended for Local Install and cannot run on a System Install out of the box. To have the examples run on a System Install, you need to make certain modifications first, as described in the section called “Modify Examples for System Install”.
The installation process involves a number of activities that must be completed in the order shown below.
An overview of steps is given below.
Prepare |
1. Fulfill Installation Requirements |
Install | |
Finalize |
Start by setting up your system to install and run NSO.
To install NSO:
-
Fulfill at least the primary requirements.
-
If you intend to build and run NSO examples, you also need to install additional applications listed under Additional Requirements.
Primary requirements to do a Local Install include:
-
Linux for
x86_64
architecture is required for production. Linux or macOS Darwin forx86_64
or macOS Darwin forarm64
is required for development purposes. -
GNU libc 2.24 or higher.
-
Java JRE 17 or higher. Used by Cisco Smart Licensing.
-
Required and included with many Linux/macOS distributions:
-
tar command. Unpack the installer.
-
gzip command. Unpack the installer.
-
ssh-keygen command. Generate SSH hostkey.
-
openssl command. Generate self-signed certificates for HTTPS.
-
find command. Used to find out if all required libraries are available.
-
which command. Used by the NSO package manager.
-
libpam.so.0. Pluggable Authentication Module library.
-
libexpat.so.1. EXtensible Markup Language parsing library.
-
libz.so.1 version 1.2.7.1 or higher. Data compression library.
-
Additional requirements to, for example, build and run NSO examples, service, include:
-
Java JDK 17 or higher.
-
Ant 1.9.3 or higher.
-
Python 3.7 or higher.
-
Python Setuptools is required to build the Python API.
-
Often installed using the Python package installer pip:
-
Python Paramiko 2.2 or higher. To use netconf-console.
-
Python requests. Used by the RESTCONF demo scripts.
-
-
xsltproc command. Used by the support/ned-make-package-meta-data command to generate the package-meta-data.xml file.
-
One of the following web browsers is required for NSO GUI capabilities. The version must be supported by the vendor at the time of release.
-
Safari
-
Mozilla Firefox
-
Microsoft Edge
-
Google Chrome
-
-
OpenSSH client applications. For example ssh and scp commands.
To download the Cisco NSO installer and example NEDs:
-
Go to the Cisco's official Software Download site.
-
Search for product "Network Services Orchestrator" and select the desired version.
-
There are two versions of the NSO installer, i.e. for macOS and Linux systems. Download the desired installer.
You need to know your system specifications (Operating System and CPU architecture) in order to choose the appropriate NSO Installer.
NSO is delivered as an OS/CPU specific signed self-extractable archive. The signed archive file has the pattern
nso-VERSION.OS.ARCH.signed.bin
that after signature verification extracts the nso-VERSION.OS.ARCH.installer.bin
archive file, where:
-
VERSION
is the NSO version to install. -
OS
is the Operating System (linux
for all Linux distributions anddarwin
for macOS). -
ARCH
is the CPU architecture, for example,x86_64
.
If your downloaded file is a signed.bin
file, it means that it has been digitally signed by Cisco, and upon execution, you will verify the signature and unpack the
installer.bin
.
If you only have installer.bin
, skip to next step.
To unpack the installer:
-
In the terminal, list the binaries in the directory where you downloaded the installer, for example:
cd ~/Downloads ls -l nso*.bin -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.darwin.x86_64.installer.bin -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.darwin.x86_64.signed.bin
-
Use the
sh
command to run thesigned.bin
to verify the certificate and extract the installer binary and other files. An example output is shown below.sh nso-6.0.darwin.x86_64.signed.bin # Output Unpacking... Verifying signature... Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ... Successfully downloaded and verified crcam2.cer. Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ... Successfully downloaded and verified innerspace.cer. Successfully verified root, subca and end-entity certificate chain. Successfully fetched a public key from tailf.cer. Successfully verified the signature of nso-6.0.darwin.x86_64.installer.bin using tailf.cer
-
List the files to check if extraction was successful.
ls -l # Output -rw-r--r-- 1 user staff 1.8K Nov 29 06:05 README.signature -rw-r--r-- 1 user staff 12K Nov 29 06:05 cisco_x509_verify_release.py -rwxr-xr-x 1 user staff 199M Nov 29 05:55 nso-6.0.darwin.x86_64.installer.bin -rw-r--r-- 1 user staff 256B Nov 29 06:05 nso-6.0.darwin.x86_64.installer.bin.signature -rwxr-xr-x@ 1 user staff 199M Dec 15 11:45 nso-6.0.darwin.x86_64.signed.bin -rw-r--r-- 1 user staff 1.4K Nov 29 06:05 tailf.cer
The following contents are unpacked:
-
nso-VERSION.OS.ARCH.installer.bin
: The NSO installer. -
nso-VERSION.OS.ARCH.installer.bin.signature
: Signature generated for the NSO image. -
tailf.cer
: An enclosed Cisco signed x.509 end-entity certificate containing the public key that is used to verify the signature. -
README.signature
: File with further details on the unpacked content and steps on how to run the signature verification program. To manually verify the signature, refer to the steps in this file. -
cisco_x509_verify_release.py
: Python program that can be used to verify the 3-tier x.509 certificate chain and signature.
The NED Packages that are available with the NSO Installation are netsim-based example NEDs. These NEDs are used for NSO examples only.
Fetch the latest production-grade NEDs from Cisco Software Download using the URLs provided on your NED license certificates.
Run the sh nso-VERSION.darwin.x86_64.installer.bin --help
command to view additional help on running binaries. More details can be found in the ncs-installer(1) manual page included with NSO and also available from the online documentation on DevNet.
Notice the two options for --local-install
or --system-install
. An example output is shown below.
sh nso-6.0.darwin.x86_64.installer.bin --help # Output This is the NCS installation script. Usage: ./nso-6.0.darwin.x86_64.installer.bin [--local-install] LocalInstallDir Installs NCS in the LocalInstallDir directory only. This is convenient for test and development purposes. Usage: ./nso-6.0.darwin.x86_64.installer.bin --system-install [--install-dir InstallDir] [--config-dir ConfigDir] [--run-dir RunDir] [--log-dir LogDir] [--run-as-user User] [--keep-ncs-setup] [--non-interactive] Does a system install of NCS, suitable for deployment. Static files are installed in InstallDir/ncs-<vsn>. The first time --system-install is used, the ConfigDir, RunDir, and LogDir directories are also created and populated for config files, run-time state files, and log files, respectively, and an init script for start of NCS at system boot and user profile scripts are installed. Defaults are: InstallDir - /opt/ncs ConfigDir - /etc/ncs RunDir - /var/opt/ncs LogDir - /var/log/ncs By default, the system install will run NCS as the root user. If the --run-as-user option is given, the system install will instead run NCS as the given user. The user will be created if it does not already exist. If the --non-interactive option is given, the installer will proceed with potentially disruptive changes (e.g. modifying or removing existing files) without asking for confirmation.
Local Install of NSO Software is performed in a single user-specified directory, for example in your $HOME
directory. It is always recommended to install NSO in a directory named as the version of the release, for example, if the
version being installed is 6.0
, the directory should be ~/nso-6.0
.
To run the installer:
-
Navigate to your Install Directory.
-
Run the following command to install NSO in your Install Directory. The
--local-install
parameter is optional.$ sh nso-VERSION.OS.ARCH.installer.bin $HOME/ncs-VERSION --local-install
An example output is shown below.
sh nso-6.0.darwin.x86_64.installer.bin --local-install ~/nso-6.0 # Output INFO Using temporary directory /var/folders/90/n5sbctr922336_ 0jrzhb54400000gn/T//ncs_installer.93831 to stage NCS installation bundle INFO Unpacked ncs-6.0 in /Users/user/nso-6.0 INFO Found and unpacked corresponding DOCUMENTATION_PACKAGE INFO Found and unpacked corresponding EXAMPLE_PACKAGE INFO Found and unpacked corresponding JAVA_PACKAGE INFO Generating default SSH hostkey (this may take some time) INFO SSH hostkey generated INFO Environment set-up generated in /Users/user/nso-6.0/ncsrc INFO NSO installation script finished INFO Found and unpacked corresponding NETSIM_PACKAGE INFO NCS installation complete
The installation program unpacks the NSO manual pages from the documentation archive in $NCS_DIR/man
. ncsrc
makes an addition to $MANPATH
, allowing you to use the man
command to view them. The manual pages are also available in the PDF format and from the online documentation located on
NCS man-pages, Volume 1 in Manual Pages
.
Following is a list of few of the installed manual pages:
-
ncs(1): Command to start and control the NSO daemon.
-
ncsc(1): NSO Yang compiler.
-
ncs_cli(1): Frontend to the NSO CLI engine.
-
ncs-netsim(1): Command to create and manipulate a simulated network.
-
ncs-setup(1): Command to create an initial NSO setup.
-
ncs.conf: NSO daemon configuration file format.
For example, to view the manual page describing NSO configuration file you should type:
$ man ncs.conf
Apart from the manual pages, extensive information about command line options can be obtained by running ncs
and ncsc
with the --help
(abbreviated -h
) flag.
$ ncs --help
$ ncsc --help
The installation program creates a shell script file named ncsrc
in each NSO installation, which sets the environment variables.
To set the environment variables:
-
Source the
ncsrc
file to get the environment variables settings in your shell. You may want to add this sourcing command to your login sequence, such as.bashrc
.For
csh/tcsh
users, there is ancsrc.tcsh
file withcsh/tcsh
syntax. The example below assumes that you are usingbash
, other versions of/bin/sh
may require that you use.
instead ofsource
.$ source $HOME/ncs-VERSION/ncsrc
-
Most users add source
~/nso-x.x/ncsrc
(where x.x is the NSO version) to their~/.bash_profile
, but you can simply do it manually when you want it.Once it has been sourced, you have access to all the NSO executable commands, which start with
ncs
.ncs {TAB} {TAB} # Output ncs ncs-maapi ncs-project ncs-start-python-vm ncs_cmd ncs-backup ncs-make-package ncs-setup ncs-uninstall ncs_conf_tool ncs-collect ncs-netsim ncs-start-java-vm ncs_cli ncs_load ncsc ncs_crypto_keys-tech-report
NSO needs a Deployment/Runtime Directory where the database files, logs, etc. are stored. An empty default directory can be
created using the ncs-setup
command.
To create a Runtime Directory:
-
Create a Runtime Directory for NSO by running the following command. In this case, we assume that the directory is
$HOME/ncs-run
.$ ncs-setup --dest $HOME/ncs-run
-
Start the NSO daemon
ncs
.$ cd $HOME/ncs-run $ ncs
A common misunderstanding is that there exists a dependency between the Runtime Directory and the Installation
Directory. This is not true. For example, say that you have two NSO installations .../ncs-2.3.1
and .../ncs-2.3.2
. The following sequence runs ncs-2.3.1
but using an example and configuration from ncs-2.3.2
.
$ cd .../ncs-2.3.1 $ . ncsrc $ cd .../ncs-2.3.2/examples.ncs/datacenter-qinq $ ncs
Since the Runtime Directory is self-contained, this is also the way to move between examples. And since the Runtime Directory is self-contained including the database files, you can compress a complete directory and distribute it. Unpacking that directory and starting NSO from there gives an exact copy of all instance data.
$ cd $NCS_DIR/examples.ncs/data-center-qinq $ ncs $ ncs --stop $ cd $NCS_DIR/examples.ncs/getting-started/1-simulated-cisco-ios $ ncs $ ncs --stop
To conclude the NSO installation, a license registration token must be created using a (CSSM) account. This is because NSO uses Cisco Smart Licensing, as described in Cisco Smart Licensing in Administration Guide to make it easy to deploy and manage NSO license entitlements. Login credentials to Cisco Smart Software Manager (CSSM) account are provided by your Cisco contact and detailed instructions on how to create a registration token can be found in Cisco Smart Licensing in Administration Guide. General licensing information covering licensing models, how licensing works, usage compliance, etc., is covered in the Cisco Software Licensing Guide.
To generate a license registration token:
-
When you have a token, start a Cisco CLI towards NSO and enter the token, for example:
admin@ncs# license smart register idtoken YzIzMDM3MTgtZTRkNC00YjkxLTk2ODQt OGEzMTM3OTg5MG Registration process in progress. Use the 'show license status' command to check the progress and result.
Upon successful registration, NSO automatically requests a license entitlement for its own instance and for the number of devices it orchestrates and their NED types. If development mode has been enabled, only development entitlement for the NSO instance itself is requested.
-
Inspect the requested entitlements using the command
show license all
(or by inspecting the NSO daemon log). An example output is shown below.admin@ncs# show license all ... <INFO> 21-Apr-2016::11:29:18.022 miosaterm confd[8226]: Smart Licensing Global Notification: type = "notifyRegisterSuccess", agentID = "sa1", enforceMode = "notApplicable", allowRestricted = false, failReasonCode = "success", failMessage = "Successful." <INFO> 21-Apr-2016::11:29:23.029 miosaterm confd[8226]: Smart Licensing Entitlement Notification: type = "notifyEnforcementMode", agentID = "sa1", notificationTime = "Apr 21 11:29:20 2016", version = "1.0", displayName = "regid.2015-10.com.cisco.NSO-network-element", requestedDate = "Apr 21 11:26:19 2016", tag = "regid.2015-10.com.cisco.NSO-network-element", enforceMode = "inCompliance", daysLeft = 90, expiryDate = "Jul 20 11:26:19 2016", requestedCount = 8 ...
If no registration token is provided, NSO enters a 90 days evaluation period and the remaining evaluation time is recorded hourly in the NSO daemon log:
... <INFO> 13-Apr-2016::13:22:29.178 miosaterm confd[16260]: Starting the NCS Smart Licensing Java VM <INFO> 13-Apr-2016::13:22:34.737 miosaterm confd[16260]: Smart Licensing evaluation time remaining: 90d 0h 0m 0s ... <INFO> 13-Apr-2016::13:22:34.737 miosaterm confd[16260]: Smart Licensing evaluation time remaining: 89d 23h 0m 0s ...
During upgrades, if you experience the 'Communication Send Error' with license registration, restart the Smart Agent.
In a situation where NSO instance has no direct access to the Cisco Smart Software Manager, one option is Cisco Smart Software Manager Satellite that can be installed to manage software licenses on the premises. Install the satellite and use the command call-home destination address http <url:port>
to point to the satellite.
Another option when direct access is not desired is to configure an HTTP or HTTPS proxy, e.g., smart-license smart-agent proxy url https://127.0.0.1:8080
. If you plan to do this, take the note below regarding ignored CLI configurations into account:
If ncs.conf
contains configuration for any of java-executable, java-options, override-url/url or proxy/url under the configure path /ncs-config/smart-license/smart-agent/
, then any corresponding configuration done via the CLI is ignored.
When configuring NSO in HA mode, the license registration token must be provided to the CLI running on the primary node. Read more about HA and node types in NSO High Availability in Administration Guide.
Licensing activities are also logged in the NSO daemon log as described in the section called “Monitoring NSO” in Administration Guide. For example, a successful token registration results in the following log entry:
<INFO> 21-Apr-2016::11:29:18.022 miosaterm confd[8226]: Smart Licensing Global Notification: type = "notifyRegisterSuccess"
To check registration status, use the command show license status
An example output is shown below..
admin@ncs# show license status Smart Licensing is ENABLED Registration: Status: REGISTERED Smart Account: Network Service Orchestrator Virtual Account: Default Export-Controlled Functionality: Allowed Initial Registration: SUCCEEDED on Apr 21 09:29:11 2016 UTC Last Renewal Attempt: SUCCEEDED on Apr 21 09:29:16 2016 UTC Next Renewal Attempt: Oct 18 09:29:16 2016 UTC Registration Expires: Apr 21 09:26:13 2017 UTC Export-Controlled Functionality: Allowed License Authorization: License Authorization: Status: IN COMPLIANCE on Apr 21 09:29:18 2016 UTC Last Communication Attempt: SUCCEEDED on Apr 21 09:26:30 2016 UTC Next Communication Attempt: Apr 21 21:29:32 2016 UTC Communication Deadline: Apr 21 09:26:13 2017 UTC
Before staring NSO, it is recommended to explore the installation contents.
Navigate to the newly created Installation Directory, for example:
cd ~/nso-6.0
The Installation Directory includes the following contents:
-
Documentation
-
Examples
-
Network Element Drivers
-
Shell scripts
Along with the binaries, NSO installs a full set of documentation available in the in the doc/
folder in the Installation Directory. There is also an online version of the documentation available on DevNet.
ls -l doc/ drwxr-xr-x 5 user staff 160B Nov 29 05:19 api/ drwxr-xr-x 14 user staff 448B Nov 29 05:19 html/ -rw-r--r-- 1 user staff 202B Nov 29 05:19 index.html drwxr-xr-x 17 user staff 544B Nov 29 05:19 pdf/
Run index.html
in your browser to explore further.
Local Install comes with a rich set of examples to start using NSO.
$ ls -1 examples.ncs/ README crypto datacenter development-guide generic-ned getting-started misc service-provider snmp-ned snmp-notification-receiver web-server-farm web-ui
In order to communicate with the network, NSO uses NEDs as device drivers for different device types. Cisco has NEDs for hundreds
of different devices available for customers, and several are included in the installer in the /packages/neds
directory.
In the example below, NEDs for Cisco ASA, IOS, IOS XR, and NX-OS are shown. Also included are NEDs for other vendors including Juniper JunOS, A10, ALU, and Dell.
$ ls -1 packages/neds a10-acos-cli-3.0 alu-sr-cli-3.4 cisco-asa-cli-6.6 cisco-ios-cli-3.0 cisco-ios-cli-3.8 cisco-iosxr-cli-3.0 cisco-iosxr-cli-3.5 cisco-nx-cli-3.0 dell-ftos-cli-3.0 juniper-junos-nc-3.0
Note
The example NEDs included in the installer are intended for evaluation, demonstration, and use with the examples.ncs
. These are not the latest versions available, and often do not have all the features available in production NEDs.
A large number of pre-built supported NEDs are available which can be acquired and downloaded by the customers from Cisco Software Download. Note that the specific file names and versions that you download may be different from the ones in this guide. Therefore, remember to update the paths accordingly.
Like the NSO installer, the NEDs are signed.bin
files that need to be run to validate the download and extract the new code.
To install new NEDs:
-
Change to the working directory where your downloads are. The filenames indicate which version of NSO the NEDs are pre-compiled for (in this case NSO 6.0), and the version of the NED. An example output is shown below.
cd ~/Downloads/ ls -l ncs*.bin # Output -rw-r--r--@ 1 user staff 9708091 Dec 18 12:05 ncs-6.0-cisco-asa-6.7.7.signed.bin -rw-r--r--@ 1 user staff 51233042 Dec 18 12:06 ncs-6.0-cisco-ios-6.42.1.signed.bin -rw-r--r--@ 1 user staff 8400190 Dec 18 12:05 ncs-6.0-cisco-nx-5.13.1.1.signed.bin
-
Use the
sh
command to runsigned.bin
to verify the certificate and extract the NED tar.gz and other files. Repeat for all files. An example output is shown below.sh ncs-6.0-cisco-nx-5.13.1.1.signed.bin
Unpacking... Verifying signature... Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ... Successfully downloaded and verified crcam2.cer. Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ... Successfully downloaded and verified innerspace.cer. Successfully verified root, subca and end-entity certificate chain. Successfully fetched a public key from tailf.cer. Successfully verified the signature of ncs-6.0-cisco-nx-5.13.1.1.tar.gz using tailf.cer
-
You now have 3 tar (.tar.gz) files. These are compressed versions of the NEDs. List the files to verify as shown in the example below.
ls -l ncs*.tar.gz -rw-r--r-- 1 user staff 9704896 Dec 12 21:11 ncs-6.0-cisco-asa-6.7.7.tar.gz -rw-r--r-- 1 user staff 51260488 Dec 13 22:58 ncs-6.0-cisco-ios-6.42.1.tar.gz -rw-r--r-- 1 user staff 8409288 Dec 18 09:09 ncs-6.0-cisco-nx-5.13.1.1.tar.gz
-
Navigate to the
packages/neds
directory for your Local Install, for example:cd ~/nso-6.0/packages/neds
-
In the
/packages/neds
directory, extract the .tar files into this directory using thetar
command with the path to where the compressed NED is located. An example is shown below.tar -zxvf ~/Downloads/ncs-6.0-cisco-nx-5.13.1.1.tar.gz tar -zxvf ~/Downloads/ncs-6.0-cisco-ios-6.42.1.tar.gz tar -zxvf ~/Downloads/ncs-6.0-cisco-asa-6.7.7.tar.gz
Here is a sample list of the newer NEDs extracted along with the ones bundled with the installation:
drwxr-xr-x 13 user staff 416 Nov 29 05:17 a10-acos-cli-3.0 drwxr-xr-x 12 user staff 384 Nov 29 05:17 alu-sr-cli-3.4 drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-asa-cli-6.6 drwxr-xr-x 13 user staff 416 Dec 12 21:11 cisco-asa-cli-6.7 drwxr-xr-x 12 user staff 384 Nov 29 05:17 cisco-ios-cli-3.0 drwxr-xr-x 12 user staff 384 Nov 29 05:17 cisco-ios-cli-3.8 drwxr-xr-x 13 user staff 416 Dec 13 22:58 cisco-ios-cli-6.42 drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-iosxr-cli-3.0 drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-iosxr-cli-3.5 drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-nx-cli-3.0 drwxr-xr-x 14 user staff 448 Dec 18 09:09 cisco-nx-cli-5.13 drwxr-xr-x 13 user staff 416 Nov 29 05:17 dell-ftos-cli-3.0 drwxr-xr-x 10 user staff 320 Nov 29 05:17 juniper-junos-nc-3.0
The last thing to note are the files ncsrc
and ncsrc.tsch
. These are shell scripts for bash and tsch that setup your PATH and other environment variables for NSO. Depending on your
shell, you need to source this file before starting NSO.
For more information on sourcing shell script, see the Local Install steps.
The command ncs -h
shows various options when starting NSO. By default, NSO starts in the background without an associated terminal. It is recommended
to add NSO to the /etc/init
scripts of the deployment hosts. For more information, see the ncs(1) in Manual Pages
.
Whenever you start (or reload) the NSO daemon, it reads its configuration from ./ncs.conf
or ${NCS_DIR}/etc/ncs/ncs.conf
or from the file specified with the -c
option.
$ ncs $ ncs --stop $ ncs -h ...
If you intend to use your NSO instance for development purposes, enable the development mode using the command license smart development enable
.
One of the included scripts with an NSO installation is ncs-setup
, which makes it very easy to create instances of NSO from a Local Install. You can look at the --help
or ncs-setup(1) in Manual Pages
for more details, but the two options we need to know are:
-
--dest
defines the directory where you want to set up NSO. if the directory does not exist, it will be created. -
--package
defines the NEDs that you want to have installed. You can specify this option multiple times.
Note
NCS is the original name of the NSO product. Therefore, many of the commands and application features are prefaced with ncs
. You can think of NCS as another name for NSO.
To create an NSO instance:
-
Run the command to set up an NSO instance in the current directory with the IOS, NX-OS, IOS-XR and ASA NEDs. You only need one NED per platform that you want NSO to manage, even if you may have multiple versions in your installer
neds
directory.Use the name of the NED folder in
${NCS_DIR}/packages/neds
for the latest NED version that you have installed for the target platform. Use the tab key to complete the path, after you start typing (alternatively, copy and paste). Verify that the NED versions below match what is currently on the sandbox to avoid a syntax error. See example below.ncs-setup --package ~/nso-6.0/packages/neds/cisco-ios-cli-6.44 \ --package ~/nso-6.0/packages/neds/cisco-nx-cli-5.15 \ --package ~/nso-6.0/packages/neds/cisco-iosxr-cli-7.20 \ --package ~/nso-6.0/packages/neds/cisco-asa-cli-6.8 \ --dest nso-instance
-
Check the
nso-instance
directory. Notice that several new files and folders are created.$ ls nso-instance/ logs ncs-cdb ncs.conf packages README.ncs scripts state $ ls -l nso-instance/packages/ total 0 lrwxrwxrwx 1 user docker 51 Mar 19 12:44 cisco-asa-cli-6.8 -> /home/user/nso-6.0/packages/neds/cisco-asa-cli-6.8 lrwxrwxrwx 1 user docker 52 Mar 19 12:44 cisco-ios-cli-6.44 -> /home/user/nso-6.0/packages/neds/cisco-ios-cli-6.44 lrwxrwxrwx 1 user docker 54 Mar 19 12:44 cisco-iosxr-cli-7.20 -> /home/user/nso-6.0/packages/neds/cisco-iosxr-cli-7.20 lrwxrwxrwx 1 user docker 51 Mar 19 12:44 cisco-nx-cli-5.15 -> /home/user/nso-6.0/packages/neds/cisco-nx-cli-5.15 $
Following is a description of the important files and folders:
-
ncs.conf
is the NSO application configuration file, and is used to customize aspects of the NSO instance (for example, to change ports, enable/disable features, and so on.) See ncs.conf(5) in Manual Pages for information. -
packages/
is the directory that has symlinks to the NEDs that we referenced in the--package
arguments at time of setup. See NSO Packages in Development Guide for more information. -
logs/
is the directory that contains all the logs from NSO. This directory is useful for troubleshooting.
-
-
Start the NSO instance by navigating to the
nso-instance
directory and typing thencs
command .You must be situated in the
nso-instance
directory each time you want to start or stop NSO. If you have multiple instances, you need to navigate to each one and use thencs
command to start or stop each one. -
Verify that NSO is running by using the
ncs --status | grep status
command.$ ncs --status | grep status status: started db=running id=31 priority=1 path=/ncs:devices/device/live-status-protocol/device-type
-
Add Netsim or lab devices using the command
ncs-netsim -h
.
If you already have a Local Install with existing data that you would like to convert into a System Install, the following procedure allows you to do so. However, a reverse migration from System to Local Install is not supported.
Note
It is possible to perform the migration and upgrade simultaneously to a newer NSO version, however, doing so introduces additional complexity. If you run into issues, first do the migration, and then perform the upgrade.
The following procedure assumes that NSO is installed as described in the NSO Local Install process, and will perform an initial System Install of the same NSO version. After following these steps, consult the NSO System Install guide for additional steps that are required for a fully functional System Install.
The procedure also assumes you are using the $HOME/ncs-run
folder as the Run Directory. If this is not the case, modify the following path accordingly.
To migrate to System Install:
-
Stop the current (local) NSO instance, if it is running.
$ ncs --stop
-
Take a complete backup of the Runtime Directory for potential disaster recovery.
$ tar -czf $HOME/ncs-backup.tar.gz -C $HOME ncs-run
-
Change to Super User privileges.
$ sudo -s
-
Start the NSO System Install.
$ sh nso-VERSION.OS.ARCH.installer.bin --system-install
-
If you have multiple versions of NSO installed, verify that the symbolic link in
/opt/ncs
points to the correct version. -
Copy the CDB files containing data to the central location.
# cp $HOME/ncs-run/ncs-cdb/*.cdb /var/opt/ncs/cdb
-
Ensure that the
/var/opt/ncs/packages
directory includes all the necessary packages, appropriate for the NSO version. However, copying the packages directly could later on interfere with the operation of thenct
command. It is better to only use symbolic links in that folder. Instead, copy the existing packages to the/opt/ncs/packages
directory, either as directories or as tarball files. Make sure that each package includes the NSO version in its name and is not just a symlink, for example:# cd $HOME/ncs-run/packages # for pkg in *; do cp -RL $pkg /opt/ncs/packages/ncs-VERSION-$pkg; done
-
Link to these packages in the
/var/opt/ncs/packages
directory.# cd /var/opt/ncs/packages/ # rm -f * # for pkg in /opt/ncs/packages/ncs-VERSION-*; do ln -s $pkg; done
The reason for prepending
ncs-VERSION
to the filename is to allow additional NSO commands, such asnct upgrade
andsoftware packages
to work properly. These commands need to identify which NSO version a package was compiled for. -
Edit the
/etc/ncs/ncs.conf
configuration file and make the necessary changes. If you wish to use the configuration from Local Install, disable the local authentication, unless you fully understand its security implications.<local-authentication> <enabled>false</enabled> </local-authentication>
-
When starting NSO later on, make sure that you set the package reload option, or use
start-with-package-reload
instead ofstart
with/etc/init.d/ncs
.# export NCS_RELOAD_PACKAGES=true
-
Review and complete the steps in NSO System Install, except running the installer, which you have done already. Once completed, you should have a running NSO instance with data from the Local Install.
-
Remove the package reload option if it was set.
# unset NCS_RELOAD_PACKAGES
-
Update log file paths for Java and Python VM through the NSO CLI.
$ ncs_cli -C -u admin admin@ncs# config Entering configuration mode terminal admin@ncs(config)# unhide debug admin@ncs(config)# show full-configuration java-vm stdout-capture file java-vm stdout-capture file ./logs/ncs-java-vm.log admin@ncs(config)# java-vm stdout-capture file /var/log/ncs/ncs-java-vm.log admin@ncs(config)# commit Commit complete. admin@ncs(config)# show full-configuration java-vm stdout-capture file java-vm stdout-capture file /var/log/ncs/ncs-java-vm.log admin@ncs(config)# show full-configuration python-vm logging log-file-prefix python-vm logging log-file-prefix ./logs/ncs-python-vm admin@ncs(config)# python-vm logging log-file-prefix /var/log/ncs/ncs-python-vm admin@ncs(config)# commit Commit complete. admin@ncs(config)# show full-configuration python-vm logging log-file-prefix python-vm logging log-file-prefix /var/log/ncs/ncs-python-vm admin@ncs(config)# exit admin@ncs# admin@ncs# exit
-
Verify that everything is working correctly.
At this point you should have a complete copy of the previous Local Install running as a System Install. Should the migration fail at some point and you want to back out of it, the Local Install was not changed and you can easily go back to using it as before.
$ sudo /etc/init.d/ncs stop $ source $HOME/ncs-VERSION/ncsrc $ cd $HOME/ncs-run $ ncs
In the unlikely event of Local Install becoming corrupted, you can restore it from the backup.
$ rm -rf $HOME/ncs-run $ tar -xzf $HOME/ncs-backup.tar.gz -C $HOME
To uninstall Local Install, delete the Install Directory.
The installation process involves a number of activities that must be completed in the order shown below.
An overview of steps is given below.
Prepare |
1. Fulfill Installation Requirements |
Install | |
Finalize |
Start by setting up your system to install and run NSO.
To install NSO:
-
Fulfill at least the primary requirements.
-
If you intend to build and run NSO deployment examples, you also need to install additional applications listed under Additional Requirements.
Primary requirements to do a System Install include:
-
Linux for
x86_64
architecture is required for production. Linux or macOS Darwin forx86_64
or macOS Darwin forarm64
is required for development purposes. -
GNU libc 2.24 or higher.
-
Java JRE 17 or higher. Used by Cisco Smart Licensing.
-
Required and included with many Linux/macOS distributions:
-
tar command. Unpack the installer.
-
gzip command. Unpack the installer.
-
ssh-keygen command. Generate SSH hostkey.
-
openssl command. Generate self-signed certificates for HTTPS.
-
find command. Used to find out if all required libraries are available.
-
which command. Used by the NSO package manager.
-
libpam.so.0. Pluggable Authentication Module library.
-
libexpat.so.1. EXtensible Markup Language parsing library.
-
libz.so.1 version 1.2.7.1 or higher. Data compression library.
-
Additional requirements to, for example, build and run NSO production deployment examples, include:
-
Java JDK 17 or higher.
-
Ant 1.9.3 or higher.
-
Python 3.7 or higher.
-
Python Setuptools is required to build the Python API.
-
Often installed using the Python package installer pip:
-
Python Paramiko 2.2 or higher. To use netconf-console.
-
Python requests. Used by the RESTCONF demo scripts.
-
-
xsltproc command. Used by the support/ned-make-package-meta-data command to generate the package-meta-data.xml file.
-
One of the following web browsers is required for NSO GUI capabilities. The version must be supported by the vendor at the time of release.
-
Safari
-
Mozilla Firefox
-
Microsoft Edge
-
Google Chrome
-
-
OpenSSH client applications. For example ssh and scp commands.
-
cron. Run time-based tasks, such as logrotate.
-
logrotate. rotate, compress, and mail NSO and system logs.
-
rsyslog. pass NSO logs to a local syslog managed by rsyslogd and pass logs to a remote node.
-
systemd or init.d scripts to start and stop NSO.
To download the Cisco NSO installer and example NEDs:
-
Go to the Cisco's official Software Download site.
-
Search for product "Network Services Orchestrator" and select the desired version.
-
There are two versions of the NSO installer, i.e. for macOS and Linux systems. For System Install, choose the Linux OS version.
You need to know your system specifications (Operating System and CPU architecture) in order to choose the appropriate NSO Installer.
NSO is delivered as an OS/CPU specific signed self-extractable archive. The signed archive file has the pattern
nso-VERSION.OS.ARCH.signed.bin
that after signature verification extracts the nso-VERSION.OS.ARCH.installer.bin
archive file, where:
-
VERSION
is the NSO version to install. -
OS
is the Operating System (linux
for all Linux distributions anddarwin
for macOS). -
ARCH
is the CPU architecture, for example,x86_64
.
If your downloaded file is a signed.bin
file, it means that it has been digitally signed by Cisco, and upon execution, you will verify the signature and unpack the
installer.bin
.
If you only have installer.bin
, skip to next step.
To unpack the installer:
-
In the terminal, list the binaries in the directory where you downloaded the installer, for example:
cd ~/Downloads ls -l nso*.bin -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.linux.x86_64.installer.bin -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.linux.x86_64.signed.bin
-
Use the
sh
command to run thesigned.bin
to verify the certificate and extract the installer binary and other files. An example output is shown below.sh nso-6.0.linux.x86_64.signed.bin # Output Unpacking... Verifying signature... Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ... Successfully downloaded and verified crcam2.cer. Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ... Successfully downloaded and verified innerspace.cer. Successfully verified root, subca and end-entity certificate chain. Successfully fetched a public key from tailf.cer. Successfully verified the signature of nso-6.0.linux.x86_64.installer.bin using tailf.cer
-
List the files to check if extraction was successful.
ls -l # Output -rw-r--r-- 1 user staff 1.8K Nov 29 06:05 README.signature -rw-r--r-- 1 user staff 12K Nov 29 06:05 cisco_x509_verify_release.py -rwxr-xr-x 1 user staff 199M Nov 29 05:55 nso-6.0.linux.x86_64.installer.bin -rw-r--r-- 1 user staff 256B Nov 29 06:05 nso-6.0.linux.x86_64.installer.bin.signature -rwxr-xr-x@ 1 user staff 199M Dec 15 11:45 nso-6.0.linux.x86_64.signed.bin -rw-r--r-- 1 user staff 1.4K Nov 29 06:05 tailf.cer
The following contents are unpacked:
-
nso-VERSION.OS.ARCH.installer.bin
: The NSO installer. -
nso-VERSION.OS.ARCH.installer.bin.signature
: Signature generated for the NSO image. -
tailf.cer
: An enclosed Cisco signed x.509 end-entity certificate containing the public key that is used to verify the signature. -
README.signature
: File with further details on the unpacked content and steps on how to run the signature verification program. To manually verify the signature, refer to the steps in this file. -
cisco_x509_verify_release.py
: Python program that can be used to verify the 3-tier x.509 certificate chain and signature.
The NED Packages that are available with the NSO Installation are netsim-based example NEDs. These NEDs are used for NSO examples only.
Fetch the latest production-grade NEDs from Cisco Software Download using the URLs provided on your NED license certificates.
Run the sh nso-VERSION.linux.x86_64.installer.bin --help
command to view additional help on running binaries. More details can be found in the ncs-installer(1) manual page included with NSO and also available from the online documentation on DevNet.
Notice the two options for --local-install
or --system-install
.
sh nso-6.0.linux.x86_64.installer.bin --help
To run the installer:
-
Navigate to your Install Directory.
-
Run the installer with
--system-install
option to perform System Install. This option creates an Install of NSO that is suitable for deployment.$ sudo sh nso-VERSION.OS.ARCH.installer.bin --system-install
For example:
$ sudo sh nso-6.0.linux.x86_64.installer.bin --system-install
The System Install by default creates the following directories:
-
The Installation Directory is created in
/opt/ncs
, where the distribution is available. -
The Configuration Directory is created in
/etc/ncs
, where thencs.conf
file, SSH keys, WebUI certificates are created. -
The Running Directory is created in
/var/opt/ncs
, where runtime state files, CDB database, and packages are created. -
The Log Directory is created in
/var/log/ncs
, where the log files are populated. Also, init scripts are created in/etc/init.d/ncs
and system-wide environment variables are created in/etc/profile.d/ncs.sh
.
For the --system-install
option, you can also choose user-defined (non-default) Installation Directory, Configuration Directory, Running Directory,
and Log Directory with --install-dir
, --config-dir
, --run-dir
and --log-dir
parameters, and specify that NSO should run as a different user than root with the --run-as-user
parameter.
If you choose a non-default Installation Directory by using --install-dir
, you need to specify --install-dir
for subsequent installs and also for backup and restore.
For more information on ncs-installer
, see the ncs-installer(1) man page.
For an extensive guide to NSO deployment, refer to Deployment Example in Administration Guide.
The installation program will unpack the NSO manual pages from the documentation archive, allowing you to use
the man
command to view them. The manual pages are also available in the PDF format and from the online documentation located on
NCS man-pages, Volume 1 in Manual Pages
Following is a list of few of the installed manual pages:
-
ncs(1): Command to start and control the NSO daemon.
-
ncsc(1): NSO Yang compiler.
-
ncs_cli(1): Frontend to the NSO CLI engine.
-
ncs-netsim(1): Command to create and manipulate a simulated network.
-
ncs-setup(1): Command to create an initial NSO setup.
-
ncs.conf: NSO daemon configuration file format.
For example, to view the manual page describing NSO configuration file you should type:
$ man ncs.conf
Apart from the manual pages, extensive information about command line options can be obtained by running ncs
and ncsc
with the --help
(abbreviated -h
) flag.
$ ncs --help
$ ncsc --help
By default, the Linux kernel allows overcommit of memory. However, memory overcommit produces an unexpected and unreliable environment for NSO since the Linux Out Of Memory Killer, or OOM-killer, may terminate NSO without restarting it if the system is critically low on memory. Also, when the OOM-killer terminates NSO, no system dump file will be produced, and the debug information will be lost. Thus, it is strongly recommended that overcommit is disabled.
To achieve this with immediate effect, give the command:
# echo 2 > /proc/sys/vm/overcommit_memory
When overcommit_memory = 2
, the
/proc/sys/vm/overcommit_ratio
parameter defines
the percent of the physical RAM + swap space used. The default
is "50", or 50%. This setting will underutilize RAM usage if the
system has more physical RAM than 50%.
Setting the overcommit_ratio
parameter to "100"
will include any swap if present. On-disk memory (swap)
gives the advantage of having more memory available in case
an application needs more RAM than physically available
momentarily. But it is usually slow, and thus best practice
is to refrain from using the swap for NSO. To allocate
physical RAM only, set the overcommit_ratio
parameter to 100 * ((RAM - swap space) / RAM).
If the system's physical RAM (MemTotal) is less than or equal
to the swap space (SwapTotal), using the swap cannot be
avoided and the overcommit_ratio
should be set
to '100'.
Example 1 - physical RAM (MemTotal) > swap space (SwapTotal):
# cat /proc/meminfo | grep "MemTotal\|SwapTotal" MemTotal: 8039352 kB SwapTotal: 1048572 kB
Calculate the overcommit ratio:
100 * ((8039352-1048572)/8039352) = ~86.9%
To set both overcommit parameters with immediate effect:
# echo 2 > /proc/sys/vm/overcommit_memory # echo 86.9 > /proc/sys/vm/overcommit_ratio
Example 2 - physical RAM (MemTotal) == swap space (SwapTotal):
# cat /proc/meminfo | grep "MemTotal\|SwapTotal" MemTotal: 16000000 kB SwapTotal: 16000000 kB
To set both overcommit parameters with immediate effect:
# echo 2 > /proc/sys/vm/overcommit_memory # echo 100 > /proc/sys/vm/overcommit_ratio
To ensure the overcommit remains disabled after reboot,
adjust the overcommit_ratio
parameter to match
your system memory and add the two lines to the
/etc/sysctl.conf
file. See the Linux
sysctl.conf(5)
manual page for details.
Refer to the Linux
proc(5)
manual page for more details on the
overcommit_memory
and
overcommit_ratio
parameters.
Note
If NSO aborts due to failure to allocate memory,
NSO will produce a system dump by default before
aborting. When starting NSO from a non-root user,
set the NCS_DUMP
environment variable to point
to a filename in a directory that the non-root user can
access. The default setting is
NCS_DUMP=ncs_crash.dump
, where the file is
written to the NSO run-time directory, typically
NCS_RUN_DIR=/var/opt/ncs
. If the user running
NSO cannot write to the directory the
NCS_DUMP
environment variable points to,
generating the system dump file will fail, and the debug
information will be lost.
The installation is configured for PAM authentication, with group assignment based on the OS group database
(e.g. /etc/group
file). Users that need access to NSO must belong to either the ncsadmin
group (for unlimited access rights) or the ncsoper
group (for minimal access rights).
To set up user access:
-
To create the
ncsadmin
group, use the OS shell command:# groupadd ncsadmin
-
To create the
ncsoper
group, use the OS shell command:# groupadd ncsoper
-
To add an existing user to one of these groups, use the OS shell command:
# usermod -a -G 'groupname' 'username'
To set environment variables:
-
Change to Super User privileges.
$ sudo -s
-
The installation program creates a shell script file in each NSO installation which sets environment variables needed to run NSO. With the
--system-install
option, by default, these settings are set on the shell. To explicitly set the variables, sourcencs.sh
orncs.csh
depending on your shell type.# source /etc/profile.d/ncs.sh
-
Start NSO.
# /etc/init.d/ncs start
Once you log on with the user that belongs to
ncsadmin
orncsoper
, you can directly access the CLI as shown below:$ ncs_cli -C
As part of the System Install, the NSO daemon ncs
is automatically started at boot time. You do not need to create a Runtime Directory for System Install.
To conclude the NSO installation, a license registration token must be created using a (CSSM) account. This is because NSO uses Cisco Smart Licensing, as described in Cisco Smart Licensing in Administration Guide to make it easy to deploy and manage NSO license entitlements. Login credentials to Cisco Smart Software Manager (CSSM) account are provided by your Cisco contact and detailed instructions on how to create a registration token can be found in Cisco Smart Licensing in Administration Guide. General licensing information covering licensing models, how licensing works, usage compliance, etc., is covered in the Cisco Software Licensing Guide.
To generate license registration token:
-
When you have a token, start a Cisco CLI towards NSO and enter the token, for example:
admin@ncs# license smart register idtoken YzIzMDM3MTgtZTRkNC00YjkxLTk2ODQtOGEzMTM3OTg5MG Registration process in progress. Use the 'show license status' command to check the progress and result.
Upon successful registration, NSO automatically requests a license entitlement for its own instance and for the number of devices it orchestrates and their NED types. If development mode has been enabled, only development entitlement for the NSO instance itself is requested.
-
Inspect the requested entitlements using the command
show license all
(or by inspecting the NSO daemon log). An example output is shown below.admin@ncs# show license all ... <INFO> 21-Apr-2016::11:29:18.022 miosaterm confd[8226]: Smart Licensing Global Notification: type = "notifyRegisterSuccess", agentID = "sa1", enforceMode = "notApplicable", allowRestricted = false, failReasonCode = "success", failMessage = "Successful." <INFO> 21-Apr-2016::11:29:23.029 miosaterm confd[8226]: Smart Licensing Entitlement Notification: type = "notifyEnforcementMode", agentID = "sa1", notificationTime = "Apr 21 11:29:20 2016", version = "1.0", displayName = "regid.2015-10.com.cisco.NSO-network-element", requestedDate = "Apr 21 11:26:19 2016", tag = "regid.2015-10.com.cisco.NSO-network-element", enforceMode = "inCompliance", daysLeft = 90, expiryDate = "Jul 20 11:26:19 2016", requestedCount = 8 ...
If no registration token is provided, NSO enters a 90 days evaluation period and the remaining evaluation time is recorded hourly in the NSO daemon log:
... <INFO> 13-Apr-2016::13:22:29.178 miosaterm confd[16260]: Starting the NCS Smart Licensing Java VM <INFO> 13-Apr-2016::13:22:34.737 miosaterm confd[16260]: Smart Licensing evaluation time remaining: 90d 0h 0m 0s ... <INFO> 13-Apr-2016::13:22:34.737 miosaterm confd[16260]: Smart Licensing evaluation time remaining: 89d 23h 0m 0s ...
During upgrades, If you experience 'Communication Send Error' during license registration, restart the Smart Agent.
In a situation where NSO instance has no direct access to the Cisco Smart Software Manager, one option is
Cisco Smart Software Manager Satellite that can be installed to manage software licenses on the premises. Install the satellite and use the command call-home destination address http <url:port>
to point to the satellite.
Another option when direct access is not desired is to configure an HTTP or HTTPS proxy, e.g., smart-license smart-agent proxy url https://127.0.0.1:8080
. If you plan to do this, take the note below regarding ignored CLI configurations into account:
If ncs.conf
contains configuration for any of java-executable, java-options, override-url/url or proxy/url under the configure path /ncs-config/smart-license/smart-agent/
, then any corresponding configuration done via the CLI is ignored.
When configuring NSO in High Availability (HA) mode, the license registration token must be provided to the CLI running on the primary node. Read more about HA and node types in High Availability in Administration Guide.
Licensing activities are also logged in the NSO daemon log as described in the section called “Monitoring NSO” in Administration Guide. For example, a successful token registration results in the following log entry:
<INFO> 21-Apr-2016::11:29:18.022 miosaterm confd[8226]: Smart Licensing Global Notification: type = "notifyRegisterSuccess"
To check registration status, use the command show license status
.
admin@ncs# show license status Smart Licensing is ENABLED Registration: Status: REGISTERED Smart Account: Network Service Orchestrator Virtual Account: Default Export-Controlled Functionality: Allowed Initial Registration: SUCCEEDED on Apr 21 09:29:11 2016 UTC Last Renewal Attempt: SUCCEEDED on Apr 21 09:29:16 2016 UTC Next Renewal Attempt: Oct 18 09:29:16 2016 UTC Registration Expires: Apr 21 09:26:13 2017 UTC Export-Controlled Functionality: Allowed License Authorization: License Authorization: Status: IN COMPLIANCE on Apr 21 09:29:18 2016 UTC Last Communication Attempt: SUCCEEDED on Apr 21 09:26:30 2016 UTC Next Communication Attempt: Apr 21 21:29:32 2016 UTC Communication Deadline: Apr 21 09:26:13 2017 UTC
Since all the NSO examples and README steps that come with the installer are primarily aimed at Local Install, you need to modify them in order to run them on a System Install.
To work with the System Install structure, this may require a little or bigger modification depending on the example.
For example, to port the example.ncs/development-guide/nano-services/basic-vrouter
example to the System Install structure:
-
Make the following change to the
basic-vrouter/ncs.conf
file:<enabled>false</enabled> <ip>0.0.0.0</ip> <port>8888</port> -<key-file>${NCS_DIR}/etc/ncs/ssl/cert/host.key</key-file> -<cert-file>${NCS_DIR}/etc/ncs/ssl/cert/host.cert</cert-file> +<key-file>${NCS_CONFIG_DIR}/etc/ncs/ssl/cert/host.key</key-file> +<cert-file>${NCS_CONFIG_DIR}/etc/ncs/ssl/cert/host.cert</cert-file> </ssl> </transport>
-
Copy the Local Install
$NCS_DIR/var/ncs/cdb/aaa_init.xml
file to thebasic-vrouter/
folder.
Other, more complex examples may require more ncs.conf
file changes or require a copy of the Local Install default $NCS_DIR/etc/ncs/ncs.conf
file together with the modification described above, or require the Local Install tool $NCS_DIR/bin/ncs-setup
to be installed, as the ncs-setup
command is usually not useful with a System Install. See the section called “Migrate to System Install” for more information.
NSO can be uninstalled using the ncs-installer(1) option only if NSO is installed with --system-install
option. Either part of the static files or full installation can be removed using ncs-uninstall
option. Ensure to stop NSO before uninstalling.
# ncs-uninstall --all
Executing the above command removes the Installation Directory /opt/ncs
including symbolic links, Configuration Directory /etc/ncs
, Run Directory /var/opt/ncs
, Log Directory /var/log/ncs
, init scripts from /etc/init.d
and user profile scripts from /etc/profile.d
.
To make sure that no license entitlements are consumed after you have uninstalled NSO be sure to perform the deregister command in the CLI:
admin@ncs# license smart deregister