Advanced
Network Controllers
Controller-centric automation — centralized inventory, asynchronous tasks, and observed-state validation, illustrated through a vendor-neutral mock controller and a real Cisco Catalyst Center example.
Every module before this one connects to devices individually. This module introduces a different architecture: a controller that centrally represents an entire network, so your code talks to one system instead of managing many separate connections. You'll learn why controllers exist, the northbound/southbound split between what your code calls and how the controller actually reaches devices, and why a controller accepting a request isn't the same as a change being complete -- verified through real asynchronous task-and-polling workflows and a genuine mismatch between reported and observed state. Cisco Catalyst Center appears as a real, concrete anchor for these concepts, shown through its documented API rather than a live connection.
Next up
Why Network Controllers Exist
0 / 7 completeLessons
- 1
Why Network Controllers Exist
The shift from device-centric automation (Netmiko, Ansible, direct REST) to controller-centric automation — one system that centrally represents many devices, rather than many independent connections.
Advanced11 min readNext up - 2
Controller Architecture: Northbound, Southbound, and Centralized State
Northbound (what your code calls) vs. southbound (how the controller talks to devices, invisible to you) — and why a controller is not simply 'Ansible with centralized state.'
Advanced12 min read - 3
Inventory and Resources: Querying a Controller's View of the Network
Real, verified GET requests against this module's mock controller's sites and devices — the controller IS the inventory, queried rather than locally maintained.
Advanced11 min read - 4
Asynchronous Controller Workflows: Tasks and Polling
202 Accepted, a task ID, and a poll loop — the module's centerpiece: a controller accepting a request is not the same claim as the change being complete, verified directly against real success and real failure paths.
Advanced15 min read - 5
Policies, Templates, and Controller-Driven Change
Submitting a desired-state change through a controller's task workflow — reusing Lesson 4's submit-then-poll pattern directly, with the same read-first, lab-only-mutation discipline as every prior module.
Advanced12 min read - 6
Desired State vs. Observed State: Controller-Driven Validation
A task reporting 'completed' is a claim, not proof — verified directly against a real mismatch, where a controller's own task status and its separately-queried observed state disagree.
Advanced12 min read - 7
Capstone: Automating a Network Through a Controller
The complete pipeline: query the controller's own inventory, submit desired state per device, poll each task, validate observed state, and produce a structured report — the architectural shift from device-centric to controller-centric automation, proven end to end.
Advanced19 min read