Cisco DNA Center Template Archive/Restore

Background

I have written a number of blogs about CLI templates in Cisco DNA Center.  These templates can be used as part of the “provisioning” workflow in the UI, or programmatically directly from the API.

One question that often comes up is the ability to share templates through archive and restore.  This utility provides this capability.  This is useful when sharing templates or taking templates from one DNA Center to another (e.g. Development -> Production).

Installing

The code can be cloned from  github. I recommend you use a virtual environment, but this is optional.

git clone https://github.com/CiscoDevNet/DNAC-TemplateTool.git

python3 -m venv env3
source env3/bin/activate

There is one dependency, that is the dnacentersdk. This is contained in the requirements.txt file.

pip install -r requirements.txt

The final step is to setup the environment variables to connect to dnacenter. There is a sample in env_dnac. You will need to edit these to point to your DNA Center. You need to use the source command to make these active.

source vars_dnac

Getting Started

Once you have installed the dependencies and modified the environment variables, you can run the script. Running the script with no arguments will dump the templates in json format. You can save this to a file.

./template_archive.py > all.json

You can then use this file as the input to restore the templates.

$ ./template_archive.py --restore all.json
['Cloud DayN Templates/DMVPN Spoke for Branch Router - System Default/1', 'Cloud DayN Templates/DMVPN for Cloud Router - System Default/1', 'Cloud DayN Templates/IPsec for Branch Router - System Default/1', 'Cloud DayN Templates/IPsec for Cloud Router - System Default/1', 'Onboarding Configuration/3k-stack/1', 'Onboarding Configuration/3k-stack/2', 'Onboarding Configuration/9300-sdwan/1', 'Onboarding Configuration/DMVPN Hub for Cloud Router- System Default/1', 'Onboarding Configuration/IPsec 1 Branch for Cloud Router - System Default/1', 'Onboarding Configuration/IPsec 2 Branch for Cloud Router - System Default/1', 'adam/int-desc/1', 'adam/int-desc/2', 'adam/int-desc/3', 'adam/int-desc/4', 'adam/int-desc/5', 'adam/loop/1', 'adam/loop/2', 'adam/loop/3']
Updating template:DMVPN Spoke for Branch Router - System Default, CurrentVesion:1, NewVersion:1
Skipping template DMVPN Spoke for Branch Router - System Default, version 1.  Mismatch with existing version1
Updating template:DMVPN for Cloud Router - System Default, CurrentVesion:1, NewVersion:1
Skipping template DMVPN for Cloud Router - System Default, version 1.  Mismatch with existing version1
Updating template:IPsec for Branch Router - System Default, CurrentVesion:1, NewVersion:1
Skipping template IPsec for Branch Router - System Default, version 1.  Mismatch with existing version1
Updating template:IPsec for Cloud Router - System Default, CurrentVesion:1, NewVersion:1
Skipping template IPsec for Cloud Router - System Default, version 1.  Mismatch with existing version1
Updating template:3k-stack, CurrentVesion:2, NewVersion:1
Skipping template 3k-stack, version 1.  Mismatch with existing version2
Updating template:3k-stack, CurrentVesion:2, NewVersion:2
Skipping template 3k-stack, version 2.  Mismatch with existing version2
Updating template:9300-sdwan, CurrentVesion:1, NewVersion:1
Skipping template 9300-sdwan, version 1.  Mismatch with existing version1
Updating template:DMVPN Hub for Cloud Router- System Default, CurrentVesion:1, NewVersion:1
Skipping template DMVPN Hub for Cloud Router- System Default, version 1.  Mismatch with existing version1

As expected, nothing happens as all of the templates are already present.  The script checks the version of the template before updating it.  If you were to remove a template, or a project, they would be restored.  Alternatively, you could restore to a different DNA Center and the templates would be added there.

Anatomy of a Template

Templates consist of the following sections, properties, variables and the template body. Each of these are stored together in a version.  The following picture shows three different versions of a template, each with a different set of properties, variables and template body.

Components of a template

An example of the template properties appears below.  There are two mandatory properties

◈ the device type, which can be as broad as a family (e.g. all switches) or as narrow as a particular model (e.g. Catalyst 9300).

◈ The operating system E.g. IOS-XE.

Template Properties

Variables are defined in a template ($hostname) is an indication of a variable.  A variable can have a type, a default value, or in some circumstances, be marked as not a variable.  This is useful for encrypted passwords, where “$” might appear as part of the configuration.

Template Variable Properties

The final part of the template is the body.  This is velocity syntax.  The following extremely simple template sets the hostname of a device.    Hostname is also a variable.

Template body

Templates are stored in projects, which you can think of like a folder in a directory structure.  The template name inside a project is unique, while different projects can contain a template with the same name.  Remember, although these templates share the same name, they are different instances as they are in different projects.  You can see an example of projects below. “Onboarding Configuration” and “Cloud DayN Templates” are two projects that are always present.

Template Projects