Modern enterprise WANs are becoming increasingly software-driven. With Cisco SD-WAN, centralized management, policy-based configuration, APIs, templates, and automation provide a strong foundation for managing large numbers of branch and data-center sites.
But there is an important question:
How can network engineers make SD-WAN configuration changes faster without sacrificing control and reliability?
One answer is to combine NetDevOps and CI/CD practices with Cisco SD-WAN automation.
Instead of making a configuration change directly on a production device, engineers can define the desired change, store it in Git, validate it, test it, review it, deploy it through the SD-WAN Manager API or automation tools, and finally verify the resulting network state.
A simple way to visualize the approach is:
Design → Git → Validate → Test → Approve → Deploy → Verify
Cisco's SD-WAN Manager API is specifically designed for controlling, configuring, and monitoring devices in the SD-WAN overlay, and Cisco documents Network-as-Code as one of its automation use cases.
What Is NetDevOps?
NetDevOps brings software-development practices into network operations.
Traditional network management often follows this model:
Requirement
↓
Engineer logs in
↓
Configuration change
↓
VerifyThis approach can work well for individual changes, but becomes increasingly difficult when an organization manages hundreds or thousands of SD-WAN sites.
A NetDevOps approach introduces:
- Version control
- Automation
- Automated validation
- Testing
- Peer review
- Controlled deployment
- Configuration history
- Rollback capability
- Continuous verification
For Cisco SD-WAN, this can apply to configuration and policy elements such as:
- Device configuration
- Feature templates
- Device templates
- Configuration Groups
- Policy Groups
- Application-Aware Routing policies
- Security policies
- Routing policies
- VPN configuration
- Transport configuration
- Interface configuration
Cisco's current SD-WAN Manager API documentation includes configuration APIs for templates and policies as well as monitoring and device-management operations.
Why Use CI/CD for Cisco SD-WAN?
SD-WAN is centrally managed by design.
That provides enormous operational advantages, but it also means that an incorrectly designed centralized change can have a much larger blast radius than a change made on a single router.
For example:
Manual Router Change
Engineer
↓
Branch-101compared with:
Centralized SD-WAN Policy Change
Engineer
↓
SD-WAN Manager
↓
Policy
↓
Multiple BranchesThis is where CI/CD can add an additional layer of protection.
Key Benefits
1. Version Control
Configuration and automation artifacts can be stored in Git.
2. Automated Validation
Changes can be checked before deployment.
3. Controlled Testing
Policies and configurations can be tested before production rollout.
4. Peer Review
Another engineer can review the proposed change.
5. Controlled Deployment
The pipeline can deploy only approved changes.
6. Better Auditability
Every change can be associated with a commit, review, pipeline execution, and deployment result.
7. Easier Rollback
Previous versions can be identified and used as part of the recovery process.
Cisco SD-WAN CI/CD Pipeline
A practical SD-WAN pipeline can contain six stages:
1. Source
↓
2. Build & Validate
↓
3. Test
↓
4. Approval
↓
5. Deploy
↓
6. Verify & MonitorLet's examine each stage from a network engineer's perspective.
Stage 1: Source Repository
The process starts with the desired configuration or policy definition.
Instead of immediately changing the SD-WAN environment, the change is stored in a Git repository.
For example:
sdwan-automation/
│
├── devices/
│ ├── branch-101.yaml
│ └── branch-102.yaml
│
├── templates/
│ ├── wan-template.yaml
│ └── security-template.yaml
│
├── policies/
│ ├── app-route-policy.yaml
│ └── traffic-policy.yaml
│
└── scripts/
├── validate.py
└── deploy.pyA typical workflow could be:
Engineer
↓
Feature Branch
↓
Configuration Change
↓
Pull Request
↓
Peer Review
↓
MergeThis gives the network team a history of the proposed and approved changes.
Stage 2: Build and Validate
In software development, the build stage often means compiling an application.
In network CI/CD, the meaning is slightly different.
The pipeline can prepare and validate the SD-WAN configuration before deployment.
Possible checks include:
- YAML/JSON syntax
- Required parameters
- IP addressing
- Site IDs
- VPN definitions
- Template variables
- Policy structure
- Naming standards
- Configuration dependencies
- Security rules
- Organizational standards
For example:
Configuration
↓
Syntax Check
↓
Schema Check
↓
Policy Check
↓
Dependency Check
↓
PASS / FAILIf validation fails, the pipeline should stop.
Validation
↓
❌ FAILED
↓
Stop Pipeline
↓
Notify EngineerThis is much better than discovering the same error after a production deployment.
Stage 3: Test the SD-WAN Change
Testing is one of the most important parts of network CI/CD.
Consider a proposed Application-Aware Routing policy.
The engineer wants business-critical application traffic to prefer MPLS when the SLA requirements are satisfied and use another available transport when they are not.
Before deploying the policy broadly, the pipeline should validate the intended behavior.
Possible checks include:
- Policy syntax
- Policy structure
- VPN configuration
- Application classification
- SLA definitions
- Preferred transport
- Failover behavior
- Routing behavior
- Tunnel status
- BFD status
- Connectivity
- Latency
- Packet loss
- Jitter
A simplified workflow is:
New Policy
↓
Deploy to Test Environment
↓
Generate Traffic
↓
Measure SLA
↓
Verify Path Selection
↓
Test Failover
↓
PASS / FAILStage 4: Approval
After automated testing succeeds, the change can move to an approval stage.
For production SD-WAN, this is particularly important because a centralized policy can potentially affect many sites.
A mature workflow might look like:
Git Commit
↓
Validation
↓
Testing
↓
Security Check
↓
Peer Review
↓
Change Approval
↓
ProductionFor high-risk changes, the pipeline should not automatically proceed without appropriate authorization.
This is an important principle:
Automation should reduce manual effort, not remove operational governance.
Stage 5: Deploy Through SD-WAN Manager
Once approved, the pipeline can use the SD-WAN Manager API or an approved automation framework to perform the deployment.
Cisco documents the SD-WAN Manager REST API for configuration, provisioning, monitoring, and integration with automation platforms.
A simplified architecture is:
Network Engineer
↓
Git Repository
↓
CI/CD Platform
↓
Automation Engine
↓
SD-WAN Manager API
↓
SD-WAN Overlay
↓
Branch / Hub DevicesThe automation layer could use technologies such as:
- Python
- Ansible
- REST API clients
- Terraform where appropriate
- CI/CD platform integrations
Cisco also provides API operations for previewing device configuration and attaching device templates, which can be incorporated into controlled automation workflows.
Stage 6: Verify and Monitor
Deployment should not be considered successful simply because the API returned a successful response.
The pipeline should verify the resulting operational state.
For example:
Deployment
↓
Check Device Status
↓
Check Control Connections
↓
Check OMP
↓
Check BFD
↓
Check Tunnel State
↓
Check Policy
↓
Check Application Performance
↓
SUCCESSCisco's SD-WAN Manager APIs provide access to device and monitoring information, including overlay and application-related operational data.
This enables a much more complete workflow:
Configure → Verify → Observe
rather than simply:
Configure → Assume Success
A Practical Cisco SD-WAN CI/CD Example
Let's consider a real-world scenario.
A company wants to change the application routing policy for its critical ERP application.
The requirement is:
Application: ERP
Preferred Path:
MPLS
Backup Path:
Internet
SLA:
Low latency
Low packet loss
Acceptable jitterInstead of modifying the policy directly in production, the network engineer creates a change request.
Step 1 — Create the Configuration
The desired policy is represented in the repository.
ERP Policy
↓
Preferred Transport
↓
SLA Requirements
↓
Fallback TransportStep 2 — Commit to Git
The engineer creates a feature branch:
main
|
+---- feature/erp-path-policyThe configuration is committed.
Step 3 — Automated Validation
The CI/CD pipeline checks:
✓ Policy syntax
✓ Required parameters
✓ VPN references
✓ SLA definitions
✓ Transport references
✓ Naming standardsStep 4 — Test
The change is tested in an appropriate non-production environment.
The pipeline verifies:
ERP Traffic
↓
MPLS Available?
↓
YES → Use MPLS
↓
MPLS Degraded?
↓
YES → Evaluate Backup Path
↓
InternetStep 5 — Approval
The network team reviews:
- Expected behavior
- Scope
- Potential impact
- Rollback plan
- Test results
The change is approved.
Step 6 — Production Deployment
The automation platform communicates with SD-WAN Manager.
The approved configuration is deployed.
Step 7 — Verification
The pipeline checks:
- Device status
- Policy activation
- Tunnel health
- BFD
- Application path
- Latency
- Loss
- Jitter
If everything passes:
Deployment = SUCCESSIf the expected state is not achieved:
Deployment
↓
Verification Failed
↓
Stop / Rollback / EscalateSD-WAN Manager APIs and Network as Code
One of the biggest advantages of Cisco SD-WAN for NetDevOps is its programmable management interface.
The current Cisco documentation explicitly describes Network-as-Code as a use case for the SD-WAN Manager API.
This changes the mindset from:
"I need to configure 100 routers."
to:
"I need to define the desired network state and automate its deployment."
The API can be used for activities such as:
- Provisioning
- Configuration
- Monitoring
- Device inventory
- Template operations
- Policy operations
- Application statistics
- Alarms and events
Cisco's API examples also demonstrate retrieving inventory and operational information, working with templates and policies, and retrieving application-aware routing statistics.
Git + SD-WAN Manager + Automation
A powerful architecture can look like this:
┌──────────────────┐
│ Network Engineer │
└────────┬─────────┘
│
↓
┌──────────────────┐
│ Git Repository │
└────────┬─────────┘
│
↓
┌──────────────────┐
│ CI/CD Platform │
└────────┬─────────┘
│
┌───────────┴───────────┐
↓ ↓
Validation Testing
│ │
└───────────┬───────────┘
↓
Approval Gate
↓
┌──────────────────┐
│ Automation Engine│
└────────┬─────────┘
↓
┌──────────────────┐
│ SD-WAN Manager │
│ REST API │
└────────┬─────────┘
↓
┌──────────────────┐
│ SD-WAN Overlay │
└──────────────────┘This provides a clear separation between:
Configuration → Validation → Deployment → Verification
What Tools Can Be Used?
A Cisco SD-WAN CI/CD implementation can use several categories of tools.
| Function | Example |
|---|---|
| Source Control | Git, GitHub, GitLab |
| CI/CD | Jenkins, GitLab CI/CD, GitHub Actions |
| Automation | Python, Ansible |
| SD-WAN Interface | SD-WAN Manager REST API |
| Configuration | YAML, JSON |
| Testing | Python/API-based tests, pyATS where appropriate |
| Lab | Cisco Modeling Labs |
| Monitoring | Existing SD-WAN monitoring/observability platforms |
The exact toolset should depend on your organization's existing automation platform and operational requirements.
Traditional SD-WAN Change vs CI/CD Change
Traditional Model
Engineer
↓
SD-WAN Manager
↓
Change
↓
VerifyCI/CD Model
Engineer
↓
Git
↓
Validation
↓
Automated Test
↓
Peer Review
↓
Approval
↓
SD-WAN Manager API
↓
Deployment
↓
VerificationThe second model introduces additional checkpoints before the production network is changed.
Why Git Is Important for SD-WAN
Suppose an application routing policy was changed last week and application performance subsequently degraded.
The engineer needs to determine:
What changed?
With version control, the answer can begin with the repository history.
For example:
Monday
Policy Version 10
↓
Tuesday
Policy Version 11
↓
Wednesday
Performance IssueThe engineer can investigate the difference between versions and correlate the change with operational data.
This provides much stronger change visibility than relying entirely on manual records.
Rollback Strategy
Every automated deployment should have a recovery strategy.
A simplified model is:
Known Good Version
↓
New Version
↓
Deploy
↓
Verify
↙ ↘
FAIL PASS
↓ ↓
Rollback ContinueRollback should be carefully designed for the specific SD-WAN configuration and policy being changed.
For example, a rollback might involve restoring a previously approved configuration or policy version rather than simply reversing individual CLI commands.
CI/CD Does Not Mean Full Automation on Day One
This is an important lesson for network engineers.
You don't need to automate your entire SD-WAN environment immediately.
A safer maturity path is:
Level 1 — Version Control
Store automation and configuration artifacts in Git.
Level 2 — Validation
Automatically validate every change.
Level 3 — Testing
Introduce automated testing.
Level 4 — Approval
Add peer review and controlled approval gates.
Level 5 — Automated Deployment
Deploy approved changes automatically.
Level 6 — Continuous Verification
Verify the network after deployment.
Level 7 — Advanced Automation
Introduce more sophisticated orchestration and Network-as-Code workflows.
This gradual approach helps teams build confidence.
Best Practices for Cisco SD-WAN CI/CD
1. Start With Read-Only Automation
Before automating production changes, automate information collection.
For example:
Device Inventory
Control Connections
OMP
BFD
Tunnel Status
Application Performance2. Use Git for Change History
Keep configuration and automation artifacts version controlled.
3. Separate Test and Production
Never make production the first place where a new pipeline is tested.
4. Use Approval Gates
Especially for centralized policies affecting multiple sites.
5. Protect Credentials
API credentials should not be stored directly in configuration files or Git repositories.
6. Limit Automation Permissions
Give automation accounts only the access they actually require.
7. Build Rollback Into the Process
Do not design deployment first and think about rollback afterward.
8. Verify the Operational Result
An API success response does not necessarily mean the desired business outcome has been achieved.
9. Monitor the Blast Radius
A policy affecting one site is very different from one affecting hundreds of branches.
10. Keep the Pipeline Simple
Start with one useful use case and expand gradually.
CI/CD and Application-Aware Routing
Application-aware routing is an excellent example of where network CI/CD can provide value.
Imagine a policy containing:
Application
↓
Preferred Path
↓
SLA
↓
FallbackA pipeline can validate that:
- The application is correctly identified
- The correct VPN is referenced
- The SLA class exists
- The required transport is available
- The fallback behavior is defined
- The policy does not unintentionally affect unrelated traffic
This can significantly reduce the chance of introducing an incorrect centralized policy.
CI/CD for Security Policy Changes
The same methodology can be applied to SD-WAN security changes.
For example:
Security Policy Change
↓
Syntax Validation
↓
Policy Validation
↓
Security Review
↓
Test
↓
Approval
↓
Deployment
↓
VerificationSecurity changes deserve additional scrutiny because an incorrect policy may create either connectivity problems or unintended exposure.
CI/CD and Multi-Site SD-WAN
One of the biggest advantages of SD-WAN is centralized policy and configuration management.
That same characteristic makes testing and governance important.
Consider:
SD-WAN Manager
|
┌──────────────┼──────────────┐
↓ ↓ ↓
Region A Region B Region C
| | |
Branches Branches BranchesA poorly designed centralized change could affect multiple regions.
A CI/CD pipeline can introduce controls before that change reaches the production environment.
The Future: Network as Code
CI/CD is one step toward a broader Network-as-Code operating model.
The progression can look like:
Manual Configuration
↓
Automation
↓
Version Control
↓
Network as Code
↓
CI/CD
↓
Continuous Verification
↓
Intent-Driven NetworkingCisco's SD-WAN Manager API documentation specifically identifies Network-as-Code as an automation use case, making SD-WAN a natural platform for engineers who want to develop these skills.
CI/CD Skills Every SD-WAN Engineer Should Learn
If you are a traditional network engineer moving toward NetDevOps, you do not need to become a full-time software developer.
Start with:
Git
Learn:
- Clone
- Branch
- Commit
- Pull request
- Merge
- Revert
Python
Learn:
- Variables
- Functions
- JSON
- REST API calls
- Error handling
REST APIs
Understand:
- GET
- POST
- PUT
- DELETE
- Authentication
- HTTP status codes
- JSON
YAML
Learn how to represent configuration and automation data.
CI/CD
Understand:
- Pipeline
- Job
- Stage
- Runner
- Artifact
- Approval
- Deployment
Testing
Learn how to verify whether a network change produced the expected result.
These skills complement traditional networking knowledge rather than replacing it.
A Simple Mental Model
If you remember only one diagram from this article, remember this:
CISCO SD-WAN CI/CD
CHANGE
↓
Git Commit
↓
Validate
↓
Test
↓
Security Check
↓
Peer Review
↓
Approval
↓
SD-WAN Manager
↓
Deployment
↓
Verification
↙ ↘
PASS FAIL
↓ ↓
Done RollbackThis is the foundation of a safer SD-WAN automation strategy.
Final Thoughts
Cisco SD-WAN already provides centralized management, policy-based networking, templates, APIs, and automation capabilities.
CI/CD adds an engineering discipline around those capabilities.
Instead of treating every network change as an isolated administrative task, the change becomes part of a controlled lifecycle:
Define → Version → Validate → Test → Review → Deploy → Verify
The biggest benefit is not simply faster deployment.
It is confidence.
A well-designed CI/CD pipeline can help SD-WAN engineers make changes more consistently, detect errors earlier, maintain better audit trails, and reduce the risk associated with large-scale centralized changes.
For network engineers, learning CI/CD is therefore not about abandoning traditional networking.
It is about adding software-engineering practices to the networking skills you already have.
Frequently Asked Questions
What is CI/CD in SD-WAN?
CI/CD in SD-WAN is a controlled workflow in which configuration and policy changes are versioned, validated, tested, approved, deployed, and verified using automation.
Can Cisco SD-WAN be automated using APIs?
Yes. Cisco provides REST APIs for SD-WAN Manager that can be used for configuration, provisioning, monitoring, and integration with automation workflows.
Can Git be used for Cisco SD-WAN?
Yes. Git can be used to version-control configuration definitions, automation scripts, policy representations, and other deployment artifacts.
What is the role of Python?
Python can act as the automation layer between a CI/CD platform and SD-WAN Manager APIs.
Should SD-WAN production changes be fully automatic?
Not necessarily. High-impact changes should normally have appropriate validation, authorization, and approval controls.
What should be tested before deployment?
Depending on the change, testing can include configuration validity, policy behavior, routing, tunnel health, BFD, application performance, SLA behavior, and security requirements.
What is the biggest advantage of CI/CD for SD-WAN?
The biggest advantage is the ability to make network changes repeatable, auditable, testable, and controlled rather than relying primarily on manual operations.
Related Articles from Netterrene
AI Planning Strategies for SD-WAN Engineers
This article explores planning approaches for SD-WAN scenarios including vManage/SD-WAN Manager, vSmart/SD-WAN Controller, application-aware routing, and multi-site operations.
The Agent Loop in Cisco SD-WAN
A useful follow-up for understanding how AI-driven troubleshooting can investigate WAN health, path performance, application behavior, and policy.
How AI Memory Can Transform Cisco SD-WAN Operations
Explores working memory, long-term memory, and RAG concepts in the context of SD-WAN operations.
Multi-Agent AI Systems for Cisco SD-WAN Engineers
Explains Supervisor, Peer-to-Peer, and Hierarchical agent patterns using SD-WAN operational examples.
Anatomy of an AI Agent for Cisco SD-WAN
A knowledge-assessment style article covering agent concepts and their relationship to SD-WAN troubleshooting and automation.
Need Help With Cisco SD-WAN, ACI or Network Automation?
Need help with Cisco ACI, Nexus, data center networking, SD-WAN, or network automation?
I am a CCIE Data Center engineer with 18+ years of enterprise networking experience.
Contact me for consulting, troubleshooting, design reviews, and project support free of cost.
