My latest project has been a switch refresh and a deployment of a Catalyst Center with Assurance only for a customer across all of their sites. Now the task I had at hand was how can I use Catalyst Center to automate as much configuration on the switches as possible. Because we were only licensed for Assurance we did not have access to use any of the SD-Access fabric automation that Catalyst Center was built to provide.

After trying a few different techniques, I found what I believe to be the best current way of automating everything on a switch, minus the interface and SVI commands. Before I could configure anything I needed to figure out what are the common commands on the current switches that can be automated. It sounds easy at first, but once you start documenting all of the commands you realize that the common commands tend to fall into one of three categories:

Global Commands: These are configuration that are applied organization wide to all devices.

Site Specific Commands: These are configuration that apply to all devices at a specific site.

Type Specific Commands: These are configuration that apply to a type or use case of device. For instance commands for Core switches vs Access switches.

Once I figured out which commands I could automate and what devices needed those commands based on where that command falls in the categories above, I could start to configured Catalyst Center.

OUT OF BOX EXPERIENCE

One of the main pillars of Catalyst Center is configuration automation. Because of this Cisco has provided pre-built automation workflows into the software. All of these settings can be found either under the Design > Network Settings page, or the Settings page for Catalyst Center itself. About half of the commands noted in the Global category are satisfied in the pre-built workflow. Some of these include:

NETWORK SETTINGS PAGE

This sections lists all of the settings found in the Design > Network Settings > Network page:

• AAA Servers
• NTP Servers
• DNS Servers
• Message of the Day Banner
• DHCP Servers (however I never found a use for this setting)

It also important to note that while in my case all of these settings were global, Catalyst Center allows you to change these settings in the Hierarchy by site as well. So if you have sites that use different AAA servers, or a different order of AAA servers, then you can make those site specific changes here as well.

CATALYST CENTER SETTINGS PAGE

This section lists some of the additional network services found under System > Settings page:

• SNMP Servers
• Syslog Servers
• Netflow Servers

By default Catalyst Center will configure itself as a server to receive monitoring data using the above protocols, but you can also add your own server IPs in the list as well. This is great for integrating existing Network Monitoring or SIEM services into the workflow of Catalyst Center. Note that out of the box it wont configure SNMP strings or usernames, only add the IPs as destinations for the protocols. You will need to use a custom template to include the strings and/or usernames.

CUSTOM TEMPLATES

For the rest of the Global, Site specific, and Type specific commands we need to use Custom Templates. Now Custom Templates in Catalyst Center are extremely powerful and can be their own post with how in depth they can get, so for the sake of this blog post I’m keeping it high level. Custom Templates can be written using either Ninja or Velocity scripting languages and support both logic operators and variables.

To get to the custom templates navigate to the template hub; Tools > Template Hub. Once in the Template Hub I like to first create a new project; click Add in the upper right corner and select Project. A project is a way to keep your templates organized. In the left panel you can filter out the templates by project so later you don’t have to search through all of the pre-built templates that come with Catalyst Center.

The next thing to do is create your first template. Go back to the Add button in the top right corner and click on Template. Name the Template something meaningful as this is what you will be presented with when it comes time to associate it with the Network Profile. I like to use something like site-TemplateName, or Global-TemplateName so I can keep track of where it should go. Then choose the project name to associate with and if you are using Ninja or Velocity. Finally choose the IOS type and choose a device family.

The device family is a key part, it allows you to create templates that apply say to a 9300 vs a 9200. This is important because some commands for the 9300 that uses the full blown IOS-XE don’t work on the 9200 that uses IOS-XE_lite. Finally, I like to add Tags to the template to indicate which tagged devices should receive this template. Tags are discussed later in this blog, and are a way I like to determine which of the Type Specific devices this template should be applied (ie Core switch commands, or Access switch commands, or both).

Note: I would actually create the Tags first before creating the templates as tags are shown in a dropdown box. Check out the section on tags for more info.

Create the template, then edit it to then paste in the configuration you want to have applied to the devices. This is the part where you can get really creative with logic and variables, but I’m going to skip this for now. Save the template and commit. Repeat this process to build out your template library.

APPLYING TEMPLATES

Between the On-Box configuration and custom Templates you now have all the configuration ready to automate. But how do we apply it to devices? Well there are two ways templates and configuration is applied, Network Profiles and Tags within the Network Profiles.

NETWORK PROFILES

Network Profiles is how Catalyst Center groups configuration to be pushed to a device. You can have one profile per site per device type (ie Switching, Routing, Wireless, ect). I like to create a Network Profile per site for every device type, which in this last project was just switching. I can then add the different templates under the nth-day tab. All of the global templates that apply to this site, as well as the site specific templates are then bundled under this profile.

When you save the network profile you need to assign it to a site. Click assign site and choose the site from the hierarchy. Now any device that is assigned to this site will use this profile and be configured with the templates upon provisioning of the device. This is great for pushing all of the Global and Site specific commands, but what about Type specific commands? Well this is where Tags come into play.

TAGS

The way I use tags are to identify how a device is being used. In this case I had tags for Core, Distribution, Edge, and Access. By tagging the devices in the device inventory I am telling Catalyst Center what I intend to configure this switch as. For instance, this current project, the network uses the traditional 3-tiered architecture with layer 2 access switches. I have a template for OSPF routing that I only want applied to the Core and Distribution switches. By using the tags when I created the template I can control which type of switch this template is applied to.

To give an example, a core switch is added to Catalyst Center and tagged as CORE, this switch is added to a site then provisioned. Catalyst Center will apply the appropriate Network Profile containing all of the templates, each of the templates are checked for which tags should apply and Catalyst Center sees the routing template has CORE tagged. This template is then applied to this switch.

To create tags, navigate to Provision > Inventory and just above the list of devices you will see a button for tag, hover over it and choose the “manage tags” option. Here you can create tags and provide some logic. What I like to do is in the advanced section of the tag you can add some logic where you can choose the hostname contains and then I put some value that follows the host naming convention. In this case I use the words CORE, DIS, ACC, EDG in the hostname to signify the type, then when ever a device is discovered in Catalyst Center with that in the hostname the appropriate tag is applied.

You can see how by just utilizing a good naming convention when bootstrapping the device and assigning it to the correct site most of the configuration for the device is automated. Then you just need to focus on configuring the interfaces and SVIs and the switch is ready for deployment.

Hopefully you found this post helpful and saves you a lot of time deploying your devices using Catalyst Center.