{"id":459,"date":"2025-09-28T21:34:20","date_gmt":"2025-09-28T21:34:20","guid":{"rendered":"https:\/\/www.passguide.com\/blog\/?p=459"},"modified":"2025-09-28T21:34:20","modified_gmt":"2025-09-28T21:34:20","slug":"streamlining-configuration-automation-via-catalyst-center-and-assurance","status":"publish","type":"post","link":"https:\/\/www.passguide.com\/blog\/streamlining-configuration-automation-via-catalyst-center-and-assurance\/","title":{"rendered":"Streamlining Configuration Automation via Catalyst Center and Assurance"},"content":{"rendered":"

In a modern enterprise network, managing and deploying consistent configurations across a fleet of switches located at various sites is a challenging task. Manual configurations are time-consuming and prone to errors, often leading to inconsistencies that create operational risks and reduce efficiency. The availability of automation platforms like Catalyst Center provides an opportunity to simplify this process. However, limitations arise when the deployment is licensed only for the Assurance feature set, excluding access to full SD-Access automation capabilities. This was the exact scenario for a recent customer project that involved a full switch refresh and Catalyst Center deployment across all of their sites.<\/span><\/p>\n

With only Assurance licensing available, the key objective was to determine how to automate as much of the switch configuration process as possible using the tools included with Catalyst Center. Without SD-Access fabric capabilities, alternative methods had to be explored. After testing several techniques, a strategy was developed that allowed for the automation of almost every aspect of switch configuration, excluding only interface and SVI commands, which still required manual handling.<\/span><\/p>\n

The starting point for this strategy involved understanding the configurations already present on the switches. While this initially appeared to be a simple process, it quickly became apparent that identifying common configurations required a more nuanced approach. Commands had to be categorized to make automation manageable and targeted. Three primary configuration categories emerged, each influencing the automation approach.<\/span><\/p>\n

Global Commands<\/b><\/p>\n

Global commands are those applied universally across all devices in the organization, regardless of location or function. These settings form the baseline of every switch\u2019s configuration and typically include administrative and security elements. Common examples include the login banner, NTP settings, DNS configurations, and AAA authentication methods.<\/span><\/p>\n

By identifying and grouping these commands as global, they can be applied uniformly using Catalyst Center\u2019s built-in automation tools. Applying global configurations ensures a consistent operational and security posture across all sites. It also reduces the need for repeated configuration tasks for each switch individually.<\/span><\/p>\n

In the context of the project, these commands were set up using Catalyst Center’s Design menu under Network Settings. The flexibility to apply these globally, or override them on a per-site basis, added further value. Even though all customer sites used the same global settings, the ability to tailor settings later based on regional needs remained available through the site hierarchy.<\/span><\/p>\n

Site-Specific Commands<\/b><\/p>\n

Site-specific commands are settings that must vary based on the physical or logical location of the switch. These often include logging destinations, region-specific AAA servers, or unique SNMP configurations tailored to local monitoring tools. Failing to manage these variations properly can lead to misrouted logs, failed authentication attempts, or broken integrations with network monitoring platforms.<\/span><\/p>\n

To automate site-specific configurations, the Catalyst Center hierarchy is leveraged. Each site is defined in the Catalyst Center topology, and network profiles or templates are created and assigned at this level. This enables targeted deployment of commands to switches at specific sites while maintaining a centralized automation strategy.<\/span><\/p>\n

For this customer deployment, once commands were identified as site-specific, templates were customized and applied through Catalyst Center\u2019s site hierarchy. This allowed for subtle but necessary differences between regions to be reflected in the automated configuration process.<\/span><\/p>\n

Type-Specific Commands<\/b><\/p>\n

Type-specific commands apply to switches based on their intended function in the network. For example, core switches may need OSPF routing configurations, while access switches require specific VLAN handling or port security policies. Recognizing which devices require which commands is critical to deploying relevant configurations without overloading or misconfiguring devices.<\/span><\/p>\n

To manage this layer of automation, device tagging within Catalyst Center was used. Tags were created to represent different switch roles, such as Core, Distribution, Edge, and Access. Templates were then associated with these tags to ensure that only relevant configurations were applied to each switch. This enabled precise control over what configurations were pushed based on the role of each switch.<\/span><\/p>\n

In the case of the customer\u2019s traditional three-tier architecture, switches were tagged according to naming conventions, allowing Catalyst Center to automatically apply the correct templates during provisioning. This significantly streamlined the deployment process and ensured functional accuracy.<\/span><\/p>\n

Out-of-Box Automation in Catalyst Center<\/b><\/p>\n

Catalyst Center offers a suite of built-in automation tools designed to simplify the initial configuration process. Even under the limitations of the Assurance-only license, many essential settings can be automated directly using the Design and System Settings interfaces.<\/span><\/p>\n

The Design > Network Settings > Network section is where foundational services are defined. Here, administrators can specify global network services, including AAA servers, NTP servers, DNS servers, DHCP servers, and the message of the day banner. In this project, all these settings were implemented as global configurations to maintain uniformity. However, Catalyst Center also permits these to be overridden per site, which supports flexibility in more complex deployments.<\/span><\/p>\n

Within the System > Settings menu, other network services can be configured. These include SNMP servers, Syslog servers, and Netflow destinations. Catalyst Center, by default, configures itself to receive data from these protocols. However, administrators can also define external destinations to integrate with existing monitoring and SIEM platforms. It is important to note that while Catalyst Center allows IP address input for these services, other elements such as SNMP strings and user credentials must still be applied via custom templates.<\/span><\/p>\n

The out-of-box features covered approximately half of the global configurations required in this deployment. These tools are effective for establishing consistent foundational settings across the network and provide an essential building block for further automation.<\/span><\/p>\n

Custom Templates in Catalyst Center<\/b><\/p>\n

For configurations that fall outside of what Catalyst Center supports natively, custom templates provide the necessary flexibility. Templates can be written using scripting languages like Ninja or Velocity and allow for the use of logic and variable substitution. This means configurations can adapt based on device characteristics, site location, or assigned tags, making the deployment process intelligent and adaptable.<\/span><\/p>\n

To begin creating custom templates, the administrator navigates to the Template Hub under the Tools section. Within the Template Hub, the first step is to create a project to organize related templates. Creating a project keeps custom templates separate from the system-provided ones and simplifies navigation in environments with large libraries.<\/span><\/p>\n

Each template is then created under the project. It is important to use a clear and consistent naming convention, such as Global-TemplateName or Site-TemplateName. During creation, administrators select the scripting language, specify the IOS type, and choose the device family. This last step ensures compatibility between the template and the switch hardware. For example, some commands supported on Catalyst 9300 switches may not work on Catalyst 9200 switches due to differences in the IOS-XE versions they support.<\/span><\/p>\n

Before creating templates, it is useful to define tags within Catalyst Center. These tags can be assigned to devices and referenced within the templates to control where and how configurations are applied. For instance, a template designed for OSPF routing could be tagged to apply only to Core and Distribution switches.<\/span><\/p>\n

After the template is created, the configuration commands are entered. These can include conditional logic and variable-based inputs, enabling flexible and dynamic configuration generation. Once completed, the template is saved and committed, making it available for deployment.<\/span><\/p>\n

Custom templates allowed the project team to automate the remaining half of the configurations not covered by out-of-box features. With the combination of projects, templates, and tags, Catalyst Center provided the structure necessary for scalable and accurate automation.<\/span><\/p>\n

Applying Templates Using Catalyst Center<\/b><\/p>\n

Once all necessary templates are created\u2014covering global, site-specific, and type-specific configurations\u2014the next step is applying them to devices in a structured and scalable way. Catalyst Center uses two primary mechanisms to control how and where templates are applied: <\/span>Network Profiles<\/b> and <\/span>Tags<\/b>. These tools allow configuration to be pushed automatically during the provisioning process based on a device\u2019s location and intended role in the network.<\/span><\/p>\n

Introduction to Network Profiles<\/b><\/p>\n

Network Profiles in the Catalyst Center act as bundles of configuration assigned to specific sites and device roles. A profile groups templates together, allowing all associated configurations to be applied to a switch during provisioning. Each Network Profile is created per device role, such as switching, routing, or wireless, and per site.<\/span><\/p>\n

For this project, only switches were involved, so a single device role was used. However, the concept scales across multiple roles and can be extended to other device types in larger environments.<\/span><\/p>\n

Creating Network Profiles for Automation<\/b><\/p>\n

To create a Network Profile, navigate to the Design section within Catalyst Center, then choose Network Profiles. From there, a new profile can be created and associated with the relevant device role and site.<\/span><\/p>\n

Within the profile, templates can be added under the nth-day configuration tab. This is where templates are assigned for initial deployment and ongoing automation. In the project, all global and site-specific templates were added to each site-specific Network Profile. This allowed for the automation of a majority of the switch configuration during the provisioning process.<\/span><\/p>\n

Each Network Profile is then bound to a specific site using the Assign Site function. When a switch is discovered or manually added and assigned to that site, it inherits the Network Profile during provisioning. The templates in the profile are automatically evaluated and applied as part of the configuration push.<\/span><\/p>\n

Limitations of Network Profiles Alone<\/b><\/p>\n

Network Profiles alone cannot address all configuration needs. Specifically, they cannot distinguish between different switch types within the same site. For example, if a site contains both access and core switches, and each requires different routing configurations, a Network Profile cannot apply different templates to each based on role.<\/span><\/p>\n

To solve this problem, Catalyst Center uses Tags. Tags introduce another layer of control, allowing templates to be applied based on device classification within the same Network Profile.<\/span><\/p>\n

Understanding Tags in Catalyst Center<\/b><\/p>\n

Tags are user-defined labels assigned to devices that describe their role or classification. In the context of this project, Tags such as Core, Distribution, Edge, and Access were created. These Tags allowed the system to identify the intended use of a switch and apply only the relevant templates.<\/span><\/p>\n

For instance, a template containing OSPF routing commands should only be applied to Core and Distribution switches. By tagging those switches accordingly, the OSPF template is selectively deployed only where appropriate.<\/span><\/p>\n

Creating and Managing Tags<\/b><\/p>\n

To create and manage Tags, navigate to the Provision menu and select Inventory. Above the device list, there is a Tag button. Hovering over it reveals the option to manage tags. Here, administrators can define new tags and apply logic to automate their assignment.<\/span><\/p>\n

In this project, a naming convention was used to simplify tag assignment. Device hostnames included role-based identifiers such as CORE, DIS, ACC, and EDG. In the advanced settings of each tag, logic was defined so that if the hostname contained one of these identifiers, the appropriate tag would be assigned automatically.<\/span><\/p>\n

This approach saved time and reduced the chance of tagging errors. When a switch was discovered by Catalyst Center and added to the inventory, it was immediately tagged based on its hostname. These tags were then used to determine which templates would be applied during provisioning.<\/span><\/p>\n

Applying Templates Based on Tags<\/b><\/p>\n

Tags can be associated with templates during creation in the Template Hub. Each template includes an option to define applicable tags. This defines the conditions under which the template should be applied.<\/span><\/p>\n

During provisioning, Catalyst Center checks the tags assigned to each device. Templates within the associated Network Profile are then filtered based on these tags. Only templates with matching tags are applied. This provides granular control over configuration deployment, ensuring each device receives only the settings it requires.<\/span><\/p>\n

In the customer project, this approach allowed different templates to be applied to access switches versus core switches within the same site. By combining Network Profiles with Tags, full configuration automation was achieved based on both location and device function.<\/span><\/p>\n

Workflow Example: End-to-End Automation<\/b><\/p>\n

To illustrate how all the components work together, consider a new core switch being added to Site A:<\/span><\/p>\n

The switch is bootstrapped with a hostname such as SITEA-CORE-01. This hostname triggers automatic tag assignment via the tagging logic defined in Catalyst Center.<\/span><\/p>\n

The switch is then added to the Catalyst Center inventory and assigned to Site A. Based on this assignment, the switch inherits the Network Profile for Site A.<\/span><\/p>\n

The Network Profile contains global and site-specific templates. These are evaluated, and any without tag restrictions are applied automatically.<\/span><\/p>\n

The tagged templates are filtered. Only those tagged with CORE are considered. The switch has the CORE tag, so it receives all relevant CORE templates.<\/span><\/p>\n

During provisioning, all selected templates are pushed to the device, resulting in an automated and targeted configuration deployment.<\/span><\/p>\n

Benefits of This Automation Strategy<\/b><\/p>\n

Using Catalyst Center with only the Assurance license, this approach delivered significant value. Configuration tasks that would have previously required manual input for each device were now handled automatically during provisioning. This led to several benefits:<\/span><\/p>\n

Configuration consistency was achieved across all sites, ensuring each device met global and site-specific standards.<\/span><\/p>\n

Operational time was significantly reduced, allowing engineers to focus on high-value tasks rather than repetitive CLI work.<\/span><\/p>\n

Device roles were clearly defined using tags, enabling intelligent configuration targeting and eliminating configuration drift.<\/span><\/p>\n

The system became scalable, supporting future expansion and changes in network architecture without revisiting each device manually.<\/span><\/p>\n

Remaining Manual Configuration Tasks<\/b><\/p>\n

Despite the automation capabilities described, some configuration elements still require manual input. Specifically, interface configurations and SVIs could not be automated within the Assurance license. These elements were completed manually after initial provisioning.<\/span><\/p>\n

However, because all other aspects of the configuration had been automated, the remaining tasks were minimal. This reduced the potential for error and significantly accelerated the deployment timeline.<\/span><\/p>\n

Preparing for Advanced Template Development<\/b><\/p>\n

With the foundational structure of automation in place, the next phase of optimization involves expanding the use of logic, variables, and conditionals within custom templates. By leveraging the scripting capabilities of Ninja and Velocity, administrators can create adaptive templates that adjust based on device, site, and tag input. This will be explored further in the next part.<\/span><\/p>\n

Introduction to Advanced Template Design<\/b><\/p>\n

With the foundational automation process established using global, site-specific, and type-specific templates, along with the application through Network Profiles and Tags, the next step is refining automation with advanced scripting. Cisco Catalyst Center supports powerful template customization using scripting languages like <\/span>Ninja<\/b> and <\/span>Velocity<\/b>, which allow logic-based decision-making, dynamic variable substitution, and flexible command application. These features transform static configuration templates into intelligent, reusable assets that adapt to multiple deployment scenarios.<\/span><\/p>\n

Why Use Advanced Logic in Templates<\/b><\/p>\n

The value of scripting logic in templates lies in its ability to:<\/span><\/p>\n

Avoid duplicate templates for similar use cases<\/span>
\n<\/span> Reduce human error during manual customization<\/span>
\n<\/span>. Make templates more scalable across diverse hardware and software platforms.s<\/span>
\n<\/span> Adapt configuration dynamically based on site, device role, or variable input<\/span><\/p>\n

With these goals in mind, template authors can write once and deploy many times with accuracy and confidence.<\/span><\/p>\n

Scripting Language Options<\/b><\/p>\n

Catalyst Center supports two scripting languages for template creation:<\/span><\/p>\n

Velocity<\/b> is a Java-based scripting language that supports variables, conditions, and loops. It is commonly used in Cisco DNA templates due to its simplicity and integration with structured data.<\/span><\/p>\n

Ninja<\/b> is another supported language designed for simple configurations. It is less common in more complex deployments but suitable for static or partially dynamic templates.<\/span><\/p>\n

For advanced logic and structured configuration control, <\/span>Velocity<\/b> is the preferred language in this implementation.<\/span><\/p>\n

Template Components and Structure<\/b><\/p>\n

A well-structured template includes the following core components:<\/span><\/p>\n

Header definitions for variables and required data<\/span>
\n<\/span> Conditional logic blocks to manage different configuration outcomes<\/span>
\n<\/span> Loop structures to apply repeated commands like VLANs or ACLs<\/span>
\n<\/span> Device family or platform-specific commands gated with if-else statements<\/span>
\n<\/span> Commented sections for clarity and maintainability<\/span><\/p>\n

This modular approach keeps templates easy to manage while making them powerful enough to address a wide variety of scenarios.<\/span><\/p>\n

Using Variables in Templates<\/b><\/p>\n

Variables act as placeholders that can be replaced at runtime with actual values. In Catalyst Center, variables can be created in the template definition and mapped to site-specific, device-specific, or user-entered values.<\/span><\/p>\n

For example, in a Velocity template:<\/span><\/p>\n

shell<\/span><\/p>\n

CopyEdit<\/span><\/p>\n

#set ($ntpServer = \\”${ntp_server}\\”)<\/span><\/p>\n

ntp server $ntpServer<\/span><\/p>\n

In this example, the variable <\/span>ntp_server<\/span> is defined in the Catalyst Center GUI and assigned a value per site. When the template is executed, the actual IP address replaces the placeholder.<\/span><\/p>\n

Default Values and Optional Inputs<\/b><\/p>\n

To make templates resilient, it is useful to assign default values in case no input is provided. Velocity supports this with conditional operators.<\/span><\/p>\n

shell<\/span><\/p>\n

CopyEdit<\/span><\/p>\n

#set ($ntpServer = $ntp_server)<\/span><\/p>\n

#if (!$ntpServer)<\/span><\/p>\n

\u00a0\u00a0#set ($ntpServer = \\”192.168.1.1\\”)<\/span><\/p>\n

#end<\/span><\/p>\n

ntp server $ntpServer<\/span><\/p>\n

In this example, if no value is assigned to <\/span>ntp_server<\/span>, the script defaults to using <\/span>192.168.1.1<\/span>.<\/span><\/p>\n

Conditional Logic for Device Role<\/b><\/p>\n

Templates often need to behave differently based on the type of device they are applied to. Conditional logic allows the template to evaluate the tag or input and adjust the configuration accordingly.<\/span><\/p>\n

shell<\/span><\/p>\n

CopyEdit<\/span><\/p>\n

#if ($device_role == \\”CORE\\”)<\/span><\/p>\n

router ospf 10<\/span><\/p>\n

\u00a0network 10.0.0.0 0.255.255.255 area 0<\/span><\/p>\n

#end<\/span><\/p>\n

#if ($device_role == \\”ACCESS\\”)<\/span><\/p>\n

spanning-tree portfast default<\/span><\/p>\n

#end<\/span><\/p>\n

In this scenario, the template checks the value of <\/span>device_role<\/span> and applies the appropriate configuration. This enables a single template to serve multiple use cases.<\/span><\/p>\n

Looping Through Lists<\/b><\/p>\n

Another advanced technique is using loops to apply commands multiple times based on a list input. This is useful for VLANs, ACLs, or interface configurations that vary per site or device.<\/span><\/p>\n

bash<\/span><\/p>\n

CopyEdit<\/span><\/p>\n

#foreach ($vlan in $vlan_list)<\/span><\/p>\n

vlan $vlan.id<\/span><\/p>\n

\u00a0name $vlan.name<\/span><\/p>\n

#end<\/span><\/p>\n

Here, the template loops through a list of VLANs and creates each one dynamically. The <\/span>$vlan_list<\/span> variable must be a structured list of objects passed to the template.<\/span><\/p>\n

Platform-Specific Configuration Handling<\/b><\/p>\n

Certain commands may only be valid on specific switch models. Velocity logic can also help handle differences between platforms.<\/span><\/p>\n

shell<\/span><\/p>\n

CopyEdit<\/span><\/p>\n

#if ($platform == \\”C9300\\”)<\/span><\/p>\n

stack-mac persistent timer 0<\/span><\/p>\n

#end<\/span><\/p>\n

#if ($platform == \\”C9200\\”)<\/span><\/p>\n

No stack-mac persistent<\/span><\/p>\n

#end<\/span><\/p>\n

This ensures platform-specific commands are only applied where they are valid, avoiding errors during deployment.<\/span><\/p>\n

Template Reusability Across Sites<\/b><\/p>\n

With variables, logic, and conditional branching, a single well-designed template can be used across all customer sites with minimal adjustments. During the provisioning process, Catalyst Center prompts for the required inputs or fetches them based on site configuration, device metadata, or tags. This significantly reduces the total number of templates needed in the system.<\/span><\/p>\n

Building Complex Templates Step-by-Step<\/b><\/p>\n

A typical process for building complex templates includes:<\/span><\/p>\n