Software-defined networking (SDN)

Traditional networks are distributed. Every router and switch runs its own control plane — building routing tables, running spanning tree, learning MAC addresses — and then its data plane forwards frames and packets based on those local decisions. Configuration happens box by box through the command line, which is slow to change and easy to make inconsistent.

SDN moves the control plane off the individual devices and into a centralized controller with a network-wide view. The devices retain their data planes and keep forwarding traffic at hardware speed, but they receive their forwarding instructions and policy from the controller. Two API directions make this work. Southbound APIs run between the controller and the network devices, using protocols such as OpenFlow, NETCONF, and RESTCONF. Northbound APIs run between the controller and applications or automation scripts, typically as REST APIs exchanging JSON or XML — this is the interface an engineer or orchestration tool actually programs against.

The practical payoff is consistency and speed. A policy change is defined once at the controller and pushed to every relevant device, which reduces configuration drift and human error and makes automated provisioning possible. Controller platforms also provide network-wide telemetry and assurance. The trade-offs are a potential single point of failure, dependence on controller reachability, and a shift in required skills toward APIs and scripting.

The CCNA exam includes SDN in its network automation and programmability domain. Expect questions comparing traditional device-by-device management with controller-based management, identifying which plane a given function belongs to, distinguishing northbound from southbound interfaces, and recognizing REST API methods and JSON-encoded data.