Administration

User Management

Users are configured at the path aaa authentication users

admin@ncs(config)# show full-configuration aaa authentication users user
aaa authentication users user admin
 uid        1000
 gid        1000
 password   $1$GNwimSPV$E82za8AaDxukAi8Ya8eSR.
 ssh_keydir /var/ncs/homes/admin/.ssh
 homedir    /var/ncs/homes/admin
!
aaa authentication users user oper
 uid        1000
 gid        1000
 password   $1$yOstEhXy$nYKOQgslCPyv9metoQALA.
 ssh_keydir /var/ncs/homes/oper/.ssh
 homedir    /var/ncs/homes/oper
!...

Access control, including group memberships, is managed using the NACM model (RFC 6536).

admin@ncs(config)# show full-configuration nacm
nacm write-default permit
nacm groups group admin
 user-name [ admin private ]
!
nacm groups group oper
 user-name [ oper public ]
!
nacm rule-list admin
 group [ admin ]
 rule any-access
  action permit
 !
!
nacm rule-list any-group
 group [ * ]
 rule tailf-aaa-authentication
  module-name       tailf-aaa
  path              /aaa/authentication/users/user[name='$USER']
  access-operations read,update
  action            permit
 !

So, adding a user includes the following steps:

Create the user: admin@ncs(config)# aaa authentication users user <user-name>
Add the user to a NACM group: admin@ncs(config)# nacm groups <group-name> admin user-name <user-name>
Verify/change access rules.

It is likely that the new user also needs access to work with device configuration. The mapping from NSO users and corresponding device authentication is configured in authgroups.

admin@ncs(config)# show full-configuration devices authgroups
devices authgroups group default
 umap admin
  remote-name     admin
  remote-password $4$wIo7Yd068FRwhYYI0d4IDw==
 !
 umap oper
  remote-name     oper
  remote-password $4$zp4zerM68FRwhYYI0d4IDw==
 !
!

So the user needs to be added here as well. If the last step is forgotten you will see the following error:

jim@ncs(config)# devices device c0 config ios:snmp-server community fee
jim@ncs(config-config)# commit
Aborted: Resource authgroup for jim doesn't exist

Packages

NSO Packages contain data-models and code for a specific function. It might be a NED for a specific device, a service application like MPLS VPN, a WebUI customization package etc. Packages can be added, removed and upgrade in run-time. A common task is to add a package to NSO in order to support a new device-type, or upgrade an existing package when the device is upgraded.

(We assume you have the example up and running from previous section). Current installed packages can be viewed with the following command:

admin@ncs# show packages
packages package cisco-ios
 package-version 3.0
 description     "NED package for Cisco IOS"
 ncs-min-version [ 3.0.2 ]
 directory       ./state/packages-in-use/1/cisco-ios
 component upgrade-ned-id
  upgrade java-class-name com.tailf.packages.ned.ios.UpgradeNedId
 component cisco-ios
  ned cli ned-id  cisco-ios
  ned cli java-class-name com.tailf.packages.ned.ios.IOSNedCli
  ned device vendor Cisco
NAME      VALUE
---------------------
show-tag  interface

 oper-status up

So the above command shows that NSO currently have one package, the NED for Cisco IOS.

NSO reads global configuration parameters from ncs.conf. More on NSO configuration later in this guide. By default it tells NSO to look for packages in a packages directory where NSO was started. So in this specific example:

$ pwd
.../examples.ncs/getting-started/using-ncs/1-simulated-cisco-ios
$ ls packages/
cisco-ios
$ ls packages/cisco-ios
doc
load-dir
netsim
package-meta-data.xml
private-jar
shared-jar
src

As seen above a package is a defined file structure with data-models, code and documentation. NSO comes with a couple of ready-made packages: $NCS_DIR/packages/. Also there is a library of packages available from Tail-f especially for supporting specific devices.

Adding and upgrading a package

Assume you would like to add support for Nexus devices into the example. Nexus devices have different data-models and another CLI flavor. There is a package for that in $NCS_DIR/packages/neds/nexus.

We can keep NSO running all the time, but we will stop the network simulator to add the nexus devices to the simulator.

$ ncs-netsim stop

Add the nexus package to the NSO runtime directory by creating a symbolic link:

$ cd $NCS_DIR/examples.ncs/getting-started/using-ncs/1-simulated-cisco-ios/packages
$ ln -s $NCS_DIR/packages/neds/cisco-nx
$ ls -l
... cisco-nx -> .../packages/neds/cisco-nx

The package is now in place, but until we tell NSO for look for package changes nothing happens:

  admin@ncs# show packages packages package
  cisco-ios ...  admin@ncs# packages reload

>>> System upgrade is starting.
>>> Sessions in configure mode must exit to operational mode.
>>> No configuration changes can be performed until upgrade has
completed.
>>> System upgrade has completed successfully.
reload-result {
    package cisco-ios
    result true
}
reload-result {
    package cisco-nx
    result true
}

So after the packages reload operation NSO also knows about nexus devices. The reload operation also takes any changes to existing packages into account. The datastore is automatically upgraded to cater for any changes like added attributes to existing configuration data.

Simulating the new device

$ ncs-netsim add-to-network cisco-nx 2 n
$ ncs-netsim list
ncs-netsim list for  /Users/stefan/work/ncs-3.2.1/examples.ncs/getting-started/using-ncs/1-simulated-cisco-ios/netsim

name=c0 ...
name=c1 ...
name=c2 ...
name=n0 ...
name=n1 ...


$ ncs-netsim start
DEVICE c0 OK STARTED
DEVICE c1 OK STARTED
DEVICE c2 OK STARTED
DEVICE n0 OK STARTED
DEVICE n1 OK STARTED
$ ncs-netsim cli-c n0
n0#show running-config
no feature ssh
no feature telnet
fex 101
 pinning max-links 1
!
fex 102
 pinning max-links 1
!
nexus:vlan 1
!
...

Adding the new devices to NSO

We can now add these Nexus devices to NSO according to the below sequence:

admin@ncs(config)# devices device n0 device-type cli ned-id cisco-nx
admin@ncs(config-device-n0)# port 10025
admin@ncs(config-device-n0)# address 127.0.0.1
admin@ncs(config-device-n0)# authgroup default
admin@ncs(config-device-n0)# state admin-state unlocked
admin@ncs(config-device-n0)# commit
admin@ncs(config-device-n0)# top
admin@ncs(config)# devices device n0 sync-from
result true

Configuring NSO

ncs.conf

The configuration file ncs.conf is read at startup and can be reloaded. Below follows an example with the most common settings. It is included here as an example and should be self-explanatory. See man ncs.conf for more information. Important configuration settings:

load-path: where NSO should look for compiled YANG files, such as data-models for NEDs or Services.
db-dir: the directory on disk which CDB use for its storage and any temporary files being used. It is also the directory where CDB searches for initialization files. This should be local disc and not NFS mounted for performance reasons.
Various log settings
AAA configuration
Rollback file directory and history length.
Enabling north-bound interfaces like REST, WebUI
Enabling of High-Availability mode

Run-time configuration

There are also configuration parameters that are more related to how NSO behaves when talking to the devices. These resides in devices global-settings.

admin@ncs(config)# devices global-settings
Possible completions:
  backlog-auto-run               Auto-run the backlog at successful connection
  backlog-enabled                Backlog requests to non-responding devices
  commit-queue
  commit-retries                 Retry commits on transient errors
  connect-timeout                Timeout in seconds for new connections
  ned-settings                   Control which device capabilities NCS uses
  out-of-sync-commit-behaviour   Specifies the behaviour of a commit operation involving a device that is out of sync with NCS.
  read-timeout                   Timeout in seconds used when reading data
  report-multiple-errors         By default, when the NCS device manager commits data southbound and when there are errors, we only
                                 report the first error to the operator, this flag makes NCS report all errors reported by managed
                                 devices
  trace                          Trace the southbound communication to devices
  trace-dir                      The directory where trace files are stored
  write-timeout                  Timeout in seconds used when writing
  data

Monitoring NSO

Use the command ncs --status to get runtime information on NSO.

Backup and Restore

All parts of the NSO installation, can be backed up and restored with standard file system backup procedures.

The most convenient way to do backup and restore is to use the ncs-backup command. In that case the following procedure is used.

Backup

NSO Backup backs up the database (CDB) files, state files, config files and rollback files from the installation directory.

To take a complete backup (for disaster recovery), use
```
ncs-backup
```
The backup will be stored in Run Directory /var/opt/ncs/backups/ncs-VERSION@DATETIME.backup

For more information on backup, refer to ncs-backup(1) in Manual Pages .

NSO Restore

NSO Restore is performed if you would like to switch back to a previous good state or restore a backup.

Note

It is always advisable to stop NSO before performing Restore.

First stop NSO if NSO is not stopped yet.
```
/etc/init.d/ncs stop
```
Then take the backup
```
ncs-backup --restore
```
Select the backup to be restored from the available list of backups. The configuration and database with run-time state files are restored in /etc/ncs and /var/opt/ncs.
Start NSO.
```
/etc/init.d/ncs start
```