Exploring Cisco NSO: The Technical Details (Part 3/3)

Updated: July 7, 2025

Another installment in our series of articles where we take a look under the hood of Cisco NSO. This time, we will examine more closely how Cisco NSO handles configuration and how the system can help secure networks, facilitate troubleshooting, and manage services. NSO achieves this by using reference counting and a Cisco-proprietary algorithm called FASTMAP.

So, what are FASTMAP and Reference Counting?

Let's start with the simpler of the two, reference counting—a concept that all Python and Java programmers should be well aware of, along with anyone programming in languages that use garbage collection to manage variables and memory for the programmer.

NSO has internal functions for the same type of management, but for the configuration created by services. Note, however, that both reference counting and FASTMAP work with the YANG model of the configuration that NEDs and Device Manager send and retrieve from the equipment, not directly with the configuration in the equipment.

So, when a service is created in Cisco NSO, and that service, in turn, generates configuration sent out to the equipment, each part of that configuration gets a reference counter that tracks how many services use this configuration, as there can be more than one. An example is an access list that we reuse for all services of a specific type. The configuration also gets a backpointer to the service or services in question. With this backpointer to the service, we have the answer to a first important question: How can we know which services are affected if we change a certain part of the configuration in the equipment?

What is FASTMAP?

In addition to creating reference counters and pointers, FASTMAP is the algorithm that ensures we don't need to take extra steps to manage service configurations throughout their lifecycle, including updates and when they are removed from the network. When a service is created, a "reverse diff" for the configuration of this service is saved, which contains what is needed to remove this instance of the service. If the service is updated, this diff is used to (without changing the equipment) remove the service, and then Cisco NSO runs the code to create the service again with the changes made. The difference between this new configuration and the configuration present in the equipment then represents the changes that need to be made. The final step is to send this list of changes to the NED that manages the equipment and updates its configuration.

Back to Reality

So, what does this mean in practical terms for a company that wants to use Cisco NSO? Let's look at an example.

In this scenario, we have already implemented Cisco NSO and manage our equipment and its services through NSO. However, a technician has logged directly onto a device and changed the configuration. In this case, Cisco NSO will indicate that the equipment in question is no longer in sync because the configuration does not match what is expected. We first handle the simplest case: The technician made a mistake, and the change should have been made via the service in NSO instead. We then instruct Cisco NSO to push out its version of the configuration, overwriting the change. After that, if necessary, we update the service's parameters, and this update is then rolled out to the network via Cisco NSO. The technician receives training on what should have been done instead.

But what if the technician was right? What if the service wasn't working as it should, and the change made isn't available as a parameter to set in NSO? Then we instruct NSO to sync its view from the equipment instead. The imported updated configuration will not match what the service expects, so Cisco NSO can use the backpointer to identify which services are affected. For example, if an access list used by multiple services has been updated, we might have solved one problem in one service but created problems in four others.

We now need to investigate the underlying problem and its solution. Perhaps we need to update the service to include this change and roll it out to all instances of this service on all equipment we have? Alternatively, we could create a version 2 of the service where one can choose whether this feature should be on or off, and update the services for customers who want the change, while those who don't want it can keep the older version?

Note that this view of services is not only limited to services delivered to others. Exactly the same logic and configuration management can be applied to, for example, AAA configurations. This is a service that all equipment should have directly when they are put into operation, so we can add it automatically. Furthermore, we really want to know if someone has changed it and be able to restore it to the expected configuration, but it's not unlikely that it might need to be updated or changed sometimes too. The same applies to all other parts of the "standard" configuration applied to the equipment, from COPP filters to the authentication banner when logging in.

Thinking of all configuration in terms of services, where all configuration in the equipment actually originates from and is managed as a service, can be a major transition for a company. Especially for organizations accustomed to manually changing configuration until symptoms disappear (but probably not the underlying fault). Similarly, it's a transition to think of the service's entire lifecycle and all its instances more industrially, instead of constantly finding and "fixing" the same problem over and over again.

Do you need help getting started with network automation and Cisco NSO?

Whether you need help with analysis, implementation, or long-term support, our experienced Cisco NSO consultants can guide you through every step of the process. With the right support, you can maximize the benefits of network automation, reduce costs, and improve overall network efficiency. Contact us today to find out how we can help your company succeed with Cisco NSO!

Talk to us about Cisco NSO