Almost every mid-to-large enterprise WAN ends up running both MPLS and DMVPN. Not because someone planned it that way, but because they solve different problems, and a real network has both problems. MPLS gives you a private, SLA-backed, any-to-any core. DMVPN gives you cheap, encrypted, dynamic connectivity over anything with an internet connection. The interesting question is not "which one" - it is "how do they fit together."
This article compares the two honestly and shows the standard hybrid designs. It is the synthesis of the transport series. For the fundamentals, see the MPLS guide and the DMVPN guide.
What each one actually is
The distinction that matters: MPLS is a purchased service with a contract; DMVPN is a design you own end to end. That shapes everything - cost, control, SLA, and who you call when it breaks.
The honest comparison
Neither wins outright. MPLS buys you performance guarantees and offloads the core; DMVPN buys you cost, speed of deployment, and control. Which is why the answer for most enterprises is not one or the other.
The hybrid designs
1. MPLS primary, DMVPN backup
The most common pattern. Each site has an MPLS circuit and an internet circuit. MPLS carries production traffic; a DMVPN overlay over the internet sits ready as backup. If the MPLS circuit fails, routing shifts to the DMVPN.
! Prefer MPLS: higher local-pref / lower metric on the MPLS-learned routes,
! DMVPN routes as the less-preferred backup path.
! On failure, the backup path takes over automatically.You get the MPLS SLA for normal operation and the DMVPN as a cheap insurance policy - far cheaper than a second MPLS circuit for redundancy. The design work is making the failover clean: route preference so MPLS wins when both are up, and fast failure detection (BFD, IP SLA tracking) so the switch to DMVPN is quick.
2. Active/active with application-aware routing
Use both circuits simultaneously, and steer traffic by application. Latency-sensitive, SLA-critical traffic (voice, video, ERP) over MPLS; bulk, backup, and internet-bound traffic over the DMVPN. This is exactly the problem SD-WAN was built to automate - application-aware routing making these decisions per-flow, per-SLA, dynamically. A hand-built version uses PBR and route-maps; SD-WAN does it as a policy.
3. DMVPN over MPLS (yes, really)
Run a DMVPN on top of your MPLS service. Why? To get encryption over MPLS (for compliance) without asking the provider for it, to get dynamic spoke-to-spoke over an MPLS L3VPN that would otherwise route everything through a hub, or to have a single consistent overlay whether the underlay is MPLS or internet. The MPLS L3VPN becomes just another transport for the DMVPN cloud.
4. Dual DMVPN clouds over dual transports
Two DMVPN clouds, one over MPLS, one over internet, is the classic dual-cloud design. Each transport is a separate DMVPN, and routing (or SD-WAN policy) chooses between them. This is the fully self-owned version of the hybrid, with no reliance on the provider for anything but raw transport.
Where SD-WAN fits
Everything above - the failover, the application steering, the transport selection - is manual policy in a traditional design. You configure route preferences, PBR, IP SLA trackers, and you maintain them. It works, and CCIE candidates need to know how to build it by hand.
SD-WAN productises exactly this. It abstracts "MPLS and DMVPN and internet" into "transports", measures each one's real-time performance, and applies application-aware routing as a centralised policy. The hybrid designs above are precisely the problem SD-WAN automates - which is why understanding them by hand is the foundation for understanding what SD-WAN is doing for you. (The SD-WAN cluster covers this in depth.)
Choosing, in practice
- Critical site, SLA-bound apps, budget available: MPLS primary, DMVPN internet backup. The standard enterprise branch.
- Cost-sensitive, many sites, tolerant apps: DMVPN over internet as the primary, no MPLS. Common for retail, remote offices.
- Compliance requires encryption everywhere: DMVPN over MPLS, or DMVPN everywhere.
- You want per-application transport selection without hand-crafting it: SD-WAN over both transports.
- Global sites where MPLS is prohibitively expensive: DMVPN over internet, accepting best-effort, possibly with SD-WAN measuring path quality to route around brownouts.
Key takeaways
- MPLS is a purchased service - private, SLA-backed, QoS honoured, expensive, provider-controlled. DMVPN is a self-built overlay - encrypted, cheap, dynamic, best-effort, fully under your control.
- Most enterprises run both, because they solve different problems.
- The most common hybrid is MPLS primary, DMVPN internet backup - the SLA for production, cheap insurance for failure.
- Other patterns: active/active with application steering, DMVPN over MPLS (for encryption or dynamic mesh), and dual DMVPN clouds over dual transports.
- All of these are manual policy in a traditional design (route preference, PBR, IP SLA tracking) and are exactly what SD-WAN automates. Understanding them by hand is the foundation for understanding SD-WAN.
- Choose by app sensitivity, budget, compliance, and how much of the transport decision you want to automate.
Next: expert transport troubleshooting - MPLS and DMVPN ticket scenarios. The full cluster indexes live on the MPLS pillar and the DMVPN pillar.
