SD-WAN Overview
1. What Is SD-WAN and Why Was It Created?
SD-WAN (Software-Defined Wide Area Networking) is a technology approach that applies software-defined networking (SDN) principles to the enterprise WAN. It decouples the WAN's control plane (routing decisions, policy, management) from the data plane (packet forwarding), centralising intelligence in a software controller while allowing edge devices to forward traffic over any available transport — MPLS, broadband internet, LTE/5G, or satellite — simultaneously.
SD-WAN emerged as a direct response to the limitations of traditional MPLS-centric WAN architectures in a world where cloud computing, SaaS applications, and mobile workforces have fundamentally changed where enterprise traffic goes. In the early 2000s, most enterprise traffic stayed inside the corporate network — MPLS was ideal. By the mid-2010s, 60–80% of enterprise traffic was destined for the internet and cloud, yet WAN architecture still forced all branch traffic through the corporate data centre before reaching the internet — adding latency, consuming expensive MPLS bandwidth, and creating a bottleneck.
| Problem with Traditional WAN | SD-WAN Solution |
|---|---|
| High MPLS cost for growing bandwidth needs | Use cheap broadband internet alongside (or replacing) MPLS; significant cost reduction |
| All traffic backhauled through HQ before reaching cloud/internet | Direct cloud breakout from branches — SaaS traffic goes directly to the internet from the branch |
| Manual per-device CLI configuration for each branch router | Centralised policy management via GUI/API; zero-touch provisioning for new branches |
| Static routing decisions — no awareness of real-time link quality | Application-aware routing with real-time path selection based on measured latency, jitter, and loss |
| Internet transport is insecure — no native encryption | Built-in IPsec encryption on all overlay tunnels, regardless of transport |
| Weeks to provision a new branch circuit | Zero-touch provisioning — a new branch can join the fabric in hours, not weeks |
| Single-vendor, single-transport lock-in | Transport-agnostic — mix any combination of transports and switch providers freely |
Related pages: WAN Technologies Overview | WAN Overview | MPLS | DMVPN | IPsec VPN | GRE Tunnels | Controller-Based Networking | Northbound & Southbound APIs | QoS Overview | OSPF Overview | BGP Overview | Ansible Overview | Cisco SD-WAN / Viptela Lab
2. Traditional WAN vs SD-WAN — Side by Side
Understanding the limitations of traditional WAN architecture is the key to appreciating what SD-WAN changes. The comparison below covers the most important dimensions.
| Dimension | Traditional WAN (MPLS-centric) | SD-WAN |
|---|---|---|
| Transport | Single provider MPLS circuit per site | Any transport: MPLS + internet + LTE simultaneously |
| Control plane | Distributed — each router runs its own routing protocol (OSPF, BGP) independently | Centralised — SD-WAN controller (vSmart) distributes policy to all edge devices |
| Configuration | Per-device CLI configuration — every router configured individually | Centralised GUI/API (vManage) — policies defined once, pushed to all devices |
| New branch provisioning | Weeks — MPLS circuit order, physical installation, manual CLI configuration | Hours — zero-touch provisioning; device connects and auto-downloads configuration |
| Internet/cloud access | Branch traffic backhauled through HQ (data centre) then out to internet — adds 30–100+ ms latency to cloud apps | Direct cloud breakout — branch sends SaaS/internet traffic directly to internet; HQ traffic stays on MPLS/SD-WAN fabric |
| Path selection | Static or protocol-based (OSPF metric, BGP) — no real-time awareness of jitter or loss | Real-time per-path measurement (BFD) — routes traffic based on measured latency, jitter, loss per application |
| Security | MPLS is logically private but unencrypted; internet requires separate IPsec VPN infrastructure | Built-in IPsec on all paths — internet and MPLS both encrypted in the overlay; integrated next-gen firewall available on some platforms |
| Visibility | Limited — per-device logs and SNMP polling; no application-level visibility | Centralised application-level telemetry — see which apps use which paths in real time |
| Cost | High MPLS circuit costs; expensive to scale bandwidth | Lower — cheap broadband for bulk traffic; MPLS only where QoS SLA is needed |
Traditional WAN — cloud traffic backhaul problem:
[Branch 1]──MPLS──────────────────────[HQ Data Centre]──Internet──►[Office 365]
[Branch 2]──MPLS──────────────────────[HQ Data Centre]──Internet──►[Salesforce]
[Branch 3]──MPLS──────────────────────[HQ Data Centre]──Internet──►[AWS]
ALL internet/cloud traffic flows through HQ regardless of destination.
Branch in Dubai → Salesforce in UAE: goes Dubai→London HQ→Salesforce UAE
Result: high latency, wasted MPLS bandwidth, HQ internet pipe bottleneck.
SD-WAN — direct cloud breakout:
[Branch 1]──MPLS (voice only)──────────────────►[HQ]
└──Internet (broadband)──────────────►[Office 365 directly]
[Branch 2]──Internet (broadband)────────────────►[Salesforce directly]
└──LTE (backup)
[Branch 3]──MPLS (voice) + Internet (data)───────►[HQ + AWS directly]
Each branch sends cloud traffic directly to internet.
MPLS bandwidth freed up for voice and business-critical apps.
3. Overlay and Underlay — The Core Concept
The single most important conceptual distinction in SD-WAN is the separation between underlay and overlay networks. Understanding this split explains how SD-WAN achieves transport-independence.
3.1 Underlay — The Physical Transport
The underlay is the physical or logical network that provides raw IP connectivity between SD-WAN edge devices. The underlay can be any combination of transport technologies — MPLS, broadband internet, LTE/5G, satellite, or Metro Ethernet. SD-WAN does not care what the underlay is; it uses whatever is available to build the overlay.
Underlay — provides basic IP reachability between edge devices:
[vEdge Branch A]──[MPLS circuit]──────────────────►[vEdge HQ]
[vEdge Branch A]──[Internet broadband]────────────►[vEdge HQ]
[vEdge Branch A]──[LTE cellular link]─────────────►[vEdge HQ]
▲ ▲ ▲
WAN interface 1 WAN interface 2 WAN interface 3
(MPLS) (internet) (LTE)
The underlay is just dumb IP transport — the vEdge device
uses all three simultaneously to build the overlay.
3.2 Overlay — The SD-WAN Fabric
The overlay is a virtual network of IPsec-encrypted tunnels that SD-WAN edge devices (vEdge / cEdge) build on top of all available underlay transports. The overlay creates a full-mesh (or hub-and-spoke) logical topology of encrypted tunnels between all sites — regardless of which underlay each tunnel uses. Applications and routing policies operate on the overlay; the underlay is invisible to them.
Overlay — IPsec tunnels on top of the underlay:
[vEdge Branch A] ═══IPsec over MPLS══════════════ [vEdge HQ]
[vEdge Branch A] ═══IPsec over Internet══════════ [vEdge HQ]
[vEdge Branch A] ═══IPsec over LTE═══════════════ [vEdge HQ]
[vEdge Branch A] ═══IPsec over Internet══════════ [vEdge Branch B]
(direct spoke-to-spoke tunnel — no backhaul through HQ)
OMP (Overlay Management Protocol):
→ SD-WAN's own routing protocol for the overlay
→ Runs between vEdge devices and vSmart controller
→ Distributes routes, policies, and keys across the fabric
→ Replaces BGP/OSPF for SD-WAN fabric routing decisions
BFD (Bidirectional Forwarding Detection):
→ Runs between every pair of vEdge devices on every tunnel
→ Measures latency, jitter, and loss on each path in real time
→ Reports metrics to vSmart → used for application-aware routing
| Concept | Underlay | Overlay |
|---|---|---|
| What it is | Physical/logical transport infrastructure | Virtual encrypted tunnel network built on top |
| Examples | MPLS, internet DSL, LTE, satellite | IPsec tunnels, OMP routes, BFD sessions |
| Who sees it | vEdge device — uses underlay for tunnel endpoints | Applications, policies, routing — operate on overlay |
| Routing | Standard IP routing (BGP, OSPF, static) to reach far-end vEdge IPs | OMP distributes overlay routes; application policies steer traffic |
| Security | May be unencrypted (internet) or logically private (MPLS) | Always encrypted — all overlay tunnels use IPsec |
4. Cisco SD-WAN / Viptela Architecture
Cisco's SD-WAN solution is based on technology acquired from Viptela in 2017. It uses a set of clearly defined components — each with a distinct role — that together form the complete SD-WAN fabric. Understanding these components and their interactions is essential for the CCNA and CCNP Enterprise exams.
Cisco SD-WAN / Viptela full architecture:
┌────────────────────────────────────────────────────────────────────┐
│ MANAGEMENT PLANE │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ vManage — Centralised NMS / Orchestration GUI │ │
│ │ • Web dashboard and REST API │ │
│ │ • Policy definition and deployment │ │
│ │ • Monitoring, telemetry, alerts │ │
│ │ • Device onboarding and software upgrades │ │
│ └──────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────┘
│ HTTPS / NETCONF │ HTTPS / NETCONF
▼ ▼
┌──────────────────────┐ ┌────────────────────────────────┐
│ CONTROL PLANE │ │ ORCHESTRATION PLANE │
│ vSmart Controller │ │ vBond Orchestrator │
│ • Runs OMP │ │ • First point of contact for │
│ • Distributes routes│◄──OMP──►│ new vEdge devices │
│ and policies to │ │ • Authenticates devices │
│ all vEdge devices │ │ • Tells devices where to find │
│ • Makes centralised │ │ vSmart (NAT traversal) │
│ path decisions │ │ • Public-facing; must be │
└──────────────────────┘ │ reachable from internet │
│ OMP (TLS) └────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────┐
│ DATA PLANE │
│ vEdge / cEdge Routers — at every branch, DC, and HQ site │
│ • Builds IPsec tunnels to all other vEdge devices (overlay) │
│ • Forwards packets based on policies from vSmart │
│ • Runs BFD on every tunnel to measure path quality │
│ • Enforces application-aware routing, QoS, security │
│ • Provides local WAN, LAN, and optionally firewall functions │
└────────────────────────────────────────────────────────────────────┘
5. The Four SD-WAN Planes and Their Components
5.1 vManage — Management Plane
vManage is the centralised network management system (NMS) and orchestration platform for the entire SD-WAN fabric. It is the single pane of glass through which administrators define policies, monitor the network, and manage all devices. All configuration and policy changes flow from vManage to the rest of the fabric.
| vManage Function | Description |
|---|---|
| Centralised GUI dashboard | Web-based interface showing real-time topology, device health, tunnel status, and application performance across all sites |
| REST API | Northbound API for integration with ITSM tools (ServiceNow), automation platforms, and custom scripts (Python, Ansible) |
| Policy definition | Centralised point for all data plane policies — QoS, application routing, security, AAR (Application-Aware Routing) rules |
| Device templates | Configuration templates pushed to vEdge/cEdge devices; separates device-specific variables from policy structure |
| Software upgrades | Centralised IOS XE / vEdge software image management across all WAN edge devices |
| Telemetry and alerts | Real-time streaming telemetry from all vEdge devices; configurable alerts for link failures, SLA violations, security events |
5.2 vSmart — Control Plane
vSmart is the centralised control plane controller. It runs OMP (Overlay Management Protocol) — the SD-WAN fabric's own routing protocol — communicating with all vEdge devices over TLS-secured connections. vSmart is responsible for distributing routes, keys, and policies to every edge device, making the path-selection intelligence centralised rather than distributed.
vSmart control plane role: vEdge Branch A ──OMP/TLS──► vSmart ──OMP/TLS──► vEdge Branch B vEdge Branch C ──OMP/TLS──► vSmart ──OMP/TLS──► vEdge HQ vSmart receives OMP route advertisements from all vEdge devices. vSmart applies centralised policy (e.g., "VOIP goes via MPLS path") vSmart re-advertises modified routes with policy applied to all vEdges. vEdge devices forward packets based on what vSmart tells them. vSmart does NOT sit in the data path — it only controls policy. If vSmart goes down, existing forwarding continues based on last- known state; new policy changes cannot be applied until vSmart recovers (similar to SDN controller failure behaviour).
5.3 vBond — Orchestration Plane
vBond is the orchestrator — the first component a new SD-WAN edge device contacts when it boots for the first time. vBond authenticates the device's certificate, discovers its public IP address (important for NAT traversal), and tells it the IP addresses of the vSmart controllers to connect to. Once initial orchestration is complete, vBond is no longer in the regular data or control path.
vBond new device onboarding flow: New vEdge device powers on at branch: Step 1: vEdge contacts vBond (pre-configured vBond IP or via DNS) Step 2: vBond authenticates vEdge certificate (validates against CA) Step 3: vBond discovers vEdge's public IP (behind NAT) Step 4: vBond provides list of vSmart controller IPs to vEdge Step 5: vEdge connects to vSmart via OMP Step 6: vEdge connects to vManage for configuration templates Step 7: vEdge builds IPsec overlay tunnels to other vEdge devices vBond must be publicly reachable from the internet (or via STUN/NAT traversal) because new branch devices may be behind NAT and cannot predict their own public IP. vBond = "phone book" — tells new devices where everything is.
5.4 vEdge / cEdge — Data Plane
vEdge routers are Viptela's original purpose-built hardware and virtual SD-WAN edge devices. cEdge routers are Cisco IOS XE-based routers (e.g., ISR 4000, ASR 1000, CSR 1000v) running the Cisco SD-WAN software. Both perform the same data plane functions. All user traffic flows through these devices.
| vEdge / cEdge Function | Description |
|---|---|
| IPsec tunnel termination | Builds and maintains encrypted IPsec tunnels to all other SD-WAN edge devices across all available transports |
| BFD path monitoring | Sends BFD hello packets every second on each tunnel to measure latency, jitter, and packet loss in real time |
| OMP participation | Peers with vSmart over OMP; advertises local prefixes; receives overlay routes and policies |
| Application-aware routing | Classifies application traffic using DPI; applies policy to forward each application on the best-performing path based on BFD-measured metrics |
| LAN connectivity | Connects to local LAN switches/VLANs; can run OSPF or BGP with LAN-side routers for local route distribution |
| Security enforcement | Can enforce application-level firewall, URL filtering, IPS (on advanced platforms); segment traffic using VPNs |
6. OMP — Overlay Management Protocol
OMP (Overlay Management Protocol) is the SD-WAN fabric's proprietary routing and signalling protocol that replaces BGP/OSPF for the overlay network. OMP runs between vEdge devices and vSmart controllers over TLS-secured TCP connections. It carries three types of information: routes, TLOCs, and policies.
| OMP Information Type | What It Carries | Purpose |
|---|---|---|
| OMP Routes | Prefixes reachable via the overlay (analogous to BGP NLRIs — Network Layer Reachability Information) | Tells all vEdge devices what subnets are reachable at each site, and via which TLOC |
| TLOCs (Transport Locators) |
Identifies each tunnel endpoint: System IP + Colour (transport type) + Encapsulation (IPsec/GRE) | Each vEdge can have multiple TLOCs (one per WAN interface); vSmart uses TLOCs to build the overlay topology |
| Service Routes | Information about services available at a site (firewall, IPS, load balancer) | Allows traffic to be steered to security service nodes in a service-chaining topology |
TLOC — Transport Locator — the SD-WAN tunnel endpoint identifier: TLOC = (System IP) + (Color) + (Encapsulation) Example: vEdge at Branch A has three WAN links: TLOC 1: 10.0.0.1 + mpls + ipsec (MPLS circuit) TLOC 2: 10.0.0.1 + biz-int + ipsec (Business internet) TLOC 3: 10.0.0.1 + lte + ipsec (LTE cellular) Colors are predefined labels (mpls, biz-internet, public-internet, lte, metro-ethernet, etc.) that identify the transport type. Colors allow policies to distinguish between transports: "Send VoIP only over the mpls-colored TLOC" "Send bulk data over biz-internet or lte TLOCs" vSmart distributes TLOC information to all vEdge devices so each device knows the tunnel endpoints (public IPs) for every remote site across all transport types.
7. Application-Aware Routing (AAR)
Application-Aware Routing (AAR) is one of SD-WAN's most compelling capabilities. Instead of routing traffic based purely on destination IP prefix (as traditional routing protocols do), AAR routes traffic based on application identity and real-time measured path quality — choosing the best transport for each application dynamically, and switching paths automatically when quality degrades.
How Application-Aware Routing works: Step 1 — Classify traffic: vEdge uses Deep Packet Inspection (DPI) / NBAR to identify applications. Microsoft Teams RTP audio → classified as "ms-teams-audio" Salesforce HTTPS → classified as "salesforce" Windows Update download → classified as "ms-windows-update" Unknown bulk TCP → classified as "default" Step 2 — Define SLA thresholds per application class: VoIP / video: latency ≤ 150 ms, jitter ≤ 30 ms, loss ≤ 1% (see QoS Marking for DSCP classes) Business apps: latency ≤ 300 ms, loss ≤ 2% Bulk data: no SLA threshold Step 3 — Measure real-time path quality using BFD: MPLS path: latency 12 ms, jitter 2 ms, loss 0% ✔ (excellent) Internet path: latency 45 ms, jitter 8 ms, loss 0% ✔ (acceptable) LTE path: latency 80 ms, jitter 25 ms, loss 1% ✔ (marginal) Step 4 — Apply AAR policy: Teams audio → MPLS path (lowest latency and jitter) Salesforce → Internet path (meets SLA, cheaper than MPLS) Win Update → LTE or Internet (no SLA, cheapest available) Step 5 — Path degrades automatically: MPLS packet loss spikes to 3% (exceeds VoIP SLA threshold) → vEdge detects via BFD within seconds → Automatically migrates Teams audio to Internet path → No manual intervention required
AAR Configuration Concepts
| AAR Component | Description |
|---|---|
| SLA Class | Defines acceptable thresholds for latency, jitter, and packet loss. Named policy objects (e.g., "VOIP-SLA", "BUSINESS-SLA") referenced in data policies |
| Data Policy | Defines which traffic matches which SLA class and which TLOCs (transports) to prefer. Configured in vManage and distributed by vSmart to relevant vEdge devices |
| BFD measurement | BFD sends probe packets on each tunnel every 1 second (configurable). Rolling average of loss/latency/jitter is maintained per tunnel per color |
| Fallback behavior | If no path meets the SLA threshold, configurable fallback: use best available path, drop traffic, or use a backup transport |
8. Zero-Touch Provisioning (ZTP)
Zero-Touch Provisioning (ZTP) is the SD-WAN feature that allows a new branch router to join the fabric and receive its full configuration automatically — without any engineer needing to physically touch or pre-configure the device. An IT administrator ships a factory-fresh vEdge or cEdge device to the branch; a local non-technical user plugs it in and connects the WAN cables. The device does the rest.
Zero-Touch Provisioning flow:
Day 0: Factory-fresh vEdge device ships to Branch location.
IT admin pre-provisions the device in vManage (serial number,
template assignment) before it is even unboxed.
Day 1: Branch user unboxes device, connects WAN cable(s) and LAN switch.
Powers on.
Automatic process:
Step 1: Device reads pre-loaded vBond IP (from factory or USB)
Step 2: Device connects to vBond over internet
Step 3: vBond validates device certificate (against root CA)
Step 4: vBond provides vSmart IP addresses
Step 5: Device connects to vSmart via OMP/TLS
Step 6: Device connects to vManage
Step 7: vManage pushes device template (interface config, routing,
QoS, security policies)
Step 8: Device builds IPsec tunnels to all other SD-WAN edge devices
Step 9: Branch is live — typically completes in 15–30 minutes
No CLI access required. No engineer truck roll. No manual config.
The branch user only needed to plug in cables and power.
9. SD-WAN Security — Built-In vs Bolted-On
Security in SD-WAN is fundamentally different from traditional WAN. Rather than relying on a separate VPN concentrator or firewall to secure internet traffic, SD-WAN builds security into the fabric at every layer.
9.1 Overlay Encryption
All SD-WAN overlay tunnels use IPsec with AES-256-GCM encryption by default. Every packet traversing the overlay — even over MPLS — is encrypted and authenticated. Keys are automatically distributed and rotated by vSmart via OMP. No manual IKE configuration is required on edge devices.
SD-WAN encryption — automatic key management: vSmart distributes encryption keys to vEdge devices via OMP. vEdge A and vEdge B receive each other's public keys automatically. IPsec SA (Security Association) is established between the two devices. Key rotation: vSmart re-keys tunnels automatically (configurable interval, typically 1-24 hours) — no manual rekeying required. This means even MPLS tunnels in the overlay are encrypted — traffic is protected even from the MPLS provider.
9.2 Authentication and PKI
Every SD-WAN device (vEdge, cEdge, vSmart, vBond, vManage) has a unique certificate signed by a trusted Certificate Authority. All control-plane connections (OMP between vEdge and vSmart) use TLS with mutual certificate authentication — no device can join the fabric without a valid certificate. This prevents rogue devices from inserting themselves into the fabric.
9.3 Security Services on the Edge
Advanced SD-WAN platforms integrate security functions directly into the WAN edge device, eliminating the need for separate security appliances at each branch:
| Security Function | Description |
|---|---|
| Zone-Based Firewall | Stateful inspection between LAN segments and internet breakout traffic — same ZBF concepts as Cisco IOS Zone-Based Firewall |
| URL Filtering | Blocks or monitors web access by URL category — malware, gambling, social media — without backhauling to HQ proxy |
| IPS / IDS | Intrusion Prevention / Detection System integrated into the cEdge — inspects traffic for known threats without a separate security appliance |
| DNS Security | Integration with Cisco Umbrella — blocks malicious domains at DNS resolution time before the connection is even established |
| Segmentation (VPNs) | SD-WAN uses separate VPN segments (not the same as IPsec VPN — these are traffic segmentation groups) to isolate guest, corporate, and IoT traffic end-to-end across the fabric |
10. SD-WAN Design Patterns and Use Cases
10.1 Hub-and-Spoke vs Full Mesh
Hub-and-Spoke SD-WAN:
All branch-to-branch traffic flows through a hub site (HQ or DC).
Simpler to manage; hub has full visibility and security control.
Traffic path: Branch A → HQ → Branch B.
Drawback: HQ adds latency; HQ bandwidth becomes a bottleneck.
Full-Mesh SD-WAN:
Every site has direct IPsec tunnels to every other site.
Traffic path: Branch A → Branch B directly.
Lower latency; no HQ bottleneck.
Drawback: More tunnels = more state; complex at very large scale.
Regional Hub SD-WAN (most common enterprise design):
Branches in each region connect to a regional hub.
Regional hubs connect to each other and to the DC.
Balances scalability with performance.
[Branch A]──┐ ┌──[Branch D]
[Branch B]──┤──[Regional Hub EMEA]────[Regional Hub APAC]──┤──[Branch E]
[Branch C]──┘ │ └──[Branch F]
[HQ / DC]
10.2 Common SD-WAN Use Cases
| Use Case | SD-WAN Capability Used |
|---|---|
| Replace or augment expensive MPLS | Use cheap internet broadband for bulk traffic; retain MPLS only for voice and latency-critical applications; AAR steers traffic appropriately |
| Direct cloud access from branches | Direct internet breakout at branch with URL filtering and DNS security; Office 365, Salesforce, AWS reach directly without HQ backhaul |
| WAN resilience and failover | Multiple transports per site; BFD detects path degradation in <1 second; AAR automatically reroutes before users notice |
| Rapid branch deployment | Zero-Touch Provisioning; new branches live in minutes; no on-site engineer required |
| Consistent security policy across all sites | Centralised security policies in vManage; same firewall, URL filter, and IPS rules enforced at every site automatically |
| Visibility and troubleshooting | vManage real-time telemetry; application-level flow visibility; identifies which path each application uses and its quality metrics |
10.3 SD-WAN vs DMVPN — Key Differences
| Feature | DMVPN | SD-WAN |
|---|---|---|
| Control plane | Distributed (EIGRP/OSPF/BGP over mGRE tunnels) | Centralised (vSmart + OMP) |
| Management | Per-device CLI (or Cisco DNA Center for some) | Fully centralised vManage GUI/API |
| Multi-transport | One tunnel per transport; manual failover policy | Automatic multi-transport with real-time BFD steering |
| Application awareness | Limited — routing based on prefix, not app identity | Full DPI / NBAR application classification and AAR |
| Zero-touch provisioning | Manual spoke config required | Full ZTP — factory-new device joins automatically |
| Cloud integration | Manual configuration for cloud breakout | Native direct cloud breakout; cloud gateway integrations |
See also: WAN Technologies Overview | MPLS | DMVPN | IPsec VPN | GRE Tunnels | Controller-Based Networking | Northbound & Southbound APIs | Cisco SD-WAN / Viptela Lab | DMVPN Phases Lab