Describe Controller-Based and Software-Defined Architectures

Domain 6.3 | Automation and Programmability — 10% of exam

Learning Objectives

By the end of this lesson, you will be able to:

• Define overlay, underlay, and fabric, and explain how they relate to each other.
• Explain the separation of control plane and data plane as SDN’s foundational architectural principle.
• Correctly distinguish northbound APIs from southbound APIs, including their typical protocols and direction of communication.
• Contrast a traditional device’s distributed control plane with SDN’s centralized model, using a concrete example from earlier in this course.

Key Terms Glossary

Overlay, Underlay, and Fabric

These three terms describe the layered structure of a modern software-defined network architecture, and understanding how they relate to each other is the foundation this entire lesson builds on.

The underlay is the actual physical network — the routers, switches, and physical links that exist in the real world, carrying real electrical or optical signals between real pieces of hardware. The underlay’s job is deliberately narrow: providing reliable IP connectivity between overlay endpoints. Critically, the underlay doesn’t need to understand the overlay’s logical structure at all — it just needs to route ordinary IP packets from one point to another, exactly as any router covered throughout the earlier domains of this course already does.

The overlay is the logical network built on top of that physical infrastructure. A common concrete example is VXLAN (Virtual Extensible LAN), which creates virtual Layer 2 or Layer 3 connectivity between endpoints regardless of the underlying physical path between them, by encapsulating the original traffic inside a VXLAN header and an outer IP packet that the underlay can route normally.

This is conceptually the exact same encapsulation principle covered in objective 5.5’s VPN tunnel discussion — a packet wrapped inside another packet so it can traverse infrastructure that doesn’t need to understand its original, inner contents at all. The overlay is what applications and users effectively “see” — from their perspective, two endpoints appear directly, logically connected, even though the actual physical path between them might cross many underlay hops entirely invisible to that logical view.

Walking Through What VXLAN Encapsulation Actually Does

It’s worth grounding “encapsulation” in a bit more concrete detail here, since the same word carries real technical weight rather than being purely abstract. A device originating traffic on the overlay — say, a virtual machine communicating with another virtual machine that happens to sit on a physically distant rack — sends its original Ethernet frame exactly as it always would.

A VXLAN-capable device at the edge of the fabric (commonly called a VXLAN Tunnel Endpoint, or VTEP) intercepts that frame, wraps it inside a VXLAN header (which includes a VXLAN Network Identifier, functioning conceptually similarly to a VLAN ID but supporting a vastly larger number of possible values), and then wraps that entire package inside a standard UDP/IP packet addressed to the destination VTEP’s real, physical underlay IP address.

The underlay routers along the path see only this outer UDP/IP packet — an entirely ordinary packet from their perspective, requiring no VXLAN-specific awareness at all — and route it exactly as they would any other IP traffic. Upon arrival, the destination VTEP strips away the outer encapsulation, recovers the original Ethernet frame, and delivers it to the destination as though it had traveled directly, with no encapsulation ever involved from the original endpoints’ point of view.

The fabric is simply the combined overlay/underlay system, managed as a single, cohesive architecture rather than two separately administered layers. Cisco’s SD-Access is the flagship example of this model in the CCNA context — a fabric architecture where the underlay provides basic connectivity, the overlay provides the logical, policy-driven network structure, and both are managed together through the controller-based approach covered in objective 6.2.

The Separation of Control Plane and Data Plane

This is the foundational architectural principle of SDN — arguably the single most important concept in this entire lesson, since nearly every other term here builds directly on top of it.

Every network device performs two conceptually distinct functions. The control plane makes forwarding decisions — calculating the best route, building a routing or forwarding table, deciding what should happen to a given packet. The data plane actually carries out those decisions — physically forwarding each individual packet according to whatever the control plane has already determined.

In a traditional network, every individual device runs both its own control plane and its own data plane, independently. Recall objective 3.4’s description of OSPF: every router independently builds its own link-state database and independently runs the SPF algorithm to calculate its own best paths — that calculation is a control plane function, and it’s fully distributed, happening separately on every single router in the network, each one doing its own math without a central authority telling it the answer.

In an SDN architecture, this changes fundamentally: the control plane is centralized in a controller, which computes the forwarding logic for the network and pushes it down to devices, while the data plane remains distributed across the individual devices, which still physically forward packets themselves. The devices no longer independently calculate their own routing decisions the way an OSPF router does — they receive those decisions from the controller and simply execute them. This separation is the defining characteristic that distinguishes SDN from traditional networking, more than any single specific protocol or vendor platform.

It’s worth sitting with the OSPF contrast specifically, since it makes this abstract distinction concrete using a protocol already covered in depth earlier in this course. Under traditional OSPF, if you wanted to see how a given router decided its best path, you’d look at that specific router’s own link-state database and SPF calculation — every router is independently authoritative for its own routing decisions. Under an SDN architecture managing the same network, that authority has moved: the controller now decides, and individual devices execute — a genuinely different distribution of decision-making authority across the network, even if the actual packets end up traveling similar physical paths in both models.

Northbound and Southbound APIs

A controller doesn’t exist in isolation — it needs to communicate in two directions, and the terminology for each direction is a frequently tested, frequently confused pair.

Northbound APIs are interfaces between the controller and the layer above it — business applications, orchestration systems, or automation scripts that need to request network changes or retrieve network state. A request like “provision a new VLAN for this new department” — expressed at the business-intent level covered in objective 6.2 — travels through a northbound API from whatever system or script is making that request down into the controller.

A concrete illustration makes this less abstract: an IT service portal where a manager clicks a button to “onboard a new contractor” might, behind the scenes, send an HTTP request to the controller’s northbound API, which in turn triggers the controller to translate that request into the actual VLAN assignment, ACL policy, and wireless authentication settings needed to fulfill it — precisely the translation process discussed in objective 6.2’s intent-based networking section. The service portal itself never needs to know anything about VLANs, ACLs, or specific device configuration syntax at all; it only needs to know how to speak the controller’s northbound API.

Southbound APIs are interfaces between the controller and the actual network devices below it, which the controller uses to push configuration and collect telemetry. Common examples include NETCONF and OpenFlow, covered in more detail below.

The Exam Tip Worth Internalizing

“Northbound” and “southbound” are genuinely easy to reverse under exam pressure, and the reliable way to keep them straight: north is “up,” toward applications and orchestration; south is “down,” toward the actual network devices — matching how network topology diagrams are conventionally drawn, with a controller in the middle, applications sitting above it, and devices sitting below it. If you can picture that standard diagram layout, the compass direction naming stops being arbitrary and becomes a direct visual mnemonic instead.

Southbound Protocols: NETCONF and OpenFlow

NETCONF is a southbound protocol using XML-encoded data over SSH to configure network devices, commonly paired with YANG data models that define the structure of the configuration data being exchanged. This connects to the JSON-focused discussion coming later in this domain (objective 6.7) — NETCONF specifically uses XML rather than JSON, an important detail to keep distinct, since REST APIs (the primary focus of objective 6.5) most commonly use JSON, while NETCONF’s own established convention is XML.

YANG deserves a brief note of its own, since it’s frequently mentioned alongside NETCONF: it’s a data modeling language that defines exactly what configuration and state data a device exposes and how that data is structured — think of it as a schema or blueprint describing the shape of the information NETCONF actually carries, rather than a protocol for transmitting that data itself. A device’s YANG model defines what’s possible to configure or query; NETCONF is the mechanism that actually carries requests and responses conforming to that model between a controller and the device.

OpenFlow is an earlier, foundational SDN southbound protocol that takes a more direct approach: it allows a controller to directly program a device’s flow tables — the actual, low-level forwarding rules a switch consults to decide what to do with a given packet. OpenFlow was historically significant as one of the first protocols to concretely demonstrate the control-plane/data-plane separation principle in a working, standardized implementation, which is why it’s worth recognizing by name even though it isn’t the only southbound protocol in modern use.

Recognizing These Terms in a Described Scenario

Since this objective packs several distinct terms into one lesson, it’s worth practicing recognition rather than only memorizing definitions in isolation. A scenario mentioning traffic being “encapsulated” to create connectivity “regardless of the physical path” is describing an overlay. A scenario describing basic IP reachability between two points, with no mention of any logical policy or virtual network structure, is describing the underlay specifically. A scenario describing both layers being “managed together” or referencing “SD-Access” by name is describing a fabric.

A scenario describing a router “independently calculating” its own path, with no outside authority providing the answer, is describing a traditional, distributed control plane — while a scenario describing a controller “pushing down” forwarding logic that devices simply execute is describing SDN’s centralized control plane instead. And any scenario describing a request originating from a script, application, or orchestration system reaching toward the network is northbound, while any scenario describing the controller reaching down to actually configure or query a device is southbound.

Common Misconceptions

• “The underlay needs to understand the overlay’s logical structure to function correctly.” It specifically doesn’t — the underlay’s entire job is providing basic IP reachability; the overlay’s encapsulation is what carries the logical structure, invisible to the underlay routing that carries it.
• “SDN means individual devices no longer do any forwarding work at all.” The data plane — actually forwarding packets — remains distributed across individual devices in an SDN architecture; only the control plane (the decision-making) centralizes into the controller.
• “Northbound means toward the network devices, since that’s the ‘real’ network.” North is toward applications and orchestration, sitting conceptually above the controller; south is toward the actual devices, sitting below it — this is a common and easy point of confusion worth double-checking deliberately.
• “NETCONF and REST APIs are interchangeable, using the same data format.” NETCONF conventionally uses XML over SSH; REST APIs (covered in objective 6.5) most commonly use JSON over HTTP — related concepts in the broader automation space, but distinct protocols with different typical encodings.
• “Fabric is just another word for overlay.” Fabric specifically refers to the combined overlay and underlay system managed together as one architecture — it isn’t a synonym for either layer individually, but the integrated whole.

Frequently Asked Questions

Does every controller-based network need to use VXLAN specifically for its overlay?

No — VXLAN is a common and widely referenced example of overlay technology, but other overlay encapsulation methods exist; the key conceptual point is the overlay/underlay separation itself, not that VXLAN is the only possible implementation.

Can a traditional, non-SDN network still have something resembling an overlay, like a VPN tunnel?

Yes, in a limited sense — a VPN tunnel (covered in objective 5.5) is itself a form of overlay, logical connectivity built on top of physical infrastructure via encapsulation, even outside a full SDN/fabric architecture. The distinguishing feature of a true SDN fabric is combining that overlay concept with centralized, controller-based management of both layers together, not simply the presence of any encapsulated tunnel at all.

Why does OpenFlow matter if it’s described as an “earlier” protocol?

It’s historically significant as one of the first concrete, standardized demonstrations of centralizing the control plane while leaving the data plane distributed — understanding it helps ground the abstract control-plane/data-plane separation concept in a specific, real technical mechanism, even as newer protocols and platforms have since emerged alongside or beyond it.

Does centralizing the control plane in a controller mean routing protocols like OSPF become irrelevant?

Not necessarily in every deployment — some SDN and fabric architectures still use underlay routing protocols like OSPF to maintain basic underlay connectivity between fabric nodes, while the overlay’s logical policy is what’s actually centralized and controller-managed; the two concepts can coexist in the same overall architecture, operating at different layers.

How do northbound and southbound APIs relate to the REST API concepts covered later in this domain?

Northbound APIs are very commonly implemented as REST APIs specifically, since REST’s characteristics (covered in objective 6.5) — stateless, HTTP-based, easy to consume from scripts and applications — fit naturally with how orchestration systems and automation scripts need to interact with a controller from above.

Can a controller communicate with another controller, and if so, what direction would that be?

Controller-to-controller communication does occur in some larger, multi-domain architectures, and it doesn’t cleanly fit the northbound/southbound framing at all — those two terms specifically describe a controller’s relationship to the layers above and below it in a single management hierarchy, not lateral relationships between peer controllers managing different parts of a larger environment. Recognizing that this scenario exists, without needing deep configuration knowledge of it at the CCNA level, helps avoid forcing every possible API relationship into the northbound/southbound vocabulary when it genuinely doesn’t apply.