Software defined networking takes the decision making out of each switch and router and puts it in a central controller, leaving the devices to forward traffic. The Open Networking Foundation defines SDN as the physical separation of the network control plane from the forwarding plane, with one control plane controlling several devices.
Almost no small office deploys that directly. What it meets instead is the same idea sold as cloud managed networking, SD-WAN or a data center fabric.
- SDN moves the control plane off the devices and into a controller
- The devices keep forwarding, they just stop deciding
- OpenFlow was the first standard interface for that split, not the only one
- Most businesses buy the outcome, as a cloud portal or an SD-WAN service
- Ask where the control plane lives and what happens when it is unreachable
On this page
The ideaWhat software defined networking actually means
Every traditional switch and router runs two things at once. A control plane works out where traffic should go, running routing protocols and building tables. A forwarding plane moves the packets according to those tables. The page on control plane and data plane covers that split in detail.
Software defined networking separates them physically. The Open Networking Foundation, which started the movement, defines SDN as the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices. The switches keep forwarding. The thinking moves to a controller.
The ONF's own description of the architecture is worth reading carefully, because it names the payoff. Network intelligence is logically centralized in software based controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.
That last phrase is the whole point. Configure one system instead of forty boxes, and let it work out the individual device configurations. The ONF lists the attributes it expects from the architecture: directly programmable, agile, centrally managed, programmatically configured, and open standards based when implemented on open standards.
The version of an SDN network that never quite arrived was the fully open one. Vendors built controllers around their own network infrastructure instead, and the industry ended up with several partly closed implementations of the same idea rather than one open, centralized fabric.
ArchitectureThe controller, and the two interfaces around it
An SDN architecture is usually drawn as three layers with the SDN controller in the middle.
The infrastructure layer. The network devices, switches and routers, that forward traffic and hold the tables the controller writes. The infrastructure still has local hardware, it just takes its instructions from elsewhere.
The control layer. The controller itself, holding the network topology, the policy and the global view. In an open deployment this is a platform such as ONOS or OpenDaylight. In a commercial one it is the vendor's own controller or cloud management service.
The application layer. The applications that ask the network for something: a security policy engine, an orchestration system, a network management tool, an in house script.
Two interfaces connect the layers. The southbound interface runs from controller down to the network devices, and OpenFlow is the one everybody names.
The ONF calls OpenFlow a foundational element for building SDN solutions, and its timeline dates the first standard interface for separating the control and data planes to 2012. NETCONF, gNMI and vendor APIs do the same job in most shipping products.
The northbound interface runs from the controller up to applications, usually as a REST API. This is where SDN and network automation overlap and get confused.
Automation scripts a network whose control plane is still distributed across the devices. SDN changes where the control plane lives. A network can have either without the other.
In practiceWhere a small or midsize business actually meets SDN
Almost nobody reading this will install a controller and speak OpenFlow to bare metal switches. That is a carrier, hyperscaler and large campus technology. The ideas arrived anyway, packaged.
Cloud managed networking. Access points, switches and firewalls that hold their policy in a vendor cloud and are managed from one portal. This is SDN thinking with centralized management rented rather than owned, and the page on cloud managed networking covers what happens when the license lapses.
SD-WAN. Branch routers that take their routing policy from a central controller and pick paths per application across broadband and private links. The Cisco SD-WAN page walks through a specific implementation and the controller components in it.
Data center fabrics. Leaf and spine networks programmed centrally, usually over virtual VXLAN overlays. This is where classic SDN got real adoption, because a data center network has enough identical devices for centralized control to pay off.
Public cloud networking. Every virtual network, security group and route table in a cloud account is software defined networking, run by the provider's own controllers. Most businesses use these virtual networks daily without calling them SDN.
The buying question is not whether to adopt SDN. It is whether centralized control is worth the dependency, at your size, for that part of the network.
Adjacent termsSDN is not NFV, and not network management
Three terms travel together in every SDN article and mean different things. Keeping them apart is what makes vendor documentation readable.
Network virtualization builds logical networks on top of one physical network. VLANs and VXLAN overlays are network virtualization, and they work with or without a controller.
Network functions virtualization, or NFV, moves functions that used to be appliances, such as firewalls, load balancers and WAN optimizers, onto standard servers as virtual machines or containers. NFV changes what the infrastructure runs. SDN changes what decides where traffic goes.
Network management is monitoring, alerting, configuration backup and reporting. A centralized management system is not an SDN controller, because management does not make forwarding decisions. This is the distinction vendors blur hardest, because one management portal looks like centralized control from outside.
The three combine well. A data center can run an NFV firewall, a virtual network overlay and an SDN controller programming the underlay, with one management system watching all of it. They remain separate purchases and separate failure domains.
Security runs across all three. Centralized control means network security policy is written once and applied everywhere, which is the benefit. It also makes the controller and its credentials the most valuable target on the network, which is the cost.
SDN vs SD-WANSDN vs SD-WAN, and why the names blur
SD-WAN is an application of SDN, not a competitor to it. The sdn vs sd-wan question comes up because vendors market them separately and the acronyms look alike.
Scope is the difference. SDN describes an architecture that can be applied to any network: a data center fabric, a campus, a carrier core. SD-WAN applies it to one place, the links between sites and to the internet.
The problem each one solves. SDN exists to make a large network programmable and centrally managed from one point. SD-WAN exists to use cheap internet links safely and to route each application over the best path available.
The device mix differs. SDN fabrics are usually homogeneous switches in racks. SD-WAN is edge routers in offices, connected over links the business does not control.
A sentence that survives most arguments: all SD-WAN is a software defined network, but most software defined networks are not SD-WAN.
PitfallsWhere people go wrong
Calling every automation project SDN. Scripting device configurations is automation. Unless the control plane moved off the devices, the architecture did not change.
Assuming SDN means OpenFlow. OpenFlow was the first standard southbound interface and remains a reference point, but most shipping products use NETCONF, gNMI or a proprietary API instead.
Not asking what happens when the controller is unreachable. This is the most important operational question in sdn networking, and different products answer it differently.
Buying a controller for a network with one switch. Centralized control pays off when there are many network devices to configure identically. Below that, it is overhead with a license attached.
Ignoring who holds the keys. A cloud controller means policy, telemetry and sometimes traffic data depend on a vendor account. That is a security and business risk to accept deliberately, not to discover at renewal.
Expecting the physical network to stop mattering. Cabling, uplink capacity, power and loops behave exactly as before. A virtual overlay hides the physical network from administrators, not from physics.
ComparisonFour ways to run a network, and where control lives in each
| Criterion | Traditional network | Classic SDN | SD-WAN | Cloud managed |
|---|---|---|---|---|
| Where control decisions are made | On every device | In a central controller | In a central controller | In the vendor's cloud |
| What you configure | Each box, one at a time | Policy in the controller | Policy per application | Policy in a web portal |
| Interface down to devices | The device CLI | OpenFlow, NETCONF or an API | A vendor protocol | A vendor protocol |
| If the controller is unreachable | Nothing changes | Depends on the mode | Forwarding continues, no new policy | Forwarding continues, no changes |
| Typical buyer | Any single site | Carriers, clouds, large campuses | Businesses with several sites | Small and midsize offices |
| What it is usually bought for | Nothing, it is the default | Programmability at scale | Cheaper, smarter branch links | Fewer hours spent per device |
| Realistic fit for a 50 person office | Still common | No | Only with multiple sites | Yes |
The row that decides the answer for most readers is the last one. A single site office gets the benefit of SDN through a cloud managed platform, and nothing from a controller it would have to run itself. The row people skip is the unreachable controller.
A well built SDN or SD-WAN deployment keeps forwarding traffic when the controller goes away, because the data plane already has its instructions, and only changes stop. Confirm that behavior in the documentation of anything you buy, rather than assuming it.
FAQFrequently asked questions
What is SDN in simple terms?
It is a way of running a network where the devices no longer decide where traffic goes on their own. A central controller holds the policy and the view of the whole network, and tells the switches and routers what to do.
What is a software defined network made of?
Forwarding devices at the bottom, a controller in the middle holding the policy and the topology, and applications on top that ask the controller for what they need. A southbound interface connects controller to devices, a northbound API connects it to applications.
What does an SDN controller do?
It maintains a global view of the network, computes what each device should forward, pushes those instructions down, and presents the whole network to applications as one logical switch. It is the piece that replaces the per device control plane.
What is OpenFlow?
The first standardized protocol for a controller to program the forwarding tables of a switch. The Open Networking Foundation describes it as a foundational element for building SDN solutions, and dates the first standard interface to 2012.
Is OpenFlow still used?
It remains the reference example and appears in research, teaching and some fabrics, but most commercial products use NETCONF, gNMI or vendor specific APIs for the same job. Very few offices run OpenFlow in production.
What is the difference between SDN and SD-WAN?
SDN is the architecture: control plane separated from forwarding and centralized. SD-WAN applies that architecture to wide area links between branches. All SD-WAN is software defined, but SDN covers data centers and campuses too.
Is SDN the same as network automation?
No. Automation scripts and orchestrates devices that still run their own control planes. SDN moves the control plane itself. They are often used together, and confusing them leads to buying the wrong thing.
Does SDN need special hardware?
Classic OpenFlow deployments need switches that support it. Most current implementations work with the vendor's own hardware and a controller or cloud service, so the hardware is ordinary, but it is tied to that platform.
What happens if the SDN controller fails?
In a well designed deployment the devices keep forwarding traffic using the instructions they already have, and only configuration changes stop. Some designs handle new flows badly without a controller, which is why controllers are usually deployed in clusters.
What are the benefits of SDN?
One place to apply policy, consistent configuration across many devices, faster change, and a programmable interface for other systems. The benefits scale with the number of devices, which is why the technology took hold in data centers first.
What are the drawbacks?
A central controller is a central dependency, the skills are different from traditional networking, and most implementations tie you to one vendor. For a small network the complexity can exceed the benefit.
Do small businesses use SDN?
Indirectly, almost always. Cloud managed Wi-Fi and switching, SD-WAN services and public cloud networking are all built on it. Running a controller in house is rare below a few hundred devices.
Is cloud networking software defined networking?
Yes. Virtual networks, subnets, route tables and security groups in a public cloud are programmed by the provider's controllers. The customer gets an API and a portal, which is exactly the northbound interface in the architecture.
Keep readingRelated concepts
Read next · Routing Control Plane vs Data Plane, and Why the Split Matters to an Admin The split SDN is built on, explained on its own terms, including where the management plane sits. Open this next10 min- Infrastructure · 8 min Cisco SD-WAN, and Why the Controller Never Touches Your Traffic One vendor's implementation in detail, including the controller components and how routes move.
- Infrastructure · 10 min Cloud Managed Networking, and What Happens When You Stop Paying The packaged version most offices actually buy, and what happens when the license lapses.