The first thing that trips people up in Catalyst SD-WAN is not OMP or TLOCs or policy - it is provisioning. How does configuration actually get onto a WAN Edge? There are three answers, they arrived in three different eras of the product, and knowing which one you are dealing with matters more than almost anything else when you inherit an SD-WAN deployment.
This article covers CLI templates, feature templates, and configuration groups - what each is, why they exist, and which one to use in 2026. It extends the complete SD-WAN guide.
A note on the output below. A full Catalyst SD-WAN control-plane deployment (Manager, Validator, Controller, plus certificate onboarding) is a large, GUI-and-API-driven build that cannot be faithfully reproduced through a device CLI session. The command syntax and output shown here is drawn from Cisco's current 20.x documentation and reflects real WAN Edge CLI - it is presented as a documented reference, clearly labelled, not as a home-lab capture. Where a command is standard IOS XE that runs on the edge, it is the genuine article.
The three provisioning models, in order of arrival
CLI templates: full control, full responsibility
A CLI template is exactly what it sounds like - the device's running configuration, with variables:
system
host-name {{hostname}}
system-ip {{system_ip}}
site-id {{site_id}}
organization-name "PingLabz-SDWAN"
vbond {{vbond_ip}}
!
sdwan
interface GigabitEthernet1
tunnel-interface
encapsulation ipsec
color {{tloc_color}}
exit
exitYou get complete control - every knob, every corner case, anything the product supports. The price is that you also own every mistake, and there is no structure to reuse. CLI templates are the escape hatch: when a feature template cannot express what you need, you drop to CLI. In a well-run modern deployment they are the exception, not the rule.
Feature templates: structured but proliferating
Feature templates decompose the device config into functional blocks, each configured through a form in Manager:
- A system feature template (system-ip, site-id, org-name, vBond).
- A VPN 0 (transport) template plus a tunnel-interface template per transport.
- A VPN 512 (management) template.
- A service VPN template per customer VPN, plus interface templates.
- An OMP template, a BGP/OSPF template if you run one to the service side, and so on.
You bundle these into a device template and attach it to devices, supplying the per-device variables (via a CSV for bulk). Manager renders and pushes the CLI.
Feature templates were a big step up from raw CLI - reusable, validated, less error-prone. Their weakness is proliferation: a real deployment ends up with dozens of feature templates and a matrix of device templates, and changing something common (an NTP server, a syslog host) can mean touching many templates. That pain is exactly what configuration groups set out to solve.
Configuration groups: the current model
Configuration groups (20.8 onward, and the model to learn now) raise the abstraction level. Instead of many small feature templates, you describe a handful of profiles:
The win is reuse with less repetition: common settings live in a profile once, feature parameterisation is cleaner, and applying a group to many devices is more intent-driven. Configuration groups also integrate with Manager's newer topology and monitoring workflows. For any new deployment on a recent version, this is where to start.
Verifying what got pushed (on the edge)
Whichever model produced it, the result is CLI on the WAN Edge, and you verify it with the show sdwan family - these are real IOS XE Catalyst SD-WAN commands (documented reference):
Edge# show sdwan running-config system
system
system-ip 10.0.0.11
site-id 100
organization-name "PingLabz-SDWAN"
vbond 10.0.0.3
Edge# show sdwan control connections
PEER PEER PEER SITE DOMAIN PEER PROT STATE
TYPE PROT SYSTEM-IP ID ID PRIVATE IP
vsmart dtls 10.0.0.4 1 1 10.0.0.4 dtls up
vbond dtls 10.0.0.3 0 0 10.0.0.3 dtls up
vmanage dtls 10.0.0.2 1 0 10.0.0.2 dtls upshow sdwan control connections is the single most important command on a WAN Edge - it tells you whether the device has joined the fabric (control connections to the Manager, Validator, and Controller all up). If these are not up, nothing else matters, and no template will help until they are.
Choosing a model
- New deployment, recent version: configuration groups. It is the current direction, cleaner to maintain, and integrates with the newer Manager workflows.
- Existing feature-template deployment: keep it if it works, but plan the eventual move to configuration groups. Do not mix models for the same devices.
- A device that needs something no structured model expresses: a CLI template, or a CLI add-on profile on top of a configuration group. The escape hatch, used sparingly.
- Bulk-provisioning many identical branches: any structured model plus a device-variables CSV. This is where templating pays for itself.
Key takeaways
- Catalyst SD-WAN has three provisioning models: CLI templates (raw config, full control), feature templates (structured forms, reusable but proliferating), and configuration groups (intent-based profiles, the current model from 20.8+).
- For any new deployment on a recent version, start with configuration groups. Feature templates are the previous generation; CLI templates are the escape hatch.
- All three ultimately render CLI onto the WAN Edge, verified with the
show sdwancommand family. show sdwan control connectionsis the first command to run on any edge - it confirms the device has joined the fabric (Manager, Validator, Controller all up).- Do not mix provisioning models for the same devices; migrate deliberately when you move from feature templates to configuration groups.
Next: OMP deep dive - routes, TLOCs, service routes, and path selection. The full cluster index lives on the SD-WAN pillar.
