How SD-WAN Works: Software-Defined Wide Area Networking

Software-Defined Wide Area Networking (SD-WAN) is an approach to WAN architecture that decouples the network control plane from the data plane, allowing enterprises to build wide area networks using commodity internet circuits, LTE/5G, and broadband alongside or instead of traditional MPLS connections. An SD-WAN overlay abstracts the underlying transport, creating encrypted tunnels between sites and using a centralized controller to make real-time traffic steering decisions based on application requirements and link quality. The result is a WAN that costs less than MPLS, adapts to changing network conditions automatically, and provides direct cloud access from branch offices rather than backhauling everything through a central data center.

SD-WAN emerged around 2012-2014 as enterprises faced a fundamental mismatch: their WANs were built for an era when applications lived in the data center, but traffic patterns had shifted toward SaaS and public cloud. Backhauling Office 365 and Salesforce traffic through an MPLS hub-and-spoke topology to a central internet breakout point added latency, consumed expensive MPLS bandwidth, and created bottlenecks. SD-WAN solved this by enabling local internet breakout at branches, intelligent path selection across multiple transport types, and centralized policy management — all without requiring changes to the underlying network infrastructure.

Traditional WAN vs. SD-WAN

To understand why SD-WAN matters, you need to understand what it replaced. A traditional enterprise WAN is built on MPLS circuits purchased from one or more service providers. Each branch office gets an MPLS connection to the provider's PE router, and the provider builds L3VPN tunnels between sites. The enterprise pays per-megabit pricing that is often 5-10x more expensive than equivalent broadband bandwidth. Adding a new branch takes weeks to months for circuit provisioning. Changing routing policy means opening tickets with the service provider and waiting for manual configuration changes on their PE routers.

MPLS has real advantages: it provides deterministic latency, guaranteed bandwidth through QoS, and SLA-backed reliability. For real-time applications like voice and video conferencing, MPLS's traffic engineering capabilities ensure packets arrive in order with consistent jitter. The BGP signaling that underpins MPLS L3VPN (MP-BGP with VPNv4/VPNv6 address families) provides clean separation between customer routing domains.

But MPLS was designed for a world where branch traffic flowed to the data center and back. When 60-80% of branch traffic is destined for the internet — SaaS applications, cloud workloads, video streaming — the hub-and-spoke MPLS model becomes a liability. Every packet to Office 365 traverses the MPLS cloud to the data center, exits through a centralized firewall, crosses the internet to Microsoft, and then makes the entire return trip. The latency alone can make applications unusable.

SD-WAN addresses the MPLS limitations by creating an overlay network across whatever transport is available. A branch can use a $200/month cable broadband connection alongside a $50/month LTE backup, get direct internet breakout for SaaS traffic, and still send internal application traffic through encrypted tunnels to the data center or other branches. The SD-WAN controller manages all of this centrally, pushing policies to edge devices at every site.

The Overlay Architecture: Tunnels and Encapsulation

At its core, SD-WAN is an overlay network. The edge devices at each site (sometimes called CPE, vEdge, or simply SD-WAN appliances) establish encrypted tunnels to every other site, forming a full or partial mesh. These tunnels typically use IPsec for encryption, sometimes combined with GRE or VXLAN for encapsulation. The underlay — the actual physical transports (broadband, MPLS, LTE) — is treated as a dumb pipe; the SD-WAN overlay makes all routing and policy decisions.

When a packet arrives at a branch SD-WAN appliance from a local LAN device, the appliance performs deep packet inspection (DPI) to identify the application. It then consults its local policy table (pushed from the controller) to determine which overlay tunnel should carry this traffic. The packet is encapsulated in a new IP header with the destination being the remote SD-WAN appliance, encrypted with IPsec ESP, and sent out the appropriate WAN interface. At the remote end, the receiving appliance decapsulates, decrypts, and delivers the packet to the local LAN.

The key difference from a simple VPN is intelligence. A site-to-site IPsec VPN creates static tunnels with fixed routing. SD-WAN creates dynamic tunnels that can:

Steer traffic per-application — Voice goes over MPLS, web browsing goes over broadband, backup traffic goes over LTE during off-peak hours.
Fail over in sub-second timeframes — If the primary link degrades (packet loss exceeds a threshold), traffic shifts to the secondary link within milliseconds, often without dropping a single VoIP call.
Load-balance across multiple links — A single TCP flow might stay on one link for consistency, but aggregate traffic is distributed across all available transports based on real-time performance metrics.
Enforce security policy inline — The same appliance that handles tunneling can also inspect traffic, enforce URL filtering, and integrate with cloud security services (SASE).

The Centralized Controller

The defining characteristic of SD-WAN is the separation of the control plane from the data plane. Traditional WAN routers combine both: the same device that forwards packets also runs routing protocols, computes paths, and holds configuration. In SD-WAN, these functions are split:

The controller (orchestrator) runs centrally — either in the cloud or on-premises. It holds the global network topology, defines forwarding policies, manages security certificates, distributes encryption keys, monitors link health, and pushes configuration to all edge devices. The controller never touches user traffic; it is a pure control-plane element.
The edge device (data plane) sits at each site. It establishes overlay tunnels, performs DPI, enforces policies, encrypts/decrypts traffic, and forwards packets. The edge device receives its configuration and policy from the controller but makes local forwarding decisions autonomously based on real-time link conditions.

This split means that a network administrator can define a policy like "route all Zoom traffic over the lowest-latency link, with failover to any link with less than 1% packet loss" in the controller's web UI, and that policy is instantly pushed to hundreds of branch appliances simultaneously. In a traditional WAN, achieving this would require configuring PBR (policy-based routing), IP SLA probes, and track objects on every single router — a process that is error-prone and scales poorly.

Most SD-WAN controllers also provide a management plane with centralized visibility: real-time dashboards showing per-application bandwidth usage, link health metrics (latency, jitter, packet loss), tunnel status, and security events across all sites. This visibility alone is a major selling point, since traditional WANs often have limited end-to-end monitoring.

Application-Aware Routing

Application-aware routing is what separates SD-WAN from a simple multi-link VPN. Instead of routing based solely on destination IP prefix (as BGP and OSPF do), SD-WAN routes based on the application generating the traffic and the real-time quality of available links.

The process works as follows:

Application identification — The SD-WAN appliance uses DPI to identify applications from the first few packets of a flow. Modern DPI engines can identify thousands of applications, including encrypted SaaS traffic (by SNI in the TLS ClientHello, certificate attributes, or IP/domain reputation databases). Some platforms maintain cloud-updated application signature databases with updates pushed multiple times daily.
Link quality measurement — The appliance continuously probes all WAN links using BFD (Bidirectional Forwarding Detection) or proprietary probes, measuring latency, jitter, packet loss, and available bandwidth in real time. These measurements happen every few hundred milliseconds to seconds.
Policy evaluation — For each identified application, the appliance evaluates the configured SLA policy. For example: "Voice traffic requires latency < 150ms, jitter < 30ms, packet loss < 1%. Preferred link: MPLS. Failover: broadband."
Path selection — The appliance selects the best path that meets the SLA requirements. If no path meets the SLA, the appliance may fall back to the best available path, or drop the traffic, depending on policy.
Continuous re-evaluation — Unlike static routing, SD-WAN re-evaluates path selection continuously. If the MPLS link's latency spikes above 150ms, voice traffic is seamlessly moved to broadband. When MPLS recovers, traffic may shift back (configurable hysteresis prevents flapping).

This is fundamentally different from traditional QoS. MPLS QoS (DiffServ/DSCP markings) can prioritize voice packets over data packets on the same link, but it cannot move traffic to a different link when quality degrades. SD-WAN does both: it applies QoS markings within each tunnel and steers traffic between tunnels based on real-time conditions.

Zero-Touch Provisioning

Deploying a traditional WAN router at a new branch requires a network engineer to configure the device, set up routing protocols, establish VPN tunnels, and test connectivity. For a 500-branch enterprise, this means hundreds of truck rolls with skilled technicians.

SD-WAN uses zero-touch provisioning (ZTP) to eliminate this. The process typically works as follows:

The administrator pre-stages the new site in the controller, defining its WAN interfaces, LAN subnets, and security policies.
A factory-default SD-WAN appliance is shipped to the branch site. An on-site employee (not a network engineer) plugs in power and a WAN cable.
The appliance boots and contacts a cloud-hosted provisioning server (sometimes called a "phone-home" server or PnP portal) using a factory-embedded certificate or serial number for authentication.
The provisioning server verifies the device identity and redirects it to the appropriate SD-WAN controller.
The controller pushes the complete configuration to the appliance: tunnel endpoints, routing policy, security policy, application SLA definitions, and firmware updates.
The appliance establishes overlay tunnels to all other sites and begins forwarding traffic according to policy.

The entire process, from unboxing to full connectivity, typically takes 10-15 minutes. The on-site person needs no networking knowledge — they just plug in cables. This is a dramatic improvement over the weeks or months required for MPLS circuit provisioning and traditional router deployment.

WAN Optimization

Many SD-WAN platforms integrate WAN optimization features that were previously provided by dedicated appliances from vendors like Riverbed or Silver Peak (now part of HPE Aruba). These techniques reduce the amount of data that needs to traverse WAN links:

TCP optimization — The SD-WAN appliance terminates TCP connections locally and re-originates them over the WAN with optimized parameters: larger window sizes, selective acknowledgments, and congestion algorithms tuned for high-latency links. This eliminates the "bandwidth-delay product" problem where TCP's flow control prevents full utilization of high-latency links.
Deduplication — Data that has been previously sent over the WAN is cached and referenced by hash. If the same data block appears again (common with file shares, backups, and email attachments), only the hash reference is sent, not the full data. Deduplication ratios of 50-80% are common for enterprise traffic patterns.
Compression — Standard LZ-based or zlib compression applied to WAN traffic. Less effective than deduplication for repeated content but provides consistent savings on compressible data.
Forward error correction (FEC) — The appliance adds redundant packets to each stream so that the receiving end can reconstruct lost packets without retransmission. This is especially valuable for real-time applications (voice, video) over lossy links like LTE, where waiting for TCP retransmission would be too slow.
Packet order correction — When traffic is load-balanced across multiple links with different latencies, packets can arrive out of order. The receiving appliance buffers and reorders packets before delivering them to the LAN, preventing application-level issues.

Cloud On-Ramp and SaaS Optimization

One of SD-WAN's most impactful features is cloud on-ramp — the ability to provide optimized, direct connectivity from branch offices to cloud services without backhauling through the data center.

There are two distinct forms of cloud on-ramp:

SaaS on-ramp identifies traffic destined for cloud applications (Office 365, Salesforce, AWS, Google Workspace) and routes it directly to the internet from the branch, bypassing the data center entirely. The SD-WAN appliance uses application signatures and Microsoft/Google/AWS published IP ranges to identify this traffic. Some platforms go further: they probe multiple internet paths to the SaaS provider from the branch and select the lowest-latency path. Cisco Viptela, for example, maintains a database of SaaS endpoint performance metrics across its global customer base, sharing anonymized latency data so that each branch can select the optimal path to each SaaS application.

IaaS on-ramp extends the SD-WAN overlay directly into public cloud providers. Instead of terminating the SD-WAN tunnel at the data center and then traversing a dedicated connection (like AWS Direct Connect or Azure ExpressRoute) to reach cloud workloads, the enterprise deploys virtual SD-WAN appliances inside AWS VPCs, Azure VNets, or GCP VPCs. The branch SD-WAN appliance builds overlay tunnels directly to the cloud-hosted virtual appliance, providing the same application-aware routing and path selection for cloud workloads as for data center applications. The cloud virtual appliance acts as a transit hub within the cloud, connecting to workloads across multiple VPCs or regions.

This is where SD-WAN intersects with BGP in interesting ways. Cloud on-ramp deployments often use BGP peering between the SD-WAN virtual appliance and the cloud provider's virtual router (AWS VGW, Azure Route Server, GCP Cloud Router). The SD-WAN appliance advertises the enterprise's internal routes into the cloud environment and learns cloud routes in return, creating a seamless routing domain that spans on-premises and cloud. You can observe these cloud-edge autonomous systems and their peering relationships using a BGP looking glass.

Security: From MPLS Trust to Zero Trust

MPLS networks offer inherent traffic isolation — each customer's VPN is separated at the label level, and traffic never touches the public internet. SD-WAN, running over the internet, must provide equivalent or better security through encryption and policy enforcement.

SD-WAN security operates at multiple layers:

Transport encryption — All overlay tunnels use IPsec with AES-256-GCM encryption and IKEv2 key exchange. The centralized controller manages the PKI infrastructure, automatically rotating keys and distributing certificates to all edge devices. This eliminates the manual IPsec configuration that makes traditional site-to-site VPNs difficult to manage at scale.
Segmentation — SD-WAN supports network segmentation through virtual routing domains (similar to VRFs in traditional routing). A single overlay can carry multiple isolated segments: one for production traffic, one for guest Wi-Fi, one for IoT devices, one for PCI-compliant payment systems. Segmentation policies are defined centrally and enforced at every edge device.
Integrated firewall — Many SD-WAN platforms include stateful firewall, IDS/IPS, URL filtering, and anti-malware capabilities directly on the edge appliance. This eliminates the need for separate branch security appliances, though enterprises with strict security requirements may still chain SD-WAN with dedicated NGFW appliances.
SASE integration — Secure Access Service Edge (SASE) combines SD-WAN with cloud-delivered security services: Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Zero Trust Network Access (ZTNA), and Firewall-as-a-Service (FWaaS). Internet-bound traffic from branches is steered to the nearest cloud security PoP for inspection before reaching its destination. Vendors like Palo Alto (Prisma SASE) and Zscaler have deeply integrated their cloud security platforms with SD-WAN.

How SD-WAN Interacts with BGP

SD-WAN overlays sit on top of underlay networks that are routed by BGP. While the overlay makes its own routing decisions, the underlay still determines how encapsulated packets reach their destination. This creates an interesting layered routing architecture.

At the underlay level, each WAN transport has its own routing. The broadband link at a branch connects to an ISP whose routes are determined by BGP. The MPLS link connects to a service provider whose PE routers use MP-BGP for VPN routing. When the SD-WAN appliance sends an encapsulated packet out a WAN interface, it is the underlay BGP routing that determines how that packet traverses the internet to reach the remote SD-WAN appliance. The AS path taken by the encapsulated packet depends entirely on the underlay ISP's peering and transit arrangements.

At the overlay level, the SD-WAN controller manages route distribution. When a new branch comes online, the controller learns about its LAN subnets (either through static configuration or by redistributing routes from a local routing protocol) and distributes these routes to all other SD-WAN edge devices. This is functionally similar to how BGP route reflectors distribute routes in an MPLS L3VPN, but the signaling protocol is proprietary to each SD-WAN vendor rather than standardized BGP.

Some SD-WAN platforms can participate directly in BGP. The edge appliance can peer with local routers using eBGP, learn routes dynamically, and advertise SD-WAN routes back. This is essential in environments where SD-WAN coexists with traditional routing infrastructure — for example, a data center where the SD-WAN appliance connects to a BGP-speaking core router and needs to advertise branch routes into the data center's routing domain. Cisco Viptela's vEdge and Catalyst SD-WAN platforms support full BGP functionality including communities, AS-path prepending, and route filtering.

SD-WAN Vendors and Architectures

The SD-WAN market has consolidated around several major platforms, each with distinct architectural approaches:

Cisco SD-WAN (Viptela)

Cisco acquired Viptela in 2017 for $610 million and has made its architecture the foundation of Cisco Catalyst SD-WAN. The Viptela architecture has four distinct components:

vManage — The management plane. A web-based GUI and REST API for configuration, monitoring, and troubleshooting. Runs as a cluster for high availability.
vSmart — The control plane. Distributes routing information (using Cisco's proprietary OMP — Overlay Management Protocol), data policies, and app-route policies to all edge devices. vSmart controllers maintain DTLS/TLS sessions with every edge device.
vBond — The orchestration plane. Handles initial device authentication and facilitates NAT traversal for edge devices behind firewalls. The first point of contact for ZTP.
vEdge / cEdge — The data plane. Physical or virtual appliances at each site. cEdge devices run IOS-XE and support full Cisco routing features (BGP, OSPF, EIGRP) alongside SD-WAN functionality.

OMP is the protocol that ties Viptela's architecture together. It runs between vSmart controllers and edge devices (and between vSmart controllers in a multi-controller deployment), distributing three types of routes: OMP routes (prefixes from each site), TLOCs (Transport Locators — representing each WAN interface's public IP and color/encapsulation type), and service routes (for service chaining through firewalls or other network services). OMP is functionally analogous to MP-BGP in MPLS networks: it provides route distribution with policy control, but optimized for the SD-WAN overlay model.

VMware SD-WAN (VeloCloud)

VMware acquired VeloCloud in 2017 and integrated it into VMware SASE. VeloCloud's architecture is distinguished by its gateway-mediated approach:

SD-WAN Gateways — Cloud-hosted nodes that act as relay points for SD-WAN traffic. Instead of building direct tunnels between every pair of branch devices, branches build tunnels to the nearest gateway, and gateways relay traffic between sites. This simplifies the control plane at the cost of adding a hop, though for traffic between geographically distant sites, the gateway network (with its optimized backbone) often provides better performance than direct internet paths.
VeloCloud Orchestrator — The centralized management and control plane. Handles policy definition, device management, and monitoring.
SD-WAN Edges — Branch appliances that can be physical or virtual. They support Dynamic Multi-Path Optimization (DMPO) which continuously measures path quality and steers traffic at the sub-flow level.

VeloCloud's gateway-mediated architecture has an advantage for enterprises with many small branches: a 200-site deployment with direct mesh tunneling requires 19,900 tunnels (n*(n-1)/2), while a gateway-mediated approach requires only 200 tunnels (one per site to the gateway). The gateways form a full mesh among themselves, handling inter-site relay. After the VMware/Broadcom acquisition in 2023, the VeloCloud product line was rebranded and its long-term roadmap became uncertain, leading some customers to evaluate alternatives.

Palo Alto Prisma SD-WAN (CloudGenix)

Palo Alto Networks acquired CloudGenix in 2020 and integrated it into Prisma SASE. Prisma SD-WAN is notable for its tight integration with Palo Alto's security stack:

Prisma Access — Cloud-delivered security (SWG, CASB, ZTNA, FWaaS) tightly integrated with the SD-WAN fabric. Internet-bound traffic from branches is steered to the nearest Prisma Access PoP for security inspection.
ION devices — Branch SD-WAN appliances. The Prisma approach emphasizes application-defined networking: rather than configuring network constructs (VLANs, VRFs, ACLs), administrators define policies in terms of applications, user groups, and security zones.
Autonomous Digital Experience Management (ADEM) — End-to-end monitoring from the user's device through the SD-WAN fabric to the SaaS application, providing visibility into every segment of the path.

Fortinet Secure SD-WAN

Fortinet's approach is unique in that its SD-WAN functionality is built directly into the FortiGate NGFW platform. There is no separate SD-WAN appliance; the same FortiGate device that provides firewall, IPS, and anti-malware also handles SD-WAN tunneling, application-aware routing, and WAN optimization. For security-focused enterprises, this is compelling: a single device, single policy framework, and single management plane (FortiManager) for both SD-WAN and security. The tradeoff is vendor lock-in to Fortinet's ecosystem.

Other Notable Platforms

HPE Aruba EdgeConnect (Silver Peak) — Known for strong WAN optimization heritage. First-packet iQ for application identification, Unity Boost for WAN optimization.
Versa Networks — Multi-tenant architecture popular with service providers offering managed SD-WAN services. Full routing stack (BGP, OSPF) on the edge device.
Juniper Mist AI SD-WAN (128 Technology) — Unique session-smart routing approach that eliminates tunnel overhead by inserting metadata into packet headers rather than encapsulating entire packets.

SD-WAN vs. MPLS: The Economics

The economic argument for SD-WAN is straightforward. MPLS pricing varies by region and provider, but typical costs for a 100 Mbps MPLS circuit in the US range from $500-$2,000/month per site. A 100 Mbps broadband connection costs $50-$100/month. Even accounting for the cost of SD-WAN appliances ($1,000-$5,000 per site) and SD-WAN licensing ($100-$300/month per site), the total cost of an SD-WAN deployment is typically 50-70% less than equivalent MPLS connectivity.

But the comparison is not purely about cost. MPLS provides guarantees that internet-based SD-WAN cannot match:

SLA-backed latency and uptime — MPLS providers offer contractual guarantees (e.g., 99.99% uptime, <50ms latency between sites). Internet broadband has no such guarantees. SD-WAN mitigates this with multi-link redundancy: if one broadband link degrades, traffic shifts to another, but the individual links themselves are best-effort.
Deterministic routing — MPLS traffic follows engineered paths through the provider's backbone. Internet traffic follows BGP best-path routing, which can change unpredictably. During a BGP hijack or route leak, SD-WAN underlay traffic could be misdirected.
End-to-end QoS — MPLS honors DSCP markings across the provider network. Internet routers generally ignore or re-mark DSCP values.

Many enterprises adopt a hybrid approach: they keep MPLS for mission-critical applications (voice, real-time trading, hospital systems) while offloading bulk traffic and SaaS applications to broadband via SD-WAN. Over time, as broadband reliability improves and SD-WAN optimization techniques mature, the MPLS circuits are gradually downgraded or eliminated entirely. This hybrid model — augmenting rather than replacing MPLS — is the most common SD-WAN deployment pattern today.

SASE: SD-WAN Meets Cloud Security

Secure Access Service Edge (SASE), defined by Gartner in 2019, converges SD-WAN with cloud-delivered security into a single architecture. In the SASE model, the SD-WAN edge device steers traffic not only to other branch sites and data centers but also to the nearest cloud security PoP, where traffic is inspected by a full security stack before reaching its destination.

The SASE stack typically includes:

SD-WAN — Transport abstraction, application-aware routing, WAN optimization.
Secure Web Gateway (SWG) — URL filtering, SSL inspection, malware detection for web traffic.
Cloud Access Security Broker (CASB) — Visibility and control over SaaS application usage, DLP policies, shadow IT detection.
Zero Trust Network Access (ZTNA) — Per-application access control based on user identity, device posture, and context. Replaces traditional VPN remote access.
Firewall-as-a-Service (FWaaS) — Full L4-L7 firewall inspection in the cloud, including IPS, application control, and threat prevention.

SASE represents the convergence of networking and security — a recognition that in a world where users are everywhere, applications are in the cloud, and the network perimeter has dissolved, it makes no sense to separate the WAN fabric from the security stack. Every major SD-WAN vendor now offers a SASE solution, though the depth of integration varies significantly between vendors who built security natively (Palo Alto, Fortinet) and those who partner with or acquired security capabilities (Cisco, VMware).

Limitations and Failure Modes

SD-WAN is not without limitations. Understanding its failure modes is essential for proper deployment:

Controller dependency — While the data plane continues forwarding during controller outages (using cached policy), no new configuration changes can be pushed, and new sites cannot be onboarded. A controller outage lasting hours or days effectively freezes the network's ability to adapt. Most vendors support controller redundancy (active/active or active/standby clusters), but this adds cost and complexity.
Underlay quality floor — SD-WAN can optimize around moderate link degradation, but it cannot create bandwidth or latency from nothing. If all broadband links to a branch are saturated, SD-WAN can only prioritize which applications suffer. FEC adds overhead (typically 15-30% bandwidth for meaningful error correction), consuming additional capacity on already-constrained links.
DPI limitations with encryption — As TLS 1.3, QUIC, and encrypted DNS become ubiquitous, DPI-based application identification becomes harder. SD-WAN increasingly relies on SNI (which ECH/ESNI may encrypt), IP reputation databases, and heuristic analysis rather than deep payload inspection. Some applications become opaque to the SD-WAN classifier.
Vendor lock-in — SD-WAN overlay protocols are proprietary. There is no standard for SD-WAN tunnel signaling, policy distribution, or application identification. Migrating from one SD-WAN vendor to another requires a complete forklift replacement of all edge devices and controller infrastructure. This is a stark contrast to MPLS, where standardized protocols (LDP, RSVP-TE, MP-BGP) allow multi-vendor interoperability.
Complexity in brownfield deployments — Integrating SD-WAN into an existing network with established routing protocols, VPN tunnels, and security policies is challenging. The SD-WAN overlay must coexist with existing routing without creating loops or black holes, which requires careful mutual redistribution between SD-WAN and legacy routing protocols.

SD-WAN and the Future of Enterprise WAN

SD-WAN has moved from a disruptive startup technology to a mature, consolidated market. Gartner estimated that by 2025, over 65% of enterprises would have implemented SD-WAN, up from less than 10% in 2018. The technology continues to evolve in several directions:

AI/ML-driven operations — Vendors are incorporating machine learning for predictive path selection (anticipating link degradation before it impacts traffic), automated troubleshooting, and anomaly detection. Juniper's Mist AI platform and Cisco's Predictive Analytics in Catalyst SD-WAN are examples of this trend.
Network-as-a-Service (NaaS) — Cloud-delivered SD-WAN where the entire fabric — controller, edge, and even the underlay transport — is consumed as a service. Vendors like Aryaka and Cato Networks have pioneered this model with their own global private backbones.
5G integration — 5G fixed wireless access as an SD-WAN transport, providing high-bandwidth, low-latency connectivity at branch offices without wired infrastructure. SD-WAN platforms are adding cellular bonding and 5G-aware path selection.
SSE/SASE convergence — Security Service Edge (SSE) and SD-WAN converging into unified SASE platforms where networking and security are indistinguishable, managed by a single policy engine.

The fundamental insight behind SD-WAN — that software abstraction and centralized control can transform a collection of commodity connections into an intelligent, application-aware network — parallels the same insight that drove SDN in data center networking. The enterprise WAN was one of the last bastions of traditional, box-by-box network management. SD-WAN has systematically dismantled that model, and the industry is unlikely to return to the days of managing hundreds of branch routers through CLI templates and manual MPLS provisioning.

Explore Enterprise WAN Infrastructure with BGP

SD-WAN overlays ride on top of underlay networks that are interconnected through BGP. The ISPs providing broadband, the carriers providing MPLS, and the cloud providers hosting SD-WAN gateways all participate in the global BGP routing table. Understanding the underlay is essential for troubleshooting SD-WAN performance — if the underlay path between two sites traverses congested peering points or takes a suboptimal route through distant autonomous systems, the SD-WAN overlay will inherit those problems.

Use the god.ad BGP Looking Glass to examine the AS paths, peering relationships, and route origins for the ISPs and carriers that form the underlay of enterprise SD-WAN deployments. You can look up the autonomous systems of major transit providers, cloud platforms, and SD-WAN gateway networks to understand how overlay traffic is actually routed across the internet.

AS8075 — Microsoft: Azure and Office 365, the most common SD-WAN SaaS target
AS16509 — Amazon / AWS: cloud on-ramp destination for IaaS workloads
AS15169 — Google Cloud: GCP and Google Workspace
AS36351 — SoftLayer (IBM Cloud): enterprise cloud infrastructure
AS13335 — Cloudflare: CDN and SASE gateway network