Cisco SD-WAN lab, onboarding and templates: from controllers to configured edges
In short: A Cisco SD-WAN lab needs the Manager, Controller and Validator images plus some edges, run in CML, EVE-NG or a cloud. Devices are trusted only if their serial numbers are on the allowed list, usually synced from Plug and Play Connect. Once an edge joins, the Manager pushes its configuration from device templates built from reusable feature templates with per-site variables.
Building a lab
You learn Cisco SD-WAN fastest by building it. The options are:
- Cisco Modeling Labs (CML): Cisco's own simulator, with SD-WAN images available for licensed users. Good integration and supported images.
- EVE-NG: a popular emulator where you upload the controller and edge images yourself.
- Cisco dCloud and sandboxes: ready-made, time-limited labs with nothing to install.
- A cloud account: controllers and virtual edges as virtual machines, closest to a real deployment but you pay while it runs.
The Manager is the hungriest component: plan for several virtual CPUs and well over 16 GB of RAM for it alone. Check the current release notes for the sizing of the version you install, and keep the lab isolated from production networks.
Installing the controllers
- Deploy the Manager, Validator and Controller images and give each a system IP, site ID and the same organisation name.
- Configure VPN 0 (transport) interfaces so they can reach each other, and VPN 512 for out-of-band management.
- Set up a certificate authority. Labs often use an enterprise root CA on the Manager; production normally uses Cisco's signing service.
- Add the Validator and Controller to the Manager, generate their certificate signing requests, install the signed certificates and confirm control connections are up.
Plug and Play and device onboarding
The fabric only accepts edges whose serial numbers it knows. In production you add devices to the Plug and Play (PnP) Connect portal in your Cisco Smart Account, link them to a controller profile (organisation name and Validator address), then sync the list to the Manager. In offline labs you download the list as a signed file and upload it to the Manager instead. With zero-touch provisioning, a new router contacts the PnP service on boot, learns which Validator to use and joins without anyone typing commands.
Manual onboarding is still useful in labs. A vEdge needs basic system settings, a tunnel interface in VPN 0 and the root certificate, then is activated with its chassis number and a one-time token from the Manager. A cEdge (an IOS XE router) must first be put into controller mode, which erases its configuration and reloads it:
controller-mode enable
After reload you give it a bootstrap configuration (system IP, site ID, organisation, Validator address and a transport tunnel interface), or let PnP supply one. The commands differ between releases, so follow the guide for your version.
Device, feature and CLI templates
Configuring hundreds of routers by hand defeats the point of SD-WAN. Instead you build feature templates for each part of the configuration (system, banners, VPN 0 interfaces, OMP, BFD, service VPN interfaces, routing) and combine them into a device template for each type of site. Values that change per site, such as the site ID, system IP or LAN subnet, are variables you fill in per device, often by uploading a spreadsheet.
A CLI template is the alternative: you paste a full configuration with variables. It is common for the Controller, because centralised policies can only be pushed to a Controller that is managed by a template. Newer releases add configuration groups, a simpler workflow intended to replace feature templates over time, so check which your release recommends.
Tip: attach templates to one lab device first, use the Manager's configuration preview and diff view, and only then attach the template to every site.
Real-world example: forty branches in a fortnight
A building society needed to replace routers in 40 branches. The network team created one device template for single-router branches and one for larger dual-router branches, then prepared a spreadsheet of variables (site ID, system IP, LAN subnet, broadband details) for every branch. Routers were added to PnP Connect by serial number before shipping. Branch staff plugged them in; each router reached the Validator, appeared on the Manager and received its template within minutes. The two engineers spent their time checking tunnels and application performance rather than typing configuration.
Practice
Why must device serial numbers be known to the fabric before onboarding?
What is the relationship between device templates and feature templates?
What must be done to a Cisco IOS XE router before it can join as a cEdge?
Key takeaways
- Labs run in CML, EVE-NG, dCloud or a cloud account; the Manager needs the most resources.
- Controllers need a shared organisation name, system IPs and trusted certificates.
- Edges must be on the allowed list, usually synced from PnP Connect.
- cEdge routers must be switched to controller mode before onboarding.
- Device templates combine feature templates with per-site variables; Controllers often use CLI templates.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.