How to Use the Plug and Play Template Editor in DNA Center – Part 3

The first and second blog posts in this series gave an overview of network Plug and Play (PnP) and how it has evolved in Cisco DNA Center.   They showed a very simple workflow to provision a device with a configuration template with a variable called “hostname.”   This was done by the UI and programmatically via the API.

This blog post looks at creating PnP configuration templates using template editor in Cisco DNA Center.  Here, we will cover the User Interface and basic concepts, and subsequent blog posts will cover advanced topics, Day-N provisioning and the associated API.

Template Editor

The template editor is a standalone application at the bottom of the Cisco DNA Center home page.  It can be used for Day-0 (PnP) or Day-N configurations.

When the editor is opened for the first time, a project needs to be created along with a template. Projects are like folders to contain and structure the templates you build.  The example below, shows the “base config” template used in the earlier blogs.  “pnp” and “adam” are just project names.

Creating a new Template

Click the “+” at the top of the template page or the gear beside a project to add a new template.  The “+” allows you to create a project or a template, while the gear creates a template with the project.

The “add new template” slide out will appear.  This contains metadata about the template, such as the device types it applies to and the flavor of IOS. The example below applies to routers and switches (all models) which run IOS-XE.  It is possible to restrict the template to a specific version of code or model of device.

NOTE:  It is possible to have a single template or a composite sequence of templates. Currently composite sequences are not supported in PnP.

Click on the template to edit it.  The three boxes on the top right are used to navigate between the following views:

◈ Edit – to edit/commit the template.

◈ Variable – provide metadata about the variables used in the template. “$” is used to signify a variable.

◈ Simulation mode – View the rendered template by providing a set of test values for the variables.

It is important to realize that templates have a 2-phase commit.  A template can be saved, but it needs to be “committed” before it can be used. Templates have version control based on the “commit process”.

First Version

After entering some commands, the template needs to be saved and committed.  Any string that starts with “$” will be treated as a variable. In this example, “$hostname” is a variable.  Multiple variables are supported.

Variable Types

After committing an initial template version, the variables view can be used to change the type of the variable if required.  Variables can also be marked as “not a variable”, which is useful for configuration strings that contain  “$”.  I will discuss this more in the advanced blog post.

Simulation

Simulations can be used to test the template with dummy variables.  This is particularly useful later on when using loops and other control structures in a template.

Select the simulation tab, and then the “New Simulation” action.

You then need to provide a value for the variables, and run the simulation to see the result.  Notice how the hostname variable has been replaced by its value (“fred”).

The simulation feature is particularly relevant with more sophisticated templates.