Mental model
Cisco objective 5.6 (v1.1) says “Describe the capabilities of automation tools such as Ansible, Terraform, and Cisco NSO”. The v1.0 blueprint also mentioned Puppet and Chef; v1.1 dropped them. Three tools now.
Each solves a slightly different problem.
| Tool | Shape | Best for |
|---|---|---|
| Ansible | Imperative-ish; task list in YAML; agentless | Config of servers and network devices; smaller teams; SSH everywhere |
| Terraform | Declarative; HCL config files; providers | Cloud resources; one source of truth for mixed-stack infra |
| Cisco NSO | Declarative, model-driven; speaks YANG natively | Multi-vendor network service orchestration; strict change control |
Ansible
How it works
- A playbook is YAML listing tasks (per-step actions).
- An inventory lists hosts (
sw1 ansible_host=10.0.0.1). - Ansible SSHes to each host (or hits an API for cloud / network devices) and runs each task.
- Each task calls a module (
ios_config,copy,apt,template). - Modules are built to be idempotent: same task, no change if the system already matches.
What a playbook looks like
- hosts: switches
gather_facts: no
tasks:
- name: Set NTP server
cisco.ios.ios_ntp:
server: 10.0.0.1
state: present
See reading an Ansible playbook.
Pros + cons
| Pros | Cons |
|---|---|
| Agentless — no software to install on managed hosts | Slower than parallel API calls at huge scale |
| YAML is accessible to non-coders | YAML gotchas (indentation, yes as bool) |
| Big module ecosystem (Cisco, Juniper, Palo, cloud) | Imperative-ish ordering can hide intent |
Checks mode (--check) for dry run | Needs Python on controller (not target) |
Terraform
How it works
- Write declarative
.tffiles describing resources. terraform initfetches providers (plugins for AWS, Azure, Cisco DNA Center, Catalyst SD-WAN, NSO).terraform planshows the diff vs current state.terraform applyreconciles live state to match configuration.- A state file records what Terraform knows exists (usually in S3 / blob storage with locking).
What a config looks like
resource "aws_instance" "web" {
ami = "ami-0abc12345"
instance_type = "t3.small"
}
resource "ciscodnacenter_site" "nyc" {
name = "nyc-dc1"
type = "building"
}
Pros + cons
| Pros | Cons |
|---|---|
| Fully declarative; plan vs apply loop | Learning curve (HCL + state) |
| Huge provider ecosystem | State file needs careful handling (lock, backup) |
| Dry run is first-class | Not great for day-2 operational tasks (reboots, show commands) |
| Deep cloud support | Still catching up on network device coverage vs Ansible |
Cisco NSO (Network Services Orchestrator)
How it works
- Service models describe network services (MPLS L3VPN, QoS profile, firewall rule set) once.
- Device models describe each vendor’s config via YANG.
- Operator maps a service to devices; NSO figures out the vendor-specific config and pushes atomically.
- Change can be committed, dry-run, rolled back cleanly.
- Speaks NETCONF / RESTCONF natively, Netmiko / Expect for legacy CLI.
Why NSO is different
- Cross-vendor by design. One service, Cisco + Juniper + Arista rendering.
- Transactional. Half-applied changes get rolled back; no partial-config problems.
- State-aware. Knows what config IT has pushed vs what the device actually has.
When to reach for it
- Managed service provider that pushes MPLS L3VPN services to hundreds of PE devices across vendors.
- Change-sensitive enterprise where “half the fabric got the change, half didn’t” is unacceptable.
- Service abstraction so operators pick from a menu instead of writing per-vendor CLI.
Comparison table
| Attribute | Ansible | Terraform | Cisco NSO |
|---|---|---|---|
| Paradigm | Imperative-ish declarative | Fully declarative | Model-driven declarative |
| Config language | YAML | HCL (.tf) | YANG + templates |
| Agent | None (SSH / API) | None (API) | None (NETCONF / API) |
| Primary audience | Server & network admins | Infra engineers | Service providers, large enterprise |
| Dry run | --check | plan | commit dry-run |
| State | Not required | State file | Transaction log + CDB |
| Open source | Yes | Yes (BSL) | No (commercial) |
| Cross-vendor | Via modules | Via providers | Native goal |
What dropped from the v1.1 blueprint
- Puppet and Chef — still in use at some sites but Cisco removed them from the exam. If you see them in older study material, note the change.
- Terraform was added (previously not called out explicitly).
FAQ
Which should I learn first? Ansible — easiest to install, YAML is accessible, works against existing SSH-only gear.
Can I use all three on the same network? Yes. Common pattern: Terraform for cloud + Catalyst Center templates; Ansible for day-2 config and ad-hoc tasks; NSO for the carrier-grade service layer. They coexist.
Does NSO really need a license? Yes. There is a free developer edition for learning (NSO Learning License). Production use is paid, typically by number of managed devices.
Is Ansible going agent-based? No. Agentless is a core design choice. Ansible Automation Platform (RedHat) adds a central controller, but managed nodes still have no agent.