Sd Wan Engineer

SD-WAN (Software-Defined WAN) Engineer

When to Use

• Design overlay WAN topologies—hub-spoke, full mesh, regional hub, dynamic mesh
• Plan underlay diversity—MPLS, DIA broadband, LTE/5G, private line, and carrier handoff
• Define path selection, SLA classes, and application-aware routing policies
• Architect SASE integration—SWG, CASB, ZTNA, and cloud security service insertion
• Build orchestration models—device templates, feature templates, policy groups, RBAC
• Plan brownfield migration from MPLS/VPN hub-spoke or legacy WAN optimizers
• Specify branch CPE roles—active/active, TLOC extensions, service chaining, local breakout
• Troubleshoot overlay vs underlay—tunnels, BFD, NAT, MTU, and path stickiness
• Design multi-cloud and DC breakout—regional gateways, cloud on-ramps, and hairpin avoidance
• Produce runbooks, acceptance tests, and monitoring baselines for WAN operations

When NOT to Use

• Carrier core BGP/MPLS design, IX peering, or internet backbone routing only → network-backbone-architect
• Cloud landing zone, VPC design, and Well-Architected service selection → cloud-architect, enterprise-cloud-architect
• Provision cloud subnets, VPN to cloud, and managed LB without SD-WAN overlay focus → cloud-engineer
• Cloud IAM, CSPM, and org guardrails as primary deliverable → cloud-security-engineer
• Corporate security program, IdP, and endpoint controls without WAN architecture → information-security-engineer
• Terraform modules, CI/CD, and K8s delivery without SD-WAN design → infrastructure-engineer
• SLO programs, on-call, and production incident process as main task → site-reliability-engineer
• Application throughput, caching, and horizontal scale without WAN path design → high-concurrency-scalability
• REST/GraphQL and enterprise application integration → enterprise-integration-api-developer
• Physical rack, power, and cabling without SD-WAN edge role → infrastructure-engineer, field-services-engineer

Related skills

Core Workflows

1. Scope, constraints, and success criteria

Clarify sites, traffic matrix, compliance, and migration constraints.

See `references/sd_wan_engineer_scope.md`.

2. Overlay topology and underlay

Select hub roles, mesh policy, and circuit mix per site class.

See `references/overlay_topology_and_underlay.md`.

3. Path selection, SLA, and application routing

Define business policies, SLA classes, and app identification.

See `references/path_selection_sla_and_app_routing.md`.

4. Security, SASE, and service insertion

Place NGFW, SWG, ZTNA, and local vs centralized breakout.

See `references/security_sase_and_ztna_insertion.md`.

5. Orchestration, templates, and day-two operations

Model controllers, templates, change workflow, and observability.

See `references/orchestration_templates_and_operations.md`.

6. Migration, HA, and troubleshooting

Plan cutover waves, HA modes, and overlay/underlay fault isolation.

See `references/migration_ha_troubleshooting.md`.

Outputs

• WAN context — site inventory, traffic matrix, critical apps, and compliance constraints
• Logical topology — overlay roles, hub map, regional gateways, and breakout points
• Underlay map — circuits per site, diversity, carrier handoff, and IP addressing plan
• Policy catalog — SLA classes, path selection rules, and application definitions
• Security architecture — service insertion, SASE integration, and segmentation zones
• Orchestration model — template hierarchy, RBAC, and promotion workflow
• Migration plan — waves, rollback triggers, parallel-run criteria, and acceptance tests
• Operations pack — dashboards, alarms, runbooks, and escalation matrix

Principles

• Treat underlay independence as a design goal—overlay must survive single-circuit loss where required
• Prefer explicit SLA classes over opaque “best path” defaults; document stickiness and failover timers
• Minimize hairpinning—local breakout for trusted SaaS and regional gateways for cloud on-ramps
• Design brownfield with parallel run and measurable cutover gates, not big-bang unless constrained
• Separate control plane (orchestrator) resilience from data plane (edge) HA in runbooks
• Use vendor concepts generically; validate against target platform docs before production config

Migration, HA, and troubleshooting

Table of contents

1. High availability modes 2. Brownfield SD-WAN migration 3. Migration waves 4. Parallel run and cutover 5. Troubleshooting methodology 6. Common failure patterns 7. Acceptance testing 8. Post-migration operations

High availability modes

Align BFD timers with app SLA—voice may need sub-3s failover; bulk can wait longer.

Document split-brain behavior if control link lost between HA pair.

Brownfield SD-WAN migration

Typical sources:

• MPLS hub-spoke with regional DC
• DMVPN / IPsec mesh over internet
• Dual-MPLS with static routing
• WAN optimizers at branch

Brownfield SD-WAN migration principles:

1. Inventory circuits, routes, apps, and security dependencies 2. Pilot representative site class in each region 3. Parallel run MPLS + SD-WAN overlay before removing legacy 4. Migrate routing in phases—prefix advertisement, hub preference, default route 5. Decommission legacy only after soak period and rollback window closed

Avoid migrating routing and security in the same maintenance window without rollback.

Migration waves

Each wave includes: rollback trigger, owner, communication plan, success metrics.

Parallel run and cutover

Cutover checklist:

• [ ] All TLOCs green; certs valid
• [ ] App catalog routes verified
• [ ] Security logs flowing to SIEM
• [ ] NMS maps updated
• [ ] Carrier change requests submitted (if replacing handoff)

Troubleshooting methodology

Use overlay vs underlay isolation first:

User report (slow / down)
    │
    ├─ LAN OK? ──no──► LAN/Wi-Fi team
    │
    ├─ Underlay up? (per TLOC, circuit util, errors)
    │       └─no──► carrier / physical
    │
    ├─ Overlay tunnel up? (control, BFD, cert)
    │       └─no──► orchestrator, cert, MTU, NAT
    │
    ├─ Policy / SLA match expected path?
    │       └─no──► app ID, policy group, hub role
    │
    └─ Security service drop? (FW, SWG, ZTNA)
            └─yes──► security policy / SASE PoP

Collect: timestamp, site, app, source/dest, underlay colors tried, SLA stats, recent template push.

Common failure patterns

VeloCloud / Viptela / Prisma SD-WAN each expose different UI labels—map diagnostics to generic steps above.

Acceptance testing

Store results per wave for audit.

Post-migration operations

• Soak 2–4 weeks before MPLS disconnect
• Rebaseline dashboards and alarm thresholds
• Update DR runbooks and circuit inventory
• Train NOC on overlay vs underlay views
• Review cost vs performance (broadband vs MPLS commit)

Backbone or DCI changes after SD-WAN stable → network-backbone-architect.

Orchestration, templates, and operations

Table of contents

1. Control plane architecture 2. Template hierarchy 3. Device lifecycle 4. Policy promotion workflow 5. RBAC and tenancy 6. Monitoring and observability 7. Multi-cloud and DC breakout operations 8. Day-two runbooks

Control plane architecture

Control plane outage does not always stop forwarding—document last-known-good behavior and stale policy risk.

Template hierarchy

Use layered templates to scale branch connectivity:

Golden templates per site class; exceptions via attach variables (hostname, circuit IDs, hub preference).

Avoid one-off CLI on edges—drift breaks orchestration model.

Device lifecycle

Zero-touch provisioning requires DHCP/DNS options or redirect to onboarding server—document per vendor (Viptela ZTP, VeloCloud activation, etc.).

Policy promotion workflow

Dev policy group → lab edges → validation
      ↓
Staging / pilot site class (1–2 weeks)
      ↓
Production rollout by region (change ticket)
      ↓
Post-change verification (dashboards + synthetic apps)

• Version templates; export JSON/XML for audit
• Use read-only analyst role for NOC
• Rollback = reattach previous policy group version, not manual box fixes

RBAC and tenancy

Separate prod vs lab orchestrator tenants where possible.

Monitoring and observability

Monitor overlay and underlay separately:

Export to SNMP, syslog, IPFIX/NetFlow, telemetry (gRPC)—align with enterprise NMS/SIEM.

Dashboards per site class:

• Top sites by loss or jitter
• Underlay utilization vs commit
• Policy change timeline
• Certificate expiry horizon

For production SLO alignment → site-reliability-engineer.

Multi-cloud and DC breakout operations

Avoid asymmetric routing between cloud and on-prem—document preferred paths for IaaS RFC1918 prefixes.

Day-two runbooks

Minimum runbook set:

1. Site hard down — underlay vs overlay triage tree 2. Degraded performance — SLA class stats, path stickiness reset 3. Certificate expiry — renewal and staggered redeploy 4. Controller upgrade — maintenance checklist 5. Quarantine site — security incident isolation template 6. Mass template push failure — rollback and partial attach recovery

Pair with carrier escalation matrix (circuit ID, NOC number).

Overlay topology and underlay

Table of contents

1. Overlay vs underlay 2. Topology patterns 3. Hub roles and regional design 4. Underlay types 5. Circuit diversity and carrier handoff 6. Addressing and NAT considerations 7. CPE and TLOC concepts 8. Design checklist

Overlay vs underlay

SD-WAN abstracts underlay so policy applies uniformly; still design underlay independently—overlay cannot fix a single-path site if SLA requires diversity.

Topology patterns

Hub-spoke SD-WAN remains common for centralized NGFW/SWG. Add regional hubs when RTT to a single super-hub exceeds app tolerance.

Hub roles and regional design

Define explicit roles:

• Super-hub / DC hub — data center aggregation, cloud on-ramp, corp apps
• Regional hub — inspection and breakout for a geography
• Transit hub — optional MPLS internet handoff or partner interconnect

Rules of thumb:

• Place voice/video gateways near users or use local breakout to UCaaS PoPs
• Align cloud on-ramp with provider region (e.g., AWS Direct Connect location)
• Limit policy fan-out—fewer hub tiers reduce asymmetric routing bugs

Underlay types

Underlay overlay independence: each transport interface is a TLOC (transport location) bound to a circuit; overlay builds across TLOCs.

Circuit diversity and carrier handoff

Carrier handoff documentation per site:

• Handoff type (RJ45, fiber, NNIs)
• Provider VLAN/C-tag, bandwidth, burst
• Support contacts and circuit IDs
• Demarc and smart-hands escalation (field-services-engineer for physical work)

Addressing and NAT considerations

• Use private addressing consistently; avoid overlapping site LANs without NAT policy
• Document NAT modes on internet underlays (static 1:1 vs PAT) for inbound services
• Set MTU/MSS end-to-end—IPsec overhead often requires MSS clamp (1400–1420 common)
• IPv6 dual-stack: confirm overlay and security services support v6 paths if required

CPE and TLOC concepts

Vendor-agnostic patterns (Cisco Viptela, VeloCloud, Fortinet, Prisma SD-WAN):

Branch connectivity templates should declare: number of TLOCs, expected colors, hub preference, and local LAN segments (VRFs/services).

Design checklist

• [ ] Site class assigned; topology role (spoke, mesh node, hub) documented
• [ ] Minimum two underlays for HA sites; LTE backup defined for small sites
• [ ] No unintended hairpin (SaaS, branch-branch) without policy intent
• [ ] Hub scale validated (tunnel count, throughput, security throughput)
• [ ] MTU tested on each underlay path; MSS clamp configured
• [ ] Carrier handoff and diversity recorded per site
• [ ] Overlap with network-backbone-architect for MPLS VPN design at provider edge

Path selection, SLA, and application routing

Table of contents

1. Policy model 2. SLA classes 3. Path selection mechanics 4. Application-aware routing 5. DPI and identification caveats 6. WAN optimization concepts 7. QoS and DSCP 8. Testing and validation

Policy model

SD-WAN policy typically stacks:

1. Centralized business policy — who talks to whom (topology), default action 2. SLA / performance policy — which underlays satisfy latency, loss, jitter 3. Application policy — match apps to SLA classes and breakout 4. Security policy — firewall, IPS, URL filtering (often paired with SASE)

Keep policies composable: site overrides only where justified; document exceptions.

SLA classes

Define a small set of SLA classes (3–6) rather than per-app tunnels:

Per class, specify:

• Measurement interval and probe type (BFD, IP SLA, synthetic HTTP)
• Failover threshold (e.g., loss > 2% for 3 intervals)
• Stickiness duration (avoid flapping)
• Backup order when primary underlay fails

Path selection should be deterministic for operations—avoid opaque “AI routing” without exported logic.

Path selection mechanics

Document asymmetric paths (different forward/return underlay) when allowed and when blocked.

Application-aware routing

Application-aware routing maps identified traffic to SLA classes and breakout:

Build an application catalog:

DPI and identification caveats

• Encrypted traffic (TLS 1.3, QUIC) reduces DPI fidelity—prefer domain/SaaS lists and endpoint agents where required
• Split tunnel vs full tunnel changes what CPE inspects
• DNS misconfiguration causes wrong breakout (internal resolver vs public)
• Custom ports need explicit rules—do not rely on default web classification

WAN optimization concepts

WAN optimization in SD-WAN context may include:

• TCP optimization (window scaling, retransmission handling)—verify benefit on modern high-BW links
• Deduplication / compression—often retired for encrypted SaaS; still relevant for replication to DC
• Protocol-specific proxies (CIFS, etc.)—legacy; prefer app modernization

When user mentions WAN optimization, clarify whether they mean:

1. Legacy WAN accel appliances → migration to app-aware routing + adequate bandwidth 2. SD-WAN performance features (FEC, packet duplication for lossy links) 3. SaaS acceleration via SASE PoP proximity

QoS and DSCP

If provider does not honor DSCP on broadband, do not assume end-to-end QoS—use path selection instead.

Testing and validation

Record baseline overlay vs underlay metrics before production cutover.

SD-WAN engineer scope

Table of contents

1. Role boundary 2. Intake checklist 3. Traffic matrix and site classes 4. Non-functional requirements 5. Compliance and data residency 6. Deliverables 7. Handoffs

Role boundary

The SD-WAN engineer owns overlay WAN design and operations: how branches and data centers connect over diverse underlays with centralized policy, application-aware forwarding, and integrated security services.

Intake checklist

Capture before topology or policy design:

Traffic matrix and site classes

Build a traffic matrix (source → destination → app → volume/latency sensitivity):

Define site classes with default templates:

• DC / regional hub — high bandwidth, dual underlay, security stack, cloud on-ramp
• Large branch — dual underlay, local breakout optional, guest segmentation
• Small branch — LTE backup, simplified policy, zero-touch provisioning
• Temporary / IoT — minimal overlay, strict segmentation, no lateral paths

Non-functional requirements

Document measurable targets per site class:

Compliance and data residency

• Identify data residency requirements (traffic must not transit specific countries)
• Map inspection points (centralized vs local) to regulatory allow/deny lists
• Document logging retention for security and WAN telemetry (PII in flow records)
• Align with zero trust posture—identity before app access, not VPN trust alone

Deliverables

Handoffs

Security, SASE, and ZTNA insertion

Table of contents

1. Security services on SD-WAN 2. Traffic breakout models 3. SASE architecture 4. Zero trust WAN 5. ZTNA insertion 6. Segmentation and zones 7. Vendor concept mapping 8. Operations and compliance

Security services on SD-WAN

Common security services chained at edge or hub:

SD-WAN service chaining forwards selected flows through a service node (on-box or at hub) before egress.

Traffic breakout models

Zero trust WAN reduces implicit trust in MPLS; combine identity-based access with least-privilege segmentation instead of flat VPN.

SASE architecture

SASE (Secure Access Service Edge) converges WAN edge + security stack in cloud-delivered PoPs:

Branch CPE ──overlay──► SASE PoP ──► Internet / SaaS / DC connector
              │              │
              │              ├── SWG, CASB, FWaaS
              │              └── ZTNA broker
              └── optional regional hub for private apps

Design decisions:

• PoP selection — latency to users vs data residency
• Connector placement — DC connector for private apps; HA pairs
• Policy single pane — align SD-WAN templates with SASE policy lifecycle
• Logging — flow and security logs to SIEM (information-security-engineer)

This skill covers architecture-level SASE integration, not full corp GRC program.

Zero trust WAN

Principles for zero trust WAN with SD-WAN:

1. No flat VPN trust — segment by app and identity 2. Explicit verification — device posture, user identity, app entitlement 3. Micro-segmentation — VRFs, zones, or service VLANs at branch 4. Continuous monitoring — anomaly on flows and DNS

Map legacy trusted MPLS apps to ZTNA or private access connectors during migration.

ZTNA insertion

ZTNA insertion patterns:

Coordinate with DNS (split horizon), certificate pinning, and private app publishing.

Do not conflate ZTNA with site-to-site mesh—site connectivity remains SD-WAN; user-to-app is ZTNA.

Segmentation and zones

Document east-west rules at branch (branch-server to branch-printer) vs north-south (branch to internet/DC).

Vendor concept mapping

Conceptual mapping only—not configuration guides:

Validate feature parity (TLS inspect, IPv6, multicast) per release notes.

Operations and compliance

• Change control for security policy tied to WAN templates
• Key management for certificates on CPE and PoPs
• Data residency for inspected traffic in SASE PoPs
• Incident response — isolate site (quarantine template) vs kill switch on breakout

Cloud-side controls for breakout targets → cloud-security-engineer.