WAN transport architecture selection
Requirement / business driver
Choose the enterprise WAN architecture that balances SLA, cost, agility, app-awareness, and security.
Options
- MPLS L3VPN - SP-managed private any-to-any with strong SLA.
- DMVPN over internet (DIY) - cheap encrypted overlay you build/operate.
- SD-WAN - transport-independent, app-aware, centrally managed (often hybrid MPLS + internet).
Comparison
Tradeoffs
MPLS buys a guaranteed SLA at high cost and low agility; DMVPN is cheap but routing-based and manual; SD-WAN gives app-aware steering, central policy, agility, and integrated security on any/multiple transports, at the cost of relying on best-effort internet (mitigated by path selection/remediation).
WAN edge redundancy (single vs dual provider)
WAN resilience is a ladder, each rung adding cost: single CE + single provider (cheapest; SPOF at both router and provider) -> dual CE, single provider (survives a router failure, not a provider outage) -> dual CE + dual provider (survives a whole-provider failure; the resilient default for critical WAN). Real diversity means avoiding shared fate: confirm the two "diverse" circuits don't ride the same fibre / conduit / POP (SRLG), or the second provider is cosmetic. The same spectrum applies at the branch - single transport (one MPLS or one internet) vs dual / hybrid transport (MPLS + internet, or dual internet) with SD-WAN (SD-WAN design) choosing the path per application. Dual provider rungs also carry a quieter operational bill: features shrink to the least common denominator between carriers, QoS models and BGP AS topologies diverge per provider and must be mapped at every dual-homed site, and capacity is effectively paid for twice - name these costs when a scenario weighs a second carrier against a second circuit from the same one. Match the rung to business criticality and budget, not to a reflex "always dual."
The colocation cloud edge and private-link anatomy
When application gravity inverts the old 80/20 (most traffic now leaves for cloud/SaaS), the enterprise data centre stops being the WAN's natural centre - a carrier-neutral colocation facility often takes that role: one cross-connect-rich site with private on-ramps to every major cloud, carrier, IX and SaaS front door, hosting the enterprise's own edge/security stack without being on enterprise premises. When it earns its cost: the enterprise runs its own WAN, the IaaS share keeps growing, apps are latency/SLA-sensitive, or a multicloud future is plausible (the same facility later interconnects clouds - including geo-distributed AI clusters - over an enterprise-controlled high-speed underlay). When it does not: small estates on managed WAN services where Internet + SaaS is genuinely good enough.
The private link itself has a standard anatomy worth recognising: a dedicated 10/100G port (or a sub-rate "hosted" circuit through a partner) delivered at the colo demarc, per-tenant separation by 802.1Q service tags onto virtual interfaces (VIFs), and BGP per VIF - a private VIF reaching the enterprise's VPC/VNet space and a public VIF reaching the provider's public services (object storage and friends) without touching the Internet. Add BFD for failure detection the provider's slow keepalives will not give you, and mind the egress economics: inbound is free, outbound is billed (cheaper than Internet egress, still real money) - replication-heavy and AI/data-pipeline designs should be costed on the outbound direction before the topology is blessed (SD-WAN design Cloud OnRamp automates the overlay on top of exactly these links).
The provider-dependent vs independent framing
The exam canon names this same decision axis explicitly: provider-coordinated / dependent WAN virtualization means the SP runs the virtualization for you (an MPLS L3VPN/L2VPN service - your edge just hands off), while provider-independent / over-the-top (OTT) means you build the overlay yourself - DMVPN/IPsec or SD-WAN - across any transport, keeping control (and operational burden) in-house. The constraint mapping in Tunneling technology selection and the transport economics above answer which side wins; recognize the vocabulary, because scenario options are often phrased in exactly these terms.
One level below procurement sits the structural axis for a self-run core - single-plane vs dual-plane vs multiplanar - in Network hierarchy and topologies.
Recommendation / justification
Default to SD-WAN for modern WANs needing app-awareness, agility, multi-transport, and central policy; retain MPLS where a strict contractual SLA is required (commonly a hybrid: MPLS + internet under one SD-WAN policy); use DMVPN for a Cisco-centric DIY cost play. The justification is transport independence + per-app control + central policy/security, traded against guaranteed-SLA needs.
What would change this (mid-scenario twist)
- Hard SLA / latency contract on key apps -> keep MPLS for them (hybrid).
- Lowest cost, simple, Cisco shop -> DMVPN.
- Heavy cloud/SaaS + security consolidation -> SD-WAN with SASE.
Validation checks
- Are SLA-critical apps still guaranteed (MPLS or measured remediation)?
- Is the control/orchestration plane resilient and the onboarding secure?
IPv6 / dual-stack note
All three carry IPv6; confirm v6 reachability and policy across every transport, not just v4.
The WAN-optimisation appliance era - closed
One architecture generation deserves a verdict rather than silence: the WAN-optimisation appliance pair (TCP proxying with window-scaling and large-initial-window shields, byte-level deduplication over synchronised history caches, branch object caches) attacked the same latency/loss barrier per-flow. Treat it today as a migration liability, not a design pattern: SD-WAN absorbed the path-selection role (SD-WAN design), TLS-everywhere hollowed out deduplication, and the transport mechanics the proxies patched now live in the endpoints (TCP behavior and the network). In a scenario, an installed base of optimisation appliances is a decommission-or-bypass line item in the SD-WAN migration plan, not a component to redesign around.
Related
Spaced repetition
The single biggest advantage of SD-WAN over both MPLS and DMVPN is [...].
The single biggest advantage of SD-WAN over both MPLS and DMVPN is transport independence with per-app path control and central policy.
In a hybrid WAN you keep MPLS specifically for [...].
In a hybrid WAN you keep MPLS specifically for traffic that needs a guaranteed contractual SLA.
The WAN edge redundancy ladder, cheapest to most resilient?
Single CE/single provider -> dual CE/single provider (survives a router failure) -> dual CE/dual provider (survives a provider outage); and verify the two circuits aren't a shared-fate SRLG (same fibre/conduit/POP).
WAN virtualization splits into [...] (the SP's MPLS VPN service) and [...] (a self-built DMVPN/IPsec/SD-WAN overlay across any transport).
WAN virtualization splits into provider-coordinated/dependent (the SP's MPLS VPN service) and provider-independent / over-the-top (a self-built DMVPN/IPsec/SD-WAN overlay across any transport).
When does a colocation "cloud edge" beat connecting clouds from the enterprise DC?
Self-run WAN + growing IaaS + latency/SLA-sensitive apps (or a multicloud future): the carrier-neutral colo gives private cross-connects to every provider and hosts the edge/security stack; small managed-WAN estates skip it.
Private cloud-link anatomy: [...] - and cost the [...] direction first.
Private cloud-link anatomy: dedicated 10/100G (or hosted sub-rate) port, per-tenant 802.1Q/VIF separation, BGP per VIF (private VIF to VPCs, public VIF to provider public services), BFD for detection - and cost the outbound/egress direction first.
Beyond price, a second carrier costs [...].
Beyond price, a second carrier costs least-common-denominator features, per-carrier QoS/BGP-topology divergence to map at every site, and paying for capacity twice.
What is the modern design verdict on WAN-optimisation appliances?
A closed era - SD-WAN absorbed path selection, TLS-everywhere hollowed out deduplication, and endpoint TCP stacks absorbed the proxy shims; in a migration scenario they are a decommission-or-bypass line item, not a component to preserve.
Sources
- Cisco Live BRKRST-2041 (2013): dual-carrier operational costs; re-passed in full batch 65: WAN-optimisation-era verdict added.
- Cisco Live BRKNWT-2126 (Hill, 2024): colocation-centric cloud edge, private-link anatomy, egress economics.
- Cisco Press, Cisco SD-WAN; Optimal Routing Design (WAN).