SDN and SD-WAN Fundamentals: Separating the Control Plane from the Data Plane

Traditional networking, covered throughout most of this series, distributes intelligence across every individual device, each making its own independent forwarding decisions. Software-Defined Networking fundamentally changes this by centralizing that intelligence, and this article explains the control plane and data plane separation underlying SDN, covers how SD-WAN applies these principles specifically to wide area network connectivity, and explains the practical benefits this architectural shift provides.

SDN ArchitectureControl Plane Data Plane SeparationSD-WAN

~5 min read · Updated Sep 11, 2026

Revisiting the Control Plane and Data Plane

Every networking device covered throughout this series conceptually performs two distinct functions. The Control Plane makes decisions -- running routing protocols like OSPF and BGP, discussed earlier in this series, to determine the best path to every destination. The Data Plane (also called the forwarding plane) actually moves traffic based on those decisions -- the CEF-based forwarding, discussed earlier in this series, that switches and routers perform on every packet.

Traditional (distributed) architecture:
Every single router and switch runs its own
control plane AND its own data plane locally --
each device independently calculates its own
routing table and independently forwards traffic
based on its own local decisions

The SDN Shift: Centralizing the Control Plane

Software-Defined Networking (SDN) separates these two functions architecturally: a centralized SDN Controller handles the control plane decision-making for an entire fleet of devices, while the individual devices retain only the data plane function of actually forwarding traffic based on instructions received from the controller.

SDN (centralized) architecture:

SDN Controller: makes all forwarding decisions
  for the entire network, maintaining a
  network-wide view rather than each device
  independently calculating its own limited view

Network Devices: retain only data plane
  functionality, forwarding traffic exactly
  as instructed by the controller, without
  independently running routing protocol
  calculations themselves

This is conceptually the same architectural pattern already seen twice earlier in this series -- the centralized WLC managing lightweight access points for wireless networks, and controller-based networking managing traditional wired infrastructure -- now formalized as SDN's core architectural principle and applied across an entire network fabric.

Why Centralization Provides Real Benefits

Benefits of centralized control:

Global network visibility: the controller sees
  the entire network's state at once, rather
  than each device only knowing about its
  immediate neighbors, as with OSPF or EIGRP,
  discussed earlier in this series

Simplified device configuration: individual
  devices become comparatively simple forwarding
  engines, with complex policy logic centralized
  at the controller rather than distributed
  and duplicated across every device

Faster, more consistent policy changes: a policy
  update made once at the controller propagates
  consistently to every affected device, rather
  than requiring the same change to be manually
  applied device by device, as with the
  traditional CLI configuration covered
  throughout most of this series

SD-WAN: Applying SDN Principles to Wide Area Networks

SD-WAN (Software-Defined Wide Area Network) applies the same control plane centralization to WAN connectivity, discussed earlier in this series, specifically addressing the limitations of traditional WAN designs that relied entirely on expensive, dedicated circuits like MPLS.

Traditional WAN design:
Branch offices connect to a central location
using dedicated, expensive circuits (MPLS),
with limited ability to dynamically choose
between different paths based on real-time
conditions

SD-WAN design:
Branch offices connect using ANY available
transport -- MPLS, broadband internet, LTE/5G --
with a centralized SD-WAN controller
dynamically selecting the best path for each
type of traffic based on real-time link
quality measurements

Key SD-WAN Capabilities

Application-aware routing: different applications
  can be routed over different underlying transport
  links based on their specific requirements --
  voice traffic, requiring the low latency
  discussed earlier in this series regarding QoS,
  might use a dedicated MPLS link, while bulk
  data transfer uses cheaper broadband internet

Dynamic path selection: the SD-WAN controller
  continuously monitors each available path's
  actual performance (latency, jitter, packet
  loss) and can shift traffic away from a
  degrading path in near real-time, without
  waiting for a link to completely fail the
  way traditional routing protocol convergence,
  discussed earlier in this series, requires

Zero-touch provisioning: a new branch device
  can be shipped to a remote site, plugged in,
  and automatically receive its full configuration
  from the central controller, without requiring
  a network engineer to manually configure it
  via CLI on-site or remotely

Why SD-WAN Matters for Modern Enterprise Connectivity

The shift toward cloud-hosted applications has fundamentally changed WAN traffic patterns: traffic increasingly flows directly from a branch office to a cloud provider rather than being routed back through a central data center first, a pattern traditional hub-and-spoke MPLS WAN designs handle poorly, since it forces cloud-bound traffic through an unnecessary detour. SD-WAN's ability to intelligently route traffic directly toward its actual destination, using whichever available transport link is currently best suited for that specific traffic type, directly addresses this shift.

The Trade-Offs of Centralized Control

Considerations when adopting SDN/SD-WAN:

Controller as a critical dependency: since the
  controller makes the actual forwarding
  decisions, its availability and redundancy
  become critical -- most production SDN and
  SD-WAN deployments require carefully designed
  controller redundancy, unlike a traditional
  distributed control plane where no single
  device's failure affects the entire network's
  ability to make routing decisions

Requires new operational skills: administrators
  need to learn the specific controller platform's
  interface and abstractions, which may differ
  significantly from traditional CLI-based
  device-by-device configuration covered
  throughout most of this series

Why This Represents a Genuine Architectural Shift

SDN and SD-WAN do not replace the underlying networking concepts covered throughout this entire series -- routing, switching, and QoS still fundamentally determine how traffic actually moves through a network. What changes is where the intelligence controlling those decisions lives: rather than being distributed and independently calculated by every device using protocols like OSPF and EIGRP, discussed earlier in this series, that intelligence becomes centralized, giving network operators a single point of visibility and control over decisions that were previously scattered across hundreds or thousands of independently operating devices.

Written & researched by Dr. Shahin Siami

Related Articles

Enterprise Network Architecture: The Three-Tier Design Model

Every technology covered so far in this series -- VLANs, routing protocols, redundancy protocols -- needs an overall architectural framework to be deployed coherently rather than as an ad hoc collection of features. This article explains the classic three-tier hierarchical design model, covers the distinct role each layer plays, explains the simplified two-tier collapsed core alternative, and discusses how these models extend into modern data center design.

Continue

Multicast Fundamentals: IGMP and PIM Explained

Sending the same video stream individually to a thousand viewers would waste enormous bandwidth, and multicast solves this by delivering a single stream efficiently to exactly the devices that actually want it. This article explains how multicast addressing differs from unicast and broadcast, covers IGMP as the protocol hosts use to join multicast groups, and walks through how PIM builds the distribution trees that carry multicast traffic efficiently through a network.

Continue

First Hop Redundancy Protocols: HSRP, VRRP, and GLBP Explained

Every host on a network relies on a single default gateway, and that gateway becoming a single point of failure would undermine the redundancy carefully built everywhere else in the network. This article explains why first hop redundancy matters, walks through HSRP's active/standby model, compares it against the open-standard VRRP, and covers GLBP's added ability to load-balance traffic across multiple routers simultaneously.

Continue

Route Redistribution: Exchanging Routes Between Different Routing Protocols

Real enterprise networks often run multiple routing protocols simultaneously, whether due to mergers, legacy equipment, or vendor requirements, and these protocols do not automatically share routes with each other. This article explains why redistribution becomes necessary, covers the critical metric mismatch problem between protocols, walks through configuring redistribution between OSPF and EIGRP, and covers the routing loop risks that make careful redistribution design essential.

Continue

BGP Fundamentals: The Protocol That Runs the Internet

Every interior routing protocol covered so far in this series operates within a single organization's network, but connecting separate organizations together across the internet requires an entirely different protocol built around policy rather than pure shortest-path calculation. This article explains what makes BGP a path-vector protocol, covers the distinction between eBGP and iBGP, walks through essential path attributes used for path selection, and covers basic BGP configuration and verification.

Continue

Multi-Area OSPF: Scaling with Areas, LSA Types, and Route Summarization

A single-area OSPF design, discussed earlier in this series, does not scale to large networks, since every router must process the full topology database of every other router. This article explains why OSPF areas exist, covers the different Link-State Advertisement types that carry information between areas, explains the role of Area Border Routers, and walks through configuring route summarization to keep large multi-area networks efficient.

Continue