Multichassis LAG concept is common in datacenter environment. Arista called it MLAG. However, some customer can demand multi vendor environment. As you know, in MLAG/MCLAG/VPC environment, there is software restriction being familiar or same vendor should be, etc. for redundant peer switch. But there is another concept that is Active Active Multihoming via EVPN-VXLAN which use Ethernet Segment Identifier.(ESI). ESI number is 10 bytes .

In this environmet, you can use multi vendor. Simple mentality is advertisement these ESI number and mac addresses behind it. Each interface should has an ESI number. When you check our topology, there is no link between LEAFs pairs as in MLAG environment. There is EVPN-VXLAN design between Spine and Leafs here. In MLAG EVPN-VXLAN design, we were configuring loopback1 IPs in LEAFS pairs and they were same IP. This IPs were VXLAN tunnels IPs. So, redundancy were provided via this. You can read my previous post about it. But this is different in Active Active Multihoming EVPN-VXLAN design.

Critical Point

Most critical point is Loopbacks of Leafs for VXLAN tunnels are not same in this environment. Loopbacks will be different and VXLAN tunnels will be up with these loopbacks IPs. Only loopback0 is enough for this environment. But remember, there was loopback0 for EVPN and loopback1 in MLAG environment and loopback1 IPs were same in LEAF pair.

So there are different VXLAN tunnels.But, how mac addresses behind port-channel interfaces in LEAF1-LEAF2 pairs will be advertised if there is no MLAG environment and VXLAN tunnels are different? Imagine that one of tunnels were down and mac adress is on that down leaf. How will it be advertised to other tunnel when there is no MLAG connection on Leafs? Answer is ESI. Becase all mac address will be associated to common ESI number per interface and this ESI number will be advertised over different tunnels. So even if one tunnel is down, ESI number will continue over other tunnel. Then even if our LEAFS are single devices, it will be redundant. No software restriction, no MLAG cable between LEAFS, no vendor restriction.

Configuration Samples

I will not share underlay EVPN-VXLAN configuration here, please check above post that I linked for that. Connection between LEAFS and SPINEs are layer 3 and there is EBGP and EVPN.

Remember that loopback0 is both EVPN and VXLAN Tunnel source IP in active active multihoming.


interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 100 vni 20100

ESI Configuration Sample


interface Port-Channel1
switchport mode trunk
evpn ethernet-segment
identifier 0050:0c00:0700:0700:0000--->manual generated.
route-target import 50:0c:00:07:00:07
lacp system-id 500c.0007.0007
–> this is random mac address. You can use mac of connected device. If you don’t add this lacp system ID, portchannel will not be up.


interface Port-Channel1
switchport mode trunk
evpn ethernet-segment
identifier 0050:0c00:0800:0700:0000---> manual generated
route-target import 50:0c:00:08:00:07
lacp system-id 500c.0008.0007
this is random mac address. You can use mac of connected device.If you don’t add this lacp system ID, portchannel will not be up.

Beneficial Commands

show bgp evpn summary

show bgp neighbors x.x.x.x evpn routes

show bgp neighbors x.x.x.x evpn advertised-routes

See below screenshot shows that next-hop includes ESI number of interface which advertises 500c.008e.0d05 mac adress of customer2.

[huge_it_gallery id=”55″]

Notes: You can find more information in below my UDEMY link about this subject.

By Mahmut Aydin

CCIE R&S #63405

6 thoughts on “Active/Active Multihoming via EVPN-VXLAN in Arista”
  1. Thanks for this article. But I can’t configure evpn multihome active-active without iBGP end EVPN sessions between leaf3 and leaf4. Could you share full config for both spines and leaf3 and leaf4 nodes please?

    1. Dear Roman,

      You do not need configure IBGP in Arista deployment. Leafs will establish EBGP with spines and again EVPN neighorship with loopbacks. So leafs will advertise its mac address to Spines. Spine will advertise to other leafs.
      Spine will behave like route reflector.
      you can send me mail to or for any details.

  2. Because we do not use ibgp and RR, spine1 receive route update from leaf1 and send it to leaf2 for the same ethernet segment (customer1), spine2 will do same thing with leaf3 and leaf4(customer2). Is it a problem or it’s normal condition?

    1. Hi Vladimir,

      Why do you think that it is problem? Spines will provide active active redundancy.

Leave a Reply

Your email address will not be published.