When does a provider's MPLS L3VPN still beat encrypted tunnels over internet links for an enterprise connecting forty branches?
answer
- one operator owns the whole path
- classes honoured end to end
- any-to-any without a tunnel mesh
- price, lead time, cloud hairpin
basics
~20 sMPLS L3VPN wins where predictability is the requirement: one provider engineers the whole path, honours traffic classes under a contract and gives any-to-any reachability; internet tunnels win on price, speed of delivery, provider diversity and direct cloud access.
solid answer
~40 sA provider L3VPN sends branch traffic across one operator's core, so latency, jitter and loss can be engineered and written into an SLA, and the provider can map the customer's markings to its own traffic classes end to end. It gives any-to-any routing without the enterprise building tunnels: a full mesh of tunnels for 40 sites is 40 x 39 / 2 = 780. Its costs are a higher price per Mb/s, circuit lead times of weeks to months, dependence on one provider's core, no encryption (RFC 4364 provides none), and cloud or SaaS traffic hairpinning through a central exit. Internet tunnels invert that list. The usual answer is hybrid: keep MPLS for sites or applications that need guarantees, add internet links for bulk and cloud traffic, and let an overlay choose per application.
go deeper
Recall the basic trade: an MPLS VPN is a private, contracted service that costs more; internet tunnels are cheaper and quicker but best effort.
Explain what the provider's single core buys, contracted latency and end-to-end traffic classes, and why tunnels need a mesh or hub to reach every site.
Diagnose the hidden costs of each: cloud traffic hairpinning through a hub, single-provider failure domains, and QoS markings lost across the internet.
Decide per site and per application, name the property that settles it for this business, and plan a hybrid with encryption where policy demands it.
## What the MPLS service actually sells A provider's **MPLS L3VPN** (RFC 4364) is not mainly a technology choice for the enterprise; it is a managed service. The provider runs the PE routers, keeps each customer in its own VRF and carries traffic between sites across its own label-switched core. What the enterprise buys is the set of properties that follow from **one operator owning the whole path**: - **Engineered performance.** The provider controls every link between PEs, so it can sell an SLA on latency, jitter, loss and availability between sites. The internet offers no such contract across several operators. - **Traffic classes honoured end to end.** The provider can map the customer's DSCP markings onto its MPLS Traffic Class queues in its core. Across the public internet, markings are commonly reset or ignored at operator boundaries. - **Any-to-any reachability.** Each site connects once to its PE and reaches every other site; the provider's MP-BGP distributes routes. No tunnel mesh to build. - **Not reachable from the internet.** The VPN's routes are not on the internet, so the WAN path itself is not exposed to internet floods. That is reachability isolation, not encryption. - **One operational contact.** The provider monitors and repairs the core, so the enterprise manages its CE routers and the contract rather than a fleet of tunnels. ## What it costs | Factor | Provider MPLS L3VPN | Encrypted tunnels over internet links | |---|---|---| | Price per Mb/s | high | low | | Time to add a site | weeks to months for a circuit | days, over any broadband or cellular link | | Performance | contracted, engineered | best effort, varies by hour and path | | QoS across the WAN | provider classes end to end | only what you enforce at your own edges | | Encryption | none by design (RFC 4364) | built in | | Provider diversity | one core, hard to mix two | trivial: any mix of ISPs | | Cloud and SaaS | usually via a central internet exit | direct, local breakout | | Mesh effort | none, provider routes it | tunnels or an overlay controller | The arithmetic of the last row: a full mesh between n sites needs n(n-1)/2 tunnels. For 40 branches that is 40 x 39 / 2 = **780** tunnels; hub-and-spoke cuts it to 39 but makes branch-to-branch traffic cross the hub. ## When MPLS still wins 1. **Real-time traffic you cannot degrade.** Voice, video, point-of-sale or industrial control between sites, where jitter and loss targets are contractual rather than hopeful. 2. **Applications intolerant of variable delay.** Synchronous replication or chatty legacy protocols that stall when round-trip time swings during peak hours. 3. **Regions with poor internet.** Where broadband is unreliable, a provider circuit with a repair-time commitment may be the only predictable path. 4. **Regulatory or audit requirements** that demand a private WAN; even then, encryption on top is often required, because the L3VPN does not encrypt. 5. **Branch-to-branch heavy traffic** where any-to-any routing without hub hairpins matters more than price. ## When the internet wins - Traffic is mostly **SaaS and public cloud**: an MPLS design that backhauls it through a data-centre exit adds latency and loads the hub, so local breakout is better. - **Cost and agility** dominate: new sites, temporary sites, sites that move. - **Provider diversity** matters more than a single contract: two ISPs of different types fail independently, while a single provider's core is one failure domain for every site. ## The judgment most designs land on The answer is rarely all-or-nothing: - Keep MPLS at the sites and for the applications that need guarantees, often the data centres and the largest branches. - Add internet links everywhere for capacity, cloud breakout and a second, diverse path. - Steer each application onto the right transport with an overlay that measures path quality, the SD-WAN pattern, which is a separate design subject. - Encrypt sensitive traffic even inside the L3VPN where policy requires it. Revisit the choice as the traffic mix shifts: a WAN designed when most traffic went to the data centre often becomes the wrong WAN once most of it goes to SaaS. A strong answer names the deciding property for this enterprise, such as the voice SLA, the replication latency, the cloud share of traffic, the budget or the time to open a site, rather than declaring either transport obsolete.
- Does an MPLS L3VPN make encryption between branches unnecessary?No. RFC 4364 states the architecture provides no cryptographic privacy; separation comes from VRFs, route targets and the provider's correct configuration. A misconfigured import target or a tap in the provider's network would expose traffic. Where policy requires confidentiality, run encryption over the L3VPN as well, accepting the overhead and the extra devices.
- Why is dual-homing branches to two different MPLS providers harder than adding a second internet link?Each provider runs its own L3VPN with its own routing, so the enterprise must exchange routes with both, usually over BGP, and prevent one provider becoming transit for the other. Path preference, failover and asymmetric return traffic all become the enterprise's problem. A second ISP under an overlay simply adds another underlay path the overlay already knows how to use.
saying these in an interview costs you the question
- MPLS is always faster because label lookups beat IP routing.
- An MPLS L3VPN is encrypted, so no further protection is needed.
- Internet links can never carry business-critical traffic.
- Moving to internet tunnels removes the need for any WAN QoS design.
- One MPLS provider gives full redundancy because its core is meshed.
- MPLS is obsolete now that SD-WAN exists.