Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

Do Enterprises Need MPLS?

Continuing the Do Enterprises Need VRFs discussion, let’s see which enterprise networks might need MPLS.

Do you need VRFs?

Read the previous blog post. If the answer is NO, you can stop reading. Otherwise, carry on.

Do you have many VRFs or plan to have a scalable solution?

No: VRF-Lite is probably good enough.

Using VRF-Lite in DMVPN environment might require multiple parallel DMVPN clouds.

Yes:

Do you believe in SD-WAN?

Yes: You don’t need MPLS or any other technology. The black box you bought will do its proprietary magic to solve all the problems you might have (or not).

No:

Is this a data center-only problem?

No:

Do you plan to do layer-3 encryption (IPsec)?

No: Use MPLS. It has way lower encapsulation overhead than anything.

Yes:You would need MPLS-over-GRE-over-IPsec, in which case VXLAN-over-IPsec might be better (assuming you can get it on your WAN gear).

Yes:

Do you plan to use overlay virtual networks?

Yes: implement VRFs with distributed routers in overlay virtual networks.

No:

Do your data center switches support MPLS at reasonable cost/performance point?

No: Use VXLAN (and change gear if it doesn’t support VXLAN).

Choosing between VXLAN and MPLS on merchant silicon boxes is tricky. Support for MPLS data plane is often dismal (example: small label space), but then these same ASICs might not support routing from VXLAN tunnels either.

Yes:

Do you really want to deal with complexities of MPLS and complexities of EVPN?

Yes: Use MPLS with L3VPN or EVPN control plane.

No: Use EVPN over VXLAN.

6 comments:

  1. Great post - thank you for that.
    However, the initial question bugs me a little. MPLS is not a solution to a problem - it's a packet encapsulation and forwarding method.

    From my opinion the question is, do enterprises need layer-3 virtualization technologies. If yes, MPLS (along with some additional protocols and features) could be the right choice.

    But this is only a helping tool for a problem (e.g. separation of security zones). Maybe there are other technologies like VRF lite (as you said), LISP, proprietary stuff like SGT.

    ReplyDelete
    Replies
    1. "From my opinion the question is, do enterprises need layer-3 virtualization technologies." << Link to that one in the first paragraph of this post ;)

      Delete
    2. If VRF = L3 virtualization technologies, than I saw that link. (however VRFs are again just a tiny piece of the whole story).
      Nevermind my jabbering ... great post, thanks for sharing!

      Delete
    3. If you want to have a L3 virtualization technology, you need a separate forwarding table for each virtual L3 domain (like you need a separate MAC table for each virtual L2 domain).

      You also need some way of populating that table, usually a routing protocol. VRF (regardless of how you call it) is thus a fundamental building block of every L3 virtualization technology.

      Delete
  2. Like DWDM, MPLS is a fantastic solution if you need to keep traffic flows separate, but like DWDM it typically requires some initial capital investment and re-architecture. (Not all vendor hardware supports true CE/PE/P MPLS infrastructure in their code, many just do VRF lite). You need to spend some time pondering the TCO/ROI.

    For instance, if your current $employer has multiple campuses or data centers and someone asks to deploy a "test" environment comprised of multiple isolated VLANs at each location, that's easy. If they then ask you to have them all talk to each other (and ONLY to each other due to security concerns) then you are doing ACLs (ugh), firewalls, L2 tunnels or L3 tunnels. The firewall solution is fine but it doesn't scale... every site you add will require one. Also firewalls don't give you the flexibility of Layer-1, 2 and 3 tunnels.

    If you invest in an MPLS infrastructure then you can spin up that VRF everywhere you need it. I think a good example of this is a lot of educational institutions run separate VRFs across a common infrastructure to keep the faculty traffic 100% separated from all the young blackhats on the student networks. Most educational IT staff don't have the budget to purchase and refresh large firewall populations, so VRF'ing it all to a centralized pair is cost effective. It should definitely be considered anytime you have a "keep this from talking to that, but let it talk to other things" challenge. Yes, there are other alternatives such as DMVPN but these again become problematic as they scale up, and they don't give you the Layer 1-3 options.

    The documentation, adoption and operational handoff isn't any worse than other solutions. I recommend at least considering it even for small/medium efforts.

    ReplyDelete
  3. Also worth noting:

    MPLS can help in designing a simple and stable core that isn't subject to the volatility of routing / topology changes at the edge. I agree these objectives can be satisfied with other solutions, but as autarch01 says, implementing MPLS doesn't have to be worse than other options. I would argue that MPLS is in a similar place to where BGP was in many enterprises a few years ago ... perceived as prohibitively complex and scary, when it doesn't have to be.

    There are some significant advantages to MPLS when it comes to upgrading or expanding the core (P) routers as you don't have to consider 'customer' routes.

    Using 6VPE you can implement IPv6 without having to re-engineer the core (P) routers.

    If running multicast, some nice options for minimising the amount of multicast state information the core has to maintain.

    Some security advantages as well, in terms of options for protecting the core control plane if the design maintains separacy of 'customer' and global routing tables.

    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.

Sidebar