NSO

NCS (Network Control System) is a product created by Tail-f over 10 years ago. Cisco acquired Tail-f in the last few years and since then NCS has been renamed to NSO (Network Services Orchestrator).

NSO is a network configuration management platform. It is a single platform from which you can manage the configuration of all devices in your network. NSO was originally targeted at service provider customers, so multi-vendor support was very important. The selling point for NSO was: “Now you can manage the thousands of devices you have from a dozen+ different vendors, from a single place.”

After spending a day with NSO, I find NSO to feel sort of like Ansible but if Ansible had an IOSXR-like CLI. Also if Ansible could create automatic rollbacks. Also if Ansible could create atomic changes and automatically rollback if they failed… OK you get the idea. NSO is definitely more powerful than Ansible but it can be a useful comparison to understand NSO if you’re just starting out and you are familiar with Ansible already.

The basic setup or workflow for NSO is as follows:

You install NSO on a Unix machine.
You add devices into NSO using one of the following southbound interfaces: SSH(CLI), NETCONF (preferred), or SNMP.
NSO discovers the config of all devices and stores it in a YANG-modeled database. (Even if you are using SSH and not NETCONF).
You can stage changes on NSO and push changes out to all your devices. If part of the changes fail, NSO can rollback all changes entirely.
If you make a manual change to a device, you need to do a sync operation from NSO so that it gets the latest config from the device and updates the NSO database.

NSO Components

There are a few terms used in the NSO platform that you should be familiar with. It’s OK if you can’t understand or remember these all right now. As you lab NSO you will naturaly understand how these components work as you become familiar with the product.

NED (Network Element Driver)

This is what is used by NSO to communicate with a managed network device. It is used for the southbound communication. For example, if you are using SSH to manage an IOS device you might use the cisco-ios-cli-6.67 NED. In Ansible, this would be called the collection. It contains all the necessary code for “how” NSO will communicate with the device. It also contains the code for how to convert the YANG modeled config in the NSO database to the IOS syntax.

Template

This is a collection of configuration parameters. For example, you might create a baseline template that defines NTP servers, DNS servers, domain name, and ssh version. In Ansible this would be a playbook. You can apply a template to multiple devices even if they are different platforms (IOS, XR, Juniper, Arista, etc). However, within the template itself, you do need to specify the config for each platform individually so that this functionality works.

Service

A service is custom-created config that you load into NSO. For example, you might make a L2VPN service that defines different parameters (PEs on each end, VPN ID, AC interface, etc). This allows you to extend the functionality of NSO. The parameters you define in your custom service become CLI commands that you can tab-to-autocomplete inside the NSO CLI which is pretty neat. In Ansible, this would be like a custom module which you then use in a playbook.

The service is itself a YANG data model with a schema defintion. The idea behind services is that it provides for intent-based configuration. Instead of you, the operator, configuring every link and every parameter of a L2VPN, you instead more loosely define the main goals of the L2VPN as a service. NSO then translates the intent-based service into the configuration that is necessary and pushes this to the devices.

CDB (Core Database)

All network configs are stored in the core database. The configs are modeled using YANG. Changes you make in NSO are made to the configs in the stored database, and only pushed to the devices once you run commit from NSO. Because of the way the config is modeled using YANG, you can always seemlessly rollback a commit or even multiple commits at once.

Device Manager

This is the component which actually interacts with the network devices using the NEDs. The device manager interacts in a transactional manner, so either the entire config change succeeds, or if not, it is entirely rolled back. This transactional nature is automatic when using NETCONF for the southbound interface, but when using SSH I believe there is some extra built-in code in the NED to accomplish this and make SSH “feel like” NETCONF. The device manager is also responsible for issuing a rollback if you decide to manually rollback changes.

Package Manager

The NEDs and services are both types of packages which need to be loaded into NSO. The package manager is the function that loads these packages. A custom service has multiple files in a directory that make up the entire package. It consists of the YANG modules, templates, extra code, etc. This entire package needs to be imported into NSO when you create your own service.

NSO Northbound Interfaces

You can manage NSO via a CLI, Web GUI or API. The CLI has two modes, Juniper or Cisco CLI syntax. Given that Cisco acquired this product, most of the docs I come across naturally use Cisco mode. However, some of the old videos on Tail-f’s youtube channel use Juniper mode. Everything you can do in the CLI should be achievable in the exposed APIs.

Next Steps

I find that NSO has a pretty steep learning curve. You really need to spend a few hours with it to understand what it does and how it works.

I would highly recommend following the “Learn NSO The Easy Way” lab from the first link in the section below. This will take you through the steps of setting up NSO, adding devices, pushing changes, creating templates, etc. You will need to use the devnet sandbox that is linked in the lab.