> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # MPLS and DMVPN Together: Choosing and Combining Enterprise Transports - URL: https://www.pinglabz.com/mpls-vs-dmvpn-enterprise-transport/ - Published: 2026-07-12T08:55:06.000Z - Updated: 2026-08-24T09:44:14.000Z - Description: MPLS gives you a private SLA-backed core; DMVPN gives you cheap encrypted connectivity over any internet link. This article compares the two honestly and shows the standard hybrid designs most enterprise WANs end up running. - Author: Jaime - Tags: MPLS, DMVPN, SD-WAN, CCIE, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/mpls/) and the [DMVPN guide](https://www.pinglabz.com/dmvpn/). ## What each one actually is MPLS L3VPN A service you *buy* from a provider. They run the core; you hand them routes at each site and they deliver any-to-any connectivity with an SLA. Private, no encryption needed on the wire (it is not the public internet), QoS honoured end to end. DMVPN An overlay you *build* yourself over any IP transport - usually the public internet. Encrypted (IPsec), dynamic spoke-to-spoke, cheap bandwidth, but no SLA and QoS is best-effort once packets hit the internet. 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 **Cost** MPLS: expensive per megabit, especially internationally. DMVPN over internet: cheap, sometimes a tenth of the cost for the same bandwidth. **SLA** MPLS: contractual latency, loss, jitter guarantees. DMVPN: best-effort - the internet promises nothing. **QoS** MPLS: honoured end to end by the provider. DMVPN: you can mark and shape at your edge, but the internet ignores your DSCP. **Encryption** MPLS: not encrypted (private core) - add it yourself if compliance requires. DMVPN: IPsec built in. **Provisioning** MPLS: weeks to months for a new circuit. DMVPN: a new spoke is up in an hour over any internet connection. **Control** MPLS: the provider owns the core; you troubleshoot through a ticket. DMVPN: you own every hop of the overlay. **Any-to-any** MPLS: native - the provider mesh gives it for free. DMVPN: dynamic spoke-to-spoke (Phase 3) achieves it, with a resolution step. 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](https://www.pinglabz.com/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 1. **Critical site, SLA-bound apps, budget available:** MPLS primary, DMVPN internet backup. The standard enterprise branch. 2. **Cost-sensitive, many sites, tolerant apps:** DMVPN over internet as the primary, no MPLS. Common for retail, remote offices. 3. **Compliance requires encryption everywhere:** DMVPN over MPLS, or DMVPN everywhere. 4. **You want per-application transport selection without hand-crafting it:** SD-WAN over both transports. 5. **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](https://www.pinglabz.com/expert-transport-troubleshooting/). The full cluster indexes live on the [MPLS pillar](https://www.pinglabz.com/mpls/) and the [DMVPN pillar](https://www.pinglabz.com/dmvpn/).