Configure Mlag On Arista Eos

What is MLAG in the context of network switches? It stands for Multi-Chassis Link Aggregation. Well, it’s like M + LAG, where LAG is that standards-based port channel thingy. The chassis part here could be a 12 slot modular switch with the size of a typical American refrigerator, or a pizza box sized 1RU fixed configuration switch. It’s all about food. Big or small, all switches need a chassis to hold the components together.

A typical network engineer should not really worry about these details, and whether we have two giant refrigerators or two pizza boxes as switches – the MLAG part of the switch configurations will be the same. The key thing here is that both MLAG peers must be of the same make/model.

The ‘Multi’ word suggests that there is more than one switch in the mix. Can I have, say 5 switches, in an MLAG domain? The answer is nope. Only two. If I was really bored, I would submit a request to rename this solution to ‘Two chassis/fixed config switches using shared LAG’. Unfortunately, my naming schema sucks, and my time and boredom are limited, so we will stick with MLAG this time around.

See, the whole thing about bundling two switches in an MLAG is to fool the next device attached to these two to think that it’s attached to a single switch. Forget about whatever marketing told you! This ‘next’ device can be a server, switch, router, firewall, or another pair of switches running MLAG. A server, for example, would typically have one link to switch A, and a second link to switch B. This server will happily build a standard port channel toward these two switches thinking that it’s connected to a single switch. MLAG pair of switches also appear as one logical L2 bridge in terms of Spanning Tree Protocol. Thus also fooling the good old STP.

With all this cleared, it’s time to focus on MLAG configuration. The example shown above contains complete configuration necessary to bring up two MLAG peers, A and B. I recommend taking a screen shot of the above config and compare it side-by-side with the explanations that follow…

Let’s break down the MLAG configuration pieces.

STP mode can be MSTP (recommended) or any other flavor.

Vlans 10 and 11 here would typically be server vlans.

Spanning tree is disabled for vlan 4094 b/c this vlan is used only for communication between peer A and peer B. This vlan is also added to trunk group PeerVLAN, so that it’s not trunked on all trunk ports by accident. Vlan 4094 is only trunked on port channel 1000. More on this later.

Port channel 10 could be connected to a server, router, another switch, firewall, or another pair of switches in MLAG. Adding ‘mlag 10’ statement to this port channel makes it a multi-chassis port channel as opposed to standard port channel. Additional port channels toward other devices would be configured in the same way as port channel 10, using their own unique mlag numbers. It’s best practice to match the port channel number and the mlag number.

Port channel 1000 is used to connect MLAG peers A and B. Control Plane communication between peer A and B happens over this port channel. ‘switchport trunk group PeerVLAN’ command on this port channel permits vlan 4094, while ‘switchport mode trunk’ permits all other vlans. Without the trunk group statement vlan 4094 is implicitly denied on a trunk port. Effectively, vlan 4094 is only trunked on port channel 1000. Notice that port channel 1000 doesn’t have ‘mlag x’ statement b/c this is a standard port channel between two switches.

MLAG domain-id must match on both peers. It’s only locally significant within the MLAG domain. In this example domain-id is ‘Arista’, but it can be anything.


  • STP still runs with MLAG, but the two peers appear as one logical L2 bridge. Use ‘show spanning-tree’ command to view the STP topology
  • One peer will be primary, the other secondary. It doesn’t really matter which one is primary b/c they are both active and forwarding traffic
  • Vlans must be configured on both switches – adding vlans to just one MLAG peer is not enough
  • If you configure routing on the MLAG peers’ uplinks, each MLAG peer will act independently – will use unique IP’s, establish its own peerings and make its own routing decisions
  • You can establish routing between MLAG peers using SVI’s
  • MLAG is an L2 concept and it doesn’t care if you configure VRF’s – feel free to do so
  • VXLAN is supported with MLAG
  • For first hop default gateway VARP (active/active) or VRRP (primary/standby) can be used
  • MLAG peers are managed independently – each using a unique management IP
  • With modular chassis, best practice is to connect ports on different line cards for the peer-to-peer port channel, for best redundancy
  • Vlan 4094 subnet should not be advertised into a routing protocol
  • Servers and other devices can still have just a single connection to one of the MLAG peers, A or B switch, although it’s best to have two links for redundancy
  • MLAG validation and troubleshooting will be covered in a separate post