Sd Wan

---
name: sd-wan
description: "Cross-platform comparison and architecture guidance for SD-WAN technologies: overlay/underlay architecture, application-aware routing, SLA-driven path selection, ZTP, orchestration, and when to use SD-WAN vs MPLS. Use for \"SD-WAN comparison\", \"SD-WAN architecture\", \"SD-WAN selection\", \"overlay vs underlay\", \"application-aware routing\", \"SD-WAN migration\", \"MPLS replacement\", \"WAN optimization\". Do NOT use for cisco-sdwan- or fortinet-sdwan-specific configuration -- use that technology's own skill."
license: MIT
---

# SD-WAN

This skill covers all SD-WAN technologies, providing cross-platform expertise in overlay/underlay network architecture, application-aware routing, SLA-driven path selection, zero-touch provisioning, centralized orchestration, and WAN transformation strategy. Sibling technology skills provide deep implementation details.

## When to Use This Skill vs. a Technology Skill

**Use this skill when the question is cross-platform or architectural:**
- "Should we replace MPLS with SD-WAN?"
- "Compare Cisco Catalyst SD-WAN vs Fortinet SD-WAN for our branches"
- "How does application-aware routing work conceptually?"
- "Design an SD-WAN overlay architecture for 200 sites"
- "What deployment model fits hub-spoke vs full-mesh?"
- "Plan an MPLS-to-SD-WAN migration"
- "SD-WAN vs SASE -- where does each fit?"

**Route to a technology skill when the question is platform-specific:**
- "Configure AAR policies on Cisco SD-WAN" --> the `cisco-sdwan` skill
- "FortiGate ADVPN 2.0 shortcut tunnels not forming" --> the `fortinet-sdwan` skill
- "vManage 20.15 cluster upgrade procedure" --> the `cisco-sdwan` skill's `references/versions/20.15.md`
- "FortiOS 7.6 passive health checks" --> the `fortinet-sdwan` skill's `references/versions/7.6.md`

## How to Approach Tasks

1. **Classify** the request:
   - **Platform selection** -- Load `references/concepts.md` for fundamentals, then compare platforms below
   - **Architecture / Design** -- Apply overlay/underlay design principles, SLA modeling
   - **Migration** -- Identify source WAN and target SD-WAN, map feature requirements
   - **Troubleshooting** -- Identify the platform, consult the technology skill
   - **Strategy** -- MPLS vs SD-WAN vs hybrid analysis

2. **Gather context** -- Number of sites, transport types (MPLS, broadband, LTE/5G), application mix, SLA requirements, existing WAN vendor, compliance constraints, team skills

3. **Analyze** -- Apply SD-WAN-specific reasoning. Consider transport diversity, application SLAs, security integration, orchestration maturity, and operational readiness.

4. **Recommend** -- Provide guidance with trade-offs, not a single answer

5. **Qualify** -- State assumptions about site count, bandwidth, and application requirements

## SD-WAN vs MPLS vs Hybrid

### When SD-WAN Makes Sense

| Scenario | Why SD-WAN |
|---|---|
| SaaS-heavy traffic (O365, Salesforce) | Direct Internet Access (DIA) avoids backhauling to DC |
| Multiple transport types available | Aggregate broadband + LTE for cost-effective redundancy |
| Branch count > 20 with diverse WAN | Centralized orchestration simplifies management at scale |
| Application performance SLAs vary | App-aware routing steers voice/video to best path |
| Rapid branch deployment needed | ZTP eliminates per-site CLI configuration |
| MPLS costs are significant | Broadband + SD-WAN overlay often 40-60% cheaper than MPLS |

### When MPLS Still Wins

| Scenario | Why MPLS |
|---|---|
| Ultra-low-latency requirements (<10ms) | Private circuits offer guaranteed performance |
| Regulatory mandate for private transport | Some industries require private WAN (not overlay) |
| Very few sites (3-5) with stable WAN | SD-WAN orchestration overhead may not justify complexity |
| No internet breakout needed | All traffic backhauled to DC by policy |

### Hybrid Approach (Most Common)

Most enterprises adopt a hybrid model:
- **MPLS** for critical sites (DC interconnect, trading floors, manufacturing)
- **SD-WAN over broadband** for standard branches
- **SD-WAN manages both** -- MPLS becomes one transport in the overlay, not the sole WAN
- AAR steers latency-sensitive traffic to MPLS, bulk traffic to broadband

## Architecture Patterns

### Overlay / Underlay Model

All SD-WAN solutions share this fundamental architecture:

```
Underlay: Physical transports (MPLS, broadband, LTE, satellite)
    |
Overlay: IPsec/GRE tunnels between SD-WAN edge devices
    |
Orchestration: Centralized controller manages overlay topology, policy, keys
    |
Application Steering: SLA-aware path selection per application
```

**Underlay independence**: The overlay abstracts transport -- same application policy regardless of whether underlay is MPLS, cable, fiber, or cellular.

### Deployment Models

| Model | Description | Use Case |
|---|---|---|
| Hub-and-Spoke | All branch traffic routes through DC hub(s) | Security inspection at DC, centralized services |
| Regional Hub | Branches connect to nearest regional hub | Geographic distribution, regulatory data sovereignty |
| Full Mesh | Direct branch-to-branch tunnels | Latency-sensitive branch-to-branch traffic (UCaaS, VDI) |
| Dynamic Mesh | Hub-spoke base with on-demand direct tunnels | Best of both: hub-spoke simplicity + mesh performance |
| Cloud Gateway | SD-WAN edge in cloud (AWS/Azure/GCP) | Multi-cloud connectivity, cloud-first architectures |

**Dynamic mesh** (Cisco TLOC-based full mesh, Fortinet ADVPN) is the most common pattern: maintain hub-spoke for control, build direct tunnels only when spoke-to-spoke traffic warrants it.

### Zero-Touch Provisioning (ZTP)

All major SD-WAN platforms support ZTP:
1. Edge device ships to site, connects to internet
2. Device contacts cloud orchestrator (vBond/SD-WAN Validator, FortiManager cloud, etc.)
3. Authenticates via serial number / certificate
4. Downloads full configuration, firmware, policies
5. Establishes overlay tunnels automatically

**ZTP reduces per-site deployment from hours to minutes** and eliminates the need for skilled personnel at remote sites.

## Application-Aware Routing (AAR)

The defining capability of SD-WAN. AAR steers application traffic to the transport that best satisfies SLA requirements.

### How AAR Works (All Platforms)

1. **Classify** -- DPI / application signatures identify traffic (NBAR2 on Cisco, FortiGuard AppDB on Fortinet)
2. **Measure** -- Active probes (BFD, ICMP, HTTP) measure per-tunnel latency, jitter, and packet loss
3. **Compare** -- Measured metrics compared against defined SLA thresholds
4. **Steer** -- Traffic forwarded to tunnel(s) meeting SLA; fallback behavior if none qualify
5. **Re-evaluate** -- Continuous measurement; reroute if path degrades

### SLA Design Guidance

| Application Class | Latency | Jitter | Loss | Transport Preference |
|---|---|---|---|---|
| Voice (VoIP, UCaaS) | < 150ms | < 30ms | < 1% | MPLS preferred, broadband fallback |
| Video (conferencing) | < 200ms | < 50ms | < 2% | Best-quality selection |
| Critical Data (ERP, DB) | < 100ms | N/A | < 0.1% | MPLS preferred |
| Bulk Data (backup, sync) | Relaxed | Relaxed | < 5% | Lowest-cost transport |
| Internet / SaaS | < 300ms | Relaxed | < 3% | DIA (direct internet) |

## Platform Comparison

### Cisco Catalyst SD-WAN (formerly Viptela)

**Architecture**: Separate controller infrastructure (SD-WAN Manager, Controller, Validator) + WAN Edge routers (Catalyst 8000 series). OMP protocol for overlay routing.

**Strengths:**
- Mature controller architecture with clear separation of management, control, and data planes
- OMP provides BGP-like overlay route distribution with rich policy attributes (TLOC, color, preference)
- Deep Cisco IOS-XE integration -- full router feature set on WAN Edge
- Enhanced AAR (EAAR) for sub-second path switching (17.12+)
- Cloud OnRamp for SaaS, IaaS (AWS/Azure/GCP), and colocation
- Strong API (vManage REST API) for automation and integration
- UTD (Unified Threat Defense) for on-box security (ZBFW, IPS, URL filtering, AMP)
- Catalyst Center integration for campus-to-WAN policy consistency

**Considerations:**
- Requires dedicated controller infrastructure (vManage/vSmart/vBond) -- higher baseline cost
- Template framework has a learning curve (feature templates, device templates, configuration groups)
- vEdge (Viptela hardware) is end-of-life; all new deployments on Catalyst 8000 / IOS-XE
- Controller cluster (3-node minimum for HA) requires careful sizing

**Best for:** Large enterprises with Cisco-centric infrastructure, complex multi-cloud requirements, and teams experienced with IOS-XE.

### Fortinet SD-WAN

**Architecture**: SD-WAN built natively into FortiOS on FortiGate appliances. No separate controller -- FortiGate IS the SD-WAN edge AND the security device. FortiManager for orchestration, FortiAnalyzer for analytics.

**Strengths:**
- Converged NGFW + SD-WAN in a single device -- no separate security appliance needed
- ADVPN 2.0 (7.4+/7.6) provides intelligent dynamic mesh with SD-WAN-aware shortcut selection
- FortiGuard ISDB eliminates manual SaaS IP prefix management
- Five steering strategies (manual, best-quality, lowest-cost, maximize-bandwidth, minimum-SLA) cover all use cases
- Passive health checks (7.4.1+) derive SLA metrics from real traffic without probe overhead
- FortiSASE integration for cloud-delivered security
- ZTNA built into the platform (access proxy + FortiClient)
- Strong price/performance ratio, especially at branch scale

**Considerations:**
- FortiManager required for centralized orchestration at scale (not included with FortiGate)
- No dedicated control plane separation -- FortiGate handles routing, security, and SD-WAN in one process
- ADVPN 2.0 is relatively new; classic ADVPN limitations remain on older FortiOS versions
- Health check tuning requires understanding of interval/failtime/recoverytime interaction

**Best for:** Organizations wanting converged security + SD-WAN in one platform, Fortinet Security Fabric environments, cost-conscious deployments with strong security requirements.

### Decision Matrix

| Factor | Cisco Catalyst SD-WAN | Fortinet SD-WAN |
|---|---|---|
| Controller architecture | Dedicated (vManage/vSmart/vBond) | Embedded (FortiGate + FortiManager) |
| Security integration | UTD on-box or Umbrella SIG | Native NGFW (FortiOS) |
| Dynamic mesh | Full-mesh by default (TLOC-based) | ADVPN 2.0 (hub-spoke + shortcuts) |
| SaaS optimization | Cloud OnRamp for SaaS | FortiGuard ISDB |
| Multi-cloud | Cloud OnRamp for IaaS | FortiGate-VM in cloud + FortiSASE |
| Price point | Higher (controller infra + edge) | Lower (edge-only + FortiManager) |
| Operational model | Separate SD-WAN + security teams | Single team for both |
| Scale ceiling | 10,000+ edges per controller cluster | FortiManager supports thousands |

## SD-WAN Security Integration

### On-Box Security
Both platforms offer on-box security inspection at the WAN edge:
- **Cisco**: UTD (ZBFW, IPS/IDS, URL filtering, AMP, DNS security) as containerized service on IOS-XE
- **Fortinet**: Full FortiOS NGFW stack (AV, IPS, web filtering, sandboxing, ZTNA proxy)

### Cloud Security (SASE Integration)
For traffic that should be inspected in the cloud:
- **Cisco**: Umbrella SIG integration via IPsec tunnels from WAN Edge
- **Fortinet**: FortiSASE PoP integration as SD-WAN overlay member

### Design Decision
- **On-box**: Lower latency, no dependency on cloud PoP, simpler architecture
- **Cloud (SASE)**: Consistent policy for remote users + branch, scales inspection independently, better for thin branches

## Migration Strategy: MPLS to SD-WAN

### Phase 1: Parallel Deployment
1. Deploy SD-WAN edges at pilot sites (10-15% of branches)
2. Keep MPLS circuits active alongside broadband
3. Add MPLS as one SD-WAN transport member
4. Validate AAR steering and SLA compliance

### Phase 2: Expand and Optimize
1. Roll out to remaining sites using ZTP
2. Tune SLA classes based on real application performance data
3. Enable DIA for SaaS traffic at branches
4. Implement security policy (on-box or SASE)

### Phase 3: MPLS Reduction
1. Identify sites where broadband SLA matches MPLS performance
2. Downgrade MPLS circuits or convert to broadband at qualifying sites
3. Retain MPLS only at critical sites (DC, compliance-mandated)
4. Monitor for 90+ days before final MPLS decommission at each site

### Migration Anti-Patterns
1. **Big-bang cutover** -- Never migrate all sites simultaneously
2. **Removing MPLS before validating SD-WAN** -- Run parallel for at least 30 days
3. **Ignoring application inventory** -- Know your traffic before defining SLA classes
4. **Skipping security design** -- SD-WAN without security inspection is a lateral movement highway

## Technology Routing

| Request Pattern | Route To |
|---|---|
| Cisco SD-WAN, vManage, vSmart, OMP, TLOC, Catalyst 8000, AAR | the `cisco-sdwan` skill (see `references/versions/20.15.md` for version specifics) |
| Fortinet SD-WAN, FortiGate SD-WAN, ADVPN, FortiManager SD-WAN | the `fortinet-sdwan` skill (see `references/versions/7.6.md` for version specifics) |

## Reference Files

- `references/concepts.md` -- SD-WAN fundamentals: overlay/underlay architecture, application-aware routing, SLA classes, zero-touch provisioning, orchestration models. Read for "how does SD-WAN work" or cross-platform conceptual questions.