Arista EOS MLAG Step by Step: Peer Link and Domain Setup

MLAG turns two Arista switches into one logical switch for the devices connected below them: a server or downstream switch bundles one link to each peer into a single LACP port channel, and both links stay active. The price of that elegance is that every part of the MLAG control plane must be configured in the right order — peer link, MLAG VLAN, domain and member ports — because a peer-link flap or a mismatched domain-id produces split-brain behavior that is painful to troubleshoot at 2 AM. This is the field-tested step-by-step procedure.

What MLAG Solves — and What It Does Not

MLAG exists to remove spanning tree from the access layer without giving up redundancy. Without MLAG, a server with two NICs cabled to two switches has only one useful path: spanning tree blocks the other, and you either accept half the bandwidth or run a different protocol. With MLAG, both links are bundled into a single LACP port channel that terminates on two different chassis, so both links forward and either switch can fail without the server noticing.

What MLAG does not do is give you a routed fabric. It is a Layer 2 construct that is local to a pair of switches; scale beyond a rack and you either add more MLAG pairs with a routed core or move to an EVPN multihoming design where ESI-LAG replaces the peer link entirely. MLAG also does not protect against a bad configuration — a mismatched MLAG ID or a divergent VLAN database produces an outage that looks like a hardware fault. If you are choosing between the two approaches at fabric scale, EVPN multihoming versus MLAG compares ESI, DF election and the operational trade-offs.

MLAG Terminology

Two of these cause most of the trouble in the field: the domain-id, which is case-sensitive and silently prevents the pair from forming if it differs by one character, and the MLAG ID, which must be the same number on both peers or the member port channel will refuse to come active on one side.

Prerequisites

• Both switches running the same EOS version, or a validated interop pair (mismatched versions are for upgrade windows, not steady state).
• At least two physical links bundled into the peer-link port channel — never run an MLAG peer link on a single cable.
• A separate Layer 3 path (routed SVI) for the MLAG heartbeat so a peer-link failure does not kill the keepalive.
• Consistent VLAN databases on both switches before enabling MLAG.
• A domain-id unique to this pair if multiple MLAG domains share the data center.
• Reload-delay tuned so a rebooted peer does not briefly black-hole traffic while it comes back up.

Step 1: Build the Peer-Link Port Channel

interface Ethernet47
   description MLAG-PEER-LINK
   channel-group 4094 mode active
   no shutdown
!
interface Ethernet48
   description MLAG-PEER-LINK
   channel-group 4094 mode active
   no shutdown
!
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 in active mode rather than a static bundle — it detects cabling mistakes on the peer link automatically. The configuration is identical on both peers.

The peer link is a normal port channel for configuration purposes, but EOS treats it specially: it never becomes an MLAG member port, and all VLANs that need to reach the peer switch must be allowed on it, including VLAN 4094. That is why the allowed-VLAN list above is explicit rather than a blanket switchport trunk allowed vlan all. Explicit lists make an accidental VLAN leak obvious in a show run diff, which matters when the peer link is also carrying data traffic for orphaned devices.

Step 2: Create the MLAG Peer VLAN and SVI

By Arista convention VLAN 4094 is reserved for MLAG inter-peer communication. Put it in a dedicated trunk group so it only traverses the peer link and cannot leak onto downstream ports:

interface Vlan4094
   ip address 169.1.1.1/30
   no autostate
   mtu 9214
!
interface Port-Channel4094
   switchport trunk group MLAG-Peer

no autostate keeps the SVI up even when no L2 member is forwarding — essential for the peer heartbeat. The mtu 9214 allows the control traffic to use jumbo frames.

The trunk group is the part engineers skip, and it is the part that prevents a subtle failure. A trunk group is a named set of ports that share membership rules — here, VLAN 4094 is only allowed to exist on ports in the group. Without it, VLAN 4094 can end up on an access-facing port, or worse, on a port that connects to another MLAG domain, and the two MLAG control planes start talking to each other. The heartbeat IP range should also be a dedicated /30 that exists nowhere else in the network.

Step 3: Define the MLAG Domain

mlag configuration
   domain-id AristaMLAG1
   local-interface Vlan4094
   peer-address 169.1.1.2
   peer-link Port-Channel4094

The domain-id is case-sensitive and must match exactly on both peers. The local-interface is the SVI used as the MLAG source, peer-address points at the other switch's SVI, and peer-link names the port channel built in step 1. Repeat this configuration on peer 2 with its own local-interface IP (169.1.1.2) pointing back at 169.1.1.1.

Add reload-delay once the domain is up. It controls how long each switch waits before bringing up MLAG and non-MLAG interfaces after a reload, so traffic is not forwarded into a half-initialised pair:

mlag configuration
   reload-delay mlag 300
   reload-delay non-mlag 330

Non-MLAG interfaces should always come up later than MLAG interfaces, so the pair has time to agree on state before orphaned devices start forwarding.

Step 4: Configure MLAG Member Port Channels

Downstream port channels that span both chassis get an MLAG ID — it must be identical 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

Repeat the same member port channel on the second peer, using its own physical interface and the same Port-Channel number and MLAG ID. Consistency rules apply to everything that matters: the port channel number, the MLAG ID, the mode (trunk or access), the native VLAN and the allowed VLAN list must all match. If they do not, show mlag reports the peer configuration as inconsistent and the member stays inactive on one side, which is a fail-open condition you will discover only when the other side of the bundle goes down.

Step 5: Bring Up the Second Peer

Configure peer 2 with the mirrored settings, changing only what must differ — the local interface IP and the peer-address:

interface Vlan4094
   ip address 169.1.1.2/30
   no autostate
   mtu 9214
!
mlag configuration
   domain-id AristaMLAG1
   local-interface Vlan4094
   peer-address 169.1.1.1
   peer-link Port-Channel4094
   reload-delay mlag 300
   reload-delay non-mlag 330

Apply the domain configuration while the peer link is already up, so the two switches negotiate immediately. If you configure MLAG before the peer link is forwarding, the domain will sit in a negotiating state until the port channel comes up — which is fine, but confusing if you are checking state mid-build.

Verification

switch# show mlag
switch# show mlag detail
switch# show mlag interfaces
switch# show port-channel 10 mlag

show mlag reports the domain state, peer-link status and whether both peers agree on the MLAG configuration; the interface output confirms which port channels are active MLAG members. Read it in this order:

switch# show mlag
MLAG Configuration:
domain-id                          : AristaMLAG1
local-interface                    : Vlan4094
peer-address                       : 169.1.1.2
peer-link                          : Port-Channel4094
peer-config                        : consistent

MLAG Status:
state                              : Active
negotiation status                 : Connected
peer-link status                   : Up
local-int status                   : Up
system-id                          : 001c.73d4.5a6b

MLAG Ports:
Disabled                           : 0
Configured                         : 0
Inactive                           : 0
Active-partial                     : 0
Active-full                        : 2

state: Active means the domain is running. peer-config: consistent means both peers agree on the MLAG configuration — if this reads inconsistent, stop and fix it before trusting any member port. Active-full means the member port channel is up on both peers; Active-partial means it is up on only one, which is the state that silently halves your redundancy.

switch# show mlag interfaces
                     local/remote
 mlag   state         local          remote        oper   config
----- --------------- -------------- -------------- ------ ---------
    10 active-full      Po10           Po10           up     up

Re-run this after every change to a member port channel. A member that drops to inactive usually means a VLAN list, native VLAN or mode mismatch between the two peers — not a physical problem.

Failure Behaviour You Must Plan For

• Peer link down, peer switches alive. The domain goes to a single-primary state. Both switches keep their MLAG member ports up, but the peer link no longer carries traffic, so any orphaned device — one with a link to only one peer — loses connectivity unless a path exists through the rest of the network.
• Peer link down with the heartbeat also down (dual primary). Both switches believe they are the primary. The MLAG members stay up on both sides, LACP partner system IDs may differ, and you can get a duplicate MAC entry and a loop if the two peers are still connected through a routed or L3 path. This is the split-brain you plan for, not the one you debug at 2 AM.
• Single peer reload. Traffic for the reloading peer's MLAG members is redirected over the peer link to the surviving switch, so the peer link must have enough headroom. Reload-delay then controls how quickly the rebooted switch rejoins.

EOS can detect the dual-primary condition by watching for the peer's MLAG control packets on non-peer-link interfaces, and you can configure what happens when it fires:

mlag configuration
   domain-id AristaMLAG1
   dual-primary detection delay 5 action errdisable all-interfaces

Treat this as a containment measure rather than a design goal. If a dual-primary event occurs, the correct fix is to restore the peer link and the heartbeat path, then investigate why both failed at once — a shared PDU, a shared upstream switch, or a fibre bundle that runs through the same conduit are the usual answers. The detailed symptom walkthrough lives in Arista EOS MLAG troubleshooting: peer-link and dual-primary.

MLAG and First-Hop Redundancy

MLAG solves Layer 2 redundancy; it does nothing for the default gateway. That is the job of VARP (or VRRP), which lets both peers share one virtual IP and one virtual MAC across the MLAG member SVIs. The combination is what makes a server rack genuinely active-active: LACP for the links, VARP for the gateway. Configure the VARP virtual address on each MLAG member SVI and verify with show ip virtual-router; the full procedure is in Arista EOS VARP: active-active gateway with MLAG.

Interaction with Spanning Tree

MLAG members should never participate in spanning tree as edge ports. Keep no spanning-tree portfast on the peer link and make sure BPDU Guard is not left enabled on the member ports facing a downstream switch (it is fine, and desirable, facing servers). If the downstream device is a switch rather than a server, it will send BPDUs and the port will be shut by BPDU Guard — a self-inflicted outage that looks like an MLAG failure. On the peer link itself, spanning tree is mostly irrelevant because the peer link is not a member port, but keeping the config explicit avoids surprises. The edge-port and guard patterns are covered in Arista EOS spanning-tree PortFast and BPDU Guard.

Common Mistakes

• Single-cable peer link. A peer-link failure then removes the only inter-peer path, and any orphaned device goes down with it.
• Heartbeat riding the peer link. If the peer-address is reachable only across the peer link, the heartbeat disappears exactly when you need it, and you get dual primary.
• VLAN 4094 in the wrong trunk group. It leaks onto downstream ports and confuses the control plane.
• Different allowed-VLAN lists on the two peers' member port channels. The port channel comes up on one side and stays inactive on the other.
• Forgetting no autostate. The heartbeat SVI goes down when the last L2 member leaves, and the domain bounces.
• Mismatched EOS versions during a partial upgrade. The pair can come up but report inconsistent configuration; do upgrades as a pair, one peer at a time, and verify show mlag between steps.

FAQ

Does the peer link have to be VLAN 4094? No — 4094 is a convention, not a requirement. Any unused VLAN works as long as it is consistent on both peers and reserved for MLAG.

Can I run MLAG over a routed link between the peers? No. The peer link is a Layer 2 port channel; it must be a direct L2 connection between the two switches. A routed path can serve as a heartbeat backup but not as the peer link.

How many MLAG members can I configure? EOS supports large numbers of MLAG members per domain, but the practical limit is the peer link's bandwidth. Every packet that arrives on one peer for a member port whose local link is down must cross the peer link.

What is the fastest way to confirm the pair is healthy? Two commands: show mlag for state: Active and peer-config: consistent, then show mlag interfaces for active-full on every member.

Compare the concept with Cisco's equivalent in our NX-OS vPC configuration guide, or go deeper on troubleshooting in the complete MLAG run book. For the underlying bundle mechanics, see Arista EOS port-channel and LACP configuration.

原文链接：https://infrarunbook.com/article/arista-eos-mlag-configuration-step-by-step