Cisco NSO (Network Services Orchestrator) is one of the most powerful network automation platforms available. It is also one of the most misunderstood. Most engineers hear "orchestrator" and think it is just another configuration management tool. It is not. NSO is fundamentally different from Ansible, Terraform, or custom Python scripts, and understanding those differences is the key to using it effectively.
What Makes NSO Different
The core difference is that NSO maintains a model of your network's intended state. When you tell NSO to configure something, it does not just push commands to a device and hope for the best. It compares the desired state against the current device state, calculates the minimum set of changes needed, and applies them transactionally. If any part of the change fails, the entire transaction rolls back.
This is not how most automation works. A typical Ansible playbook pushes a list of commands in order. If command 5 out of 10 fails, commands 1 through 4 have already been applied, and you are left with a partially configured device. NSO's transactional model prevents this entirely.
Understanding Sync States
The first concept every NSO user must understand is sync state. NSO maintains its own database (the CDB) that contains what it believes the device configuration should be. The actual device has its own running configuration. These two can get out of sync in several ways:
- **Out-of-band changes:** Someone logs into the device directly and makes a change without going through NSO. Now the device config differs from what NSO expects.
- **Failed deployments:** A change was attempted but did not fully apply. NSO thinks the change was made, but the device has the old config.
- **Initial onboarding:** When you first add a device to NSO, the CDB is empty but the device already has a configuration.
NSO provides two operations to handle sync issues. **Sync-from** reads the device's current configuration and updates the CDB to match. **Sync-to** pushes the CDB configuration to the device, overwriting whatever is there. Getting these backwards can ruin your day, so understand them before you run either one in production.
Reconciliation: The Hard Part
When you bring an existing network under NSO management, you face the reconciliation challenge. Your devices already have configurations — they are running in production. NSO needs to understand which parts of those configurations are managed by NSO services and which are "brownfield" config that was applied manually or by other tools.
The reconciliation process goes like this:
- **Sync-from all devices.** This pulls the current running configurations into the CDB so NSO has an accurate picture of what exists.
- **Create your service models.** Define the services that should manage specific configuration elements — BGP peerings, VLANs, ACLs, whatever your services cover.
- **Deploy services with reconciliation.** When you deploy a service against existing config, you use the reconcile flag. This tells NSO "this config already exists on the device, just take ownership of it in the CDB." Without the reconcile flag, NSO would try to create the config fresh and fail because it already exists.
- **Verify.** After reconciliation, run a check-sync on every device. If everything is in sync, NSO now owns those configuration elements and can manage them going forward.
This process sounds straightforward on paper. In practice, it is the most time-consuming part of any NSO deployment because real networks are messy. Configurations have been modified by dozens of engineers over years. Naming conventions are inconsistent. There are orphaned configurations that no one remembers the purpose of. All of this has to be sorted out during reconciliation.
Service Models: Think in Services, Not Commands
The biggest mental shift NSO requires is thinking about your network in terms of services rather than device commands. Instead of "apply these 15 commands to router A and these 20 commands to switch B," you define a service like "create a Layer 3 VPN between site A and site B with this bandwidth and these route targets."
NSO takes that service definition and compiles it down to the device-specific commands for every device involved. If site A has a Cisco router and site B has a Juniper router, NSO generates IOS-XR commands for one and Junos commands for the other — from a single service definition.
Service models are written in YANG, which is a data modeling language. YANG defines the inputs your service accepts (site names, IP addresses, bandwidth, etc.) and a mapping template or Python code that translates those inputs into device configuration. Learning YANG is unavoidable if you want to use NSO seriously, but the basics are approachable for anyone who has written XML or JSON schemas.
Practical First Steps
If you are evaluating NSO or about to start your first deployment, here is the order we recommend:
- **Start with the local install in a lab.** Get NSO running on a Linux VM, add two or three netsim devices (virtual devices that NSO provides for testing), and practice sync-from, sync-to, and basic config changes through the CLI and REST API.
- **Build one simple service.** Start with something small — a loopback interface service that creates a loopback on any device with a specified IP. This teaches you the YANG-to-template workflow without overwhelming complexity.
- **Practice reconciliation.** Manually configure some devices, then bring them under service management using the reconcile flag. Break things on purpose and learn how NSO's rollback and compare-config tools help you recover.
- **Connect to real devices.** Once you are comfortable in the lab, add a real device (start with a non-production switch) and repeat the exercise. The difference between netsim and real hardware will teach you lessons that lab-only experience never will.
Common Mistakes to Avoid
Do not skip the lab phase and go straight to production. Do not ignore out-of-band change detection — set up a process for handling it from day one. Do not try to model your entire network as services in the first sprint — start with one service type and expand. And do not underestimate reconciliation time. Budget twice as long as you think it will take.
Originally published at https://primeautomationsolutions.com
Top comments (0)