Cisco Network Services Orchestrator (NSO) - Glimpses

You will find a lot of literature everywhere on what is Cisco's NSO tool. Briefly, NSO aims to provide an orchestration layer; which can help ease our interaction with both traditional and SDN enabled devices. It has support for multiple vendors and can interact with network devices in multiple ways. We will learn about the features that NSO brings along gradually. The series follows no definite pattern. We will try to understand the need for NSO and then dive into the practical aspects. Let us go over some fundamental topics that we need to know before we jump to NSO.

NETWORK MANAGEMENT STANDARDISATION

We have heard about NETCONF, RESTCONF, and YANG in many presentations. We usually brush them aside thinking now is not the time. The usual thought is "My organization will take time in implementing such changes; my devices don't support them" etc. We give all sorts of excuses to learn them because we network engineers have been heavily comfortable with CLI. But smart people were focused on standardizing the way we manage networks.

RFC 3535

This blog post by the tail-f team gives a very brief read on how the RFC by the standards body IETF became the catalyst for developing the robust NETCONF protocol and how YANG became the popular data modelling language. This mention is just to take you through history; there is no need to know too much of NETCONF and YANG stuff.

Also, we need to understand the drawbacks of our existing tools (CLI, SNMP). CLI has always been proprietary stuff. You spend years and tears (when typing I wanted to write years and years, but later I thought tears are more appropriate) learning the CLI of one vendor; you are tied to it. Say you are a Cisco expert. A company that acquires you to manage their devices can have you on their payroll only to manage Cisco devices. What if later their purchase team says there are more features in Juniper devices (just an example) and deploys Juniper devices as part of an upgrade. They will have to spend more cost on acquiring resources, network engineers to manage Junos devices. Bottom-line - CLI is expensive.

SNMP has been very successful in allowing us to poll statistics from devices but honestly, it has not been successful in letting us do config changes. I may be wrong but the farthest  I have seen do are ACL changes on interfaces. So no CLI and no SNMP. What next?

CLI Scripting

I think we all by now would have tried our hands in CLI scripting.  Elementary python knowledge would arm us with the firepower to burst some show commands to our devices, wait for a timer to expire, parse the reply from devices using the very many string functions that come with python and get some usable output. Or even more, we tried our best to enter into the config terminal and push some config changes. We then had questions like was it implemented successfully? How do I push to multiple devices at the same time; should I use concepts of multi-threading etc. It is plagued with problems. But for anyone to understand the problems of Adhoc scripting you should get your hands dirty in it. Try using libraries such as paramiko to help jumpstart your ssh sessions and try building some use cases.

NSO - NETCONF & YANG

We spoke about the drawbacks of CLI and SNMP briefly to understand why NSO uses NETCONF and YANG to interact with devices southbound to get onboard in the standardization train. It doesn't mean NSO will not use CLI. We will discuss the multiple ways NSO interacts with devices in future. NSO can interact with both physical and virtual devices; can interact with multiple vendor implementations; act as sort of an SDN controller for multiple technologies like Service Provider, Data Centers etc. Standardizing the interaction between a controller and a network device which we saw earlier --> delivers, aids in the platform-vendor-agnostic features of NSO.

NEED FOR CONFIG DATABASE

We all have felt the need for a config database. Haven't we? When we see our software counterparts using git in and out we have felt why network implementations have not ingested such concepts. We saw some of these concepts come up in the latest routers  where we are asked "Do you want to commit?" Take for example IOS XR. We can guess where this concept comes from now I guess. Still, it was the responsibility of the individual devices to maintain the database and roll back ids. You could go back in the config state based on the IDs. But what about a central database in sync with the device configurations. We didn't get that. The closest we could get was Network Config Management tools that scraped the config from the devices at fixed intervals of time (say a day) and did the job of storing it in a database as a backup.

The problems with such config backups are many. Imagine you want to go back to a state say the 05th of May. You open the config tool and it gives you the config that was available on the 05th of May. There could be multiple changes done after the 05th of May on that device. How do you as a network administrator approach this problem of reverting the state to that of 05th May? We open our notepads copy the config, compare it line by line and apply our mind to negate the config and restore the config as it was on 05th of May. Keep this in the back of your mind as we progress along.

Cisco NSO has something called the CDB (Configuration Database) which is an in-memory database (If you want to know more about in-memory check this link here) and uses the YANG model for transactions. This will serve as our single Source of Truth (SoT). NSO will try to query our devices periodically; try to fetch the config and maintain an in-sync config state in the CDB. Whoa! When it queries the devices it can use multiple means; it can use CLI, it can use NETCONF but NSO does its dutiful job of maintaining the CDB; most importantly an in-sync CDB.

NORTHBOUND VS SOUTHBOUND

Northbound interactions comprise all interactions between the user and NSO. NSO supports multiple technologies for this northbound interaction. Some include REST , NETCONF , CLI (NSO has its own CLI), Web UI etc.

Southbound takes care of all interaction between our NSO and network devices. NED(Network element drivers) are written for multiple vendors and multiple OSs. For example, there is NED for Cisco ios and another for Cisco ASA.

CORE COMPONENTS

NSO consists of the following core components:-

A service manager, a device manager and a Configuration Database.

The device manager has the role of simplifying device interactions; so obviously talks to devices via previously discussed NEDs. CDB is the database where all the latest and greatest config lies. It is like an amplified git repo for network config. The service manager is the one we have to wrap our brains on. It has the task of applying service changes. Think of service as a Layer 3 VPN config. The service layer would handle it for you. Between the service layer and the device layer, we have a mapping mechanism that sorts of tells the device layer what to apply to the end devices.

This is the end of part 1. We will gradually build our NSO concepts in upcoming posts.