SDN architecture
Controller-based software-defined architecture: underlay, overlay and fabric, control/data-plane separation, and northbound/southbound APIs.
Control and data planes
SDN separates the control plane (decisions: routing, policy) from the data plane (forwarding). In controller-based architecture the control plane centralizes in the controller while devices keep the data plane — the box still forwards packets, but its behavior is programmed from above.
Underlay, overlay, fabric
Underlay, overlay, fabric
| Term | Definition |
|---|---|
| Underlay | The transport network delivering IP connectivity between fabric devices — often but not necessarily only physical infrastructure |
| Overlay | Virtual networks built on top (tunnels, e.g., VXLAN) — where tenants/services live |
| Fabric | Underlay + overlay + the control plane that operates them as one system |
- Action
- Operator declares 'guest VLAN 30 on all access switches'
- Declared via the controller (northbound intent).
- Controller maps intent to per-device configuration deltas.
- Southbound interface pushes config to each switch; the underlay carries the controller↔device traffic.
- Guest traffic now rides an explicit tunnel overlay (e.g., VXLAN segments built by the fabric) — merely creating VLAN 30 on the switches would not itself establish an overlay.
Intent lives in the controller; the fabric executes it — control is logically centralized, though real control functions (underlay protocols, SD-Access LISP nodes) can still be distributed.
Northbound and southbound APIs
Northbound versus southbound
| Interface | Direction | Examples/purpose |
|---|---|---|
| Northbound API (NBI) | Apps/tools → controller | REST APIs for automation, dashboards, integrations |
| Southbound API | Controller → devices | NETCONF/RESTCONF, OpenFlow, CLI/SNMP in practice — how intent is programmed |
Example: a network-as-a-service app calls the controller's northbound REST API to create a new segment. The controller decides which devices must change and programs them via southbound protocols. The app never touches a device CLI; the device never knows the app exists.
Verification and mistakes
Verification cues
- Southbound health = device reachability and sync state in the controller's inventory.
- Northbound health = the API's own status — a REST endpoint that answers, not a device-level test.
- Data-plane verification is unchanged: the forwarding behavior still shows in
showoutput on the devices.
Common mistakes
- Believing the data plane centralizes — forwarding stays on the devices; only control centralizes.
- Swapping northbound/southbound — north faces applications, south faces devices.
- Equating 'SDN' with OpenFlow — OpenFlow is one southbound protocol among several.
- Treating underlay/overlay as optional labels — they're the fabric's two halves.
Observation: Controller shows the new policy deployed; devices don't enforce it.
- Southbound programming failed silently on some devices
- Intent rendered to config that the device rejected
- Devices running an older image missing the feature
| Check | Indicates |
|---|---|
| Device sync/compliance state in the controller | Which devices actually took the programming. |
The device CLI (show run) | What config, if any, arrived. |
| Controller's per-device deploy logs | Rejection reason per device. |
Correction: Fix the programming gap (platform support, connectivity, rendering) and redeploy.
Device state matches intent and forwarding follows the policy.
Related resources
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.