Mental model
Traditional networks: every switch and router contains both the control plane (the brain making routing decisions, running OSPF, building forwarding tables) and the data plane (the hardware that moves packets in nanoseconds). Each device decides for itself.
This works but doesn’t scale into the “I want to change everything everywhere at once” world. Pushing a single policy change across 200 devices means logging into each.
Software-Defined Networking (SDN) moves the brains to a central controller. Devices keep their fast forwarding hardware but become “dumber” — they ask the controller (or are told by it) what to do. The controller has full visibility, applies policy from one place, and exposes APIs to applications and humans.
Apps & UI ← REST API (northbound)
↓
SDN Controller ← centralized brain
↓
Network Devices ← NETCONF / OpenFlow / gRPC / CLI (southbound)
That’s it conceptually. The rest is variations on this separation.
Northbound vs Southbound APIs
| What it is | Examples | |
|---|---|---|
| Northbound API | How applications + humans talk to the controller | REST/JSON (“create a new VLAN everywhere”) |
| Southbound API | How the controller talks to the devices | NETCONF, OpenFlow, gRPC, RESTCONF, sometimes CLI |
For CCNA: know the directions (north = up to apps, south = down to devices) and at least one example of each.
Three Cisco SDN platforms you should recognize
Cisco DNA Center (campus / enterprise)
For campus networks — managing wired + wireless across an enterprise. Replaces the “log into each switch” workflow.
- Northbound: REST API
- Southbound: NETCONF, RESTCONF, SSH/CLI for legacy
- Use cases: SD-Access (segmentation), policy automation, assurance/analytics
- Replaces: APIC-EM (its predecessor)
Cisco ACI / APIC (data center)
For data centers. Different from DNA Center — uses Nexus 9000 switches and a different architecture (intent-based policy + ACI fabric).
- APIC is the controller. Multiple APICs for HA.
- Application-centric policy — describe what apps need, ACI figures out the network config.
- Southbound: OpFlex protocol to leaf/spine switches.
Cisco Meraki (cloud-managed)
The controller lives in Meraki’s cloud — you manage everything through a web dashboard, with the controller hosted as SaaS.
- No on-premises controller to manage.
- Easy for small/distributed orgs.
- Subscription model — controller is a service you pay for.
- Limitations: less flexible than DNA Center / ACI for complex requirements.
For CCNA, recognize these names and the categories. Deep mastery isn’t expected at CCNA-level.
How SDN actually changes day-to-day work
Old way (per-device CLI):
ssh sw1
configure terminal
vlan 50
name USERS
exit
end
write memory
# repeat for sw2, sw3, sw4, ...
SDN way (push via controller):
POST /api/v1/networks/abc/vlans
{ "id": 50, "name": "USERS" }
One call, controller pushes to every relevant device, returns success/failure per device. Auditable, scriptable, idempotent (replay safe).
Intent vs imperative
Two styles of SDN configuration:
| Style | What you say | Example |
|---|---|---|
| Imperative | ”Configure interface Gi0/1 with these exact commands” | Traditional CLI / Ansible |
| Intent-based | ”Users in HR should be able to reach the file server” | DNA Center / ACI |
Intent-based is the long-term direction. You describe the desired outcome (“HR should reach file server, finance should not”). The controller figures out which ACLs, VLANs, and policies need to land on which devices to make that true. Continuously enforced.
OpenFlow — the original SDN southbound
You’ll hear about OpenFlow in textbooks. It was the protocol Stanford / ONF designed in the mid-2000s for pure SDN: the controller programs every flow-table entry on every switch.
Vendor reality: most enterprise SDN today uses NETCONF/gRPC instead. OpenFlow lingers in some research / academic contexts and a few specific products. Know the name and history; don’t expect to deploy it in production.
Common mistakes
-
Thinking SDN = automation. They overlap but aren’t the same. You can automate without SDN (Ansible + traditional devices). You can have SDN without it being fully automated. SDN is about where the control plane lives; automation is about how config gets applied.
-
Assuming SDN means OpenFlow. OpenFlow is one southbound protocol. Most enterprise SDN uses NETCONF, RESTCONF, gRPC, or hybrid CLI. “SDN” the concept is broader than “OpenFlow” the protocol.
-
Expecting SDN to replace traditional skills. A senior network engineer still needs to understand BGP, OSPF, switching. SDN abstracts the work but doesn’t eliminate the need to understand what’s underneath when it breaks.
-
Underestimating the controller as a single point of failure. A dead controller takes down policy management. Most platforms support HA controllers. Always check the controller’s failure mode in production planning.
-
Treating Meraki as identical to DNA Center. Both are Cisco SDN, but their philosophies differ. Meraki = simple, cloud-managed, less flexible. DNA Center = on-prem, more powerful, steeper learning curve. Match to the use case.
-
Skipping APIs because “I’m a network engineer, not a programmer.” Modern SDN demands API literacy. Curl + JSON + basic Python is the new RJ45 + console cable. Learn it — it’s not optional anymore.
Lab to try tonight
Use a Cisco DevNet Always-On DNA Center sandbox (no reservation required):
- Visit devnetsandbox.cisco.com, find the DNA Center Always-On sandbox. Note the URL and credentials.
- Open Postman or use curl. Authenticate to get a token:
curl -X POST https://sandboxdnac.cisco.com/dna/system/api/v1/auth/token \
-u devnetuser:Cisco123! \
-H "Content-Type: application/json"
- Use the token to list network devices:
curl -H "X-Auth-Token: <token>" \
https://sandboxdnac.cisco.com/dna/intent/api/v1/network-device
- Get a JSON response listing every device DNA Center manages — model, serial, IOS version, uptime.
- Explore the API docs at developer.cisco.com/dnacenter — list interfaces, VLANs, etc.
- Bonus: write a Python script that pulls all device hostnames + IPs and prints a CSV report.
Cheat strip
| Concept | Plain English |
|---|---|
| SDN | Software-Defined Networking — separate control from data plane |
| Controller | The brain — makes decisions, exposes APIs |
| Northbound API | App/UI → controller — usually REST |
| Southbound API | Controller → devices — NETCONF, OpenFlow, gRPC, CLI |
| DNA Center | Cisco’s campus / enterprise SDN platform |
| ACI / APIC | Cisco’s data center SDN platform (Nexus + APIC) |
| Meraki | Cisco’s cloud-managed SDN — no on-prem controller |
| Intent-based | Describe outcome, controller figures out config |
| OpenFlow | Original SDN southbound — academic now |
| Single point of failure | Controller HA matters in production |