Catalyst Center Automation with Terraform

Introduction

Managing network infrastructure through a graphical interface works fine when you have a handful of devices, but as your environment grows, manually clicking through menus becomes a liability. Every manual change introduces the risk of human error, inconsistency, and wasted time. This is the problem that Terraform solves when applied to Cisco's Catalyst SD-WAN and IOS-XE platforms.

In this lesson, we explore how Terraform integrates with Catalyst SD-WAN Manager and IOS-XE devices to bring Infrastructure-as-Code principles to network automation. You will learn what Terraform is, why it matters for network engineers, how it communicates with Cisco platforms, and how to set up your environment and write your first execution plans. By the end of this lesson, you will understand the core Terraform workflow, the role of providers and resources, and how to eliminate what is often called "Click-Ops" in favor of repeatable, standardized deployments.

Key Concepts

What Is Terraform?

Terraform is an Infrastructure-as-Code provisioning tool created by HashiCorp. It is widely used across IT roles, from system administrators to developers. Originally open source under the Mozilla Public License (MPL 2.0), HashiCorp has since changed the license to the Business Source License (BSL). Despite the license change, Terraform remains one of the most popular tools for defining and managing infrastructure in a code-driven way.

Several characteristics make Terraform well-suited for network automation:

Agentless -- Terraform does not require any software agent to be installed on the managed devices. It communicates directly using APIs.
Stateful -- Terraform keeps track of every change you make. It maintains a state file that records the current condition of your managed infrastructure, so it always knows what exists and what needs to change.
Declarative -- Instead of writing step-by-step procedures, you describe the intended goal. Terraform figures out the steps needed to reach that goal on its own.
No special programming skills required -- While basic knowledge of coding concepts is helpful, Terraform uses its own configuration language that is straightforward to learn.

Terraform Terminology

Understanding a few core terms is essential before writing any code:

Term	Definition
Execution Plan	A file that defines the provider and resources. It is written in HashiCorp Configuration Language (HCL), similar to JSON, and stored with a `.tf` extension.
Provider	A plugin that makes a collection of resources accessible. For Cisco platforms, there are dedicated providers for SD-WAN and IOS-XE.
Resource	Describes one or more infrastructure objects managed by Terraform. With the IOS-XE Terraform provider, a resource can be considered the same as a configurable feature on the device.

The Terraform Workflow

Terraform follows a consistent four-command workflow:

Command	Purpose
`terraform init`	Initializes the provider plugin. Downloads and sets up the required provider so Terraform can communicate with the target platform.
`terraform plan`	Checks your declarations for validity. This is a dry run that shows you what Terraform intends to do without making any changes.
`terraform apply`	Executes your plan. This is the command that actually provisions or modifies the infrastructure.
`terraform destroy`	Deletes the resources Terraform is managing. Use with extreme caution in production environments.

Best Practice: Always run terraform plan before terraform apply. Reviewing the execution plan helps you catch errors before they reach your network.

Orchestration vs. Click-Ops

Catalyst SD-WAN Manager is already an orchestration and automation tool on its own. So why add Terraform on top of it? The answer comes down to eliminating Click-Ops -- the inefficiencies and errors that arise from manually entering configuration through the GUI.

Consider these benefits of replacing Click-Ops with Terraform:

Eliminate manual errors -- It is incredibly easy to make a mistake when you are nested several levels deep in a configuration menu, manually entering data.
Ensure standardization -- Reusable code blocks guarantee consistent implementations across your network. Deviations from standards become easy to spot.
Reduce configuration complexity -- Do you really need multiple policy profiles to do the same thing in multiple places? Simpler systems are easier to troubleshoot.
Get time back -- When you can easily repeat a task the same way every time, you accomplish more in less time and more often.
Reduce project timelines -- Scale your team better by automating repetitive tasks.

The real goal behind orchestration, automation, and standardization is standardization itself. When we deploy by hands-on-keyboard via CLI, we make mistakes -- it is simply a reality. Terraform helps you deploy quickly while maintaining standards, speed, and flexibility.

How It Works

Cisco Catalyst SD-WAN Terraform Provider

The Catalyst SD-WAN Terraform Provider is developed by Cisco. It allows Terraform to communicate with the Catalyst SD-WAN Manager (formerly vManage) and manage SD-WAN infrastructure as code. The provider leverages the SD-WAN API to read, create, modify, and delete configuration objects.

Authentication to the SD-WAN Manager is handled through JWT-based authentication. When Terraform connects to the SD-WAN Manager, it authenticates via the API and receives a JSON Web Token that is used for subsequent API calls during that session.

IOS-XE Terraform Provider

For branch provisioning and direct device management, Terraform uses the IOS-XE Terraform Provider. This provider communicates with IOS-XE devices using RESTCONF, a standards-based REST API that runs over HTTPS.

The process for getting started with the IOS-XE provider involves three steps:

Enable RESTCONF on the target device -- The device must have RESTCONF enabled so Terraform can communicate with it over the API.
Install Terraform -- Set up Terraform on your workstation or automation server.
Create a directory and your main.tf file -- This is where you define your provider configuration and resources.

Prerequisites for IOS-XE Devices

Before Terraform can manage an IOS-XE device (such as a router or wireless LAN controller), several requirements must be met:

Requirement	Detail
RESTCONF	Must be enabled on all target devices
Username	A user account with privilege level 15 must exist
HTTPS Server	The HTTPS server must be enabled on the device
YANG Suite (optional)	Cisco YANG Suite can be installed to explore RESTCONF, NETCONF, and gNMI models

Cisco YANG Suite is described as the go-to application for network automation development. It allows you to explore RESTCONF, NETCONF, and gNMI interfaces in an intuitive way that is easy to set up. This tool is valuable during development because it helps you understand the YANG data models that Terraform resources map to.

Configuration Groups and Modularity

A powerful concept when working with Terraform and Catalyst SD-WAN is configuration groups and modularity. Rather than creating monolithic configuration files, you break your infrastructure definitions into reusable modules. Each module handles a specific function -- perhaps one defines your WAN transport, another defines your security policies, and another handles your branch site templates.

This modular approach directly supports standardization. When every branch site pulls from the same Terraform module, you guarantee that each deployment follows the same pattern. Troubleshooting becomes simpler because you know exactly what the configuration should look like.

Configuration Example

Enabling RESTCONF on an IOS-XE Device

Before Terraform can manage an IOS-XE device, RESTCONF and the HTTPS server must be enabled. Configure the target device as follows:

conf t
restconf
ip http secure-server
username admin privilege 15 secret Lab@123
end

Each line serves a specific purpose:

restconf -- Enables the RESTCONF API on the device, allowing Terraform to communicate using REST calls.
ip http secure-server -- Activates the HTTPS server, which RESTCONF requires as its transport.
username admin privilege 15 secret Lab@123 -- Creates a local user with the highest privilege level, required for full configuration access via the API.

Creating the Terraform Project Structure

On your workstation, create a working directory and your initial execution plan file:

mkdir terraform-branch
cd terraform-branch

Inside this directory, you create your main.tf file. This file defines the provider and the resources you want to manage. The file uses HashiCorp Configuration Language (HCL), which has a syntax similar to JSON and is stored with the .tf extension.

Running the Terraform Workflow

Once your .tf files are ready, you execute the standard workflow:

terraform init

This command initializes the provider plugin. Terraform downloads the specified provider (for example, the IOS-XE provider or the SD-WAN provider) and prepares the working directory.

terraform plan

This command validates your declarations and shows you exactly what Terraform intends to do. Review the output carefully. Look for any unexpected additions, modifications, or deletions.

terraform apply

This command executes the plan. Terraform communicates with the target devices or the SD-WAN Manager via their respective APIs and applies the declared configuration.

Important: The terraform destroy command removes all resources managed by Terraform. In a network automation context, this is not typically used in production because destroying network configuration can cause outages. Treat it as a lab or development tool.

Terraform vs. Ansible for IOS-XE

The reference material highlights a useful comparison between Terraform and Ansible for IOS-XE device management:

Attribute	Ansible	Terraform
Agent	Agentless	Agentless
Transport	SSH	RESTCONF
State	No built-in state management	State management included
Approach	Procedural	Declarative
Templating	Jinja2 templating support	HCL-native templating

Both tools are agentless, but they differ in how they communicate with devices and how they track changes. Ansible uses SSH and follows a procedural approach where you define the exact steps. Terraform uses RESTCONF and follows a declarative approach where you define the desired end state. The state management built into Terraform is a significant advantage -- it always knows what the current configuration looks like and can calculate the minimal set of changes needed.

Real-World Application

Branch Provisioning at Scale

One of the most compelling use cases for Terraform in Cisco environments is branch provisioning. When an organization needs to deploy dozens or hundreds of branch sites, each with routers and wireless LAN controllers, doing so manually through the GUI is not sustainable. Terraform allows you to define a branch template once and deploy it repeatedly with site-specific variables.

SD-WAN Policy Standardization

In Catalyst SD-WAN deployments, organizations often end up with multiple policy profiles that effectively do the same thing. This happens because different engineers create policies at different times without a single source of truth. Terraform solves this by making your policies code. Every policy is version-controlled, reviewed, and deployed from the same codebase. If someone needs to understand why a policy exists, they look at the code and its commit history.

Design Considerations

When planning a Terraform-based automation strategy for Cisco infrastructure, keep these points in mind:

Start with what saves the most time. Identify the tasks you repeat most often and automate those first. The goal is to get things done more efficiently.
Use modules for reusability. Break your Terraform code into modules that correspond to logical functions in your network. This ensures standardization and simplifies maintenance.
Leverage Catalyst SD-WAN Manager where it makes sense. Terraform does not need to replace everything the SD-WAN Manager does. Determine what you need from Terraform versus what you can keep doing in the manager's GUI.
Test with terraform plan religiously. Never skip the plan step. In networking, an unintended change can cause an outage.
Treat terraform destroy with caution. In a production network context, destroying resources is rarely appropriate.

Summary

Terraform is an agentless, stateful, declarative Infrastructure-as-Code tool that eliminates manual Click-Ops errors and enforces standardization across network deployments.
The Terraform workflow follows four commands: init to set up the provider, plan to validate, apply to execute, and destroy to remove resources.
The IOS-XE Terraform Provider communicates with devices via RESTCONF and requires RESTCONF, HTTPS, and a privilege-15 user account to be configured on target devices.
The Catalyst SD-WAN Terraform Provider uses JWT-based authentication to manage SD-WAN infrastructure through the SD-WAN Manager API.
Compared to Ansible, Terraform offers built-in state management and a declarative approach using RESTCONF, while Ansible uses SSH with a procedural model.

In the next lesson, we will build on these foundations and explore how to structure Terraform modules for multi-site SD-WAN deployments, putting the concepts from this lesson into practice at scale.