SD-WAN is making one of the biggest architectural changes to enterprise networking in the last ten years IT architects who are held accountable for design and direction of distributed network infrastructure need to know how SD-WAN really works not just what it does at a superficial level; knowledge of deployment topology, security integration, vendor selection and long-term scalability based on usage patterns and business goals is critical. If you’re a practitioner who needs to move beyond marketing abstractions to get a sense of how SD-WAN architecture works beneath the surface, this article provides a technical overview.
Basically, SD-WAN translates the principles of software-defined networking to the wide area network. Traditional WAN architectures depended upon dedicated hardware appliances at every site, most often MPLS routers with static configurations under local site management; SD-WAN separates a network’s control logic from its underlying physical transport while providing centralized policy management. This results in a software-defined network that can be configured, monitored, and adapted at any connected location without ever touching any location.
IT architects evaluating or implementing SD-WAN deployments will find a practical entry point in the technical resource on SD-WAN explained for IT architects, which outlines the foundational capabilities of SD-WAN and how its core components interact to deliver secure, application-aware connectivity across enterprise environments.
Separation of Control Plane and Data Plane
At the core of the SD-WAN concept is decoupling the control plane from the data plane. In the case of traditional routers, these functions are coupled to deciding how to actually forward traffic and then doing the actual forwarding by the device itself. SD-WAN dissolves this coupling. A control plane is the logic that directs how your traffic behaves including routing policy, Path selection and quality-of-service (QoS) parameters are centralized in a software controller. The data plane the real forwarding of packets is done on physical or virtual edge devices at every site in a distributed fashion.
Such separation has significant implications for architecture. Policy is defined centrally and pushed out to edge devices making it possible to change routing behavior across an entire enterprise network from a single management interface across all sites at once. In a more traditional MPLS environment, equivalent changes would need to be made through device-by-device reconfigurations over several vendor interfaces.
The terminology and formal layer structure of this separation including the control plane, management plane, forwarding plane, and their respective abstraction layers is defined in the SDN architecture layer terminology documented in RFC 7426, which provides the foundational reference model for how software-defined networking components interact across distinct planes.
SD-WAN Architectural Components
A set of architectural components form the fundamental building blocks upon which every SD-WAN deployment is based and understanding these design fundamentals enables IT architects to integrate, troubleshoot and better enhance the design accordingly.
Edge Devices
SD-WAN edge device, sometimes known as customer premises equipment in vendors’ documentation, is present at each branch, data center and point of presence into the cloud. These are the devices that actually forward traffic based on policies received from the central controller. They are either a physical or virtual enforcement point for activities taken at the transport level. In software-defined architectures, edge devices must be thin: they act as slaves of the controller and do not independently compute routing decisions.
To remain aware of WAN link conditions in real time, edge devices constantly measure packet loss, latency and jitter over all paths available. This telemetry is taken locally for local policy-based or forwarding decisions and for centralized aggregates to drive network management decisions.
The Centralized Controller
The SD-WAN controller is the brains of the architecture. In short, it monitors telemetry for all edge devices, maintains the global view of the network topology and link performance, enforces policy rules and disseminates forwarding instructions. Cloud-delivered SD-WAN architectures are hosted in the cloud (rather than on-prem) and provide one orchestration layer for managing geographically dispersed networks.
Controllers expose a management interface, typically either a web-based console or an API, whereby network administrators specify their traffic steering policies, quality-of-service rules, segmentation boundaries, and application-prioritization mappings. Once defined, these policies automatically push to all relevant edge devices without needing per-site configuration.
The Overlay Network
SD-WAN is an overlay, which is a logical network that rides above whatever physical transport you may use. An SD-WAN overlay can support broadband internet, MPLS, LTE, 5G and satellite all at once rather than being tied to a single carrier or link type. The fact that the overlay is based on encrypted tunnels (typically IPsec, though) means there’s a secure virtual path between sites independent of whatever transport technology is being used.
From an architectural standpoint, this transport independence is one of the hallmarks of SD-WAN. The diversity of physical connectivity has been abstracted as a single uniform logical fabric by the overlay. The applications and users do not observe which physical links are currently in use; the network behaves uniformly regardless of which of many paths between a given pair of points through the internetwork is up at any given time.
Application-Aware Routing and Traffic Steering
Application-aware traffic steering is a technical capability that separates SD-WAN from traditional routing. Routing decisions are traditionally based on destination IP address and entries in a routing table. SD-WAN takes this a step further by classifying traffic at Layer 7; the application that originates the traffic will be identified and a policy that routes different applications differently will be implemented.
Applications that are real-time and latency-sensitive, like voice and video are directed toward the path with the minimum-latency, minimum-jitter. Time-critical applications compete for bandwidth with only the smallest amount of distributed real time traffic; however, bulk file transfers and backup traffic are routed to leverage excess capacity without competing. These decisions are made dynamically, in real time as the link is monitored continuously rather than when it was statically configured.
The IEEE Software Defined Networks technical publication includes a detailed examination of how cloud-delivered SD-WAN architecture technical overview addresses the enterprise WAN scalability and transport independence challenges that motivate SD-WAN adoption, including how dynamic multi-path optimization and application-abstraction mechanisms function in practice.
In some implementations, when a monitored link degrades beyond defined thresholds, the SD-WAN seamlessly reroutes affected traffic to an alternative path within milliseconds, without bringing down active sessions. This dynamic behavior (sometimes called dynamic path selection or per-packet steering) builds resiliency into the SD-WAN compared to static MPLS configurations, where a failover can take much longer.
Security Architecture in SD-WAN Deployments
SD-WAN architecture with integrated security not bolted on at the perimeter. In terms of IT architectures, it implies understanding how security functions are encapsulated within the SD-WAN topology and how these components interface with the existing enterprise security infrastructure.
Most SD-WAN deployments include some firewall functionality typically next-gen firewall capabilities directly into edge devices. Enabling a security policy to be enforced at every site without requiring backhauling all the traffic to a central inspection point. Network segmentation when realized in terms of virtual routing and forwarding domains, for example, or the equivalent, separates user traffic, IoT device traffic, guest networks, etc. at the network layer across every interconnected site.
Enterprise architects are more focused on the relationship between SD-WAN and Secure Access Service Edge architecture. SD-WAN delivers the network transport layer of a SASE architecture, while security service edge functions such as zero trust network access, secure web gateway and cloud access security broker capabilities give you the security enforcement layer. As architects think about the long-term evolution of the network, understanding how those two components combine and whether or not a given SD-WAN platform provides native SASE convergence or requires third-party integration is one of the primary design choices they have to make.
Deployment Models and Topology Considerations
This calls for IT architects to choose among various SD-WAN deployment models, each of which makes different tradeoffs on performance, cost, security and operational complexity.
The hub-and-spoke model sends branch traffic to a central hub location before breaking out to the internet or cloud. This emulates the classic MPLS designs and offers centralized security inspection but does incur additional latency for cloud-bound traffic. By contrast, the internet access model breaks out traffic locally at branches, resulting in latency improvements for cloud applications but requiring security controls onboard at all locations. In cloud-hosted deployment models, traffic passes through provider-managed points of presence that simplify configurations on each site but add dependencies on the quality and reach of the provider’s network.
Most enterprise environments leverage multi-region and hybrid deployments, retaining MPLS for latency-sensitive applications while using SD-WAN tunnel overlay to move general traffic, as they cannot fully migrate away from existing infrastructure or prefer not to. Because of the degree to which the network exists as a hybrid state, IT architects have to design for this reality explicitly. After all, how is policy consistency enforced across both the legacy and SD-WAN portions of the network?
Frequently Asked Questions
How does SD-WAN work on failover when a WAN link fails?
SD-WAN edge devices always measure packet loss, latency, and jitter of all available WAN links. When a link begins to degrade below a policy-defined threshold, or when it fails completely, the SD-WAN system dynamically reroutes traffic to the next-best available path in real time, based on performance data and application-priority policies. Due to the nature of well-implemented platforms, this rerouting happens within milliseconds for active sessions which is in fact much faster than traditional routing protocol convergence on MPLS networks.
SD-WAN Controller vs Orchestrator: How Are They Different?
The controller: orchestrates the control plane in real time, propagating forwarding policies to edge devices, inspecting links and adapting paths. Meanwhile, the orchestrator operates at a more macro level where provisioning, lifecycle management and policy definition are performed on a network-wide scale. These functions are often covered in a single management plane for many SD-WAN platforms, but the conceptual separation is important to architects who must consider models of governance and where intelligence resides in their network.
How does SD-WAN fit the zero-trust network access architecture?
SD-WAN Creates the Transport Layer SD-WAN is the transport layer that connects users, devices and branch locations to applications & resources. This means that all access to those resources should be strictly controlled and based on identity, with the least-privilege principle in place, regardless of how a user is connected to the network. In a converged SASE approach, SD-WAN and zero trust network access leverage two synergistic pieces of technology: SD-WAN intelligently selects the best path for traffic moving between locations while zero trust allows you to define which users and devices are allowed to reach what applications. For integration to take place, the SD-WAN platform must allow a policy handoff to the security enforcement layer via native support or well-defined integration points with a third-party security service edge provider.
