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

MPLS-Frame-Transformation-595-opt.png

 

 

Now, consider how VXLAN works in a similar diagram.

VXLAN-Frame-Transformation-595-opt.png

 

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.

About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

You can contact Greg via the site contact page.

  • 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

          Ankur

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

      • Randy Manning

        Greg,

        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!
        Randy

  • 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.

    MPLS

    • 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)

Subscribe For Weekly Updates by Email

Get a Weekly Summary of Latest Articles and Posts to your Email Inbox Every Sunday

Thanks for signing up. Look for the email from MailChimp & make sure you confirm your email address. You may need to check your spam or gmail settings to be sure of receiving the email.

Note: You can unsubscribe at any time using the link at the bottom of every email.