Arista EOS MLAG Configuration Step by Step

MLAG is one of those Arista features that looks trivial on paper and then bites you at 2 AM because of a peer-link flap or a mismatched domain-id. I have deployed it in data center leaf pairs, in campus distribution layers, and in a couple of ugly retrofits where someone had already cabled things wrong before I showed up. This walkthrough covers the whole process the way I actually do it in the field, not the abbreviated version you get from a slide deck.

The idea behind MLAG is simple: two physical switches present themselves as a single logical switch to downstream devices, so you can build port channels that span both chassis. Downstream servers or switches see one LACP bundle. Behind the scenes, the two Arista switches are exchanging state over a dedicated peer link and coordinating MAC tables, ARP entries, and forwarding decisions. Get the peer link and the VLAN mapping right, and MLAG is one of the most reliable resiliency mechanisms in EOS. Get it wrong, and you get split-brain behavior that is genuinely painful to troubleshoot.

Prerequisites

Before you touch the config, make sure the following are true. Skipping any of these is where most MLAG deployments go sideways.

• Two Arista switches running the same EOS version, or at minimum a version pair that Arista has validated for MLAG interoperability. Mismatched versions are supported for short upgrade windows, not as a steady state.
• At least two physical links between the peers dedicated to the MLAG peer link, bundled into their own port channel. I never run a peer link on a single link — if that link dies, you lose the whole point of MLAG.
• A separate Layer 3 peer-address link, or a routed SVI, for the MLAG control plane heartbeat. Some designs share this with the peer link VLAN; I prefer to keep it distinct so a peer-link failure doesn't also kill the keepalive path.
• Consistent VLAN databases on both switches before you enable MLAG — trunk the same VLANs on the peer link that you plan to trunk on the MLAG-connected port channels.
• A domain-id that's unique to this MLAG pair if you have multiple MLAG domains in the same data center. I have seen two unrelated MLAG pairs accidentally share a domain-id after a copy-paste from a run-book, which caused all kinds of confusing peer-address conflicts.
• Console or out-of-band management access to both switches. Don't configure MLAG peer links over the same interfaces you're managing the switch through, in case something goes wrong mid-configuration.

In this example I'm using two switches, sw-infrarunbook-01 and its MLAG peer, connected back to back with two 10G links for the peer port channel. The peer link VLAN will be VLAN 4094, a convention I like because it keeps the MLAG control VLAN clearly out of the way of any production VLAN ranges.

Step-by-step setup

1. Configure the peer link port channel

Start by bundling the physical interfaces that connect the two switches directly. This becomes the MLAG peer link.

interface Ethernet1
   description MLAG-PEER-LINK
   channel-group 4094 mode active
!
interface Ethernet2
   description MLAG-PEER-LINK
   channel-group 4094 mode active
!
interface Port-Channel4094
   description MLAG-PEER-LINK
   switchport mode trunk
   switchport trunk allowed vlan 1,10,20,30,4094
   no spanning-tree portfast

Use LACP (mode active) rather than static bundling here. It gives you a sanity check — if the peer link isn't actually forming an LACP relationship, you'll see it immediately instead of discovering a half-up bundle later.

2. Create the peer-link VLAN and SVI

VLAN 4094 carries the MLAG control traffic between the two switches. Give it an SVI with a /30 or /31 point-to-point address on each side.

vlan 4094
   name MLAG-PEER
   trunk group mlagpeer
!
interface Vlan4094
   description MLAG-PEER-LINK-SVI
   ip address 192.168.100.1/30
   no autostate

The peer switch mirrors this with

ip address 192.168.100.2/30

. Don't route this VLAN anywhere else in your network — it should be a strictly local, point-to-point segment between the MLAG pair.

3. Configure the MLAG domain

This is the section that actually turns the pair into an MLAG domain. Both switches need a matching domain-id, but the local-interface and peer-address will differ because they're pointing at each other.

mlag configuration
   domain-id MLAG-DC1-POD3
   local-interface Vlan4094
   peer-address 192.168.100.2
   peer-link Port-Channel4094
   reload-delay mlag 300
   reload-delay non-mlag 330

The reload-delay values matter more than people give them credit for. They control how long the switch waits after a reload before bringing up MLAG and non-MLAG interfaces, giving the peer time to come up and sync state first. I set non-mlag slightly higher than mlag so that MLAG ports have already stabilized before other interfaces start forwarding — this avoids a brief window where traffic gets forwarded asymmetrically right after a reload.

4. Build the downstream MLAG port channel

Now configure the port channel that will actually carry production traffic to a downstream device — a server, a leaf switch, whatever is dual-homed to this MLAG pair. The key addition here is the

mlag

command inside the port channel, which must use the same MLAG ID on both peers.

interface Ethernet10
   description TO-SERVER-01
   channel-group 10 mode active
!
interface Port-Channel10
   description TO-SERVER-01-MLAG
   switchport mode trunk
   switchport trunk allowed vlan 10,20,30
   mlag 10

The

mlag 10

value has to match exactly on the peer switch's Port-Channel10 (or whatever local number you used there — the local port-channel numbers don't need to match, but the mlag ID does). This is one of the more common sources of confusion: engineers assume the port-channel number itself is the shared identifier, when it's actually the mlag ID underneath it.

5. Repeat the mirrored configuration on the peer switch

Everything above gets mirrored on the second switch, with the local-interface and peer-address swapped, and using its own local port-channel numbering if you want it to differ (I usually keep it consistent for sanity, but EOS doesn't require it).

Full configuration example

Here's the complete configuration for sw-infrarunbook-01, the primary switch in the pair:

hostname sw-infrarunbook-01
!
vlan 10
   name SERVERS
vlan 20
   name STORAGE
vlan 30
   name MGMT
vlan 4094
   name MLAG-PEER
   trunk group mlagpeer
!
interface Ethernet1
   description MLAG-PEER-LINK
   channel-group 4094 mode active
!
interface Ethernet2
   description MLAG-PEER-LINK
   channel-group 4094 mode active
!
interface Port-Channel4094
   description MLAG-PEER-LINK
   switchport mode trunk
   switchport trunk allowed vlan 1,10,20,30,4094
   no spanning-tree portfast
!
interface Vlan4094
   description MLAG-PEER-LINK-SVI
   ip address 192.168.100.1/30
   no autostate
!
interface Ethernet10
   description TO-SERVER-01
   channel-group 10 mode active
!
interface Port-Channel10
   description TO-SERVER-01-MLAG
   switchport mode trunk
   switchport trunk allowed vlan 10,20,30
   mlag 10
!
mlag configuration
   domain-id MLAG-DC1-POD3
   local-interface Vlan4094
   peer-address 192.168.100.2
   peer-link Port-Channel4094
   reload-delay mlag 300
   reload-delay non-mlag 330
!
spanning-tree mode mstp
spanning-tree mst 0 priority 4096

And the peer, sw-infrarunbook-02 in this pair (not shown in full, since it mirrors the above), differs only in the Vlan4094 address (192.168.100.2/30) and the mlag configuration's peer-address (192.168.100.1). Everything else — VLAN database, trunk allowed lists, spanning-tree priority — should be identical between the two switches. I make spanning-tree priority identical on purpose; MLAG peers should present as a single root candidate, not compete with each other.

Verification steps

Once both sides are configured, don't just eyeball the running-config and call it done. Walk through actual verification commands.

First, confirm the MLAG state itself:

sw-infrarunbook-01#show mlag
MLAG Configuration:
domain-id                    : MLAG-DC1-POD3
local-interface               : Vlan4094
peer-address                  : 192.168.100.2
peer-link                     : Port-Channel4094

MLAG Status:
state                         : Active
negotiation status            : Connected
peer-link status               : Up
local-int status               : Up
system-id                     : 02:1c:73:aa:bb:cc

You're looking for

state: Active

and

negotiation status: Connected

. If it shows

Negotiating

for more than a few seconds after both sides are configured, something's off — usually a VLAN mismatch on the peer link or an ACL blocking the peer-address traffic.

Next, check the individual MLAG interfaces:

sw-infrarunbook-01#show mlag interfaces
MLAG     Local
Interface  Interface  Local State  Peer State  Config
---------  ---------  -----------  -----------  ------
10         Po10       Active       Active       Consistent

The

Config

column showing

Consistent

is what you actually care about here. If it says

Inconsistent

, EOS is telling you the two switches disagree about something on that port channel — usually allowed VLANs, trunk mode, or speed/duplex settings on the underlying member ports.

Check the peer link separately, since it's a normal port channel underneath the MLAG abstraction:

sw-infrarunbook-01#show port-channel 4094 summary
sw-infrarunbook-01#show lacp neighbor

And confirm reachability and consistency checks across the peer:

sw-infrarunbook-01#show mlag detail
sw-infrarunbook-01#ping 192.168.100.2 source Vlan4094

show mlag detail

gives you the dual-control-plane checks — things like whether the two switches agree on the MLAG domain-id, whether STP is behaving consistently, and whether there are any config-sanity mismatches on the trunk group. I run this command as a matter of habit any time I make a VLAN change to an MLAG pair, because it's the fastest way to catch a forgotten VLAN add on one side.

Finally, verify from the downstream device's perspective. If it's a server with LACP bonding, check that it sees a single logical bundle with both links active — not two separate single-link bundles, which is the classic symptom of an MLAG ID mismatch.

Common mistakes

I've made most of these myself at some point, so take this as a list of scars rather than theory.

Forgetting to allow the peer-link VLAN on intermediate ports. If your peer link physically runs through anything other than a direct back-to-back connection, make sure every hop trunks the MLAG VLAN. It sounds obvious until someone reconfigures a patch panel or a transit switch and quietly drops VLAN 4094 from the allowed list.

Using the same VLAN for the peer link and a production VLAN. Keep the MLAG control VLAN dedicated. I've seen someone reuse a management VLAN for the peer link SVI, and when that VLAN's spanning-tree topology changed elsewhere in the network, it caused MLAG flaps that had nothing to do with the MLAG pair itself.

Mismatched reload-delay values causing traffic black-holing after a reboot. If reload-delay isn't tuned, a switch can start forwarding on non-MLAG interfaces before its peer relationship and MAC table sync have finished, leading to a short but real window of dropped or duplicated traffic right after maintenance.

Single-link peer links. This defeats half the purpose of MLAG. Always bundle at least two physical links for the peer link so a single optic or cable failure doesn't take down your control plane.

Inconsistent VLAN allowed-lists between the two switches' MLAG-facing port channels. EOS will flag this as

Inconsistent

in

show mlag interfaces

, but I've seen people ignore that column because everything still passes traffic — until the VLAN that's missing on one side is exactly the one that matters during a failover.

Not testing failover before going live. Reload one peer intentionally during a maintenance window and watch what happens to the downstream port channel. If you've never actually tested a peer failure, you don't really know your MLAG pair is resilient — you're just assuming it.

Mismatched EOS versions left in place long-term. A brief version skew during a staged upgrade is normal and supported. Leaving two MLAG peers on different major EOS releases for months, though, is asking for subtle feature-compatibility issues that are hard to diagnose because they don't show up as an obvious MLAG state error.

Forgetting

no autostate

on the peer-link SVI. Without it, the SVI can go down if all the VLAN's other ports are down, which in some topologies can create a chicken-and-egg problem with bringing the peer relationship up cleanly.

MLAG is dependable once it's running, but it rewards careful, symmetric configuration and punishes shortcuts. Every time I've had an MLAG-related incident, it traced back to one of the mistakes above rather than an actual EOS bug. Build the peer link redundantly, keep both switches' configs symmetric, verify with

show mlag detail

after every change, and actually test a failover before you trust it in production.