Data Center Technologists
Data Center Technologists
MC-LAG is dead, Long live EVPN Multi-homing

Practically every day, it seems, someone will ask me: “How can I configure MC-LAG with EVPN to provide multi-homing?


The answer, I tell them, is simple:  you don’t need to.  EVPN is a superset of MC-LAG, and it natively integrates multi-homing. It’s like the better, standard version of MC-LAG that we’ve been waiting for.


EVPN, either with VXLAN or MPLS encapsulation, natively provides N-Way multi-homing by creating the same Ethernet Segment Identifier (ESI) on multiple devices. An ESI is configured on a per-interface basis; all interfaces configured with the same ESI, on any devices within the same EVPN domain, appear as part of the same L2 segment or LAG. On top of an ESI, it’s also possible to configure LACP to provide better fault detection.

Nothing special is required for an ESI, just a LAG or MC-LAG, with or without LACP. Anything can be connected to an ESI: servers, switches, Virtual Chassis configurations, firewalls, load balancers, routers—there are no restrictions. If needed, you can even inter-connect two EVPN instances with an EVPN/ESI on both sides.  See Figure 1 for examples.

Blog_evpn_1.pngFigure 1: Examples of Ethernet Segment Identifiers (ESIs)


On an EVPN/VXLAN fabric deployed inside a data center, EVPN multi-homing can be used to:

  • Connect a server to multiple TORs with an all-active LAG
  • Connect any devices to all spines with an all-active LAG


Figure 2: Mixed type of leaf in a EVPN/VXLAN deployment leveraging EVPN multi-homing


On any existing MC-LAG architecture, two pairs of devices running MC-LAG can be replaced with two or more devices running EVPN. Unlike MC-LAG, however, EVPN/ESI is not limited to two devices; in fact, it’s possible to have four, six, eight, or more physical devices participating in the same ESI.


Figure 3: Replace MC-LAG with EVPN/VXLAN at the Spine layer



Is MC-LAG Going to Die?

All of this begs the question: is MC-LAG going away?  Of course not—at least, not for a very long time.  Juniper is committed to supporting MC-LAG, and there are no plans to change that.  We have a lot of customers who have successfully deployed MC-LAG in their production networks, and there is no need for them to change, nor should they worry about it. MC-LAG has proven to be a robust solution to deploy a L2 Fabric, and it will continue to be.

Having said that, MC-LAG is one of the last proprietary protocols in the data center.  And its two-member limit has restricted our ability to create scale-out L2 fabrics in the past.

It’s great knowing that, with EVPN multi-homing, we have a successor to MC-LAG that improves on the technology’s two main weakness listed above.  


The Mystery of EVPN

When I explain multi-homing, the next question I hear is, why are so many people unaware of such an important feature? Initially, this question really surprised me; for me, it was the most interesting part of EVPN, and I assumed people already knew about it.


Later I came to realize that, outside of Juniper, most vendors haven’t implemented this part of EVPN and still rely on an MC-LAG-like technology at the edge of the fabric to provide multi-homing!  In fact, at the last EANTC interoperability tests in Berlin, only Nokia and Juniper were able to demonstrate a successful implementation of EVPN multi-homing. 

EVPN is not a single, monolithic standard; it is actually composed of multiple RFCs and other features, and as of today, nobody has finished implementing all of them. Each vendor has decided to focus on different parts, and as such, we are seeing some significant differences like multi-homing.  This also explains why multivendor interoperability is still not widely available today.


Hopefully, as everyone continues to implement EVPN, this situation will eventually change.  Soon, we’ll be able to enjoy a true multivendor EVPN implementation.


I’m glad Juniper has decided to prioritize multi-homing.  In my opinion, it’s one of the greatest feature of EVPN, and for some time now, EVPN/ESI have been supported across Juniper MX Series, EX Series, and QFX Series platforms.


If you want to investigate how to use EVPN/ESI to provide multi-homing, please read the Juniper white paper titled “Juniper Networks EVPN Implementation for Next-Generation Data Center Architectures.”  The multi-homing section begins on page 7.


Why can MC-LAG be dead? How would you implement EVPN at scale in Multicast and VXLAN environments?

Juniper Employee

Stefan, thanks for your comment

Indeed, MC-LAG is not dead and EVPN is not yet able to replace MC-LAG in all environments today. EVPN is a younger technology than MC-LAG but it's a very promising one. For the first time, we have a very serious and standard alternative to MC-LAG and the solution will be more robust over time.

On the multicast part, you're correct, EVPN is still missing some optimization as compare to MC-LAG, especially aroud Multicast. For a multicast heavy environment I would recommend MC-LAG. This is something we are actively working on.



The title is inspired by the general expression "The king is dead, long live the king" which mean that the next generation is here. In our case the transition is not as brutal as for the kings 



Great article. two more questions:

1)what are cases except mcast where i should prefer to use mlag instead  evpn?

2) as i know juniper has some limitation in ARP Proxy function. can you clarify which on?



Still don't get Juniper datacenter strategies

...if something is dead it's trill 

SPB give all that +multicast and it's easy !!!

I love to see that standard  in Juniper Switchs




Thanks for a nice article.

I very much agree with everything you wrote, including the part about EVPN being a young technology.

From a software maturity point of view, do you think the code that has EVPN VXLAN on the QFX5100 is ready for production ?

I'm not talking just about the code for the EVPN, but the entire Junos image that is required for this feature, is it recommended for production ?