Hands-On Lab: Configuring Cisco DNA Center Template-Based Provisioning (CLI Templates)

This hands-on lab creates a CLI template in a DNA Center-style provisioning workflow using variables for site-specific values, applies it to two different devices, and verifies each device receives a customized configuration generated from the same single template.

CLI Template VariablesTemplate-Based Device ProvisioningSingle-Source Multi-Device Configuration

~3 min read · Updated Sep 27, 2026

Lab Objective

Create a CLI template containing variables for device-specific values such as hostname and loopback address, apply the same template to two different devices with different variable values supplied for each, and verify each device receives a correctly customized configuration generated from the identical underlying template.

Lab Purpose

The Ansible playbook lab covered earlier in this series demonstrated agentless configuration push from an external control node. DNA Center-style CLI templates take a similar template-and-variable approach but integrate it directly into a centralized management platform's provisioning workflow, letting an administrator define a configuration pattern once and apply it consistently across many devices with only the site-specific values changing per device.

Lab Topology

ProvisioningPlatform (template engine)

BranchRouterA (to receive: hostname
               BRANCH-A, loopback
               10.100.1.1/32)
BranchRouterB (to receive: hostname
               BRANCH-B, loopback
               10.100.2.1/32)

Task 1: Create a CLI Template with Variables

Define a template containing the common configuration structure, with variables marking the values that differ per device.

Task 2: Define Variable Values for BranchRouterA

Specify BranchRouterA's specific values for the template's variables.

Task 3: Define Variable Values for BranchRouterB

Specify BranchRouterB's specific values for the same template's variables.

Task 4: Apply the Template to Both Devices

Push the template, with each device's respective variable values, to both routers.

Task 5: Verify Each Device Received Its Correctly Customized Configuration

Confirm each router's running configuration reflects its own specific values, generated from the shared template structure.

Solution and Verification

-- CLI Template (BRANCH-STANDARD):

hostname $HOSTNAME
!
interface Loopback0
 ip address $LOOPBACK_IP 255.255.255.255
!
ip domain-name lab.local
!
line vty 0 15
 transport input ssh

-- $HOSTNAME and $LOOPBACK_IP are the
-- template variables -- everything else
-- in the template is identical across
-- every device it gets applied to

-- Variable values for BranchRouterA:

HOSTNAME = BRANCH-A
LOOPBACK_IP = 10.100.1.1

-- Variable values for BranchRouterB:

HOSTNAME = BRANCH-B
LOOPBACK_IP = 10.100.2.1

-- Template applied to BranchRouterA,
-- rendering to:

hostname BRANCH-A
!
interface Loopback0
 ip address 10.100.1.1 255.255.255.255
!
ip domain-name lab.local
!
line vty 0 15
 transport input ssh

-- Template applied to BranchRouterB,
-- rendering to:

hostname BRANCH-B
!
interface Loopback0
 ip address 10.100.2.1 255.255.255.255
!
ip domain-name lab.local
!
line vty 0 15
 transport input ssh

BranchRouterA# show running-config | include hostname
hostname BRANCH-A

BranchRouterA# show ip interface brief | include Loopback0
Loopback0    10.100.1.1    YES manual up    up

BranchRouterB# show running-config | include hostname
hostname BRANCH-B

BranchRouterB# show ip interface brief | include Loopback0
Loopback0    10.100.2.1    YES manual up    up

-- Both routers correctly received their
-- own site-specific values, generated from
-- the exact same underlying template
-- structure -- no manual, device-by-device
-- retyping of the shared configuration
-- elements (domain name, VTY transport
-- settings) was required for either device

Key Takeaway

CLI templates separate the configuration structure that stays identical across a device class from the specific values that differ per device, an approach conceptually similar to the Ansible playbook variables covered earlier in this series but integrated directly into a provisioning platform's workflow — this separation means updating a shared configuration element (adding a new line to the template) automatically applies consistently the next time the template is used, rather than requiring that change to be manually re-applied to every device individually.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Continue

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue