Building network automation solutions

9 module online course

Start now!

MPLS/VPN services and the barrier to change

Whenever you decide to use MPLS/VPN services from a Service Provider, you’re effectively ripping out your network core (including the core routers) and replacing it with the layer-3 SP backbone (the equipment vendors or service providers sometimes fail to mention this fact).

The network core outsourcing usually makes sense from the financial perspective, but also creates a significant lock-in and high switching costs that you should consider in combination with the CapEx/OpEx cost analysis when selecting your VPN service. We’ll discuss the benefits and drawbacks of MPLS/VPN and numerous other VPN technologies in the Choose the Optimum VPN Service webinar (register here).


  1. Ivan,

    I want to address your point on routing changes requiring PE config modification. I helped design and operate a Tier I ISP's initial MPLS/VPN service in the early 2000s. You're right on that routing changes on the PE will be needed under certain VPN designs.

    Here is how I see SPs being able to minimize changes.

    1) Define your MPLS/VPN service that your Ops organization can support. For instance, you can only offer static (x prefixes or fewer), BGP, and vanilla OSPF PE-CE routing protocols.

    2) Involve tech savvy SEs in the customer VPN design. They know that BGP is natural fit for MPLS/VPN and other ways to create a supportable VPN.

    3) Don't try to be everything for everybody. Standardize your MPLS/VPN service and don't allow one-offs. If you attempt to support every PE-CE protocol and lots of tweaks, you will likely face challenges as the number of VPN customers grow.

    Jeff Loughridge
  2. Thank you for the comment. I absolutely agree with everything you wrote.

    Unfortunately, not all SPs or their large customers are willing to follow these recommendations ... and the vendors are required to implement more and more knobs and tricks to cater to their needs.
  3. The current SP environment I work in (although I'm an optical guy) follows Jeff's suggestions 1 & 3: standard offerings flexible enough to accomodate nearly every client while keeping ops and maintenance simple. Anyways, most issues aren't logical config troubles, but failures in the CE, access and transport network (90% of troubles), with occasional bugs in the router OS or mismatches in implementation.

    If you can make a solution that is simple and works for hundreds of clients, you can make sales and support much simpler. The few customers that really need something very specific will pay a premium price for it and have a dedicated helpdesk, so the complexity of their custom solution doesn't impact overalls ops and create burdens that extend beyond the lifetime of the contract. And a team of competent engineers that design the generic product template should be able to design and maintain the custom solution. Fortune 500 companies have the extra cash to burn if they insist on specific implementations.
Add comment