Feature templates ask you to build a catalog of small pieces and then click them into a device template. Configuration groups ask you to fill profiles instead: system, transport, service, and a few optional extras. The result is the same kind of running config. The workflow is the one current exams and new Cisco features assume you know.
This post explains that profile stack on Cisco Catalyst SD-WAN Manager 20.18.2.1, next to C8000v routers on IOS XE 17.18.02 in my home lab. I compared it with the CLI those edges already run. I did not deploy a configuration group onto either site.
This is part of the Cisco SD-WAN series. Previous: Device and feature templates hands-on. Next: Template variables and bulk CSV attach.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
The problem: too many feature templates for one branch
A complete classic catalog for a dual-transport branch quickly grows past a dozen feature templates: system, OMP, two VPN 0 interfaces, two colors, management, service VPN, LAN interface, maybe BGP or OSPF later. Each new platform copy multiplies the pile.
Configuration groups were added to collapse that. Cisco introduced them in Release 20.8.1 (IOS XE 17.8.1a). By 20.9.1 the Create Configuration Group workflow could produce a deployable single-router site from one guided page, including WAN and LAN routing.
Think of a configuration group as a folder for a class of site, such as "standard branch." Feature profiles are reusable binders you drop into that folder. One System profile can serve every branch group that shares the same organization name and Controller affinity.
The parts on 20.18
Cisco's configuration-group guide for Manager 20.15 and later, which includes 20.18, lists these SD-WAN profile tabs. The Configuration Groups page on this 20.18.2.1 Manager matches that list: Configuration Groups, System Profile, Transport and Management Profile, Policy Profile, Service Profile, CLI Add-on Profile, and UC Voice.
- System profile. Site-id, system-ip, hostname, organization, OMP and other box-wide settings.
- Transport and Management profile. VPN 0 and VPN 512, WAN interfaces, colors, tunnel-interfaces.
- Service profile. Service VPNs such as our VPN 10, LAN interfaces, and service-side routing.
- CLI add-on profile. Raw CLI for settings the guided parcels do not model yet. Cisco documents device variables and Type 6 encryption inside this profile from 20.10.1.
- Policy profile. This lab already had one default object,
Default_Policy_Object_Profile, before I created anything. - UC Voice profile. Voice features, when you need them.
- Other profile. Extra features that do not belong in the first four.
You create or reuse profiles, add them to a group, associate devices, fill variables, and deploy. Association is not the same as deploy: Cisco's workflow lets you attach a device to the group and only later push the config.
A device that already has a classic device template cannot also have a configuration group. Cisco documents one owner. Our edges currently have neither. They are CLI-managed:
edge1#show sdwan system status | include vManaged|template
vManaged: false
Configuration template: None
Mapping our CLI into profiles
The running box already has the content those profiles would hold.
System-like facts live under system: system-ip 10.0.0.1, site-id 100, organization-name pinglabz-lab, vbond 172.16.30.30. OMP advertises connected and static routes.
Transport-like facts are the VPN 0 tunnel-interfaces and colors that the onboarding post configured on GigabitEthernet2 (mpls restrict) and GigabitEthernet3 (biz-internet).
Service-like facts are VRF 10 and GigabitEthernet4:
interface GigabitEthernet4
no shutdown
vrf forwarding 10
ip address 192.168.10.1 255.255.255.0If I were filling the 20.18 guided workflow for a new branch, those are the values I would type, with the LAN address and system-ip marked as device variables so edge2 can share the same group.
I did not run that workflow against the live sites. Deploying it would replace the CLI I just quoted. Build the group in Manager, preview it, and aim it at a spare edge first.
What I did create, and left unused, is a configuration group named unused-branch with solution sdwan and origin user. It has no associated devices (numberOfDevices is 0). I also created a System feature profile named unused-system and added it to that group. The profile has no parcels yet, so it is an empty binder, not a deployable copy of our running system CLI. Version 2 of the group still lists an empty device list.
Cisco also documents a conversion tool that turns feature templates into configuration groups (Manager 20.18.2). That migration has its own post later in the series. Do not treat this page as that procedure.
Verify a group without risking the overlay
Until you deploy, the edges keep answering as they do now:
| Check | What we see |
|---|---|
| Ownership | vManaged: false |
| Service LAN | show ip route vrf 10 shows connected plus an OMP route to the far site |
| Overlay health | Control connections and BFD still up from the CLI onboard |
After a future deploy, the same table should still pass, and vManaged should read true. If the service profile omitted GigabitEthernet4, the far-site prefix 192.168.20.0/24 would disappear from edge1 even though the tunnels stayed up.
What breaks
- Deploying over a CLI-managed site with no backup. Same risk as attaching a device template.
- Mixing a device template and a configuration group on one device. Cisco does not support both owners.
- Leaving service-side routing out of the service profile. Tunnels come up, user subnets do not.
- Assuming every new 20.x knob exists in a classic feature template. Cisco has been adding features to profiles first. Check the configuration-group guide for the release you run.
Key takeaways
- A configuration group is a site class. Feature profiles are the reusable binders inside it: system, transport and management, service, plus CLI add-on, voice, and other.
- The model has been in Manager since 20.8.1. The 20.9.1 guided workflow can produce a deployable single-router site on one page.
- Our running CLI already contains the values those profiles would hold. I mapped them, created an unused group and an empty System profile, and did not associate or deploy anything onto the working edges.
- Use one owner per device, preview before deploy, and keep the CLI copy until the first group push has been proven.