6.2 Controller-Based and Software-Defined Architectures
Key Takeaways
- SDN separates the control plane (decision-making) from the data plane (packet forwarding).
- The controller is the centralized brain that computes and programs forwarding rules into network devices.
- Northbound APIs connect applications to the controller; southbound APIs connect the controller down to devices.
- Cisco DNA Center, rebranded Cisco Catalyst Center, is Cisco's intent-based controller for enterprise campus networks.
- An overlay (e.g., VXLAN) runs on top of the physical underlay; together they form a fabric managed as one entity.
Control Plane vs. Data Plane
Every network device has two logical planes. The control plane makes decisions — it runs routing protocols (OSPF, EIGRP), builds the routing table, computes the Spanning Tree topology, and learns MAC addresses. The data plane (also called the forwarding plane) simply moves packets out the right interface based on what the control plane decided. A third management plane handles access (SSH, SNMP, syslog).
In a traditional network, every router and switch carries its own control plane and data plane. Each device decides independently and is configured box-by-box. This is the distributed control plane model.
Controller-Based Networking (SDN)
Software-Defined Networking (SDN) centralizes the control plane in an external controller. The controller computes the forwarding behavior for the whole network and programs it into the devices, which are then left to do nothing but forward packets.
The Three SDN Layers
| Layer | Also called | Role |
|---|---|---|
| Application layer | Apps / business apps | Security, analytics, and automation apps that consume network services |
| Control layer | Controller | The brain — computes policy and forwarding, the central point of management |
| Infrastructure layer | Data plane | Physical/virtual switches, routers, and APs that forward traffic |
Northbound and Southbound APIs
The APIs that glue the layers together are a guaranteed exam topic. Picture the controller in the middle: applications sit above it, devices sit below it.
| API | Connects | Typical protocols | Purpose |
|---|---|---|---|
| Northbound (NBI) | Apps ⇄ Controller | REST over HTTP/HTTPS | Apps request services and pull network data from the controller |
| Southbound (SBI) | Controller ⇄ Devices | NETCONF, RESTCONF, OpenFlow, SSH | Controller pushes config and forwarding rules to devices |
| East/Westbound | Controller ⇄ Controller | Vendor-proprietary | Sync state between multiple controllers |
Memory hook: Northbound = Network apps (looking up); Southbound = Switches and routers (looking down).
Underlay, Overlay, and Fabric
Modern campus and data-center SDN designs separate the physical wiring from the logical network.
| Concept | Definition | Example |
|---|---|---|
| Underlay | The physical IP network — cables, switches, routers and their routing | A routed campus running IS-IS or OSPF between switches |
| Overlay | A virtual network tunneled on top of the underlay | VXLAN tunnels carrying segmented traffic |
| Fabric | Underlay + overlay managed together as one system | Cisco SD-Access fabric |
How an Overlay Moves Traffic
- The underlay provides plain IP reachability between every switch (the tunnel endpoints).
- The overlay builds virtual tunnels — VXLAN encapsulates the original Layer 2 frame inside a UDP/IP packet (VXLAN uses UDP port 4789).
- The packet rides across the underlay and is decapsulated at the egress switch.
- The payoff: a VLAN or subnet can span the entire fabric regardless of where devices physically plug in, and micro-segmentation policy follows the user, not the port.
Cisco DNA Center / Catalyst Center
Cisco DNA Center is Cisco's enterprise SDN controller for campus networks. As of 2023-2024 Cisco rebranded it as Cisco Catalyst Center — it is the same product with a new name, and older API versions still carry the DNA Center label. Expect either name on the exam.
It delivers intent-based networking (IBN): you declare what you want ("engineering can reach the lab, guests cannot reach corporate") and the controller translates that intent into the device-by-device configuration.
| Feature | What it does |
|---|---|
| Intent-based networking | Business intent → automated device configs |
| Automated provisioning | Push configs to hundreds of devices at once |
| SD-Access | Software-defined campus fabric with micro-segmentation |
| Assurance | AI/ML monitoring, analytics, and root-cause analysis |
| Network Plug-and-Play | Zero-touch provisioning for new devices |
Common Trap
Do not confuse the directions: a question about configuring the switches points to a southbound protocol (NETCONF/RESTCONF), while a question about an analytics app pulling data from the controller points to a northbound REST API. Also remember SDN does not eliminate physical devices — it just centralizes their control plane.
On the Exam: Know the three layers (application, control, infrastructure), the API directions (northbound = apps-to-controller REST; southbound = controller-to-devices NETCONF/RESTCONF/OpenFlow), and that Catalyst Center (formerly DNA Center) is Cisco's intent-based campus controller.
Degrees of Centralization
Not every controller-based design centralizes the control plane to the same degree, and the exam expects you to appreciate the spectrum. In a fully centralized SDN model, the controller computes every forwarding decision and the devices are essentially dumb forwarders; this is the classic textbook OpenFlow picture. In practice, most enterprise Cisco deployments use a hybrid model: the controller handles policy, provisioning, and assurance, while the devices still run their own routing and switching protocols locally for fast convergence.
Catalyst Center sits in this hybrid space — it automates and monitors, but a switch in an SD-Access fabric still forwards traffic on its own data plane even if the controller is temporarily unreachable.
This matters for a common exam scenario: if the link to the controller goes down, does the network stop forwarding? In a hybrid Cisco design the answer is no, existing flows keep working because the data plane is local; you simply lose the ability to make new centralized policy changes until the controller returns. Contrast that with a purely centralized control plane, where losing the controller could prevent new flows from being programmed at all.
Why Intent-Based Networking Is a Step Beyond Automation
Plain automation pushes the configuration you wrote. Intent-based networking goes one level higher: you describe the business outcome and the controller decides the configuration. You say "contractors get internet but never touch the finance servers," and Catalyst Center generates the VLANs, the Scalable Group Tags, and the access policies on every fabric switch to make that true — then continuously verifies reality still matches the intent and re-mediates if it drifts.
That closed loop of translate, activate, and assure is what distinguishes an intent-based controller from a simple script runner, and it is the conceptual point Cisco wants you to walk away with for this section.
In an SDN architecture, what connects the controller to the network devices?
What is the fundamental difference between a traditional network and an SDN controller-based network?
What is the overlay in a software-defined fabric?