Solving the MPLS/VPN QoS challenge

Two weeks ago I wrote about the challenges you’ll encounter when trying to implement end-to-end QoS in an enterprise network that uses MPLS/VPN service as one of its transport components. Most of the issues you’ll encounter are caused by the position of the user-SP demarcation point. The Service Providers smartly “assume” the demarcation point is the PE-router interface ... and everything up to that point (including their access network) is your problem.

The only workable solution to the QoS-across-MPLS/VPN problem I found (and believe me, every time I meet a customer using MPLS/VPN, the issue pops up) is to move the demarcation point. Instead of trying to deal with the hidden complexities of unknown access networks, ask the Service Provider to install their CE-routers at your premises, like they did in the old days when they were trying to sell Frame Relay as Managed Network service.

The only task left to you is to shape your outbound traffic to the contractual rate (and queue within the shaping queue if necessary) and the rest is now purely the Service Provider’s responsibility. Make sure you have enforceable SLA violation penalties in your contract, deploy SLA-measurement tools (our NIL Monitor comes to mind), show your SP account manager the graphs (just to let them know you might have supporting documentation to enforce the penalties) ... and watch the QoS miraculously work as expected (OK, it helps if you’re big enough and if they know what they’re doing).

More information

If you’d like to get an overview of numerous VPN services, their benefits, drawbacks and challenges you might encounter deploying them, check out my Choose the Optimal VPN Service webinar (register here or buy a recording).

Note: This brilliantly simple solution was mentioned to me by one of my customers. For obvious reasons I have to keep quiet, but you know who you are.

6 comments:

  1. Hi Ivan

    regarding the specific QoS bandwidth conditionning, newer PE platforms as the Cisco ASR9k, or Juniper MX or Alcatel SR7750 do allow the SP to do ingress traffic-shapping + queueing, so effectivelly the SP is able to apply an identical bandwidth conditionning for input and output traffic (older platforms will only allow output shapping and input policing only so the solution will require in this case a PATCH in the shape of a CE doing the traffic-shapping the SP is incapable of doing...)

    Omar Baceski

    ReplyDelete
  2. At my company we provide a "managed" VPN service, we place a CE device at the customer site, mostly a Cisco 3400. We create multiple VRFs depending on the customer requirment, for example a data VRF and a voice Application VRF for VoIP. Not sure if this is ideal but just giving the forum some information on how at least one service provider does it.

    ReplyDelete
  3. Ivan,
    In either scenario the customer can shape and mark egress traffic at the Site-A router. What are the main problems that can arise with the "Access Network" cloud shown in your first diagram? Is that "Access Network" a shared network? If so, who typically owns and controls the QoS policies on that network?

    ReplyDelete
  4. Brad, of course you can shape/queue/mark on ingress CE, but that's just the first hop across the whole MPLS/VPN network. More about what can happen across the whole path in:

    http://blog.ioshints.info/2010/10/qos-over-mplsvpn-networks.html

    The "access network" is owned and controlled by the SP, but sometimes consistent QoS/SLA is not enforced across all the elements in the path.

    ReplyDelete
  5. That's perfect. You got it just right. I also like the Voice/App VRF split. Now just tell me in which markets you operate ;)

    ReplyDelete
  6. Thanks for the feedback. Ingress shaping is a close-to-ideal solution (but also resource-intensive). Obviously I'll have to spend some time studying the ASR9K ;)

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.