Overlay Networking & VXLAN Means MPLS in the Data Centre is Dead

Overlay networking has been around for a year or so now and the ideas behind it are well established. It was about 3/4 weeks ago while researching VTEP functionality in Dell and Arista switches that I realised I could build manually configured tunnels with VXLAN and get the same results as an EoMPLS x-connect with almost zero effort. More importantly, I don’t have to pay for expensive hardware that has MPLS functions or pay again for software licenses to upgrade with MPLS features.

Consider this diagram showing the process of MPLS encapsulation/tunnelling in a simple way




Now, consider how VXLAN works in a similar diagram.



The process is identical. And VXLAN has a number of features that are specifically designed to improve function on the data centre. Features like header entropy for effective load balancing over LAG & MLAG links.

Both MPLS and VXLAN require specific hardware support to operate at line rate but VXLAN only requires hardware support for encapsulation at the edge of the network and thus network cores do not necessarily need replacing. MPLS demands end to end support.

The EtherealMind View

I’ve designed a few data centres with MPLS to create security zones on a shared physical infrastructure. None of this projects went very well because the complexity and cost of implementing MPLS was too high. Reliability was poor and it was difficult to get enough staff with MPLS skills.

Don’t get me wrong, MPLS has it’s place in certain types of networks but it no longer has a place the data centre. SDN and Overlay networking will easily replace MPLS and provide far more functions, service and visibility.

  • Randy Manning

    What about Contrail brining MPLS into the hypervisor switch. Or VEPA, get rid of a virtual switch on a server, then MPLS on the ‘control switch’ via eVPN?

    • http://etherealmind.com Etherealmind

      At this stage, I can’t see how MPLS in the vSwitch is useful. MPLS means that every network device in the potential path must also support MPLS signalling with LDP or BGP.

      If Juniper wants to use MPLS as a flow marking technology instead of OpenFlow then that’s kind of ridiculous. MPLS doesn’t have the granularity to provide application services i.e. mark a flow to be subjected to an action.

      VEPA is an IEEE failure. The IEEE failed to deliver in timely fashion and now the market has moved past the need for VEPA. Proof if this can be found in the Cisco FEX technology as a VEPA implementation that has not been adopted by other vendors. And why bother ? Switch silicon and software are so cheap that it is more practical to put one on the motherboard than use VEPA.

      • Ankur Singla

        Greg – I am surprised with your comments even after Juniper giving you an overview of our solution. Contrail supports both VXLAN and/or GRE (MPLS over GRE) – it does not require network device to support MPLS or LDP/BGP.

        At this time, Contrail does not support native MPLS over Ethernet yet (maybe if a customer asked for it, we will do it).

        –Ankur Singla

        • http://etherealmind.com Etherealmind


          If you have time, get in touch and lets discuss quickly. If I’m not correct lets get this fixed and corrected.

      • Randy Manning


        You are right about VEPA itself being dead on arrival… I was bringing it up, because I was curious about ANY technology to get the frame out of the hypervisor based soft switch and from there getting a eVPN tunnel built out. I worked with the FEX on Cisco UCS and that solution still had a soft switch (Nexus 1K). Again, frame still in a soft switch.

        In keeping with the soft switch and contrail, looks like Ankur beat me to the MPLS/GRE.

        Great discussion!

  • Duane Grant

    Hi Greg,

    I agree that not requiring end to end support is a good thing, but i’d also like to note that there are TOR switches out there that support MPLS features without much, if any cost penalty (using merchant silicon). Here is the MPLS feature set from a EX4550. I should note that you do have to license BGP on this box, but I suspect that you’d have to do something similar to run vxlan etc.


    • The following MPLS functionality is supported on EX4550 switches:
    – Label-switching router (LSr) and label edge router (LEr) functionality
    – rSVP and LDP for label assignment and distribution (LSP setup), and BGP for advertising label-switched paths (LSPs)
    – Traffic protection through standby secondary paths
    – Traffic-engineering capabilities provided by OSPF, IS-IS,
    Constrained Shortest Path First (CSPF), and rSVP-TE
    – Static LSPs
    – IPv4 over MPLS, IPv6 tunneling
    – BGP-based L2 VPNs
    – LDP-based L2 circuits
    – L3 VPNs for IPv4 and IPv6 unicast traffic
    – Circuit cross-connect (CCC)

  • John Burns

    Any updates on the Contrail comment? My main concern with flow based networking is that it doesn’t scale, back in the early 90’s we tried this, and MPLS won out as flow based networking was too expensive resources wise. I have been seriously looking at contrail. Too bad no VMWare support. I really think the mpls concepts weather wrapped in gre or vxvlan is the way to go. I am very skeptical of per flow networking, openflow in particular. The concept of replacing a switch with essentially a router seems appealing to me. I would really like to know if you have had chance to give this an in depth look?