Catalyst Center automation replaces repetitive, device-by-device configuration with a single controller that designs, onboards, provisions and maintains your Cisco network from policy. It covers site design, switch and wireless provisioning, templates, software images and an API layer for scripting. This guide sets out what each part does, the order in which to adopt it, and the security decisions to make before you switch it on. If you have seen the platform called Cisco DNA Center, it is the same product under a new name.
TL;DR
- Catalyst Center is the new name for Cisco DNA Center. Automation is the same set of capabilities under either name.
- Automation runs across the network lifecycle: design, discovery, onboarding, provisioning, ongoing management and troubleshooting.
- Start with a clean site hierarchy, credentials and network settings. Everything later depends on them.
- Use GUI workflows and templates first, then move repeatable work to the API or Ansible.
- Treat the controller as critical infrastructure: private network, firewall, separated interfaces.
Table of Contents
- Catalyst Center or DNA Center: one product, two names
- What the automation actually covers
- Day 0 and Day 1: design, discovery and onboarding
- LAN Automation for access switches
- Wireless automation
- Workflows and templates: automation without code
- APIs and Ansible: automation as code
- Securing the controller that runs your network
- Our perspective
- A practical rollout sequence
- Getting help with Catalyst Center automation
- FAQ
- Sources
Catalyst Center or DNA Center: one product, two names
Readers searching for “Cisco DNA Center automation” and “Catalyst Center automation” are looking for the same thing. Cisco’s own product page describes Catalyst Center as formerly Cisco DNA Center, and its LAN Automation guide notes that both names may still appear in collateral during the rebranding.
This matters in practice. Older runbooks, validated designs and partner documents use the DNA Center name. Your team can use them, but should check the software release they refer to before following any step.
Cisco also publishes deployment guides for several form factors: third-generation and second-generation appliances, ESXi, Azure, AWS, Ubuntu KVM and Global Manager. The automation features described below are the same whichever form you choose, but the sizing, resilience and security design differ, so settle that first.
What the automation actually covers
“Automation” in Catalyst Center is not one feature. It is a chain of capabilities that follows the device from the design stage to day-to-day operation. Cisco’s July 2026 LAN Automation guide structures the lifecycle as planning, network design and discovery, provisioning, management of an automated stack, and troubleshooting. That is a useful frame for any project, because each stage has its own inputs and its own failure modes.
| Stage | What gets automated | Typical input from you |
|---|---|---|
| Design | Site hierarchy, floor maps, network settings, IP pools | Site list, addressing plan, naming standard |
| Discovery and onboarding | Device discovery, inventory, Plug and Play | Credentials, seed devices, device list |
| Provisioning | Switching and wireless profiles, templates, tags | Configuration standards, VLAN and SSID plan |
| Operation | Software images, reprovisioning, API-driven change | Change process, maintenance windows |
| Troubleshooting | Controller and device state through one view | Monitoring and escalation rules |
The table is deliberately generic. The detail below shows how each stage maps to specific, documented capabilities.
Day 0 and Day 1: design, discovery and onboarding
Cisco’s validated Ansible playbooks give the clearest public picture of what can be automated early in a deployment. For Day 0, they cover role-based access control, user management, and Cisco ISE and AAA integration. In other words, you decide who can change the network, and how they authenticate, before anything is provisioned.
For Day 1, the same playbooks automate site hierarchy and floor-map design, device credentials, network settings, IP-pool reservations, wireless design, wireless and switching profiles, device discovery, inventory, Plug and Play onboarding, provisioning, reprovisioning, templates and tags.
Two points follow from that list.
- Design data is the foundation. The site hierarchy, credentials and network settings are inherited by every device you add later. A messy hierarchy produces messy automation, and it is far cheaper to fix before 200 switches depend on it.
- Identity comes first. ISE and AAA integration sits in Day 0 for a reason. If you plan guest or BYOD access on the same estate, read our Cisco ISE guest access playbook before you design the wireless policy.
LAN Automation for access switches
LAN Automation is the part most people mean when they talk about automating the wired network. Cisco describes it as simplifying operations, eliminating repetitive manual configuration and establishing a standard, error-free underlay network for SD-Access.
The benefit is consistency. A campus with 40 access switches configured by hand will drift: a different VLAN here, a missing setting there. When the underlay is generated from a single design, every switch is built the same way, and a replacement can be onboarded without an engineer rebuilding a configuration from memory.
That is most valuable where estates grow quickly or span many buildings, such as a multi-academy trust, a manufacturing group with several plants, or a housing developer rolling out the same network to each new site. If your access layer is built on Catalyst switching, our Cisco Catalyst overview explains the platform choices behind it.
What to prepare before running it
- A confirmed hardware and software compatibility check for every switch in scope.
- A reserved address range for the underlay, agreed with whoever owns your IP plan.
- Seed device uplinks and cabling documented and physically verified.
- A rollback plan for each stage, so one failed onboarding does not stall the project.
Wireless automation
Wireless is where manual work is most error-prone, because one mistake in an SSID, VLAN or RF setting is repeated across every access point. Cisco’s Wireless Automation validated solution, published in November 2025, covers designing, deploying, monitoring and operating enterprise WLANs through Catalyst Center.
The documented workflow is long, and it shows how much the platform takes on: ISE integration, site hierarchy and floor maps, AAA, DNS, DHCP, NTP, SNMP and Syslog settings, WLANs, VLANs, RF profiles, controller discovery, software-image management, HA SSO, controller and AP provisioning, and AP placement on maps.
Automation does not replace the physical groundwork, though. Access point placement, cabling and coverage still decide whether users get a good experience, and a controller cannot correct a poorly sited access point. The practical points in this guide to business Wi-Fi installation are worth reading alongside your design. For sites with demanding environments, a wireless site survey before you load floor maps gives the automation accurate inputs. Our notes on warehouse wireless and student accommodation Wi-Fi cover two of the harder cases.
Workflows and templates: automation without code
Not every team wants to write scripts, and not every task justifies it. Catalyst Center workflows are GUI wizards that guide administrators through multistep tasks that would otherwise be complex or advanced to complete manually, according to Cisco’s Release 3.2.x User Guide.
Use workflows when:
- The task is infrequent, so a script would rarely pay back its build time.
- The person running it is a network generalist rather than an automation engineer.
- You want a guided, repeatable path that reduces the risk of skipped steps.
Use templates and profiles for configuration that must be identical across many devices, such as a standard access-switch build or a branch profile. Define it once, apply it by site or tag, and change it in one place.
APIs and Ansible: automation as code
Once the GUI processes are stable, repeatable work can move to code. Catalyst Center APIs use token-based authentication, and Cisco’s 3.3.x Platform User Guide states that an authentication token remains valid for 60 seconds. Scripts therefore need to request a fresh token rather than store one. Cisco DevNet’s quickstart confirms that every API call needs an access token, which validates access and identifies the requesting user.
That last point has an operational benefit: API changes are tied to a named account, so they can be audited like any other change.
The API documentation offers code previews for Shell, Node, Python, Ruby, JavaScript, JQuery, PHP, Go and Ansible. Python with the requests library is the usual starting point for network teams, and Ansible suits those who already manage servers that way.
A sensible split between GUI and code
| Task | Best approach |
|---|---|
| One-off design of a new site | Workflow |
| Standard switch or branch build | Template or profile |
| Bulk inventory reports, scheduled checks | API script |
| Rebuilding many sites from a source of truth | Ansible playbooks |
| Rare, complex change | Workflow, with review |
Securing the controller that runs your network
An automation controller can change every device it manages, so its own security carries real weight. Cisco’s September 2026 security guide recommends deploying Catalyst Center on a private internal network behind a firewall rather than exposing it to an untrusted network such as the internet. It also recommends separating the management and enterprise-network interfaces, and isolating cluster interfaces when running a three-node cluster.
In practice that means:
- No public exposure of the controller or its API.
- Named accounts with role-based access, not shared administrator logins.
- API service accounts limited to the functions their scripts need.
- Firewall rules written deliberately for every flow the controller needs, and reviewed after upgrades.
For wider controls, see our network security best practices and the network access controller guide.
Our perspective
We have supported Cisco networks for over 35 years, and the pattern is consistent: automation projects succeed or fail on preparation, not on the tool. Catalyst Center is capable, but it automates whatever standard you give it. If your estate has ten different switch builds and no agreed naming, the platform will faithfully reproduce the confusion.
Our advice is to automate in this order. First, agree the standard: hierarchy, addressing, device roles. Second, audit what you have, because discovery will surface devices and settings nobody remembered. Third, automate one site end to end and learn from it. Only then scale to the rest of the estate and add API-driven work.
We also take the view that automation should never reduce visibility. Every automated change should be traceable to a person, a ticket and a template version. For multi-site organisations such as schools, plants, hotels and housing portfolios, that traceability is what turns automation from a convenience into something an auditor can accept.
— Jacob
A practical rollout sequence
- Audit the current estate. Inventory devices, software versions and configuration drift. Our network audit checklist sets out the evidence to collect.
- Decide the platform form and resilience. Choose appliance or virtual deployment and plan for failure.
- Secure the controller. Private network, firewall rules, separated interfaces, role-based accounts.
- Build the design layer. Site hierarchy, floor maps, credentials, network settings and IP pools.
- Integrate identity. ISE and AAA before wireless and access policy.
- Pilot one site. Use LAN Automation or Plug and Play onboarding and record every exception.
- Standardise with templates and profiles. Turn pilot findings into the standard build.
- Scale and script. Roll out site by site, then move recurring tasks to the API or Ansible.
- Review regularly. Check software images, drift and access rights on a fixed schedule.
If you are also weighing WAN changes, our guide to Cisco SD-WAN design decisions covers what to settle before rollout.
Getting help with Catalyst Center automation
Many IT teams have the skills to run a controller but not the spare weeks to design, audit and migrate an estate at the same time. Re-Solution is a Cisco partner with certified consultants, and we work with organisations in education, manufacturing, logistics, hospitality, shared workspaces and property development.
We can start with a network audit to establish what you have, add a wireless survey where coverage is the risk, and then run the network for you through managed services or a subscription Network as a Service model. For project work on design and migration, see our professional services. Pricing is scoped to your estate, so contact us for a discussion.
FAQ
Is Catalyst Center the same as Cisco DNA Center?
Yes. Cisco describes Catalyst Center as the product formerly known as DNA Center. Both names can still appear in documentation and partner material during the transition, so check the software release rather than the name when following a guide.
Do I need to write code to automate with Catalyst Center?
No. Workflows and templates handle many multistep tasks through the GUI. Code becomes worthwhile for recurring or large-scale work, where Python scripts or Ansible playbooks can call the API. Start with the GUI and script only what you repeat often.
What should I set up first?
Start with the design layer: site hierarchy, credentials, network settings and IP pools, together with ISE and AAA integration. Later provisioning inherits these settings, so errors made here are repeated across every device you onboard.
Is it safe to expose Catalyst Center to the internet?
Cisco’s security guidance recommends against it. Place the controller on a private internal network behind a firewall, separate its management and enterprise interfaces, and use named, role-based accounts for people and API clients.
How long does an API token last?
According to Cisco’s 3.3.x Platform User Guide, an authentication token is valid for 60 seconds. Scripts should request a new token as needed rather than storing one for reuse.
Sources
- Cisco Catalyst Center product and deployment documentation
- LAN automation, Cisco Catalyst Center SD-Access LAN Automation guide
- Cisco Catalyst Center SD-Access LAN Automation Deployment Guide
- Cisco Validated Ansible Playbooks for Catalyst Center
- Wireless Automation with Cisco Catalyst Center (CVD)
- Cisco Catalyst Center User Guide, Release 3.2.x: Workflows
- API prerequisites, Catalyst Center Platform User Guide 3.3.x
- Cisco Catalyst Center API Quickstart
- Cisco Catalyst Center Security Best Practices Guide
- Business Wi-Fi installation: what it involves
Recommended
- Cisco Networks Catalyst Overview & Benefits
- Network automation fundamentals: a 2026 guide for IT pros
- Cisco Catalyst vs Cisco Nexus: Key Differences Explained
