It's time to take a deep dive into how Cisco NSO actually works and how it can be implemented in an existing company with established systems and processes. As experienced Cisco NSO consultants, we help companies understand how NSO can fit into their infrastructure and assist in network management. This first part focuses on the technical fundamentals of Cisco NSO, explaining its three main components: Service Manager, Device Manager, and Network Element Drivers (NED). But first, let’s start with a technical overview of Cisco NSO.
Overview of Cisco NSO
Cisco NSO consists of three layers that work together to support advanced network automation:
Service Manager
Device Manager
Network Element Drivers (NEDs)
These components are tightly integrated via the Configuration Database (CDB), which manages and stores network data. Below is an overview of the system and its components, where we break down each part and its role in network automation.
Starting from the bottom up makes it easier to understand what happens at each layer.
Network Element Drivers
A Network Element Driver (NED) acts as a driver for NSO to communicate with network devices. Today, there are NEDs available for over 1,000 different types of devices, covering most of Cisco’s portfolio, such as NX-OS and IOS-XR, but also third-party vendors like Juniper’s JunOS, Arista EOS, and Fortinet’s FortiOS, among others.
The main function of an NED is to translate between the device’s native language (e.g., CLI or REST API) and the standardized NETCONF/YANG format used internally by Cisco NSO. We will cover NETCONF/YANG in more detail in an upcoming section.
If an NED is missing for a particular device, it is possible to request Cisco to develop one. If the device already speaks NETCONF/YANG correctly, an NED can even be automatically generated using built-in tools in Cisco NSO.
This enables Cisco NSO to integrate with virtually any network device, and our Cisco NSO consultants can help design the right solution for your environment.
Device Manager
Device Manager collects all information that each NED (Network Element Driver) gathers from network equipment, including details such as the type of equipment, the version of the operating system (e.g., JunOS) being run, and more. This information is then stored by Cisco NSO in the CDB database.
CDB (Configuration DataBase) is a specially designed database to manage YANG-structured data. But Device Manager does much more than just data storage. Since it’s responsible for managing all updates in the CDB, Device Manager can also automatically check if the equipment is synchronized with Cisco NSO. Additionally, devices can be locked to prevent unwanted changes, for example, during scheduled work or when equipment is experiencing issues.
Moreover, Device Manager can automatically create and configure new equipment when added to Cisco NSO. An example of this is when a new Arista EOS device is added, Device Manager may have a predefined rule that automatically applies a standard configuration to the new device. This saves time and ensures that each new device follows company guidelines and requirements. We will also go into more detail on services and configuration management in a later section.
Device Manager can also receive and manage alarms from network equipment, depending on the support provided by the NED in use. These alarms can either be forwarded for manual handling or automatically trigger actions in Cisco NSO, such as running specific commands or applying/removing configurations. This makes Cisco NSO a powerful tool for network automation, and our experienced Cisco NSO consultants can help your company fully leverage these capabilities.
Service Manager
Service Manager is similar to Device Manager, but instead of managing information about individual network devices, it handles information about the services that the various “orders” on top of Cisco NSO require. In its simplest form, Service Manager can be used to manage equipment via CLI, but then no automation has really been achieved – you have just moved the location where commands are entered, from each individual device to Cisco NSO’s shared interface.
What makes Service Manager powerful is its ability to take a broader view of the network. Instead of configuring one device at a time, you can use service models to specify that a service includes multiple network devices, such as some ports on a Cisco router, an HP switch, and specific ports on a Fortigate firewall. The service is then created as a whole or not at all – just like Device Manager, Service Manager uses NETCONF/YANG to communicate with the CDB and manages the creation of services as a transaction. If this transaction cannot be executed, all configurations are rolled back, not just for the equipment where the error occurred.
When a service model in Service Manager is updated, such as adjusting the bandwidth that the service provides, this update is automatically saved in the CDB. This means that other systems and users interacting with Cisco NSO, such as an inventory system via REST API, will see the latest update in real time.
Learn more about how Telia automated its network
Service Models
Now that we have a better understanding of how Cisco NSO works, it’s time to address one of the biggest questions when implementing Cisco NSO: service models. A service model defines the parameters of a service, such as how much bandwidth the service should deliver, and what resources in the network the service consumes.
Having a clear picture of these parameters allows you to answer key questions such as:
If a specific network device fails, which services are affected and how? Is there redundancy to take over?
During planned maintenance on a device, which internal and external customers are affected and how? Do these services have redundancy, or do they risk interruption?
What is the cost of delivering this service? For example, optical modules are a major part of the power budget in modern equipment. How much of the electricity cost for this equipment is attributed to this service, and by extension, things like EU ETS reports?
Is there enough capacity in the network to deliver this service where it’s needed? Or do we need to expand the network to meet the requirements?
When implementing Cisco NSO, the first question is often whether the company has established service models for its services. And if they do – how are they documented and managed? It’s important to distinguish between service models and inventory models. Both can be managed by the same system but serve different roles. An inventory model answers questions such as:
→ How many copies of a certain piece of equipment do we have? What did they cost, and when will they be depreciated?
→ Where is the equipment located, down to the floor, room, and rack? What port code is needed to access it, and do the technicians need assistance on-site?
→ How many of these devices are currently in use, and for what? Are there devices in stock that can be used as spare parts, and where are they?
→ What is the serial number? What support agreements apply, and when do they expire?
One way to illustrate the difference between a service model and an inventory model is to think about what happens when a device fails and is replaced with an identical one. The service model remains the same – the node in the service graph keeps its name and parameters, and the new device receives the exact same configuration as the one it replaces. On the other hand, the inventory model is updated with the new device’s serial number, and the fact that a spare part has been used and must be replaced.
Unfortunately, service models are often a neglected part of network infrastructure, especially in traditional on-prem solutions. Cloud services like AWS and Azure require their users to explicitly create and then bind resources to services, ensuring service models are always in place from day one. However, in on-prem networks, the processes tend to be more informal, which works until the network becomes too large and complex to manage in this way. This is a unique challenge for each company, but with the help of experienced Cisco NSO consultants, you can begin to create and manage effective service models that suit your company’s needs.
Need help with Cisco NSO?
If your company is facing challenges with network automation or is considering implementing Cisco NSO, our Cisco NSO consultants can guide you through the entire process. Whether it’s about creating service and inventory models, optimizing network automation, or providing long-term support, we have the expertise you need. With our help, your company can maximize the benefits of Cisco NSO, reduce operating costs, and increase efficiency. Contact us today to see how we can support you in succeeding with Cisco NSO!
Comments