Cisco Network Services Orchestrator (NSO)
Cisco’s Network Services Orchestrator is a platform to help companies transition into an SDN / Automated Network Solution, as the constant change in devices and limitation of vendor and service integrations has turned them away, where “Time to Market” requirements are critical as delays caused by new tool deployment will result in lost revenues – This is where NSO shines.
NSO comes with a both Centralized and Unified set of APIs to control both Networks and Services either in an Automated or Real-Time, which allows for faster and more precise control of both Networks and Services, leading to higher performance and reducing cost.
NSO does this by allowing operators to adopt service configuration / SDN solutions by using a logically centralized interface to a multi-vendor network using these 3 components:
- Model-Driven programmable interface (YANG models)
- Configuration database
- Device and service abstraction layers
Device and Service Abstraction Layers
Using the YANG standard model for communication allows NSO to automation the creation / deletion / run-time modification of network services, using this Abstraction Layer to communicate with any device type, from physical equipment to virtualized equipment from layers 1-7 of the OSI model.
The Data Model for a service correlates service definitions with network operations, using an embedded algorithm to determine the minimum network changes required for a service and then executes them, utilizing the “Cisco Elastics Services Controller” (ESC) as part of the core platform to provide these flexible services while also being able to launch / configure / monitor / manage licenses of Virtual Network Functions (VNFs).
Functional Architecture
NSO is separated into two logical layers of a “Device Manager” that simplifies device integration and manages the device config scenarios, while the “Services Manager” applies those changes to the devices, meaning although there are two separate logical layers to NSO they operate very closely together into a transactional engine and database.
The core of NSO is the “Configuration Database” providing a persistent datastore that synchronizes device and service configuration, managing the relationships between services and devices so that it can handle config changes. NSO addresses the mapping, working based from the “Desired” service configuration which corresponds to the current device configuration through a dedicated mapping layer.
A high level look at the NSO Architecture:
The purpose of Device Manager is to allow management of devices using YANG and NETCONF over either SSH (CLI) or SNMP, and creates a transactional change sequence for target devices, which works automatically if the target natively runs NETCONF and YANG – Otherwise non-NETCONF devices are integrated into Device Manager using Network Element Drivers (NEDs).
Service Manager allows development of service-aware applications to modify configurations such as device port states, based on services such as MPLS / VPN / Etc. These data models are called “Service Models” which are a mapping of device-to-service, which can be accomplished in two different ways. For simpler case uses you specify config templates that transform service parameters to device config parameters, and for more complex cases a “Mapping Logic” will need to be programmed for NSO to understand. Service Manager handles the complete lifecycle of creation / modification / deletion of service instances.
Custom code / applications / specific NEDs are the types of packages that NSO loads, a package consisting of code / YANG modules / etc which load at NSO startup, and packages can be added or upgraded at run-time as well (hot swap / add).
Service Manager
NSO Service manager is used to represent network services such as L2 / L3 VPNs / BGP Peerings / ACLs / etc, which can be represented in a vendor agnostic (vendor neutral) way, so NSO users can manipulate services and let NSO calculate and apply the device changes (which allows NSO to maintain the completel life-cycle of a network service).
A service in NSO consists of the following:
- A YANG service model – This defines attributes of the service along with service identifiers and interface names, then NSO will use the YANG Service Model info to render corresponding CLI or Web GUIs for that service
- Device Configuration Map – When the service is created, NSO supports ways to define ways to make corresponding changes to devices, with either templates or with Java
Service Manage provides the following:
- Creating / Modifying / Deletion of services (using FASTMAP behind the scenes to do this)
- Dry-run service life-cycle operations and report before making modifications, so that it can predict the outcome of changes to the device
- Check-Sync all services or a specific service, this checking if the actual device config corresponds with the service view, this is used to check if the device is changed “out of band” or if the resulting device config violates permitted service configs in NSO
- Maintaining device dependencies for every service instance of NSO, it knows the corresponding device config, which allows for the mapping of configs made by service provisioning back to the service instance that created the config
- Service self-test which triggers diagnostic tests of services
Configuration Database (CDB)
The internal Configuration Database stores it own config / configs of all services / configs of all the NSO managed devices it is aware of, being “persistent” all transactions are journaled to disk and CDB runs RAM-resident with the entire configuration maintained in memory allowing for high performance transactions with the trade-off of high run-time memory requirements with the increase in config data.
NSO CDB provides:
- A model on how to handle config data in network device including an update mechanism upon subscription
- An internal API for location network element configs
- Automatic support for upgrade or downgrades of config data where required
CLI / Web GUI / NETCONF sessions are the main consumers of the Database Services, allowing client appliance to read config data from the database, and react when configs are updated.
YANG Models
NSO itself, the service models, and the device models are all defined through YANG, even if the native format may be in SNMP MIBs or CLI commands, using the YANG Schema Trees to describe to data models and encoded in XML (YANGs data modeling language).
With NSO there are 3 primary YANG sources:
- NSO data model that define the built-in functions of NSO
- Data Models from native YANG modules like NETCONF enabled devices, generated YANG modules from SNMP MIBS, or reverse engineered YANG modules from a CLI device which then provide specify the functions of devices integrated to NSO
- YANG Service Models which are made by the developer of the service application which specifiers services in YANG format
These models are first compiled into NSO when they renders all “Northbound” APIs / User Interfaces (Web GUI / CLI), and database schemas (YANG Model).
Service Model Design
A service in NSO consists of the following:
- A YANG Service Module – This defines the attributes of the service via YANG Schemas, which are then rendered into Web GUI or CLI output to match the device or service, occasionally config data will need to validated using external non-YANG model for performing Database lookups – This step developed using “MAAPI”
- A device config mapping – When the service is created, corresponding changes must be made to the devices which are defined either using service templates or programmatically using Java – Service Templates may be used to map services to device configs while Programmtic Mapping is required for more complex mapping (like when an access link is added to a VPN and how this is reflected on Customer Edge and Provider Edge routers) <– MPLS
The core tech for NSO is the capability to read / write configs to and from devices, which NSO stores the service instances and device configs in the CDB, this allows for NSO to use the real-time database to compare desired to current configs and render the commands needed for the device that will make the changes to get it to the desired state.
The transformation from service models to device models can be complex when dealing with actual config details, which is where NSO utilizes an algorithm called “FASTMAP” to simplify the task by automatically pushing creates / deletes / changes to devices by referencing the CDB for Device Configs and compare that to the Service Model provided by the developer and it will calculate the “min diff” change needed to implement the updates.
The flow of this can be illustrated once more in the diagram first reviewed:
- Create / Modify / Delete Service Models are stored in CDB for later or run time referrence
- Create / Modify / Delete Device Models are stored as the devices current state for comparison
- Network Element Drivers may be invoked along with ESC if needed
- Config changes “Southbound” to devices via SSH / NETCONF / RESTCONF / Etc after the minimal config update is calculated by NSO (the “min diff”)
- The “min diff” change / result is returned via “Northbound” presentation back to the operators via the presentation rendered for that device or service
Services
An NSO service is a function provided by network devices, thus Deleting / Creating / Modifying a service impacts the end devices managed by NSO, which DO NOT INCLUDE MANUAL STEPS but rather automated as logical operators that meet the ACID transaction properties (Atomic, Consistent DB, Isolated, and Durable). This means a transaction must complete in full as a unit or fail, there is no partial config change, this is to ensure the CDB is in a consistent state.
The “Service Model” defined the required input to deploy the service to the network, where NSO collapses the the logic to a YANG-to-YANG modem transformation if its fairly straight forward and can be done via templates, for more complex service deployments they may be expressed using Java or Python – Only the “Service Creation” need to be defined then FASTMAP engine automatically manages all other service life-cycle changes as mentioned above.
When given a “Service Model” the mapping logic read that model and updates the corresponding device tree, the mapping logic can be interface-agnostic / unaware of interface specifics or how its handled via its native mgmt protocol, thus mapping logic does not include error handling on Southbound interfaces (to the network) which is automatically managed by the NSO transaction manager.
Northbound Interfaces
Northbound Interfaces allow for management of different devices and services via Web GUI / CLI / Programmable Interfaces via NETCONF or RESTCONF, along with language bindings that might include Java / Python / Erlang and other methods as described below:
- CLI – This is a Unified CLI presented by NSO that comes with features like tab completion / command history / model awareness, and allows for scripting of all network devices on one unified CLI rather than all individual native CLI’s for devices
- RESTCONF API – A standardized REST Interface as defined in RFC 8040 and supports auto-generating Swagger / OpenAPI documents from YANG
- NETCONF – Provides OSS Applications a NETCONF interface to devices and services managed by NSO
- Java – The Java Interface is used to build applications and clients for NSO, Java interface is model-aware so programmers can work with classes from the service and device models, which eases the learning curve and assures program correctness when compiling
- JavaScript – The JavaScript interface is used to build custom Web interfaces that are AJAX-based, which allows true asynchronous client to be created
- SNMP – NSO can present operational data via SNMP to upper layer mgmt systems which can be useful for handling alarms and gathering performance data, NSO also has its own SNMP Alarm MIB used with the NSO Alarm Manager
- Web UI – Same as the CLI, NSO creates a Web UI dynamically from the models for a Unified Web UI which is highly customizable
- MAAPI (Management Agent API) – Comes in several flavors and also available for the CLI utilities in C-API / Java API / Python API
- REST API – REST inteface provides a complete model via HTTP verbs, data exchanged may be either XML or JSON
NSO CLI
The CLI for NSO comes in two flavors which is either a Juniper style CLI or Cisco XR-Style, which is a “Northbound” interface, differing from a “cut-through” CLI that communicates to devices, with the CLI acting the same as most CLI’s with a read and write prompt.
In an “Configuration” mode it shows the network config data in the NSO CDB, while in “Operational” mode it will display both the live values and operational values data stored in CDB, this CLI is rendered using 4 different YANG models: Built-in NSO YANG Model / Service Manager Models / YANG Models imported from the devices / service models.
Web GUI
Rendered from YANG data models this GUI renders NSO itself, updates itself in real-time as devices are added or changed, and work using Client-Side JavaScript – All majors browsers are supported and no plugins required with the unique port of 8080 to access it (port # in ncs.conf).
Managing Services
Southbound interfaces allow for config and mgmt of devices using this list of interfaces:
- NETCONF – This is the default
- SNMP – Via the use of SNMP MIBs
- CLI – A “NED” CLI is required for this connection type (if device supports CLI)
- IOS, IOS XR – A “NED” is needed for communication and must be loaded to NSO
- Other / Open Source – “NED” / YANG Models / Java Code is required to work
Adding devices to NSO
There are 4 methods in which a new device can be added into NSO:
- Discovery
- Manually
- Cloning
- Templates
Using the CLI devices can be added by adding the defining the devices group and the device parameters with “devices (device) ce9 address (ip addy) port (port #)” which drops into a device config mode to describe the device with “device-type cli ned-id cisco-ios” / “authgroup default” / “commit” to finish adding the device.
Devices can be synched on the CLI using “sync-from” command in config mode, you can also configure multiple devices in this config mode.
Cisco SD-WAN (Software Designed Wide Area Networks)
Cisco SD-WAN support 3rd party API integration allowing for simplicity / customization / automation of day to day operations, includes common routing protocols that make up the SD-WAN deployment such as OSPF / BGP / VRRP / IPV6.
Through the “vManage” Dashboard SD-WAN provides:
- Transport Independence – Guarantees zero network downtime, automates application flexibility over multiple connection and connection types (MPLS / Internet / 4G / Etc)
- Network Services – Networking and Security services are pushed out with clicks of a mouse in the Dashboard, along with Optimization / IPS / URL Filtering / Etc across SD-WAN “Fabric”
- Endpoint Flexibility – End points are easily provisioned to expand the SD-WAN “Fabric” via the endpoints to different sites / branches / campuses
Below we start at the top where vManage NMS is used to configure the vSmart Controllers:
Key Features of SD-WAN:
- Cloud-first Architecture
- Embedded Security
- Predictable Application Performance
SD-WAN Components:
- vManage NMS (Network Mgmt System) – Centralized Network Mgmt system to configure the Overlay for the SD-WAN
- vSmart Controller(s) – Controls all the flow of data traffic by working with vBond Orchestrator to authenticate device as they join the network
- vBond Orchestrator – Orchestrates connectivity between vEdge routers and vSmart Controllers, if behind NAT vBond Orchestrator also work as a NAT Traversal orchestrator
- vEdge Routers – Provisioned at the perimeters of sites like branches or remote offices in hardware appliance format, and form a virtual Overlay network over multiple WAN transports that make up the overlay
vManage Management Plane
This is run on its own standalone server typically (though can be run on vSmart Controller), provides the single pane network and device provisioning / management SD-WAN devices.
vSmart Control Plane
The vSmart Control Plane contains a centralized route table / route information called “OMP Routes” which is learned via the vEdge Routers and vSmart Controllers in the Overlay Network, based on policies the vSmart will share routes between sites to communicate.
vBond Orchestration Plane
vBond Orchestration Plane coordinates the initial start of vSmart controllers and vEdge Routers, facilitating the connectivity and authentication between them, and runs automatically to avoid issues with manual starts of the process.
vEdge Data Plane
These are the appliances at the edge sites and are seen as standard routers by other routers, however have the ability to load balance WAN traffic to the overlay, yet can still run regular protocols to connect to IOS devices and perform all the regular functions as well.
SD-WAN APIs
These can be used for programmatic control / config / monitoring of the devices in the overlay, and the vManage web server can also be accessed through a REST API. These API’s are “homogeneous” as they are grouped into collections that have different data sub-sets:
- Administration
- Certificate Management
- Configuration
- Device Inventory
- Monitoring
- Real-Time Monitoring
- Troubleshooting Tools
More info can be found here:
And that will be quite enough for NSO and SD-WAN Platforms!
That took a very long time to get through, these Cisco Platforms are really a brain killer at the end of the course, I try to limit the info here to the need to know for exam day stuff but there is so much of it as you can see in this giant page 🙂
Until Next Time!!!
The DEVNET GRIND! 