Automation and controllers
How automation changes network management and how controller-based networking differs from device-by-device management.
Automation's impact
Automation replaces per-device, manual, CLI-by-CLI work with programmatic changes: configuration rendered from templates, state verified continuously, rollouts repeatable. The impact on network management is consistency (no snowflake devices), speed, and the ability to treat infrastructure as code — versioned, reviewed, testable.
What automation actually changes
| Area | Before | After |
|---|---|---|
| Config drift | Slow accumulation, invisible | Detected vs the declared model |
| Rollout | Manual, error-prone per device | Template-driven, consistent |
| Rollback | Rebuild from memory/backups | Restore a versioned state |
| Compliance | Periodic audits | Continuous verification |
- Task
- Change the NTP server on 200 switches
- Traditional: script or manual SSH to 200 devices — hours, inconsistent error handling, unknown partial failures.
- Controller: edit the site/profile template → controller renders and pushes per-device config → telemetry confirms each device.
- Result: one declaration, auditable per-device outcome.
The work moved from 'edit 200 configs' to 'change one model and verify it applied'.
Controller-based management
A controller (e.g., Cisco DNA Center) holds the desired state: device inventory, site profiles, policies. It programs devices through southbound interfaces and watches telemetry to confirm intent is actually realized — assurance is the closed loop: intent → deploy → verify → correct.
Traditional versus controller-based networking
| Property | Traditional | Controller-based |
|---|---|---|
| Configuration | Per device, distributed | Central intent pushed to devices |
| Policy | Emergent from individual configs | Declared once, enforced everywhere |
| Source of truth | The running-configs themselves | The controller's model/database |
| Change process | Box-by-box maintenance windows | Orchestrated, validated rollouts |
| Troubleshooting view | Device at a time | Fabric-wide telemetry and assurance |
Verification and mistakes
Verifying automation
- Verify automation by checking device state against intent — the controller reports compliance per device.
- Drift detection is the operational check: unplanned diffs between the model and a running-config are the signal.
- Keep manual access (SSH/console) as the fallback path — automation failure must not lock operators out.
Common mistakes
- Treating automation as 'no humans needed' — it shifts effort to design and verification.
- Believing the controller replaces device CLIs — it drives them programmatically; the CLI still exists for verification.
- Pushing intent without validation — automation scales mistakes exactly as well as correctness.
- Assuming traditional management is obsolete — small estates can rationally stay device-by-device.
Observation: Controller reports 197/200 devices compliant after a config rollout.
- Three devices unreachable or auth-failed during the push
- Model rendered differently for those device types
- Local changes on the devices overriding intent
| Check | Indicates |
|---|---|
| Controller's per-device failure report | Names the exact failure stage per device. |
| Direct SSH verification on a failed device | Model vs running-config diff shows what landed. |
Correction: Fix reachability/credential issues or correct the template for those platforms, then re-run.
All devices report compliant against the intent.
Related resources
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.