Mental model
Cisco objective 5.2 says “Compare controller-level to device-level management”. Two architectures for the same job.
Device-level
Your script ─▶ Switch 1
─▶ Switch 2
─▶ Switch 3
─▶ ...
Script connects to each device, pushes config, reads state. Each device is independent.
Controller-level
Your script ─▶ Controller ─▶ Switch 1
─▶ Switch 2
─▶ Switch 3
Script calls ONE API (the controller). Controller does the work of fanning out to devices.
Device-level: pros and cons
| Pros | Cons |
|---|---|
| No controller license to buy | Your script owns device-type logic (IOS vs NX-OS vs …) |
| Works on day 1 against existing gear | Does not scale to thousands of devices nicely |
| Direct access = precise control | No cross-device assurance (did OSPF converge after my change?) |
| No single point of failure | Harder to roll back fleet-wide |
| Easy to debug (ssh and look) | Harder to audit (changes scattered) |
Typical device-level stack: SSH + Netmiko / NAPALM / ncclient / Ansible network modules.
Controller-level: pros and cons
| Pros | Cons |
|---|---|
| One API call manages hundreds of devices | Requires the controller (license, deploy, maintain) |
| Vendor abstracts device-type diversity | Controller feature set caps what you can do |
| Built-in assurance, telemetry, workflows | Single point of failure (HA mitigates) |
| Bulk ops are a one-liner | Changes outside the controller get overwritten |
| Role-based access, audit log, approvals | New API with its own learning curve |
Typical controller-level stacks: Cisco Catalyst Center, Meraki Dashboard, ACI APIC, Catalyst SD-WAN vManage, NSO.
When to pick which
| Scenario | Pick |
|---|---|
| Small lab, mixed-vendor, few devices | Device-level |
| Enterprise campus with Catalyst switches | Catalyst Center (controller) |
| Branches, cloud-managed | Meraki Dashboard (controller) |
| Data center fabric | ACI APIC (controller) |
| Cross-vendor service rollout (MPLS L3VPN across Cisco + Juniper) | NSO (controller) |
| One-off config fix on 3 devices | Device-level |
| Compliance / assurance across 1000 devices | Controller + reporting |
Hybrid in practice
Big networks run both:
- Controller for the standard, repeatable, bulk operations.
- Device-level scripts for break-glass or edge cases the controller does not cover.
Important: when a controller is in play, device-level changes get overwritten the next time the controller reconciles. Make device-level changes through the controller or disable the controller’s management of that device.
Table of Cisco controllers
| Controller | Target devices | API |
|---|---|---|
| Catalyst Center (ex-DNA Center) | Catalyst switches, routers, APs | REST + Token |
| Meraki Dashboard | Meraki MX / MS / MR / MG | REST + API key |
| ACI APIC | ACI fabric (Nexus 9000) | REST + Cookie (XML/JSON) |
| Catalyst SD-WAN vManage | SD-WAN edges (ex-Viptela) | REST + Session + CSRF |
| Nexus Dashboard | Nexus DC fabrics | REST + Token |
| NSO | Any vendor over NETCONF | REST + Basic (also NETCONF upstream) |
| Intersight | UCS compute, HyperFlex, some network | REST + OAuth2 |
See cisco-network-management-platforms for the deeper dive.
FAQ
Does controller-level mean I can forget CLI? No. CLI is the only way to debug a device that lost contact with the controller. Keep it in your toolkit.
Which is more “DevOps”? Both can be. IaC via Ansible is often device-level. IaC via Catalyst Center or Terraform-with-controller-provider is controller-level. Same principles.
What if my controller goes down? The devices keep forwarding traffic — the control plane (routing, STP) runs locally. You just cannot push new config until the controller is back.
gNMI tells me per-device state. Is that device-level or controller-level? Device-level. gNMI subscriptions are between a collector and each device directly. A controller might aggregate many gNMI streams, which then presents a controller-level view.