Another installment in our series of articles where we take a look under the hood of Cisco NSO. This time, we will take a closer look at how Cisco NSO handles configuration and how the system can help secure networks while facilitating troubleshooting and service management. NSO achieves this by using reference counting and a Cisco-proprietary algorithm called FASTMAP.
What Are FASTMAP and Reference Counting?
Let’s start with the simpler of the two: reference counting. This concept, also known as "reference counting," is something all Python and Java programmers should be familiar with, along with anyone who programs in languages that use "garbage collection" to manage variables and memory for the developer.
NSO has internal functions for the same type of management, but specifically for the configuration created by services. However, it is important to note that both reference counters and FASTMAP work with the YANG model of the configuration that NEDs and the Device Manager send to and retrieve from the equipment—not directly with the configuration on the devices themselves.
When a service is created in Cisco NSO and generates a configuration that is pushed to the devices, each part of that configuration receives a reference counter that keeps track of how many services use this configuration—since it could be more than one. An example is an access list reused across all services of a specific type. The configuration also receives a reference pointer back to the service(s) in question. With this pointer back to the service, called a “backpointer,” we have the answer to an important question: How can we determine which services will be affected if we modify a specific part of the configuration on a device?
What is FASTMAP?
In addition to creating reference counters and pointers, FASTMAP is the algorithm that ensures we do not need extra steps to manage service configurations throughout their lifecycle, including updates and removal from the network.
When a service is created, NSO stores a "reverse diff" for that service’s configuration, which contains what is needed to remove this specific instance of the service. If the service is updated, NSO first uses this diff to remove the service (without modifying the device), and then it re-executes the service creation code with the new changes. The difference between this new configuration and the configuration already on the device represents the necessary modifications. Finally, this list of changes is sent to the appropriate NED, which updates the device’s configuration.
Back to reality
So, what does this mean in practical terms for a company using Cisco NSO? Let’s look at an example.
In this scenario, we have already implemented Cisco NSO and are managing our devices and their services through it. However, a technician has logged in directly to a device and made a configuration change. In this case, Cisco NSO will indicate that the device is out of sync because its configuration no longer matches the expected state.
Let’s start with the simplest case: The technician made a mistake, and the change should have been applied via the service in NSO instead. In this situation, we instruct Cisco NSO to push its version of the configuration and overwrite the change. Then, if necessary, we update the service parameters and deploy the updated configuration across the network using NSO. The technician is then trained on what should have been done instead.
But what if the technician was actually correct? If the service is not functioning properly and the change made is not an available parameter in NSO, we instead instruct NSO to sync its view from the device. The imported configuration will not match the expected service state, so Cisco NSO can use the backpointer to identify the affected services.
For example, if an access list used by multiple services has been updated, we may have solved an issue for one service but created problems for four others.
Now, we need to investigate the underlying issue and its solution. Perhaps we need to update the service to include this change and roll it out to all instances of that service across all our devices. Alternatively, we could create a version 2 of the service, allowing users to choose whether this feature should be enabled or disabled. Customers who want the change can migrate to the new version, while those who don’t can retain the older version.
Thinking of Configuration as Services
This service-based view is not limited to externally delivered services. The same logic and configuration management apply to, for instance, AAA configurations—a service that all devices should have as soon as they are deployed. This allows us to automatically apply it while ensuring we are notified if someone modifies it so we can revert it to the expected state. However, it’s also possible that updates or modifications will be necessary at times. The same principle applies to all other parts of the "standard" configuration deployed on devices, from CoPP filters to the authentication banner displayed at login.
Thinking of all configurations in terms of services—where every configuration on a device originates from and is managed as a service—can be a significant shift for a company. This is especially true for organizations accustomed to manually tweaking configurations until symptoms disappear (but likely without fixing the underlying issue). Likewise, transitioning to a mindset where the entire lifecycle of a service and all its instances are managed in an industrialized manner, rather than continuously "fixing" the same issues over and over, can be challenging.
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!
Comments