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