Cisco Catalyst SD-WAN Deep Dive Part 8: Automation — vManage API, Terraform, and Ansible

Everything covered so far — templates, policies, certificates, device onboarding — is something a human can click through in vManage’s GUI. It’s also, without exception, something the GUI itself does by calling vManage’s own REST API. That single fact is what makes this post possible: there’s no clicking to automate around, because the API the GUI uses is the same API available for everything else.

Why this is a different automation problem than CLI scripting

Elsewhere on this site, network automation has mostly meant scripting against individual device CLIs or NETCONF endpoints — Netmiko opening an SSH session and sending commands, Nornir orchestrating that across an inventory in parallel. That model exists because most network gear doesn’t have a controller sitting in front of it with a unified view of the whole estate; you either talk to each box or you don’t talk to it at all.

Catalyst SD-WAN inverts that. vManage is the controller with the unified view — it already holds every device’s template assignment, every policy object, every certificate, as structured state — so automating the fabric means talking to vManage’s API once, not opening a session to forty WAN Edges one at a time. This is the practical payoff of the controller-based architecture from Part 1: a centralized management plane isn’t just an operational convenience for human admins, it’s what turns “automate the SD-WAN fabric” into an API-integration problem instead of a CLI-scraping problem. Netmiko and Nornir are exactly the right tools for boxes that only expose a CLI; Catalyst SD-WAN’s API already solves that same underlying problem a different way.

Terraform: desired state, declared once

Cisco maintains a Terraform provider for Catalyst SD-WAN that wraps the vManage API in Terraform’s usual resource model — feature templates, device templates, centralized policy objects, and device-to-template attachments all become Terraform resources, with the fabric’s configuration living in version control as the single source of truth. A trimmed example, defining a feature template as code:

resource "sdwan_cisco_system_feature_template" "branch_system" {
  name        = "branch-system-template"
  description = "Standard branch system settings"
  device_types = ["vedge-CSR-1000v"]

  site_id   = var.site_id
  system_ip = var.system_ip
}

This is the right model when the goal is steady-state configuration management — drift detection, peer review on a pull request before a template change ships, a single declared truth for what every branch’s template should look like. It’s the same GitOps motivation that shows up anywhere infrastructure-as-code is used, just pointed at vManage’s object model instead of a cloud provider’s.

Ansible: procedural tasks, ad hoc and sequenced

Cisco also maintains an Ansible collection for Catalyst SD-WAN, with modules covering device inventory, template operations, and policy management. Where Terraform’s strength is declaring desired state, Ansible’s strength is sequencing — a playbook is a better fit for “onboard these twelve new sites, in this order, with these certificate steps in between” than for “this is what the fabric should permanently look like.” A trimmed onboarding-flavored playbook task:

- name: Attach device template to new branch edges
  cisco.sdwan.cisco_sdwan_device_template_attach:
    template_name: "branch-system-template"
    device_list: "{{ new_branch_edges }}"
  register: attach_result

Most real shops end up using both: Terraform owns the templates and policy objects as long-lived declared state, Ansible handles the day-2 operational sequencing — bulk onboarding, certificate rotation runs, scripted maintenance windows — that doesn’t fit a desired-state model well. It’s the same division of labor that shows up in general infrastructure automation, not something specific to SD-WAN; Catalyst SD-WAN just happens to expose a clean enough API surface for both tools to plug into without anyone needing to fall back on screen-scraping a CLI.

Next

Part 9 is the one most readers arrive at directly: the MPLS-to-SD-WAN cutover playbook — sequencing an actual migration, transport by transport, without the bad weekend.