Curious how you can validate complex network designs in minutes — not hours — while keeping operations secure and predictable?
We build an automated sd-wan lab inside cisco modeling labs so teams in Singapore can test architecture, change controls, and onboarding with clarity. Our approach gives hands-on visibility into control planes, underlay and overlay design, and onboarding flows.
The open-source lab deployment tool automates Catalyst cisco sd-wan fabric creation. It speeds up controller deployment, edge onboarding, certificate tasks, and backup/restore — standardizing topology and images for repeatable results.
We set clear expectations and practical phases — requirements, install, setup, deploy, scale, maintain, backup — so teams can reproduce, reset, and reuse the environment. For related operational guidance, see our piece on hybrid WAN management best practices.
Key Takeaways
- Automation cuts setup time — build repeatable Catalyst fabrics in minutes.
- The deployment tool standardizes topology, images, and onboarding tasks.
- Hands-on testing shows control plane and overlay behavior before production.
- Guidance is practical for Singapore teams focused on speed and capacity planning.
- Follow clear phases to deploy, scale, maintain, and back up confidently.
What You’ll Learn in an Expert-Led SD-WAN Lab Environment
In an expert-led environment, automation turns complex network validation into a repeatable routine. We focus on practical outcomes—speed, consistency, and clear troubleshooting artifacts.
Why automation matters for modern deployment
Manual builds slow validation and invite configuration drift. Automation sets a consistent baseline so teams across Singapore get the same results.
What “minutes, not hours” looks like
The lab deployment tool automates fabric creation in CML. Run a single setup once, deploy a base pod, then add edges and controllers on demand. That workflow saves precious time and reduces rebuilds.
Outcomes you’ll learn:
- Control plane formation and onboarding prerequisites.
- How underlay transports shape overlay behavior.
- Operational support steps and reproducible artifacts for troubleshooting.
| Area | Benefit | Result | Notes |
|---|---|---|---|
| Setup | One-time run | Repeatable topology | Version guardrails |
| Deployment | Automated tasks | Minutes to ready | Edge and controller add-ons |
| Support | Consistent artifacts | Easier troubleshooting | Clear logs and state |
Why Use Cisco Modeling Labs for an SD-WAN Lab Deployment
For realistic validation, we use Cisco Modeling Labs to standardize topology lifecycle and governance. The platform gives repeatable topologies, clear resource controls, and a purpose-built environment for training and network validation.
Where CML can run
CML supports on-prem server installs — either bare-metal or as a VM on ESXi — and cloud instances on AWS. This flexibility helps teams match procurement, security, and cost rules in Singapore.
When clustering is worth it
Cluster when you need higher device density, multiple pods, or parallel users. Clustering increases capacity and makes performance predictable for bigger deployments.
Minimum platform requirement
Requirements: CML version 2.6 or higher. Using the correct version avoids unsupported behaviors and reduces wasted effort during lab deployment and ongoing support.
- Choose machine size aligned to simulated controllers and edges — more devices need more CPU/RAM.
- Pick the right server footprint to reduce rebuilds and protect timelines.
- Use CML as the control point for images, topology lifecycle, and access governance.
Core Components in a Catalyst SD-WAN Fabric Lab
This section maps the essential nodes and services that make a Catalyst cisco sd-wan fabric operational. We describe what each component does and how the pieces form a testable topology for Singapore teams.
SD-WAN Manager role in control and visibility
vmanage is the operational hub—policy, visibility, templates, and lifecycle control. We use vManage for onboarding, centralized templates, and to view device state during validation.
Control plane building blocks
The deployment tool creates a Validator and a Controller to form a stable control plane. These controllers and validators establish trust, orchestration, and the fabric heartbeat.
Edge routers and vEdge behavior
Edge nodes include gateway and vedge routers. They represent branch connectivity and attach to transports so we can test real branch bring-up patterns.
Underlay transports
We simulate two underlays—INET and MPLS—to test path selection and separation. This lets teams exercise transport failover and metrics without production risk.
Certificates and onboarding prerequisites
Certificate workflows are first-class tests. We validate CSR signing, OTP onboarding, and template assignments so certificate issues don’t surprise production.
- Core components: SD‑WAN Manager, Validator, Controller, Gateway router.
- Focus: control plane stability, edge bring-up, and onboarding artifacts.
- Underlays: INET and MPLS for realistic transport testing.
Practical note: For related operational guidance on connectivity and replication in the region, see our cloud replication connectivity write-up.
Prerequisites and Requirements for the SD-WAN Lab Deployment Tool
Proper preparation reduces rebuilds and saves time. We set clear system requirements so teams in Singapore can plan installs and avoid common pitfalls.
Supported host OS
Linux and macOS are the supported host systems. For Windows, use WSL, a Linux VM, or a container runtime to run the tool reliably.
Python and version pitfalls
Target Python 3.9.x. Newer releases may fail due to dependency constraints—pyats in particular can break on later versions. Use the exact version to reduce troubleshooting.
Dependency and environment basics
Create a virtual environment and install via pip. Dependencies live in the pyproject.toml file in the repository. This keeps the environment repeatable and isolates packages from the host system.
Connectivity and images
Fast connectivity between the tool host and CML is essential for controller image upload. A nearby build host or jump host minimizes network friction and speeds image and file transfers during deployment.
- Requirements: supported OS, Python 3.9, virtualenv, pip, pyats.
- Best practice: standardize a build host close to CML to improve connectivity and deployment time.
How to Install and Verify the Lab Deployment Tool
We start with a dedicated workspace and a Python virtual environment to keep installs repeatable and auditable. This approach improves support and reduces finger-pointing when multiple engineers manage the project.
Create a workspace and virtual environment
Make a clean folder, then create and activate a venv. This isolates packages and keeps your system tidy.
“A controlled environment prevents surprises during uploads and image management.”
Install via pip and validate
Run an upgrade and install the package. Example command sequence:
mkdir csdwan && cd csdwan
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip setuptools
pip install --upgrade catalyst-sdwan-lab
Verify the install with sdwan-lab –version or csdwan –version. Confirming the version avoids failed uploads or mismatched files before touching CML.
Post-upgrade best practice
After any upgrade, run csdwan setup once. This refreshes node and image definitions so subsequent deploy or backup tasks use current metadata.
| Step | Command | Why it matters |
|---|---|---|
| Workspace | mkdir csdwan | Repeatable installs and clear file ownership |
| Virtualenv | python3 -m venv venv | Isolate packages from the host system |
| Install | pip install catalyst-sdwan-lab | Installs the deployment tool and CLI |
| Verify & Setup | csdwan –version + csdwan setup | Confirms version and refreshes definitions |
How to Build Your sd wan lab Topology in CML Using Setup and Deploy
Begin with a one-time platform setup that registers node and image definitions for repeat use. The setup task creates required node entries—Manager, Validator, Controller, and Edge—and detects software images placed in your working folder.
The tool uploads found images to CML, maps them to node definitions, and creates image definitions automatically. You can also run an optional cleanup to delete old image definitions for a specific software version.
What the deploy task creates
The deploy task instantiates a base topology with two underlays (INET and MPLS), one Manager, one Validator, one Controller, and a gateway router. It configures control components and signs certificates, then applies basic templates and configuration groups.
Network and overlay details
Deploy uses fixed subnets so teams avoid addressing conflicts: VPN0 172.16.0.0/24 (fc00:172:16::/64), INET 172.16.1.0/24 (fc00:172:16:1::/64), and MPLS 172.16.2.0/24 (fc00:172:16:2::/64). The topology includes an External Connector (bridge) and an Internet Connector (NAT).
Overlay IP design is configurable: v4 (default), v6, or dual-stack depending on your enterprise roadmap. For Manager reachability choose a direct IP for simplicity, or use PATty mapping (pat:<port>) when address constraints require NAT—PATty must be enabled on CML.
“Two-step: setup prepares the platform; deploy builds the instance.”
| Task | Action | Result | Notes |
|---|---|---|---|
| setup | Register nodes & images | Reusable definitions | Optional cleanup of old images |
| image handling | Detect & upload | Mapped to node types | Place images in run folder |
| deploy | Create topology | INET/MPLS, control plane, gateway | Applies templates and certs |
Expect time-to-deploy to vary with chosen software version and available CML CPU/RAM. Heavier versions and smaller CML resources increase deploy time—plan sessions accordingly for teams in Singapore.
For decision-makers who need comparative connectivity guidance, see our note on private fibre vs MPLS vs SD-WAN in.
How to Scale, Maintain, and Reuse Your SD-WAN Lab
Scaling a test environment should be predictable — not a rebuild every time demand grows.
Add task: Use the add routine to onboard extra validators, controllers, and vedge devices automatically. It boots nodes with cloud-init, attaches them to the manager, and assigns baseline templates and configuration groups. CPU and RAM overrides are supported during add so you tune per-device resources as you grow.
Resource tuning: Increase CPU for control-heavy nodes and add RAM for high-edge counts. Proper sizing reduces boot time and stabilizes control state as device counts rise.
Backup & restore: The backup task captures CML topology plus templates, policies, and configuration groups. The restore task imports that file, rebuilds the control plane, reinstates templates/policies, and re-onboards vedge edges with a new OTP to preserve identity flows.
Delete & sign: Use delete to remove the environment and all related data — treat this as irreversible. The sign task uses the tool’s Root CA to sign CSR files and emits the signed certificate for test onboarding.
| Task | Primary Action | Outcome | Notes |
|---|---|---|---|
| Add | Onboard validators/controllers/edges | Scaled topology without rebuild | Supports CPU/RAM overrides |
| Backup | Export topology + manager data | Protects templates and policies | Creates a single restore file |
| Restore | Import file + reconfigure | Known-good rebuild | Re-onboards edges with new OTP |
| Sign / Delete | CSR signing / remove data | Test certificates / clean teardown | Delete is irreversible — confirm before running |
Operational tip: For multitenancy or system-interface specifics, see Cisco’s guidance on system interfaces and multi-tenancy.
Conclusion
, We turn complex network scenarios into predictable tests that stakeholders can trust.
An automated sd-wan lab in Cisco Modeling Labs helps us validate Catalyst cisco sd-wan designs faster and with repeatable results. Meet the minimum criteria — CML 2.6+ and a supported host (Linux or macOS; Windows via WSL/VM/container) — and you avoid costly rework.
Follow the workflow: install and verify the lab deployment tool, run setup to prepare CML, deploy the base fabric, then scale with add and protect progress with backup/restore. This sequence makes policy testing, onboarding rehearsal, certificate handling, and underlay/overlay checks practical and measurable.
Plan a first deployment using this guide, then iterate by adding controllers and edges while capturing backups to build a reusable internal practice. For related connectivity and disaster recovery guidance, see our disaster recovery connectivity note.
FAQ
What will we gain from an expert-led SD-WAN lab?
You’ll gain hands-on experience with Cisco SD-WAN components and a repeatable deployment workflow. We walk you through controller and edge roles, overlay and underlay design, image management, and policies — so teams can validate real-world topologies before production.
Why does automation matter for SD-WAN lab deployment today?
Automation reduces manual errors and saves time. Our tool provisions controllers, validators, and vEdge instances, uploads images to Cisco Modeling Labs, applies templates, and seeds certificates — all reproducibly. That lets teams focus on design and testing instead of repetitive setup.
What does “minutes, not hours” look like with an automated workflow?
With proper images and a prepared host, a typical deploy task completes in minutes for basic topologies. Parallel device creation, automated image uploads, and prebuilt templates cut setup time compared with manual VM and device configuration.
Where can Cisco Modeling Labs (CML) run for our deployment?
CML runs on an on-prem server, ESXi virtual machine, or in AWS. We recommend matching CML capacity to your topology — larger labs benefit from dedicated hosts or cloud instances with adequate CPU and RAM.
When is clustering worth it for capacity and scale?
Cluster when you need high device density or concurrent users. Clustering distributes images and device compute across nodes — useful for large simulated WANs or multi-team labs that run tests in parallel.
What is the minimum platform requirement for CML?
Use CML 2.6 or higher to ensure compatibility with modern images, API features, and our deployment tool. Older versions may lack needed functionality for automated topology creation and image management.
What role does the SD-WAN Manager (vManage) play in the lab?
vManage provides centralized control, policy distribution, and visibility. In the lab, it acts as the single pane for templates, feature toggles, diagnostics, and certificate onboarding — mirroring production operations.
What are the control plane building blocks we simulate?
We simulate controllers, validators, and orchestration components to replicate path management and telemetry. This lets you validate control-plane failover, certificate workflows, and policy propagation under test conditions.
How do WAN Edge and vEdge routers fit into the topology?
Edge devices provide branch and transport connectivity. Our deployments create vEdge or Cisco Catalyst-based edge instances connected to INET and MPLS underlays so you can test routing, path selection, and QoS.
What underlay transport options are included in the lab topology?
The tool supports Internet and MPLS underlays, plus mixed connectors. You can model realistic transport diversity to test path selection, tunnel behavior, and service chaining.
What certificates and onboarding prerequisites will we simulate?
We simulate CSR generation, signing, and certificate installation for vManage and edges. The workflow includes OTP-based edge onboarding and validator interactions so you can validate lifecycle operations.
Which host operating systems does the deployment tool support?
The tool runs natively on Linux and macOS. Windows is supported via WSL, a VM, or container. We recommend Linux hosts for best performance during image uploads and CML API interactions.
What Python version should we use and what pitfalls exist?
Use Python 3.9.x to avoid dependency conflicts. Newer or older interpreters may cause package mismatches with pyats or pip requirements — virtual environments prevent system-level issues.
How should we manage dependencies for reliable installs?
Create a virtual environment and install dependencies with pip. Use pinned requirements, include pyats where needed, and validate installs with version commands to ensure repeatable environments.
What connectivity is required between the tool host and CML?
A fast, low-latency link speeds image uploads and API calls. Uploading large software images to CML benefits from a high-throughput connection — this reduces deployment time and avoids timeouts.
How do we create a workspace and virtual environment for installs?
Make a project directory, create a Python venv, activate it, and install the tool and requirements via pip. This keeps builds isolated and makes rollbacks and upgrades safer.
How do we install via pip and validate the tool version?
Install the package with pip install and run the tool’s –version or similar command to confirm. Keep your virtual environment active when running validation commands.
What post-upgrade step should we run before other tasks?
Run the setup task after upgrades to refresh image definitions, node mappings, and templates. This ensures the deploy task uses current metadata and avoids inconsistencies.
What does the setup task perform in CML topologies?
Setup creates node definitions, registers image definitions, and offers cleanup options. It prepares CML for deployment by ensuring required images and device types are available.
How does the tool detect and upload software images and versions?
The tool scans local image directories or specified sources, matches file signatures to expected versions, and uploads missing images to CML via API. It flags mismatches for manual review.
What does the deploy task create in the lab?
Deploy provisions INET/MPLS underlays, control components like vManage and controllers, and a gateway router for external reachability. It wires VPNs and connector links to form a working fabric.
What network and subnet details are used by the deploy task?
Deploy uses defined networks for VPN0, INET, MPLS, and connector interfaces. You can supply CIDR ranges and gateway addresses to match your desired topology and test scenarios.
How do we choose overlay IP design — IPv4, IPv6, or dual-stack?
Select IPv4-only for simplicity, IPv6 for modern addressing, or dual-stack to test mixed environments. The tool supports all three and applies addressing consistently across devices.
What external reachability options exist for SD-WAN Manager?
You can expose vManage via a direct IP or use PATty-style port mapping through the CML gateway. Choose based on your access requirements and security posture.
What affects time-to-deploy in CML?
Deployment time depends on SD-WAN software version, image sizes, and available CML resources. Larger images and constrained CPU/RAM extend deployment duration.
How do we scale the lab to add more controllers and edges?
Use the add task to onboard additional validators, controllers, and edges automatically. The tool updates templates and certificate workflows so new devices join the fabric cleanly.
How should we tune CPU and RAM for device performance?
Allocate more vCPU and RAM per device for high-load simulations. Adjust CML node profiles or ESXi instance settings to meet device-level performance needs during stress tests.
What does the backup task save from the lab?
Backup captures topology state plus templates, policies, and configuration groups. This lets you restore a functional lab with consistent policy and device settings.
How does the restore task rebuild and re-onboard edges?
Restore recreates the topology from the backup and re-issues onboarding OTPs for edges. It re-applies templates and policies so devices return to a known state.
How do we safely delete lab data when finished?
Use the delete task to remove lab artifacts and free CML resources. The tool provides safe cleanup options to avoid accidental removal of shared images or templates.
What is the sign task and how are certificates handled?
The sign task automates CSR creation and signing workflows for vManage and edges. It manages certificate lifecycles within the lab so you can validate authentication and trust models.
0 comments