Enterprise SD-WAN design, migration, and Day-2 operations — vendor-agnostic, fixed-fee SOW

Depends on site count and business-cycle constraints. A 5–25 site mid-market engagement typically runs 3–6 months from SOW signature to final MPLS decommission: 2–4 weeks of transport audit and application profiling, 4–8 weeks of overlay design and pilot, 6–12 weeks of staged branch rollout, and a minimum of one full quarterly business cycle of parallel run before MPLS is cut.

A 100–500 site enterprise engagement runs 9–18 months, with the rollout phase structured as waves of 20–50 sites per weekend change window.

A 1,000+ site retail rollout can run 18–36 months when staged around seasonal business windows.

Every engagement is scoped as a fixed-fee SOW with the timeline, scope, and deliverables defined in writing before work begins.

Vendor selection is a structural decision driven by existing estate, security integration, branch count, and operational model. As a rule of thumb: Cisco Catalyst SD-WAN for IOS-XE-heavy WAN estates with existing ISE/TrustSec and Umbrella investment; Cisco Meraki SD-WAN for retail and distributed-branch footprints where operational simplicity outweighs granular policy control;

Fortinet Secure SD-WAN for organizations standardized on FortiGate branch security; Versa Networks when SD-WAN and SASE are designed together; Palo Alto Prisma SD-WAN for Palo Alto NGFW/Prisma Access estates; Cato for single-vendor SASE with minimal operational headcount; HPE Aruba EdgeConnect for existing Aruba footprints; VMware VeloCloud for installed-base continuity.

We hold design and migration experience across every platform in the 2024 Gartner MQ leaders quadrant and recommend the platform that fits the estate, not the one with the highest partner margin.

Yes, and you should. The standard WFHS methodology runs SD-WAN in parallel with MPLS for a minimum of one full quarterly business cycle before MPLS circuits are decommissioned. During parallel run, SD-WAN carries production traffic with MPLS available as standby; application-aware routing telemetry is reviewed weekly against the SLA classes defined during design, and any class that misses its threshold triggers a tuning pass before the next review.

MPLS decommission is sequenced per-site with a 30-day rollback window per site, not a fleet-wide cut on a single weekend.

Cutting MPLS on the first day of production SD-WAN traffic is the single most common cause of post-migration incidents and we explicitly design against it.

Yes. SD-WAN is the architectural replacement for DMVPN, iWAN, GET VPN, Cisco PfR, and legacy policy-based-routing overlays — each of those technologies was a point solution for a subset of what a modern SD-WAN fabric delivers as an integrated platform.

Migrations off DMVPN and iWAN are common engagements for WFHS: the DMVPN hub-and-spoke or full-mesh topology is documented during the Phase 1 audit, the PfR policies are captured and translated into SD-WAN AAR SLA classes, and the cutover preserves the existing site-to-site reachability model while adding the observability, application-awareness, and cloud integration that legacy DMVPN designs lack.

Multicast services running over DMVPN require an explicit design note in the SD-WAN overlay because multicast-over-IPsec behavior differs by vendor and is not a default inclusion.

Two patterns. Single-vendor SASE — Cato, Versa, Palo Alto Prisma, Fortinet — delivers SD-WAN and the cloud security stack (FWaaS, SWG, CASB, ZTNA, DLP) from one vendor with one policy plane. Multi-vendor SASE pairs an SD-WAN platform with a separate SSE vendor: Cisco SD-WAN with Zscaler or Netskope, Meraki SD-WAN with Umbrella, Fortinet SD-WAN with Zscaler for a deliberate best-of-breed posture.

Single-vendor SASE reduces operational complexity and shortens the contract posture; multi-vendor SASE preserves best-of-breed flexibility and avoids lock-in but requires integration design across two control planes.

We scope the SD-WAN engagement and the SSE decision in the same fixed-fee SOW when both workstreams are in play so the design trade-offs are made once, with full context.

Every engagement is priced as a fixed-fee SOW — we do not bill hourly. Scope variables that drive cost: branch count, transport complexity (single-internet, dual-internet, triple-transport with 5G), platform selection (Catalyst SD-WAN, Meraki, Fortinet, Versa, Palo Alto, Cato), Cloud OnRamp in scope (SaaS-only, IaaS, or Multicloud), whether SASE/SSE integration is included, and parallel-run duration. A 10-site mid-market greenfield runs a different scale than a 500-site MPLS replacement with SASE integration.

We return a written SOW quote within three business days of a 30-60 minute scoping call after receiving the circuit inventory and site list.

Send to sales@wifihotshots.com or call (844) 946-8746. No engagement begins without the client signing off on the fixed-fee price first.

Yes. 5G is deployed as primary WAN at sites where wireline is unavailable or uneconomic (mobile clinics, temporary construction, pop-up retail, DR locations), as a third-leg failover at sites with dual-internet to protect against dual-carrier last-mile events, and as hybrid primary-plus-backup at small-branch retail where wireline-plus-5G beats dual-wireline on cost and resilience.

Hardware options span integrated-cellular SD-WAN routers (Cisco Catalyst IR1101/IR1800, Fortinet FortiExtender, HPE Aruba EdgeConnect with pluggable cellular), dedicated cellular routers behind the SD-WAN edge (Cradlepoint NetCloud by Ericsson, Sierra Wireless AirLink), and CBRS or private LTE/5G for campus/industrial scenarios.

The design captures carrier selection per site, dual-SIM failover, and the data-cap strategy under sustained cellular-primary conditions.

A structured handoff package that transfers design intent, not just credentials: a design-intent document covering SLA class rationale and retune criteria; a BFD timer decision log with measured 95th-percentile transport jitter per circuit class; TLOC/OMP policy reference (or Fortinet/Versa/Palo Alto/Cato equivalents); Cloud OnRamp topology diagrams for each SaaS and IaaS target with BGP ASN assignments;

a change-control runbook covering branch add, branch retire, SLA class changes, new SaaS profile addition, and IPsec key rotation; and a troubleshooting playbook covering the top 20 symptoms with diagnostic commands per platform.

The handoff happens on a scheduled call with the receiving NOC and the WFHS engineer of record, reviewed section by section.

For organizations that prefer to retain WFHS engineering capacity post-cutover, our managed services practice scopes ongoing Day-2 operations as a separate fixed-fee engagement.

Cisco Catalyst SD-WAN splits the control plane into three software-defined controllers. SD-WAN Manager (formerly vManage) handles management and orchestration through a GUI and REST API, sized at a minimum 16 vCPU with 8 vCPUs reserved for control connection ports.

SD-WAN Controller (formerly vSmart) is the OMP route reflector and policy engine, running on a VM with up to 8 vCPUs. SD-WAN Validator (formerly vBond) handles authentication, NAT discovery, and edge onboarding orchestration.

Every WAN Edge authenticates with an X.509v3 SUDI certificate protected in the hardware Trust Anchor Module (TAm).

The edge first connects to the Validator over encrypted DTLS, then receives the Manager and Controller IPs to complete bring-up.

Our SD-WAN design team sizes controller capacity per IOS-XE 17.13+ release notes before issuing a fixed-fee SOW.

OMP (Overlay Management Protocol) runs between SD-WAN Controllers and WAN Edges to distribute three route families: TLOC routes, prefix (OMP) routes, and service routes. Default OMP hold time is 60 seconds. Default graceful restart timer is 43,200 seconds (12 hours), configurable from 1 second up to 604,800 seconds (7 days). Default advertisement-interval is 1 second. Default end-of-RIB timer is 300 seconds. Graceful restart is enabled by default on controllers and edges.

A device establishes a single OMP session per controller regardless of tunnel count.

For deployments over 1,001 devices, Cisco’s HA guidance caps OMP sessions at 1,500 per SD-WAN Controller, which drives the controller count planning at scale.

We model OMP session math against device roll-out projections before finalizing controller cluster size.

Application-aware routing steers application traffic across the SD-WAN overlay based on measured path SLAs. An SLA class defines maximum jitter, maximum latency, maximum packet loss, or a combination of these values for data-plane tunnels.

From Catalyst SD-WAN release 17.3.1a onward, a single policy can carry up to six SLA classes on Cisco IOS XE SD-WAN devices. Path selection is driven by preferred color, backup color, or a default action, with a fallback-best-tunnel option that relaxes criteria when no path fully meets SLA.

Standard AAR uses a default poll-interval of 10 minutes and multiplier of 6 for SLA classification — six 10-minute averages are evaluated before a path is declared out of threshold. Enhanced AAR (introduced 17.3.1a+) uses a PfR-style model with a default poll-interval of 10 seconds and multiplier of 6 for finer-grained enforcement.

That means six 10-second averages are evaluated before a path is declared out of threshold, which prevents flapping on short transient events.

BFD (Bidirectional Forwarding Detection, RFC 5880) runs on every IPsec tunnel in Catalyst SD-WAN to detect tunnel failure. Default BFD Hello interval is 1 second. Default BFD multiplier is 7, so a tunnel is declared down after 7 consecutive missed hellos (about 7 seconds).

The Hello interval is user-configurable per tunnel through the bfd color interval command and supports sub-second tuning where RFC 5880’s Desired Min TX Interval in microseconds applies.

Application-aware routing uses a separate poll-interval of 10 minutes by default with a multiplier of 6, meaning six 10-minute averages are reviewed before an AAR out-of-threshold decision is made.

That split is deliberate: BFD catches hard tunnel loss fast, while AAR reviews smoothed performance windows so mild jitter does not flap active flows off a healthy path.

TLOC stands for Transport Location and is the identifier tuple that names a WAN attachment point in Catalyst SD-WAN. Each TLOC carries three values: system IP, color, and encapsulation. Color labels the transport interface (biz-internet, private1, mpls, lte, metro-ethernet, or custom) and is central to how policy groups transports. Encapsulation is IPsec by default, with GRE available where payload overhead or middlebox compatibility demands it.

OMP distributes TLOC routes alongside prefix and service routes, and the SD-WAN Controller uses TLOC attributes in best-path selection.

In practice, TLOC colors let you define preferred and backup transports per application class and steer traffic away from a degraded provider without changing underlying routing.

Multi-Region Fabric is Cisco’s hierarchical Catalyst SD-WAN architecture introduced in IOS-XE 17.x to replace hop-by-hop policy across very large overlays. The design uses a central core region (Region 0) plus one or more regional overlays. Branches run as edge routers; regional hubs run as border routers. Devices in the same region build direct SD-WAN tunnels. Inter-region traffic traverses regional border routers.

MRF fits deployments with clear geographic boundaries, for example West Coast and East Coast for North America or a separate region for Canada.

Controllers can be dedicated by region or shared across region groups.

It eliminates the manual hop-by-hop routing policies that used to bog down global overlays, and it caps regional tunnel sprawl without breaking the single-fabric management model in SD-WAN Manager.

Catalyst SD-WAN to Secure Internet Gateway (SIG) is supported from Cisco IOS XE Catalyst SD-WAN Release 17.2.1r and vManage Release 20.2.1 onward. Up to four IPsec tunnels can be provisioned to the primary Umbrella or Zscaler data center. When two or more active tunnels are provisioned, traffic toward the SIG is distributed among them. Automatic SIG tunnels use the first NAT-outside WAN interface to establish connectivity.

Topology options include active/active and active/backup with a primary and secondary data center.

The SIG credentials feature template holds the Umbrella Organization ID, Registration Key, and Secret, which avoids per-device key management.

This is the default pattern we use when bolting cloud security onto a Catalyst SD-WAN rollout without introducing a separate SASE overlay.

Match the platform to the traffic profile. Catalyst 8300 is the branch-office platform with aggregated performance of 15 to 20 Gbps CEF and IPsec in the 1 to 5 Gbps range with services enabled. Catalyst 8500 is the high-performance aggregation platform, reaching up to 208 Gbps with IPsec, QoS, DPI, and Flexible NetFlow active. The C8500-20X6C Tier 5 variant delivers 50 Gbps IPsec full duplex and 100 Gbps aggregate.

Catalyst 8000V, the virtual edge, was validated by Miercom with 2,044 SD-WAN tunnels and 108,527 OMP routes at around 14 Gbps IPsec throughput on an AWS c5n.9xlarge instance.

The C8300/C8200 physical platforms use the DPDK framework and Intel QuickAssist (QAT) engine for crypto acceleration, which is where branch IPsec throughput actually lands under mixed real traffic.

Meraki MX sizing starts with the published throughput envelope. MX450 delivers 10 Gbps NAT firewall throughput, up to 7.5 Gbps NGFW throughput, and up to 4.5 Gbps site-to-site VPN throughput, recommended for up to 10,000 devices. MX67 and MX68 land at 700 Mbps stateful firewall, 400 Mbps VPN, and 400 Mbps NGFW detection. MX67C and MX68CW add a CAT 6 LTE uplink (no native 5G on those SKUs).

The virtual MX line covers cloud and data-center edges. vMX-S supports 250 Mbps VPN/NAT, 200 Mbps NGFW, and 50 site-to-site VPN tunnels. vMX-M supports 500 Mbps VPN/NAT, 400 Mbps NGFW, and 250 tunnels. vMX-L supports 1 Gbps VPN/NAT/NGFW and 1,000 tunnels.

Our SD-WAN architects spec MX size against both throughput and tunnel count, not throughput alone.

Cisco’s Auto VPN guidance puts hub-and-spoke “as the 1st, 2nd and 3rd option” for production deployments. Tested successful deployments run 1,000 to 1,500 tunnels per hub: closer to 1,000 on MX250/MX400 and closer to 1,500 on MX450/MX600. A device establishes one tunnel per uplink per peer, so uplink count multiplies the math fast.

The formulas matter at scale. Full mesh = H x (H-1) x L per uplink: 50 appliances with 2 uplinks each produces 4,900 tunnels.

Hub-and-spoke = 2 x (H x H x S) + (L x S x H x S): 4 hubs with 100 spokes and 2 uplinks produces 1,624 tunnels.

Cisco Secure Connect integrates up to 60 hubs simultaneously. These numbers drive hub count and MX model selection at dashboard roll-out time.

Meraki MX calculates three metrics per VPN tunnel: latency (response time), loss (packets not returned), and jitter (variability in received packet linearity). A performance score rolls those metrics up per WAN connection and drives uplink path selection. MOS score is also exposed per uplink for voice monitoring.

Evaluation order is explicit in Meraki’s design guide. If dynamic path selection rules are defined, each tunnel is checked against those rules.

If multiple paths satisfy the rule, or none do, or no rules exist, the policy-based routing (PbR) rules evaluate next.

That layered decision tree is why dynamic path selection rules should be written narrowly per application class rather than as a single catch-all: coarse rules fall through to PbR and produce unexpected uplink choices under real WAN impairment.

FortiGate Performance SLA default values are published in the FortiOS 7.6 admin guide and carry forward into 7.4. Probe check interval: 20 to 3,600,000 ms, default 500 ms. Latency threshold: 0 to 10,000,000 ms, default 5 ms. Jitter threshold: 0 to 10,000,000 ms (no published default, configurable).

Failures before an interface is marked inactive: 1 to 3,600, default 5. Successful checks before an interface is marked active again: 1 to 3,600, default 5.

One quirk catches teams: if the protocol type is HTTP or HTTPS, FortiOS automatically raises the check interval to 120,000 ms regardless of the configured value.

That is done to avoid hammering the probe target with sub-second HTTP sessions, but it means teams expecting 500 ms probes on an HTTPS health check will see 2-minute cadence in the real dataplane.

Validate protocol before tuning thresholds.

ADVPN (Auto-Discovery VPN) dynamically forms spoke-to-spoke shortcut IPsec tunnels through the hub, so lateral traffic stops tromboning. ADVPN 2.0, introduced in FortiOS 7.4.2, adds improved edge discovery and path management on top of classic ADVPN. BGP per overlay handles dynamic routing and distributes LAN routes between spokes without static-route maintenance.

Transport groups segregate the overlays cleanly: transport group 1 for Internet-link overlays, transport group 2 for MPLS-link overlay.

That separation is what lets Fortinet Secure SD-WAN scale a single hub design into large hub-and-spoke topologies with real mesh behavior.

Classic hub-and-spoke VPN on FortiGate works at smaller scale but forces every spoke-to-spoke flow through the hub, which is exactly the pattern ADVPN 2.0 eliminates.

Fortinet’s Secure Processing Unit (SPU) line is why FortiGate hardware SD-WAN numbers hold under real traffic. SoC4 consolidates network and content processing on a single chip and accelerates SD-WAN overlay tunnels, application identification, steering, remediation, and prioritization. FortiGate 100F was positioned as the first SoC4 SD-WAN ASIC platform in the Fortinet product line.

NP7 is the higher-end network processor, rated up to 200 Gbps maximum throughput over 2 x 100 Gbps interfaces.

It accelerates IPsec decryption, VXLAN termination, network address translation, hardware logging, and policy enforcement.

CP9 is the companion content processor offloading resource-intensive inspection. In practice, the ASIC path is what separates published FortiGate SD-WAN throughput from CPU-bound competing appliances at the 100F, 200F, 400F, and 600F price points.

Prisma SD-WAN Performance Policy extends the App SLA model with measurement, enforcement, and alerting per application. Link quality metrics tracked are latency, loss, and jitter. Application metrics tracked are application round-trip time and initialization-failure percentage. When an SLA violation is detected, the system moves flows to a compliant path if one exists and invokes line conditioning such as Forward Error Correction (FEC).

The Adaptive feature enables FEC or Packet Duplication on selective apps when the VPN path exceeds a configured packet-loss threshold.

Link Quality Monitoring (LQM) runs continuously across Branch-to-Data-Center and Branch-to-Branch Gateway VPN connections.

The result is autonomous remediation at the flow level without operator intervention, which is the design intent behind the Prisma SD-WAN ION platform.

ION 9200 is Palo Alto’s high-end Prisma SD-WAN branch and aggregation appliance. Port complement: 11 x 1G RJ45, 10 x 10G/1G SFP+, 4 x multi-gig 1G/2.5G/5G PoE++, 4 x 1G bypass. 64 GB RAM, 480 GB internal NVMe SSD plus a 480 GB external field-replaceable SSD, redundant 450W AC PSUs, rack-mount form factor.

ION 3200 is the small-branch end. Port complement: 8 x 10/100/1000 RJ45 plus 2 x 1 Gbps RJ45/SFP combo, 16 GB RAM, 128 GB eMMC, 150W external adapter, rack/desktop/wall-mount, 90W PoE aggregate.

ION 3200H is the hardened variant, rated -40 C to +70 C, with 5G cellular options and L2 switch ports on the C5G-WW SKU.

Our engineers spec ION model against branch port density and PoE draw before finalizing the BOM.

DMPO (Dynamic Multipath Optimization) treats multiple WAN links as a single high-bandwidth bonded link, with per-packet steering and remediation inside a DMPO tunnel. Broadcom’s performance testing exercises IPsec encryption, application recognition, link SLA measurements, and per-packet forwarding inside a fully operational DMPO tunnel topology. Edge 620 and higher platforms use DPDK by default on routed interfaces to hit published throughput numbers.

Ownership status matters for procurement.

VeloCloud sits under Broadcom post the November 2023 VMware acquisition, with Arista Networks announcing acquisition of VeloCloud from Broadcom in 2025. Broadcom’s TechDocs currently hosts the SD-WAN documentation during the ownership transition.

Support contracts, pricing models, and roadmap cadence shifted with that transition. We account for that churn when scoping new VeloCloud builds against alternative platforms like Catalyst SD-WAN, Prisma SD-WAN, or Fortinet Secure SD-WAN.

HPE Aruba EdgeConnect organizes WAN policy into Business Intent Overlays (BIOs): application-specific overlays with priority and QoS per business intent. An overlay tunnel is built per EdgeConnect node pair participating in each BIO and selects one or more underlay tunnels based on link-bonding policy and underlay tunnel state (eligible, meeting SLO, status).

Forward Error Correction reconstructs lost packets to avoid TCP retransmission; FEC ratio is configurable per business criticality, and some bonding policies use no FEC at all.

EdgeConnect continuously monitors bonded tunnels and physical WAN links, factoring delay, jitter, and packet loss into path decisions.

The EC-S-P SD-WAN gateway ships with 8 x RJ45 10/100/1000 plus 4 x 1/10 Gbps SFP+, rated for typical WAN bandwidth from 10 Mbps up to 3 Gbps.

Our SD-WAN engineers map BIO templates to application traffic before finalizing an EdgeConnect design.

Cato Networks runs 85+ points of presence (PoPs) globally, interconnected by multiple tier-1 carriers with SLA-backed transit. A key architectural difference from hyperscaler-hosted SASE: Cato’s PoPs run multitenant software in their own data centers, at a 1:1 ratio of PoPs to compute locations, not inside AWS, Azure, or GCP.

The Single Pass Cloud Engine (SPACE) applies all security inspections and network optimizations in parallel on the same packet, rather than serializing each service.

Cato converges NGFW, SWG, IPS, NG anti-malware, RBI, CASB, DLP, and ZTNA into one cloud-native stack.

The Cato Socket is the branch device: X1500 for small sites, X1600 and X1600 LTE for medium branches, X1700 for large sites and on-prem data centers.

HA mode is active/passive with LAN-port keepalive and 3-second failover when the secondary Socket LAN is up.

Sockets support up to 3 WAN connections; X1700 with Socket v20+ supports 4.

MEF 70.2, published November 2023, establishes externally visible behavior specifications for SD-WAN services. It defines three primary elements: SD-WAN Key Concepts (foundational service building blocks), SD-WAN Service Attributes (enumerable agreed information between Subscriber and Provider), and SD-WAN Service Framework (a structured approach for defining specific SD-WAN Service instances). It supersedes MEF 70.1.

For procurement, MEF 70.2 governs the formal agreement structure between the SD-WAN Subscriber (buyer) and the SD-WAN Service Provider (seller).

It focuses on what services entail rather than implementation specifics, which lets a buyer write consistent RFPs across vendors whose underlying architectures differ significantly.

Note the body’s rebrand: MEF became the Mplify Alliance in 2024, and the standards resources moved from mef.net to mplify.net, and the standards resources moved from mef.net to mplify.net. We cite MEF 70.2 language directly in procurement support work on Catalyst SD-WAN, Prisma SD-WAN, Fortinet Secure SD-WAN, and EdgeConnect rollouts.