Cisco SD-WAN Templates: — Feature Templates, Device Templates, Variables & Config Groups

① Why templates — you can't CLI 500 routers by hand

Picture Sneha at Infosys handed a rollout: 500 branch WAN Edge routers, all basically the same design — same routing, same NTP, same security — differing only in hostname, system-IP and site-ID. Configuring them by SSH is a week of copy-paste and guaranteed typos. The SD-WAN answer is templates: build the design once, scale it by data, not by hand.

The model has three layers and it's worth memorising the order. A feature template is one small block — "the System config", "VPN 0", "the NTP config". Several feature templates assemble into one device template, which holds the complete operational config for one device type (a C8000v, an ISR 1100). That device template attaches to many devices, and the bits that differ per site come from variables filled from a CSV — one row per router.

The dabbawala analogy lands this for Indian students. Mumbai's dabbawalas don't memorise 200,000 individual home addresses — they use one coding scheme (the colour-and-letter tag on each tiffin) that every dabbawala reads the same way. The scheme is the template; the specific tag on your tiffin is the variable. Build the scheme once and 5,000 dabbawalas scale it. SD-WAN templates are exactly that: the design is shared, the address is per-tiffin.

You'll live on two screens. Feature templates are at Configuration > Templates > Feature Templates (click Add Template, pick the device model, pick the feature). Device templates are one tab over at Configuration > Templates > Device Templates. In Catalyst SD-WAN Manager the menu is the same; only the product name on the banner changed.

Four words you'll use every day

Tap each card — these anchor the whole lesson.

② Feature templates — System, VPN, OMP, BGP, NTP, AAA & variables

Feature templates come in families, and a handful cover most of a branch. The System template owns the device identity — site-id, system-ip, hostname, timezone, organization-name. The VPN template defines a routing segment: VPN 0 is the transport (underlay) side, VPN 512 is the out-of-band management VPN, and VPN 1+ are your service/LAN VPNs. VPN-Interface templates sit inside a VPN and configure an actual interface (IP, tunnel, TLOC colour).

The control-plane and edge-services families round it out. OMP tunes the overlay routing protocol (timers, path limits, redistribution). BGP configures the LAN-side or DC routing peering. Banner, NTP and AAA are the housekeeping you set once and reuse everywhere — login banner text, time servers, and the TACACS/RADIUS login model. The exam loves asking which family owns which knob, so anchor them now.

Scope: the dropdown that makes one template fit many sites

Every field on a feature template has a small scope dropdown to its left, and this is the single most important control in the whole lesson. Global means the same value on every attached device (organization-name, NTP server). Device-Specific turns the field into a variable — vManage asks you to name it (e.g. host_name, system_ip) and the CSV fills it per router. Default leaves the factory value so you type nothing (and make no typo).

This is exactly why one feature template fits many sites. Set organization-name to Global (every device shares it), set system-ip and host-name to Device-Specific (each device's own value), leave console-baud-rate at Default. Now the same System template rides Mumbai, Pune and Chennai — only the CSV row changes. Get greedy and make everything Device-Specific and your CSV balloons to 40 columns; get lazy and make a unique field Global and every router ends up with the same system-IP (a fast way to break OMP).

Branch-Edge1# show sdwan running-config system
Branch-Edge1# show sdwan system status

system
 host-name           Mumbai-Edge1
 system-ip           10.0.1.1
 site-id             101
 organization-name   "Techclick-Infosec"
!
Version: 17.12.3a   vManage mode: enabled   Reboot reason: power-on

③ Device templates — assemble, fill the CSV, preview & push

Now you assemble. At Configuration > Templates > Device Templates you click Create Template > From Feature Template, pick the device model, name it, and then slot your feature templates into the sections vManage lays out — Basic Information (System, Logging, AAA, BFD, OMP, Security), Transport & Management VPN (VPN 0, VPN 512 and their interfaces), Service VPN (VPN 1+), and Additional Templates (Banner, NTP, SNMP). Each device template is specific to one device type — you can't share a C8000v template with an ISR 1100.

With the template built, you attach devices. vManage now needs the per-device values for every Device-Specific variable you created. You fill them two ways: type them into the per-device form, or — the way you do 500 at once — download the variables CSV, fill it offline, and upload it. The CSV has one column per variable and one row per device; the header row carries the exact variable names you chose.

Never skip the preview. Before the push, Config Preview (and the Config Diff view) shows the full intended config and exactly what will change versus what's on the box. This is your last safety gate — read it the way you'd read a git diff before committing. If the diff shows a line you didn't expect (a VPN being removed, an interface shut), stop and fix the template, don't push and hope.

Out-of-sync and CLI mode — how a manual change breaks the contract

A template-attached device is in Manager (vManage) mode — vManage owns the config and the box rejects local edits. Detach the template and the device drops to CLI mode, where you configure it by hand. The trap: SSH a 'quick fix' onto a device that's still in Manager mode and vManage flags the device template Out-of-sync — running config no longer matches intended config.

④ CLI add-on templates, Configuration Groups, preview & rollback

Feature templates can't expose every IOS-XE knob. When the GUI lacks a setting, you use a CLI add-on feature template. You write the literal IOS-XE commands, add the CLI add-on to the device template alongside your normal feature templates, and vManage appends those lines to the generated config. You can even use {variables} inside the CLI add-on so per-device values still come from the CSV. It's the escape hatch — powerful, but the more you lean on it, the less the GUI represents the truth.

ip ssh version 2
login block-for 120 attempts 4 within 60
ntp server 10.5.5.10 source GigabitEthernet0/0/0
banner login ^C Authorised Techclick users only ^C

! appended to the device config on push, after the GUI-built features
Branch-Edge1# show sdwan running-config | include block-for
 login block-for 120 attempts 4 within 60
! In-sync after push — the add-on lines are now template-managed

The newer model Cisco wants you on is Configuration Groups with feature profiles. Instead of dozens of separate feature templates, a configuration group bundles them into profiles (System, Transport, Service) and adds a guided workflow plus per-device parcels. You'll find it at Configuration > Configuration Groups (in Cisco vManage Release 20.11.1 and earlier it lived under Configuration > Templates > Configuration Groups). From 17.12/20.12 Cisco recommends migrating, and a Configuration Conversion Tool turns existing templates and policies into config groups and policy groups.

This matters for the exam and the field in 2025–2026. From Cisco IOS XE Catalyst SD-WAN 17.15.1a / Control Components 20.15.1, some features are configurable only by API, and those releases are the last to support a few legacy template paths — another nudge toward Configuration Groups. From 17.15.1a you can also share a feature profile across multiple configuration groups, so you stop rebuilding the same System profile per group. The 300-415 blueprint explicitly asks you to configure and verify CLI and vManage feature configuration templates and to describe configuration groups and feature profiles — so know both worlds.