Network planes and software-defined networking (SDN)
In short: Every network device has a data plane that forwards traffic, a control plane that decides where it goes, and a management plane for configuration. SDN moves much of the control into a central controller, which programs devices through APIs, so the whole network can be managed and automated as one system.
The three planes
| Plane | Job | Examples |
|---|---|---|
| Data (forwarding) | Moves packets and frames, very fast, in hardware | Switching, routing lookups, ACL filtering |
| Control | Decides where traffic should go and builds the tables | OSPF, BGP, spanning tree, ARP |
| Management | Lets people and tools configure and monitor | SSH, SNMP, syslog, APIs |
In a traditional network every device runs its own control plane and is configured one box at a time.
What SDN changes
Software-defined networking separates control from forwarding and centralises it in a controller. The controller sees the whole network, calculates the desired state, and pushes it to devices. Engineers stop typing the same commands on 200 switches and instead describe what they want once.
Northbound and southbound APIs
- Northbound APIs (usually REST with JSON) let applications, scripts and orchestration tools ask the controller for information or changes.
- Southbound APIs let the controller program devices, using protocols such as NETCONF, RESTCONF, gNMI or OpenFlow.
Underlay, overlay and intent
- The underlay is the physical network and its routing, kept simple and stable.
- The overlay is a set of virtual networks built on top, often with tunnels (VXLAN, IPsec). SD-WAN and modern campus fabrics are overlays.
- Intent-based networking goes a step further: you state the business intent (for example, "guests may only reach the internet") and the system translates it into configuration, then keeps checking that reality still matches.
Benefits and cautions
- Benefits: consistent configuration, faster changes, network-wide visibility, easier automation, policy that follows users.
- Cautions: the controller is critical, so make it highly available and secure; staff need new skills; check how devices behave if the controller is unreachable.
Real-world example: a controller-managed branch refresh
A fictional building society replaced the routers and switches in 35 branches. In the old design, each branch's routing and firewall policy was typed into its own devices, and policies had drifted apart. In the new design, a central controller held the policy: which applications could use which link, and which user groups could reach which systems. The engineers wrote the policy once in the controller; the controller then programmed each branch device through its southbound interface, while the devices kept forwarding traffic locally on their own data planes. When the security team later asked for a new rule blocking an outdated file-sharing protocol, it was added once and reached all 35 branches within minutes. The team still kept out-of-band access to each device, so a controller outage would not stop them reaching the branches.
Practice
Which plane does OSPF belong to?
Which API direction would a Python script use to ask a controller for a device list?
Give one risk of a centralised controller.
Key takeaways
- Data plane forwards, control plane decides, management plane configures.
- SDN centralises control in a controller with a network-wide view.
- Northbound APIs face applications; southbound APIs face devices.
- Overlays run on top of a simple underlay; intent-based networking checks outcomes.
- Protect the controller: it is critical infrastructure.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.