SD-WAN Templates: Feature and Device

Introduction

Managing configuration across dozens or even hundreds of SD-WAN edge devices by hand is neither scalable nor safe. A single typo in a VPN definition or an interface assignment can bring down an entire site. This is exactly why SD-WAN templates exist — they let you define configuration once, parameterize the parts that change per device, and push consistent, validated config to every router in your overlay.

In this lesson we break down the two core building blocks of SD-WAN configuration management: feature templates and device templates. You will learn how feature templates encapsulate individual functions such as VPN definitions, Ethernet interfaces, and SVI interfaces, and how device templates stitch those feature templates together into a complete, device-specific configuration. We will also explore how templates integrate with modern Infrastructure-as-Code workflows — including Terraform providers, CI/CD pipelines, pre-change validation, and automated testing — so that your SD-WAN fabric can be managed with the same rigor as application code.

By the end of this lesson you will be able to:

• Distinguish between feature templates and device templates and explain how they relate to each other.
• Read and interpret a structured YAML data model that describes templates.
• Understand the SD-WAN as Code workflow from Git commit through deployment and testing.
• Apply pre-change validation and automated testing concepts to a production SD-WAN environment.

Key Concepts

Feature Templates

A feature template is a reusable configuration fragment that describes a single network function. Rather than writing raw CLI for every router, you create a feature template once and reference it wherever it is needed. Common feature template types include:

• VPN templates — define a VPN (VRF) such as a production data VPN or an IoT VPN.
• Ethernet interface templates — configure physical or logical Ethernet interfaces within a VPN.
• SVI interface templates — configure switched virtual interfaces (Layer 3 VLAN interfaces) within a VPN.

Feature templates use a naming convention that makes their purpose instantly recognizable. For example:

Template Name	Type	Purpose
FT-VPN10-PROD	VPN	Production VPN (VPN 10)
FT-VPN20-IOT	VPN	IoT VPN (VPN 20)
FT-ETH1-VPN10	Ethernet Interface	Ethernet 1 inside VPN 10
FT-ETH2-VPN20	Ethernet Interface	Ethernet 2 inside VPN 20
FT-SVI101-VPN10	SVI Interface	SVI 101 inside VPN 10
FT-SVI201-VPN20	SVI Interface	SVI 201 inside VPN 20

The prefix FT stands for Feature Template, and the remainder of the name encodes the function, VLAN or interface number, and VPN association. This standardized naming is critical when you manage hundreds of templates across a large fabric.

Device Templates

A device template brings multiple feature templates together into a single, deployable unit that targets a specific device or device role. Where a feature template answers "how should this one function be configured?", a device template answers "what is the complete configuration for this router?"

For example, a device template named DT-REMOTE-C8000V-01 with a description of "DC Site - cEdge01" would reference the following feature templates through its VPN template associations:

Device Template	Referenced VPN Templates	Associated Interface Templates
DT-REMOTE-C8000V-01	FT-VPN10-PROD	FT-ETH1-VPN10, FT-SVI101-VPN10
	FT-VPN20-IOT	FT-ETH2-VPN20, FT-SVI201-VPN20

The prefix DT indicates a Device Template. Each VPN template listed inside the device template carries its own set of Ethernet interface templates and SVI interface templates, creating a clear hierarchy: Device Template > VPN Templates > Interface Templates.

Structured Configuration Data

Templates are ultimately expressed as structured configuration data in YAML. This YAML representation serves as a human-readable, version-controllable data model derived from the SD-WAN controller's own managed data model. The benefits of this approach are significant:

Benefit	Description
Standardization	Up to 85% standardization across all sites
Speed	Less time to complete configuration tasks
Accuracy	100% human-error free when deployed through automation
Version Control	100% of configuration changes tracked in Git
Unified DevOps Approach	Lint, syntax, and semantic validation built into the workflow

How It Works

The Template Hierarchy

The SD-WAN Manager organizes templates in a clear hierarchy. At the lowest level sit the feature templates — individual building blocks for interfaces, VPNs, policies, and services. These feature templates are assembled into device templates, which are then attached to specific edge devices or sites.

When you modify a feature template, every device template that references it picks up the change. This cascading behavior is what makes templates so powerful: update an SVI definition in one place and it propagates to every device that uses that feature template.

The SD-WAN as Code data model mirrors this hierarchy in YAML. A simplified structure looks like this:

vpn_templates:
  - name: FT-VPN10-PROD
    ethernet_interface_templates:
      - name: FT-ETH1-VPN10
    svi_interface_templates:
      - name: FT-SVI101-VPN10
  - name: FT-VPN20-IOT
    ethernet_interface_templates:
      - name: FT-ETH2-VPN20
    svi_interface_templates:
      - name: FT-SVI201-VPN20

Each VPN template nests its associated interface templates directly beneath it, preserving the logical relationship between the VPN and the interfaces that belong to it.

SD-WAN as Code Workflow

The SD-WAN as Code framework treats your entire SD-WAN configuration as code managed through a version control system such as Git. The workflow involves several roles and tools:

• A Network Engineer develops the data model and configuration using a code editor with YAML schema support.
• A DevOps Engineer builds and maintains CI/CD pipelines using tools such as GitLab CI or GitHub Actions.
• The SD-WAN Terraform Provider serves as the automation engine that translates the data model into API calls against the SD-WAN Manager.
• The SD-WAN Manager receives those API calls and pushes configuration to the SD-WAN network infrastructure across Internet, MPLS, and LTE transport links.

The end-to-end workflow follows these steps:

1. An operator pushes changes to a feature branch in Git.
2. The CI/CD pipeline triggers automatically on the feature branch.
3. Pre-change validation (input validation and linting) runs to catch syntax and semantic errors before anything touches the network.
4. After validation passes, the operator opens a pull request to merge the feature branch into the master (production) branch.
5. The pipeline triggers again on the master branch, running validation a second time.
6. Terraform deployment executes, applying the configuration to the SD-WAN Manager.
7. Automated testing verifies that the deployment succeeded and the network is in the desired state.
8. Artifacts are stored for audit and rollback purposes.

Best Practice: Pre-change validation runs on both the feature branch and the master branch. This double-gate approach ensures that no invalid configuration ever reaches the SD-WAN infrastructure, even if a merge introduces conflicts.

Pre-Change Validation and Automated Testing

Pre-change validation verifies that the configuration and planned changes adhere to a schema definition. Integrated rules enforce both technical and policy requirements. This validation logic encapsulates deep networking expertise, catching errors that a simple syntax check would miss — such as overlapping subnets, missing route targets, or policy conflicts.

Automated testing runs after deployment to validate that the change was successful and meets the desired intent. These tests integrate with both service-level and device-level health checks to ensure that the change has not caused unintended disruption. For example, a test might verify that every edge router has established the expected number of control connections to the vSmart controllers:

Verify Control Connections for Edge Router router01 (10.1.1.1)
  expected_vsmart_connections = 2
  vsmart_control_connections = 2
  Result: PASS

The testing framework uses templates to generate test cases dynamically for every site and every router defined in the data model. For each router, the test retrieves device health data from the SD-WAN Manager API, extracts the expected and current control connection counts, and compares them.

Configuration Example

Below is an example of a device template definition expressed as a structured YAML data model. This is the format you would commit to your Git repository:

- name: DT-REMOTE-C8000V-01
  description: "DC Site - cEdge01"
  edge_feature_templates:
    vpn_templates:
      - name: FT-VPN10-PROD
        ethernet_interface_templates:
          - name: FT-ETH1-VPN10
        svi_interface_templates:
          - name: FT-SVI101-VPN10
      - name: FT-VPN20-IOT
        ethernet_interface_templates:
          - name: FT-ETH2-VPN20
        svi_interface_templates:
          - name: FT-SVI201-VPN20

Each element in this data model maps directly to a template object on the SD-WAN Manager. The edge_feature_templates key groups all feature templates that apply to this edge device, organized under their respective VPN templates.

A CI/CD pipeline definition that automates the deployment of this data model includes stages for validation, planning, deployment, testing, and notification:

stages:
  - validate
  - plan
  - deploy
  - test
  - notify

deploy:
  stage: deploy
  script:
    - terraform init -input=false
    - terraform apply -input=false -auto-approve
  artifacts:
    when: always
    paths:
      - defaults.yaml

The terraform init command initializes the Terraform working directory and downloads the SD-WAN provider. The terraform apply command with -input=false and -auto-approve flags ensures fully unattended execution within the pipeline — no human prompts, no manual confirmation. The artifacts block preserves the defaults.yaml file regardless of whether the stage succeeds or fails, providing an audit trail.

Important: The -auto-approve flag should only be used in production pipelines after pre-change validation and a successful plan stage have confirmed the changes are safe. Never skip the validation stage.

Real-World Application

Common Deployment Scenarios

SD-WAN templates and the as-Code workflow apply to organizations of every size, but the value increases dramatically with scale. Common scenarios include:

• Multi-site retail or branch deployments — Hundreds of remote sites share the same device template with minor per-site variable differences (hostname, IP addressing, VLAN IDs). Feature templates enforce consistency while device-level variables handle the unique parameters.
• Segmented network environments — Organizations that separate production traffic (VPN 10) from IoT traffic (VPN 20) use dedicated VPN feature templates for each segment, each carrying its own interface templates. This ensures clean separation without per-device manual configuration.
• Brownfield migrations — The SD-WAN as Code framework includes a brownfield import tool that can extract the current state of an existing SD-WAN deployment into the structured YAML data model, giving teams a starting point for adopting Infrastructure-as-Code practices without rebuilding from scratch.

Design Considerations

The SD-WAN as Code approach applies across multiple network domains beyond SD-WAN. The same framework, data model patterns, and CI/CD integration support ACI, Catalyst Center, ISE, Firewall, Meraki, and NDFC deployments. This means a team that masters the template and pipeline concepts for SD-WAN can extend the same skills and tooling to their entire infrastructure.

The solution architecture follows a layered model:

• User Interaction Layer — GitOps, ChatOps, self-service portals, or ITSM integrations initiate changes.
• Source of Truth — Git repositories hold the authoritative data model.
• Automation Engine — Terraform, Ansible, or OpenTofu execute changes through network APIs.
• Orchestration — The SD-WAN Manager, Catalyst Center, or other controllers push configuration to the physical, virtual, or cloud infrastructure.

Best Practice: Maintain a single source of truth in your Git repository. All configuration changes should flow through the CI/CD pipeline — never apply changes directly on the SD-WAN Manager UI in production, as this creates configuration drift that is difficult to detect and reconcile.

Summary

• Feature templates are reusable configuration building blocks for individual functions (VPNs, interfaces, SVIs), while device templates combine multiple feature templates into a complete per-device configuration.
• The template hierarchy flows from device templates down through VPN templates to interface templates, and changes to a feature template cascade to every device template that references it.
• SD-WAN as Code treats the entire SD-WAN configuration as structured YAML data managed in Git, deployed through Terraform, and validated through CI/CD pipelines.
• Pre-change validation catches errors before deployment, and automated testing verifies the network state after deployment — together they deliver 100% human-error-free configuration changes.
• The same as-Code framework and principles extend beyond SD-WAN to ACI, Catalyst Center, ISE, Firewall, Meraki, and NDFC, enabling a unified DevOps approach across all network domains.

In the next lesson, we will build on these template concepts and explore how policy objects and centralized policies control traffic behavior across the SD-WAN fabric.