The role of automation in SD-WAN

As enterprises expand across multiple sites, the complexity of managing network traffic, security policies and performance optimization has grown beyond what IT teams can handle through manual intervention alone. For organizations using SD-WAN, automation can help address these challenges.

With centralized orchestration, SD-WAN automation can enable network changes, bandwidth allocation and failover responses quickly, without constant human oversight. This makes automation a key component of resilient, scalable SD-WAN architecture.

Benefits of SD-WAN

SD-WAN became popular for three primary reasons: a unified overlay, centralized configuration and application-aware path selection.

With SD-WAN, users can create a unified virtual overlay while using different types of underlays such as LTE, MPLS or the internet. As a result, an on-site user can access resources on-premises and over the internet simultaneously.

Centralized configuration enables SD-WAN management devices to apply configurations across SD-WAN edge devices at multiple sites. For example, a manager can configure new interface settings across multiple edges.

SD-WAN also classifies traffic by application and applies underlay path-selection policies. This enables users to route different types of traffic over the best-performing underlay for that type of data.  

Engineers have the option to configure and manage SD-WAN devices using either the CLI or GUI, or through automation. Typically, IT managers gravitate more toward automation and GitOps.

With automation and GitOps, users can do the following:

• Express configuration as Ansible, Python or Terraform code.
• Push the code to a Git repository.
• Have a CI/CD pipeline apply the changes.

This approach is popular because SD-WAN deployments can involve many sites, policies and configuration changes that organizations must apply consistently. It also helps when SD-WAN deployments span on-premises and public cloud environments.

Users can manage the SD-WAN devices in the cloud using Terraform or Python. Compared with context-switching between GUIs or manually SSHing into each CLI, this method can also save time.

From intent to SD-WAN deployment

When defining intent for an SD-WAN environment, the resulting configuration should produce a clear and predictable desired state. Future routine changes should also follow the same consistent pattern.

A Git workflow that feeds into a CI/CD pipeline provides the structure users need to move changes from definition to deployment. It does this with the following steps:

1. Change request. The user describes the desired change, such as onboarding a new site or updating a policy. This description can be in a GitHub issue, Linear ticket or Zendesk; any platform that can reference pull/merge requests in the Git repository.
2. New branch and merge/pull request. The user writes the configuration in Python, Ansible or Terraform and commits it to a new, isolated Git branch. Then the user opens a merge/pull request.
3. CI checks. The pipeline automatically checks the change before deployment. This can include linting and testing syntactic validity.
4. Pull request review and approval. Another user reviews the change and the results of the CI checks. This provides human oversight before the change is merged.
5. Merge. Once approved, the branch is merged into the main branch. This records the approved configuration and triggers the deployment pipeline.
6. Staging. The pipeline applies the configuration to a staging environment through the REST API of a centralized SD-WAN management device. Post-checks in the pipeline or users then verify the resulting state against the desired configuration.
7. Deploy to production. The approved configuration is deployed to the production SD-WAN environment, or rolled back if it fails.

SD‑WAN automation patterns and outcomes

Once there is a workflow for deploying changes, users can find patterns that make those changes reusable. They can then measure the outcomes they produce.

Reusable configuration with templates

Reusable templates, for example, help keep configurations consistent across sites.

With reusable templates, users can do the following:

• Create a site template with reusable settings, such as DNS and interface configurations.
• Supply site-specific values, like the hostname, system IP and site ID, as variables.
• Use the template and variables to generate a configuration for each site.

This approach can save time by avoiding manual configuration across sites.

Health and performance signals

Once reusable configuration templates are deployed, users must measure the outcome of the applied configurations. Health and performance signals provide this visibility.

These signals fall into four categories:

• Metrics. Measurements that track how the SD-WAN environment is performing, such as latency, packet loss, bandwidth usage and CPU utilization.
• Events. Occurrences or state changes, such as an interface going down or an app becoming unreachable.
• Alarms. Notifications raised when an event or monitored condition requires attention. For example, an unreachable device can raise an alarm that is sent to Slack.
• Logs. Records of device activity and system messages, such as errors, authentication attempts and connection failures.

SD-WAN platforms expose these health and performance signals through APIs. Users can then have third-party platforms consume them to build dashboards, send notifications or trigger automated actions.

Automation governance and security by design

When implementing SD-WAN automation, there must be controls around who can make changes and how they are deployed. Yes, fast deploys are helpful, but not if the user loses visibility or control.

Two practices can help with this: Change control and pipeline security. These practices make governance and security in automation easier to operate safely at scale.

Change control

Change control ensures that changes are deliberate, tracked and reviewed before they reach production. Here are five ways to establish effective change control:

• Keep documentation. Have documentation about your current network infrastructure. It helps with onboarding new engineers and keeping track of the current network architecture.
• Establish ownership. Defining ownership with a CODEOWNERS file designates the individuals or teams responsible for making changes.
• Use ticketing. Tools like Linear or Zendesk can describe configuration change issues and track related tickets from the application team in an organization.
• Keep changes small. Users can create one issue ticket and break a large configuration change into smaller merge/pull requests that reference that ticket.
• Require peer review. Users should configure a repository to at least one reviewer. This provides a second check for configuration errors and unintended changes.

Pipeline security

Another way to maintain control and visibility over changes is to constrain what the pipeline can access and do. There are several ways users can increase pipeline security, including the following:

• Protect credentials and secrets. Don’t store API tokens, passwords or other credentials directly in configuration files. Use a secrets manager platform or repository variables.
• Limit CI/CD pipeline permissions. Give the pipeline read-only access to the repository. The pipeline only needs to read the configuration files in the repository and then run the Python, Terraform or Ansible command.

Considerations for implementing SD-WAN automation

The foundation for SD-WAN automation is a consistent set of policies and templates interacting with device APIs, a Git repository and clear ownership of repository files.

Once those foundations are in place, users can roll out the automation in phases, such as the following:

• First 30 days: Start with a small number of SD-WAN sites using the existing CI/CD definitions, templates and CODEOWNERS files. Measure deployment time and change failures.
• Days 31–60: Expand the automation to more sites and check that configurations are consistent across devices.
• Days 61–90: Roll out the workflow to the remaining sites, gather and review the results, and refine the policies and templates based on those insights.

This phased approach is similar to software engineering deployment strategies, such as canary and blue/green deployments, where changes are introduced gradually. Over time, this creates a consistent and controlled process for managing SD-WAN changes at scale.

Charles Uneze is a technical writer who specializes in cloud-native networking, Kubernetes and open source.