Jump to content
  • entries
    9
  • comments
    3
  • views
    2,860

Cisco DNA - CLI Templating

BSpendlove

3,075 views

If you've ever used Cisco Prime Infrastructure's CLI Templating, you'll find that Cisco DNA's (Digital Network Architecture) CLI templating is an enhanced version found within Cisco Prime. Of course, there are many other features within DNA but this is just a quick example while I have 15 minutes of free time to demonstrate CLI templating and how it can be used to effectively deploy unified templates to a Cisco infrastructure instead of using other methods such as: Python + CLI scraping, Ansible, or Python with a combination of Git for version control.

 

The concept of a CLI template is very straight forward although you need some consideration before deploying this on a global scale. Some considerations are:

  • CLI Template versions for specific IOS (is the command supported in all IOS versions across the whole network?)
  • CLI Template versions for specific models (Are you dealing with 9300s, 3850s? 3750Xs? even plain 3550s and 3750s?, are the models even supported with Cisco DNA? Find the supported devices here)
  • Are you designing a generic template that can be used across all locations in the network or only a selected area?
  • If you are designing generic templates, have you considered to create templates based on HQ Core vs Branch Access vs Warehouse Wireless?

 

The very basics of CLI templating can allow you to just design a template with specific variables that a network engineer or level 1/1st line tech could use to deploy an access switch. You can ensure a unified configuration is applied to all remote devices upon first deployment but what stops those monkey techs logging onto a switch and changing configuration manually? It isn't smart to block login access for users and demand any configuration to be performed via a central server (eg. the DNA appliance) because there comes a time where someone may need access to a device to troubleshoot or simply put a port in a different VLAN. You have the additional features that can be integrated into your network such as Cisco ISE and TACACS+ but let's get back to DNA CLI templates.

 

Let's create a simple generic template to be applied to branch access switches.

 

image.png.4162029526234fda13b6fe5e744091d6.png

 

We need to be smart about the templating. Our branches have the same model switch, running the same IOS version but the difference is that Branch-C has another switch. We would probably want to configure an EtherChannel (no lacp/pagp, just static) between SW1 and SW2 (let's assume its 4 ports, g1/0/45-g1/0/48), so we don't want to include that configuration within our generic global template, but some global variables/commands we can deploy across all the switches would be:

 

  • Service password-encryption
  • Set hostname (per device which can be done via the template deployment)
  • Set Timezone and summer-time
  • Set VTP mode to transparent
  • Set the domain name on the switch
  • Configure 2 x Domain servers that are located at HQ

 

Some generic commands won't require user input such as enabling services, but others such as hostname will need some kind of input from either the user, or if you plan on automating this deployment you can pull data from a database (eg. a CMDB that ties into your network monitoring solution). Let's dive into the DNA template:

 

I've created a new project and then created a template called Generic - General Access Switch

image.png.4ff2f9b49ae1575b1e6c83b1a91fc711.png

 

Within DNA CLI templates, you can define variables like such: $myVariable

 

This then allows you to specific edit the variable from the input form that you will see when you deploy the template. The common variable would be a string but others include string > select, IP address, MAC address, checkboxes etc...

 

image.png.1a35b79eab965c9dc4b312e79aee6514.png

 

If we take something a bit more complicated, you can see that instead of making the user input commands such as spanning-tree portfast on interfaces the engineer would like this feature enabled, we can provide the option if they would like it enabled for the range of ports he is considering to be access ports at the specific branch site. This isn't the best example because the engineer has to be competent to know why they would want to enable portfast and to ensure that if it's a recommended design (instead of configuring via global) then to ensure they configure this on every port. That is where templating can't help you. You need to ensure staff/engineers are competent in their job and will follow documentation if you have a well documented deployment for branch access switches. Anyway, carry on:

image.png.5d12b6331ba15b53d15cf5f086256165.png

 

Cisco DNA CLI Templating uses VTL language (velocity template language). Let's change this variables so that the engineer can only set portfast to True or False and run a simulation within Cisco DNA. The big improvement with DNA is that unlike prime, there is actually a syntax checker that confirms if the syntax is correct. Cisco Prime would fail to deploy a template and then tell you something is wrong, always a handy feature.

image.png.61380f7a1685d607e64738e02cdc0cdb.png

Take a look at the test simulation of our CLI template:

image.png.b0601978603baf6d3e238e41c88e3217.png

 

Now can this be done other than using Cisco DNA?

 

CLI Templating can be done with Excel spreadsheets and Python for all I care. CLI Templating can be achieved via Ansible or even writing your own Python library with Netmiko + some templating format of choice such as XML, JSON or Jinja2. CLI Templating isn't new but that isn't what Cisco's DNA solution brings to the table. The problem that we face currently is that these templates are not compatible with other vendor configurations. This is a common problem and there isn't a single interface to allow us to interpret a configuration for different vendors, we need to individually create templates depending on the Vendor, version, model and even the device role. While Cisco DNA states some other vendors are supported such as Palo Alto (for DNA inventory), it is much easier to use Anisble for smaller environments that don't implement a lot of Cisco.

 

Cisco's DNA licenses are required when purchasing the new line of CAT9Ks (9200,9300,9400 etc...) but doesn't mean you can start running DNA centre. The DNA appliance is required along with a device license so be careful when trying to make the decision to run DNA. It isn't cheap nor something you should deploy in a weeks time.

 

0 Comments

There are no comments to display.

×