Device and Feature Templates Hands-On

A working edge already has the configuration you wish you had captured as templates: system identity, VPN 0 tunnels, a service VPN, OMP advertisements. The classic Manager workflow is to split that running config into feature templates and hang them from one device template. This post maps our C8000v CLI onto that parent-and-child model. It does not push the result onto the live edges.

I read the running configuration on Cisco Catalyst SD-WAN 20.18.2.1 with IOS XE 17.18.02, built in my home lab. Both sites still report vManaged: false.

This is part of the Cisco SD-WAN series. Previous: Feature templates vs CLI templates vs configuration groups. Next: Configuration groups and feature profiles on 20.18.

For SD-WAN Manager (formerly vManage) and the other old names, see the name map.

The problem: the running config is one blob

Here is the service VPN on edge1, trimmed:

vrf definition 10
 rd 1:10
 address-family ipv4
  exit-address-family
!
interface GigabitEthernet4
 no shutdown
 vrf forwarding 10
 ip address 192.168.10.1 255.255.255.0

OMP on the same box advertises those connected prefixes:

omp
  no shutdown
  graceful-restart
  no as-dot-notation
  address-family ipv4
   advertise connected
   advertise static

A device template does not store that as one file. It stores a list of feature templates, and each feature template owns one slice: system, OMP, VPN, Ethernet interface, and so on.

Think of the device template as a table of contents. The feature templates are the chapters. Variables are the blanks the chapter leaves for each site: system-ip, site-id, the LAN address.

The parts

Cisco's classic UI path is Configuration > Templates. You create feature templates first, then a device template that points at them.

For a C8000v that looks like ours, the minimum catalog is:

The device template for vedge-C8000V (that is the platform name Manager still uses for a Catalyst 8000v) then lists those feature templates in order. When you attach it, Manager asks you to fill every variable, by form or by CSV. That attach step is the variables post.

What I mapped from the lab, and what I did not push

Both edges already participate in VPN 10. edge1's LAN is 192.168.10.0/24 on GigabitEthernet4. edge2's LAN is 192.168.20.0/24. Overlay Management Protocol (OMP) carries each prefix to the other site. On edge1:

edge1#show ip route vrf 10
C        192.168.10.0/24 is directly connected, GigabitEthernet4
m     192.168.20.0/24 [251/0] via 10.0.0.2

The m route is OMP, administrative distance 251. The local prefix is connected, which matches advertise connected.

That is enough information to build feature templates that describe this shape. I did not attach anything. Attaching would set vManaged to true and replace the CLI that currently keeps control connections and Bidirectional Forwarding Detection (BFD) up.

I did open the factory catalog in Manager. After I added one unused banner template, Configuration > Templates listed 128 feature templates (127 factory, one user-created) and 17 factory device templates. Zero of either had a device attached. Eighty-seven of the feature templates include vedge-C8000V in their device list. The common factory types are cisco_vpn_interface (44), cisco_vpn (29), cisco_omp (8), and cisco_system (7).

A factory parent shows the table of contents clearly. Factory_Default_1_TLOC_Branch_Template has 11 child feature templates: cedge_aaa, cisco_bfd, cisco_omp, cisco_security, cisco_system (Factory_Default_Retail_Branch_System, with a cisco_logging child), several cisco_vpn entries each with cisco_vpn_interface children, and cedge_global. Default_SDBranch_C8000V_Template_V01 is the same shape plus Factory_Default_Retail_Banner. Factory_Default_C8000V_V01 uses Default_System_Cisco_V01, adds cisco_ntp, and points at Default_VPN_0_Cisco_V01 (VPN 0) and Default_VPN_1_Cisco_V01 (VPN 1). Those factory VPN IDs are not our service VPN 10.

I created one unused feature template named unused-banner, type cisco_banner, device type vedge-C8000V, with zero devices attached. I did not build a matching VPN 10 or GigabitEthernet4 feature template, and I did not point any device template at the live edges.

If you build the catalog in a lab of your own, take show sdwan running-config first. Attach to one test device, not to both production edges at once. Compare the preview against the saved CLI before you click configure.

The Manager screens themselves, per Cisco's 20.x documentation, offer a preview of the assembled config before you commit the attach. Treat a preview mismatch as a stop, not as a surprise after the push.

Verify before and after any later attach

If the preview drops GigabitEthernet4 or the OMP advertise statements, the far-site LAN will vanish from the routing table after the push.

What breaks

• Forgetting a feature template. A device template that includes system and VPN 0 but omits the service VPN will remove VPN 10 when it replaces the CLI.
• Attaching over a CLI lab. Manager becomes the source of truth. Your on-box comments and unpublished lines go away.
• Using the wrong device type. A template built for another platform will not attach cleanly to a C8000v.
• Copying interface names from a vEdge guide. Our LAN is GigabitEthernet4, not ge0/0. The vEdge post covers that mismatch.

Key takeaways

• A device template is a table of contents. Feature templates are the chapters you reuse.
• Our running CLI already shows the chapters: system, VPN 0, VPN 10 on GigabitEthernet4, and OMP advertising connected and static routes.
• I mapped that CLI onto the classic catalog, read the factory parent-and-child lists in Manager, added an unused banner template, and left vManaged set to false. Nothing was attached.
• Save the running config and read the preview before any later attach. The next post covers the newer profile stack that replaces much of this catalog.