You can put the same interface IP on an SD-WAN edge in three different ways: type it on the CLI, push a device template built from feature templates, or deploy a configuration group built from feature profiles. The overlay does not care which door you used. The operator does, because the three models age differently and they do not mix on one device.
This post compares those three generations on Cisco Catalyst SD-WAN 20.18.2.1 with C8000v routers on IOS XE 17.18.02, built in my home lab. I read how the running edges are managed today. I did not attach a template or a configuration group to either working site.
This is part of the Cisco SD-WAN series. Previous: Zero-Touch / PnP Onboarding Explained. Next: Device and feature templates hands-on.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
The problem: one running config, three editors
Once an edge has transports, trust, and tunnels, you still have to maintain its configuration. Adding a service VPN, changing a color, or standing up fifty identical branches by hand does not scale.
SD-WAN Manager has grown three answers to that:
- A CLI template (and the related CLI add-on) pastes IOS or Viptela-style text, with optional device variables.
- A device template is a bundle of feature templates: one child per function, such as system, VPN, or BGP.
- A configuration group is a bundle of feature profiles: System, Transport and Management, Service, and a few others.
Think of feature templates as prefabricated rooms you bolt into a house (the device template). Feature profiles are the same idea in the newer UX 2.0 workflow, except a profile can be reused across many groups more freely, and Cisco has been adding new knobs there first.
What the lab is running today
Both edges were onboarded from the CLI. A fresh check on edge1:
edge1#show sdwan system status | include vManaged|template
vManaged: false
Configuration template: Noneedge2 reports the same. vManaged is the flag that says SD-WAN Manager owns the running config. false means these boxes still take config-transaction and commit from an operator, the way the onboarding post left them.
I left that flag alone. Attaching a device template or deploying a configuration group would flip the edge to Manager-owned configuration. That is useful, and it is also how you accidentally replace a working CLI overlay. The hands-on posts that follow stay on the building blocks and do not push ownership onto these two sites.
Manager agrees with the CLI. Its device list shows both edges as reachable vedge-C8000V routers with no template attached. Configuration > Templates holds 17 factory device templates, including Factory_Default_C8000V_V01, Factory_Default_1_TLOC_Branch_Template, and Default_SDBranch_C8000V_Template_V01. None of them has a device attached.
The Configuration Groups page, with the SD-WAN solution selected, has tabs for Configuration Groups, System Profile, Transport and Management Profile, Policy Profile, Service Profile, CLI Add-on Profile, and UC Voice. When I first opened it, the Configuration Groups count was zero. System, Transport and Management, Service, and CLI Add-on were also empty. Policy Profile already showed one default object, Default_Policy_Object_Profile.
I then created a lab group named unused-branch and a System feature profile named unused-system, and I added that profile to the group. The group still lists zero devices. I also created an unused banner feature template, covered in the next post. Nothing in this set was associated or deployed to edge1 or edge2.
The three models
CLI, and CLI templates
The CLI is what we used to set system-ip, site-id, organization-name, Validator, colors, and service VPN 10. A CLI template is that text stored in Manager, with {{VARIABLE}} placeholders for per-device values. Cisco also documents a CLI add-on profile inside configuration groups for the bits the guided profiles do not cover yet.
CLI is honest and complete. It is also easy to drift: two edges that started identical slowly stop matching.
Feature templates and a device template
Classic Manager, under Configuration > Templates, uses a parent and children:
- Feature templates hold one feature each. A VPN feature template describes VPN 10. An interface feature template describes GigabitEthernet4.
- The device template names the platform and lists which feature templates to combine.
- You attach the device template to one or more devices and fill in the variables.
Cisco still supports this model. A device cannot use a device template and a configuration group at the same time, according to Cisco's configuration-group documentation. You pick one owner.
Configuration groups and feature profiles
Configuration groups arrived in Cisco vManage Release 20.8.1 and IOS XE 17.8.1a. On 20.15 and later, including our 20.18 Manager, Cisco documents these SD-WAN profile types:
- System
- Transport and Management
- Service
- CLI Add-On
- UC Voice
- Other
You assemble a group from profiles, associate devices, fill variables, and deploy. The Create Configuration Group workflow (from 20.9.1) walks through a single-router site on one page so the result can be deployed without bouncing between a dozen feature-template screens.
This is the model ENSDWI now expects you to recognize, and it is where Cisco has been putting new features. The older template screens do not vanish. Mixed fabrics are normal: some sites still on device templates, new sites on groups.
Which one to use in 2026
| Approach | Best when | Watch for |
|---|---|---|
| On-box CLI | Labs, break-fix, first bring-up | Config drift; no bulk attach |
| CLI template | A feature the GUI does not model yet | You maintain raw text |
| Device and feature templates | An existing catalog you already trust | New features may appear only in groups |
| Configuration groups | New 20.x work, shared profiles, UX 2.0 | Do not attach over a CLI lab without a backup |
Our fabric is the first row. That is a choice, not a limitation of 20.18. The next two posts show how the template catalog and the profile stack are built, using this running CLI as the source of truth rather than as the attach target.
Verify how an edge is managed
| Check | Command |
|---|---|
| Does Manager own the config? | show sdwan system status (look for vManaged) |
| Which template name is attached? | Same command, Configuration template |
| What the box is actually running | show sdwan running-config |
If vManaged is true, do not paste a competing config-transaction and expect it to last. Manager will refresh the device from the attached template or group.
What breaks
- Attaching a template to a CLI-built lab without a backup. The Manager copy replaces the on-box config. Take a copy of
show sdwan running-configfirst. - Assigning both a device template and a configuration group. Cisco documents one owner per device.
- Learning only feature templates from an older course. Configuration groups are the current guided workflow. Feature templates still work; they are no longer the only story.
- Editing the CLI on a vManaged device. Your change can disappear on the next push.
Key takeaways
- There are three generations: on-box or CLI templates, device templates built from feature templates, and configuration groups built from feature profiles.
- Our C8000v edges report
vManaged: falseandConfiguration template: None. Manager shows the same: reachablevedge-C8000Vdevices, no template, and a configuration group that still has zero devices associated. - Configuration groups have been in Manager since 20.8.1. On 20.18 they are the workflow Cisco documents for new profile-based work.
- Pick one owner per device. Convert later with a plan, not by attaching over a live CLI site.