CISCO NSO
Service Provider - Challenges
• Creating and configuring network services is a complex task that often requires multiple integrated
configuration changes to every device in the service chain.
• Additionally changes need to be made concurrently across all devices with service implementation
being either completely successful or completely removed from the network.
• All configurations need to be maintained completely synchronized and up to date.
• NSO solves these problems by acting as interface between the configurators (network operators and
automated systems) and the underlying devices in the network.
NSO does this by providing the following key functions:
1. Representation of the services.
2. Multi-vendor device configuration modification in the native language of the network devices.
3. Configuration Database (CDB) with current synchronized configurations for all devices and services in
the network domain.
4. Northbound interfaces that can be accessed via WebUI or with automated systems using REST, Python,
NETCONF, Java or other tools.
NSO – High Level picture
• Network engineers use NSO as a central point of management for the entire network, using a "network
CLI" or a web-based user interface.
• It is also easy to define roles limiting the authority of engineers to the devices under their control.
• Policies and integrity constraints can also be defined making sure the configuration adhere to site
standards.
NSO Work Flow
The typical work flow when using the network CLI in NSO is as follows:
1. All changes are initially made to a (logical) copy of the NSO database of configurations.
2. Changes are validated against network policies and integrity constraints using the "validate" command.
Changes can be viewed and verified by the network operator prior to committing them.
3. The changes are committed, meaning that the changes are copied to the NSO database and pushed
out to the network. Changes that violate integrity constraints or network policies will not be
committed. The changes to the devices are done in a holistic distributed atomic transaction, across all
devices in parallel.
4. Changes either succeed and remain committed or fail and are rolled back as a whole returning the
entire network to the uncommitted state.
NSO Main Features
The main features of NSO are:
• Intuitive to the methods currently used for configuring network services using either Web UI or
network CLI.
• Device changes are whole and either completely succeed or are completed discarded, no partial
configurations are left.
• Fine-grained deep control of all elements in the service.
• Centralized configuration database that is synchronized with the network. Reconciliation can done
in any direction: to network, from network.
• Rich set of user interfaces (WebUI, CLI) and scripting interfaces (REST, Python, NETCONF,
JavaScript).
NSO Architecture Overview
• NSO has two main layers: the Device Manager and the Service Manager. They serve different
purposes but are tightly integrated into one 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 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.
• NSO comes with Network Element Drivers, NEDs, that communicates with the devices.
• NEDs are not closed hard-coded adapters. Rather, the device interface is modeled in a data-model
using YANG.
• NSO can render the underlying commands from this model.
• NSO in combination with the NEDs will apply device configuration changes as atomic change sets.
• NSO netsim is used to simulate devices. Netsim can simulate management interfaces like Cisco
CLI and NETCONF. It does not simulate the network behavior.
• NSO supports a rich variety of APIs and User Interfaces. Independent of the device types NSO will
render a northbound Cisco XR style network wide CLI.
• Scripts can be written using Python, REST, and NSO CLI or other tools to automate network
activities.
• When a device gets registered with NSO NSO only knows the address, port, and authentication
information of the devices.
• In the case of netsim devices, this management information was loaded to NSO by the setup
utility. It also tells NSO how to communicate with the devices by using NETCONF, SNMP, Cisco IOS
CLI etc.
• When you start the NSO CLI it starts in operational mode, so in order to show configuration data
you have to explicitly say show running-config.
• NSO manages a list of devices, each device is reached by the path devices device "name" . You
can use standard tab completion in the CLI to learn this.
• So now NSO can try to connect to the devices:
• NSO does not need to have the connections "active" continuously, instead NSO will establish a
connection when needed and connections are pooled to conserve resources. At this time NSO can
read the configurations from the devices and populate the configuration database, CDB.
• The following command will synchronize the configurations of the devices with the CDB and
respond with "true" if successful:
Device Configuration
• View the configuration of the "c0" device using the command:
• Show a particular piece of configuration from several devices
