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.
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.
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.
Global Commands
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’s configuration and typically include administrative and security elements. Common examples include the login banner, NTP settings, DNS configurations, and AAA authentication methods.
By identifying and grouping these commands as global, they can be applied uniformly using Catalyst Center’s 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.
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.
Site-Specific Commands
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.
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.
For this customer deployment, once commands were identified as site-specific, templates were customized and applied through Catalyst Center’s site hierarchy. This allowed for subtle but necessary differences between regions to be reflected in the automated configuration process.
Type-Specific Commands
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.
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.
In the case of the customer’s 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.
Out-of-Box Automation in Catalyst Center
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.
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.
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.
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.
Custom Templates in Catalyst Center
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.
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.
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.
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.
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.
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.
Applying Templates Using Catalyst Center
Once all necessary templates are created—covering global, site-specific, and type-specific configurations—the 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: Network Profiles and Tags. These tools allow configuration to be pushed automatically during the provisioning process based on a device’s location and intended role in the network.
Introduction to Network Profiles
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.
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.
Creating Network Profiles for Automation
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.
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.
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.
Limitations of Network Profiles Alone
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.
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.
Understanding Tags in Catalyst Center
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.
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.
Creating and Managing Tags
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.
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.
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.
Applying Templates Based on Tags
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.
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.
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.
Workflow Example: End-to-End Automation
To illustrate how all the components work together, consider a new core switch being added to Site A:
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.
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.
The Network Profile contains global and site-specific templates. These are evaluated, and any without tag restrictions are applied automatically.
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.
During provisioning, all selected templates are pushed to the device, resulting in an automated and targeted configuration deployment.
Benefits of This Automation Strategy
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:
Configuration consistency was achieved across all sites, ensuring each device met global and site-specific standards.
Operational time was significantly reduced, allowing engineers to focus on high-value tasks rather than repetitive CLI work.
Device roles were clearly defined using tags, enabling intelligent configuration targeting and eliminating configuration drift.
The system became scalable, supporting future expansion and changes in network architecture without revisiting each device manually.
Remaining Manual Configuration Tasks
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.
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.
Preparing for Advanced Template Development
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.
Introduction to Advanced Template Design
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 Ninja and Velocity, 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.
Why Use Advanced Logic in Templates
The value of scripting logic in templates lies in its ability to:
Avoid duplicate templates for similar use cases
Reduce human error during manual customization
. Make templates more scalable across diverse hardware and software platforms.s
Adapt configuration dynamically based on site, device role, or variable input
With these goals in mind, template authors can write once and deploy many times with accuracy and confidence.
Scripting Language Options
Catalyst Center supports two scripting languages for template creation:
Velocity 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.
Ninja is another supported language designed for simple configurations. It is less common in more complex deployments but suitable for static or partially dynamic templates.
For advanced logic and structured configuration control, Velocity is the preferred language in this implementation.
Template Components and Structure
A well-structured template includes the following core components:
Header definitions for variables and required data
Conditional logic blocks to manage different configuration outcomes
Loop structures to apply repeated commands like VLANs or ACLs
Device family or platform-specific commands gated with if-else statements
Commented sections for clarity and maintainability
This modular approach keeps templates easy to manage while making them powerful enough to address a wide variety of scenarios.
Using Variables in Templates
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.
For example, in a Velocity template:
shell
CopyEdit
#set ($ntpServer = \”${ntp_server}\”)
ntp server $ntpServer
In this example, the variable ntp_server 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.
Default Values and Optional Inputs
To make templates resilient, it is useful to assign default values in case no input is provided. Velocity supports this with conditional operators.
shell
CopyEdit
#set ($ntpServer = $ntp_server)
#if (!$ntpServer)
#set ($ntpServer = \”192.168.1.1\”)
#end
ntp server $ntpServer
In this example, if no value is assigned to ntp_server, the script defaults to using 192.168.1.1.
Conditional Logic for Device Role
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.
shell
CopyEdit
#if ($device_role == \”CORE\”)
router ospf 10
network 10.0.0.0 0.255.255.255 area 0
#end
#if ($device_role == \”ACCESS\”)
spanning-tree portfast default
#end
In this scenario, the template checks the value of device_role and applies the appropriate configuration. This enables a single template to serve multiple use cases.
Looping Through Lists
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.
bash
CopyEdit
#foreach ($vlan in $vlan_list)
vlan $vlan.id
name $vlan.name
#end
Here, the template loops through a list of VLANs and creates each one dynamically. The $vlan_list variable must be a structured list of objects passed to the template.
Platform-Specific Configuration Handling
Certain commands may only be valid on specific switch models. Velocity logic can also help handle differences between platforms.
shell
CopyEdit
#if ($platform == \”C9300\”)
stack-mac persistent timer 0
#end
#if ($platform == \”C9200\”)
No stack-mac persistent
#end
This ensures platform-specific commands are only applied where they are valid, avoiding errors during deployment.
Template Reusability Across Sites
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.
Building Complex Templates Step-by-Step
A typical process for building complex templates includes:
- Identifying which parts of the configuration are static and which are dynamic
- Defining the required variables and their types
- Mapping those variables in Catalyst Center to inputs (either site-based, device-based, or user input)
- Adding logic to conditionally include or exclude sections of the template
- Testing the template against a variety of device roles, platforms, and input values
By following this process, even highly specialized configurations can be streamlined and standardized.
Real-World Example: OSPF Template with Tags
A good example from the project involved automating OSPF routing only on devices tagged as Core or Distribution. The template logic looked like this:
shell
CopyEdit
#if ($device_tag == \”CORE\” || $device_tag == \”DISTRIBUTION\”)
router ospf 10
network $loopback_ip 0.0.0.0 area 0
passive-interface default
no passive-interface $uplink_interface
#end
Here, several variables are used, and conditional logic ensures that routing is only enabled on specific devices.
Handling Complex Interfaces or VLAN Assignments
Although interface-level configurations were manually handled in this project, advanced templates can prepare those as well, particularly when the Assurance license is upgraded in the future. Templates can include logic like:
wasm
CopyEdit
#foreach ($intf in $access_ports)
interface $intf.name
description $intf.Description
switchport access vlan $intf.vlan
switchport mode access
spanning-tree portfast
#end
This loops through a list of access port definitions and builds interface configurations automatically.
Best Practices for Template Management
Keep templates simple and modular. Avoid combining too many roles into a single template unless truly necessary.
Use clear and consistent naming for variables and templates.s
Document logic with comments inside the template to help future engineers understand the structure
Test templates on non-production devices before rolling out at scale
Version control templates are used externally to keep a historical record of changes.
Use the Template Hub’s Projects feature to organize templates by role, site, or purpose.
Validating Templates Before Deployment
After creating or modifying a template, validation is essential. Catalyst Center provides a preview function that shows the rendered configuration before applying it to a device. Use this feature to:
Check that all variables are substituted correctly
Ensure no syntax errors exist in the script.t
Confirm that conditional blocks are evaluating as expected. ed
Preview differences between multiple devices with different roles, tags, or site assignments
Validation prevents mistakes and builds confidence in the automation pipeline.
Advanced Template Capabilities
Advanced scripting transforms Catalyst Center templates from static config pushers into intelligent automation tools. By using logic, loops, and variables, a single template can cover dozens of deployment scenarios. This enhances scalability, improves configuration accuracy, and minimizes operational effort. Even within the limitations of the Assurance license, these techniques dramatically increase the platform’s utility.
Finalizing the Automation Workflow in Catalyst Center
With templates designed, categorized, and dynamically scripted using variables and logic, the final step in an effective configuration automation project is integrating everything into the actual provisioning and deployment process. This includes standardizing how devices are named, tagged, and assigned to sites, ensuring that Catalyst Center can apply the correct configurations automatically. A strong workflow ensures consistent results and reduces manual intervention, aligning with the goal of scalable, repeatable automation.
Device Naming Conventions as a Trigger for Automation
Device naming is more than an organizational preference—it can serve as a functional automation trigger in Catalyst Center. A well-planned naming convention allows automatic tag assignment, simplifies inventory searches, and reduces errors during provisioning.
In the customer project, each switch was named using a standard format:
css
CopyEdit
[SiteCode]-[Role]-[UniqueID]
Examples include:
CopyEdit
NYC-CORE-01
LAX-ACC-02
DAL-DIS-01
This consistent structure allowed Catalyst Center to parse the hostname and apply logic for tagging. By embedding the site and role into the name, both the physical location and network function of the device could be inferred automatically during discovery.
Tagging Devices Based on Hostname Patterns
Catalyst Center supports tagging rules based on pattern matching within hostnames. This capability was used to assign tags such as CORE, DISTRIBUTION, ACCESS, and EDGE automatically when devices were added to the inventory.
For example, in the tag management interface, a rule could be defined as:
sql
CopyEdit
If the hostname contains CORE, apply the tag CORE
If the hostname contains DIS, apply the tag DISTRIBUTION
If the hostname contains ACC, apply the tag ACCESS
This logic greatly reduced manual steps and ensured that each device received the appropriate configurations based on its role in the network. It also ensured consistency when provisioning large batches of devices across multiple sites.
Automating Site Assignment
Site assignment is critical for enabling the correct Network Profile and applying templates in the Catalyst Center. When a device is added to the platform, it must be associated with a site in the hierarchy.
This was achieved in two ways:
For pre-planned deployments, devices were manually assigned to the correct site based on their location
For large-scale rollouts, the discovery process used IP address-based rules to assign devices to sites automatically.
By ensuring that each switch had the correct IP schema and naming format, the provisioning system could place it in the correct part of the hierarchy without intervention.
Bootstrap Configuration for Initial Device Setup
Before a device can be managed by Catalyst Center, it must have basic connectivity to the network and the management platform. A bootstrap configuration is used to prepare the device for discovery. This configuration is applied manually or through out-of-band methods before the device joins the production network.
The bootstrap configuration typically includes:
Basic hostname and domain
IP address and default gateway on the management interface
AAA credentials or local login for initial access
SNMP or SSH enablement if needed
DNS and NTP for time synchronization
Optional VRF or routing settings for management plane reachability
Here’s an example of a basic Bootstrap configuration used in this project:
pgsql
CopyEdit
hostname NYC-CORE-01
IP domain-name company.local
interface vlan 10
IP address 10.10.10.2 255.255.255.0
no shutdown
ip default-gateway 10.10.10.1
ip name-server 8.8.8.8
ntp server 132.163.97.1
username admin privilege 15 secret 0 admin123
Once this configuration is in place, the switch can be discovered by Catalyst Center, tagged, assigned to a site, and provisioned.
Device Discovery and Inventory Registration
Catalyst Center includes built-in discovery tools to scan for devices and add them to the inventory automatically. For this deployment, discovery protocols like CDP, LLDP, and SNMP were used. Discovery settings were configured under the Design > Network Settings > Discovery menu.
Once discovered, devices appeared in the Provision > Inventory section, where tagging and site assignment could be verified. If bootstrap naming and addressing were done correctly, tags and site locations were applied without any manual steps.
At this point, Catalyst Center was ready to begin provisioning the device using the assigned templates and Network Profile.
Provisioning Workflow
Provisioning a device in Catalyst Center follows a structured process:
The switch is discovered and added to the inventory
Tags are applied based on a hostname pattern or a manual override.
The device is assigned to a site in the hierarchy.y
The assigned Network Profile is evaluated. ed
All templates under the profile are filtered based on tags.
Relevant global, site-specific, and type-specific templates are selected.d
The user initiates the provisioning task.
Catalyst Center pushes the full configuration to the switch.h
The provisioning status is monitored for success or failure
During provisioning, Catalyst Center provides visibility into every step of the process. Errors in variable mapping or logic are displayed in the task logs, allowing for quick troubleshooting.
Post-Provisioning Tasks
After provisioning is completed, most of the device configuration is in place. Only a few tasks typically remain:
Manually configuring switchports and SVIs, which were excluded due to Assurance license limitations
Verifying that routing adjacencies or uplinks are operational
Ensuring that monitoring integrations are active and SNMP/Syslog/Netflow data is being sent to external tools
Backing up the final device configuration as a reference
In most cases, these steps were minimal and required only a few minutes per switch. Compared to traditional manual configuration, this represented a major time saving and eliminated the potential for basic misconfigurations.
Advantages Realized in Production
This automated provisioning approach produced measurable operational benefits:
Deployment time was reduced by more than 70% compared to manual CLI configuration
All switches across the customer’s global sites shared a consistent baseline configuration.on
Device roles were tracked through tagging, improving network documentation.
Templates could be updated and redeployed centrally as policies evolved.
Future switches could be added with minimal effort, requiring only bootstrap configuration.n
Perhaps most importantly, the process was repeatable. New engineers could follow the same workflow with predictable results, reducing dependency on any single person’s expertise or memory.
Planning for Growth and Future Enhancements
While the solution was deployed under an Assurance-only license, it was designed with future scalability in mind. If advanced licensing becomes available later, additional features such as SD-Access, interface templates, and policy-based automation can be layered into the existing framework.
To prepare for that, these forward-looking strategies were included:
Interface templates were drafted and stored offline for future use
Naming and tagging conventions were documented for easy expansion.
Template projects were kept organized by site, role, and function.n
Provisioning procedures were published internally for training and knowledge transfer.
This ensured that the solution was not only effective for today’s needs but also adaptable for future use cases.
Automation Lifecycle
This project demonstrated that even with only the Assurance feature set, Catalyst Center can be used to build a powerful and consistent automation framework. The key ingredients included:
Categorizing configuration into global, site-specific, and type-specific templates
Using Velocity scripting for dynamic and conditional configurations
Applying configurations through Network Profiles and Tags
Standardizing device naming, tagging, and site assignment
Automating provisioning workflows and minimizing post-provisioning effort
By combining thoughtful planning, structured design, and efficient execution, the customer was able to complete a full switch refresh project with automation at the core of the strategy.
Final Thoughts
Automating switch configuration using Catalyst Center, even with only the Assurance licensing tier, is entirely achievable when approached with structure, strategy, and creativity. Although lacking access to full SD-Access capabilities, the project demonstrated that Catalyst Center can still serve as a powerful platform for standardizing and accelerating switch deployments across an enterprise network.
What started as a manual task, refreshing switches across numerous sites, transformed into a repeatable automation framework that significantly reduced time, errors, and overhead. By dissecting configurations into global, site-specific, and type-specific layers, and then leveraging Catalyst Center’s built-in tools like Network Settings, Custom Templates, Network Profiles, and Tagging, the solution achieved consistency and control without compromising flexibility.
The key enablers of success included:
- Well-planned device naming conventions that enabled automatic tagging
- Thoughtful use of template scripting for variable-based configuration
- Strategic alignment between the site hierarchy and configuration needs
- Automation of base configurations, leaving only interface work as a manual task
These methods created a scalable system. As future devices are added or existing ones replaced, the provisioning process remains simple, structured, and consistent. Beyond operational benefits, it also builds a foundation for future growth. Should full DNA licensing or SD-Access become available, the groundwork laid during this deployment can easily evolve to support more advanced features.
This project underscored a broader truth: automation isn’t only about the tools you have, but how you use them. With some creativity and careful design, even limited feature sets can drive meaningful outcomes. The goal isn’t just to configure faster, it’s to configure smarter, and this deployment accomplished exactly that.
If you’re planning a similar project or expanding on this framework, take the time upfront to build your design principles, structure your templates, and think through how roles, sites, and settings interact. Doing so will ensure your automation efforts are sustainable, efficient, and ready for what’s next.