PlantUML DiagramController-Based Networking
A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
For decades, network devices decided everything independently. Each router ran its own routing protocol, computed its own best paths, and made its own forwarding decisions. It worked because the protocols were designed to converge to consistent answers. Controller-based networking replaces this emergent behavior with something more direct: a central system that decides, and devices that follow.
The controller sits between applications and devices. Applications talk to the controller via northbound APIs (usually REST). The controller talks to devices via southbound APIs (NETCONF, SNMP, SSH, OpenFlow, or vendor-specific interfaces). The controller becomes the single source of truth for configuration, policy, and topology.
The controller abstraction is what makes automation portable. Your Python script that talks to DNA Center doesn't care what hardware the network uses. If you migrate from Catalyst 9K to a different platform (unlikely but possible), the script stays the same — the controller handles the platform differences. This is a big win for organizations with heterogeneous networks.
| Platform | Domain | What it manages |
|---|---|---|
| Cisco Catalyst Center (formerly DNA Center) | Campus | Switches, wireless, SD-Access fabric |
| Cisco SD-WAN vManage | WAN | vEdge/cEdge routers, SD-WAN fabric |
| Cisco APIC | Data center | Nexus switches, ACI fabric |
| VMware NSX | Data center | Virtual networking, microsegmentation |
| Juniper Apstra | Data center | Multi-vendor intent-based networking |
| Arista CloudVision | Data center | EOS-based switches |
A company is modernizing its data center with 100 Nexus switches. They want centralized policy, automation, and microsegmentation. Which controller fits?
Select the safest next action.
Finish the lesson once you have worked through the material. This awards ★ 35 XP.