Cisco Network Service Orchestrator (NSO) version 5.7.18 is an evolution of the Tail-f Network Control System (NCS). Tail-f was acquired by Cisco in 2014. The product has been enhanced and forms the base for Cisco NSO. Note that the terms 'ncs' and 'tail-f' are used extensively in file names, command-line command names, YANG models, application programming interfaces (API), etc. Throughout this document we will use NSO to mean the product, which consists of a number of tools and executables. These executable components will be referred to by their command line name, e.g. ncs, ncs-netsim, ncs_cli, etc.
The purpose of this document is:
-
For readers to get a general understanding of NSO as a service orchestration and network configuration tool.
-
For user to get started using NSO through the examples collection.
This document covers the essential parts of using NSO to manage a network and features are covered at an introductory level. Please see the User Guide for more comprehensive documentation of NSO
Creating and configuring network services is a complex task that often requires multiple configuration changes to all devices participating in the service. Additionally changes generally need to be made concurrently across all devices with the changes being either completely successful or rolled back to the starting configuration. And configuration need to be kept in sync across the system and the network devices. NSO approaches these challenges by acting as interface between people or software that want to configure the network, and the devices in the network.
The key features of NSO that comes into play includes:
-
Multi-vendor device configuration management using the native protocols of the network devices.
-
A Configuration Database (CDB) managing synchronized configurations for all devices and services in the network domain.
-
A set of northbound interfaces including human interfaces like web UI and a CLI; programmable interfaces including RESTCONF, NETCONF, JSON-RPC; and language bindings including Java, Python and Erlang.
Network engineers use NSO as a central point of access to manage entire networks. They commonly do this using the NSO CLI or web UI. This document illustrates the use cases using CLI examples, but it is important to understand that any northbound interface can be used to achieve the same functionality.
All devices and services in the network can be accessed and configured using the NSO CLI, making it a powerful tool for network engineers. The CLI also provides an easy way to define roles and associated authorization policies limiting the engineers view of the devices under NSO control. Policies and integrity constraints can also be defined making sure the configuration adhere to operator standards.
The typical workflow when using the NSO CLI is as follows:
-
The user logs in to the CLI and thereby starts a new session. The session provides a (logical) copy of the running configuration of CDB as a scratch pad for edits.
-
Changes made to the scratch pad are optionally validated at any time against policies and schemas using the "validate" command. Changes can always be viewed and verified prior to committing them.
-
The changes are committed, meaning that the changes are copied to the NSO database and deltas are pushed out to the network devices that are affected by the change. Changes that violate integrity constraints or network policies will not be committed but produce validation errors. The changes to the devices are done in a distributed and atomic transaction across all devices in parallel.
-
Changes either succeed and remain committed to device configuration or fail and are rolled back as a whole returning the entire network to the prior state.
This section provides a broad overview of the NSO architecture and functionality.
NSO has two main layers: the Device Manager and the Service Manager. They serve different purposes but are tightly integrated with a transactional engine and database.
The purpose of the Device Manager is to manage device configurations in a transactional manner. It supports features like fine-grained configuration commands, bidirectional device configuration synchronization, device groups and templates, and compliance reporting.
The Service Manager makes it possible for an operator to manage high-level aspects of the network that are not supported by the devices directly, or is supported in a cumbersome way. With the appropriate service definition running in the Service Manager, an operator could for example configure the VLANs that should exist in the network in a single place, and the Service Manager compute the specific configuration changes required for each device in the network and push them out. This covers the whole life-cycle for a service: creation, modification and deletion. NSO has an intelligent and easy way to use a mapping layer so that network engineers can define how a service should be deployed in the network.
NSO uses a dedicated built-in storage Configuration Database (CDB) for all configuration data. NSO keeps the CDB in sync with the real network device configurations. Audit, to ensure configuration consistency, and reconciliation, to synchronize configuration with the devices, functions are supported. It also maintains the runtime relationships between service instances and the corresponding device configurations.
NSO uses Network Element Drivers, NEDs, to communicate with devices. NEDs are not closed hard-coded adapters. Rather, the device interface is modeled in a data-model using the YANG data modelling language. NSO can render the required commands or operations directly from this model. This includes support for legacy configuration interfaces like device CLIs. This means that the NEDs can easily be updated to support new commands just by extending the data-models with the appropriate model constructs which avoids any programming tasks as part of the change cycle.
NSO also comes with tooling for simulating the configuration aspects of a network. The netsim tool is used to simulate management interfaces like Cisco CLI and NETCONF for the purpose of examples and service development.