For most of networking history, every router and switch was an island: it made its own forwarding decisions and you configured each one by hand. Controller-based networking breaks that model by pulling the decision-making into a central controller, and it is the conceptual heart of CCNA domain 6. This article defines the control plane and data plane split, explains northbound and southbound APIs, untangles the overlay/underlay/fabric vocabulary, and maps it all to the Cisco products you will meet. It is part of the Network Automation guide, and it deliberately keeps the routing and switching you already know at the center, because controllers do not replace that knowledge, they orchestrate it.
Control Plane vs Data Plane
Every network device does two distinct jobs. The control plane decides where traffic should go: it runs the routing protocols, builds the routing and MAC tables, and figures out the topology. The data plane (also called the forwarding plane) does the actual moving: it takes a frame or packet and pushes it out the right interface, as fast as the hardware allows, based on the tables the control plane built.
In a traditional network, both planes live inside every device. Each router runs its own OSPF or BGP process, reaches its own conclusions, and forwards accordingly. It works, but the intelligence is scattered across hundreds of boxes, and a policy change means touching all of them.
What a Controller Centralizes
Software-Defined Networking (SDN) separates the control plane from the data plane and lifts the control-plane intelligence into a central controller. The devices keep their fast data planes, but they take forwarding instructions from the controller instead of each computing everything independently. The controller holds a complete, current view of the topology, and you express intent to it once ("these users may reach these resources") rather than configuring each device.
That central view is the whole point. Because the controller sees everything, it can compute paths globally, push consistent policy, and give you a single place to automate against. The tradeoff is a new dependency: the controller becomes critical infrastructure, which is why real deployments run controllers in clusters.
Northbound and Southbound APIs
A controller sits in the middle of two conversations, and the CCNA names both directions.
Faces up, toward applications and automation. This is where you (or an app, or a script) tell the controller what you want. Almost always a REST API returning JSON.
Faces down, toward the devices. This is how the controller programs switches and routers. Examples: NETCONF, RESTCONF, gRPC, and historically OpenFlow.
The mental model: your automation talks northbound to the controller in the language of intent; the controller translates that into device-specific instructions and pushes them southbound. You program the network once, through the top, instead of SSHing into every box. The northbound side is why REST APIs and JSON are on the exam at all: they are the interface between your tools and the controller.
Overlay, Underlay, and Fabric
These three terms get used loosely, so pin them down. The underlay is the physical network and its IP routing: the actual cables, switches, and the IGP (usually OSPF or IS-IS) that gives every device reachability to every other. Its only job is to move packets between the fabric nodes.
The overlay is a virtual network built on top of the underlay using tunnels. Traffic is encapsulated (wrapped in an extra header) at the ingress device, carried across the underlay as ordinary IP, and decapsulated at the egress. The overlay is where segmentation and policy live; the underlay just carries the encapsulated packets and never needs to know about them.
The fabric is the combination: the underlay plus the overlay plus the control plane that ties them together, managed as a single system. A concrete example makes it click:
VXLAN over an IP underlay is the canonical overlay example, and it is exactly the pattern behind Cisco's fabric products. If the encapsulation idea is new, the VLAN vs VXLAN article walks through why an overlay solves problems a plain VLAN cannot.
Mapping to Cisco Solutions
Cisco packages controller-based networking into products aimed at different parts of the network, and the exam expects you to know which is which.
The campus fabric. Catalyst Center is the controller; SD-Access is the fabric (VXLAN overlay, LISP control plane, TrustSec policy). See What Is Cisco Catalyst Center.
The WAN fabric (formerly Viptela). A controller-based overlay across internet and MPLS transports. See the SD-WAN guide.
Cloud-managed networking. The controller lives in Cisco's cloud; devices phone home for policy and reporting.
Traditional vs Controller-Based, Side by Side
Traditional: box by box, over the CLI. Controller-based: once, expressed as intent to the controller.
Traditional: each device sees its neighbors. Controller-based: the controller sees the whole network.
Traditional: only as consistent as the human. Controller-based: enforced uniformly from one source of truth.
Traditional: a device failure is local. Controller-based: the controller is critical, so it runs clustered.
What Stays the Same
Here is the reassuring part, and the part the exam quietly rewards. A controller does not invent new physics. Underneath SD-Access is still IP routing, still switching, still the same forwarding you learned in domains 2 and 3. The overlay rides on an underlay that runs an ordinary IGP. When a fabric misbehaves, you troubleshoot it with the same tools (ping, traceroute, reading the routing table) plus the controller's view. Controller-based networking changes how you configure and where the intelligence lives; it does not let you skip the fundamentals. If anything, it raises the bar, because now you need to understand both the abstraction and the plumbing under it.
FAQ
What is SDN in one sentence?
Software-Defined Networking separates the control plane from the data plane and centralizes the control-plane intelligence in a controller that programs the devices through APIs.
How do I remember northbound vs southbound?
Picture the controller in the middle. Applications and your automation are "above" it (northbound); the network devices are "below" it (southbound). You talk down to the controller from your tools (north), the controller talks down to the devices (south).
What is the difference between an overlay and an underlay?
The underlay is the real physical network and its IP routing. The overlay is a virtual network of tunnels built on top of it, where segmentation and policy live. The underlay just carries the encapsulated overlay traffic.
Do I still need to learn routing and switching?
Absolutely. Controllers orchestrate routing and switching; they do not replace it. The underlay is an ordinary IP network, and troubleshooting a fabric requires understanding both the overlay abstraction and the plumbing beneath it.
Key Takeaways
Controller-based networking separates control from data plane and centralizes the intelligence. You program the controller through a northbound REST API; the controller programs devices southbound with NETCONF, RESTCONF, or similar. Overlay (virtual tunnels) rides on underlay (physical IP network), and the fabric is the managed whole, with VXLAN over IP as the classic example. Cisco maps this to Catalyst Center/SD-Access for campus and Catalyst SD-WAN for the WAN. Through all of it, the routing and switching fundamentals still run underneath. Next, see how you actually talk to a controller in REST APIs and JSON for Network Engineers, and return to the Network Automation guide for the full domain-6 path.
