Arista EOS MLAG: Multi-Chassis Link Aggregation Explained

In a traditional dual-homed data center design, Spanning Tree Protocol blocks half of the uplinks to prevent loops — which means you pay for bandwidth you cannot use. Arista EOS MLAG (Multi-Chassis Link Aggregation) solves this by making two physical switches behave as one logical switch, so every uplink forwards traffic simultaneously. This article explains the MLAG building blocks — peer link, peer address, domain ID and the MLAG System ID — and shows the core configuration and verification commands from the official EOS user manual.

Beyond the basics, this expanded version covers the complete configuration sequence in order, what actually happens during each failure scenario, how MLAG compares with the alternatives (Nexus vPC and EVPN multihoming), and the operational practices — reload delay, ISSU, VLAN consistency — that separate an MLAG deployment that survives failures from one that merely looks healthy in the lab.

How MLAG Works

Two switches in an MLAG domain connect through a peer link (a dedicated port-channel carrying control traffic and, when needed, data from single-attached devices). Each peer uses the peer address to form and maintain that link. The MLAG domain ID is a text string both switches must share, and the MLAG System ID (MSI) is the domain's MAC address, automatically derived when MLAG forms — it appears in STP and LACP PDUs so downstream devices see one switch, not two.

The illusion has two halves. On the control plane the peers synchronise MAC and ARP entries over the peer link, so either switch can forward a frame destined for a host reached through the other. On the data plane the pair presents the MSI as the system identifier in LACP, which lets a server bond uplinks to two different chassis in a single port-channel. The upstream switch sees one LACP partner; the server sees one logical link; both physical links forward at the same time.

The Four Building Blocks

The peer address is not a routing adjacency and does not need to be reachable through the rest of the network — it only needs to be reachable between the two peers, which is why a dedicated peer VLAN on the peer link is the standard design. Putting the peer addresses on a management network that also carries production traffic reintroduces exactly the dependency MLAG is meant to remove: if the management path fails, the pair loses synchronisation even though the data path is fine.

Configuration Essentials

VLAN parameters must be identical on both peers for the LAGs that make up the peer link and MLAGs: access VLAN, switchport mode, trunk-allowed VLANs, native VLAN and trunk groups. Configuration drift between peers is the number one cause of traffic loss in failure scenarios.

LACP should be used on all MLAG interfaces, including the peer link — LACP control packets reference the MLAG system ID, and LACP-based LAGs automatically deactivate miscabled ports instead of bridging traffic erroneously.

switch1(config)# interface ethernet 3-4
switch1(config-if-Et3-4)# channel-group 20 mode active
switch1(config)# interface port-channel 20
switch1(config-if-Po20)# mlag 20

Full Configuration Sequence

The peer link and the peer-address VLAN come first, because the mlag configuration block refers to them. The order below is the working sequence; applying it out of order produces commit errors that are easy to misread as a software problem.

! --- Peer link (switch1) ---
switch1(config)# vlan 100,4094
switch1(config)# interface port-channel 10
switch1(config-if-Po10)# switchport mode trunk
switch1(config-if-Po10)# switchport trunk allowed vlan 100,4094
switch1(config)# interface ethernet 1-2
switch1(config-if-Et1-2)# channel-group 10 mode active

! --- Peer address VLAN ---
switch1(config)# interface vlan 4094
switch1(config-if-Vl4094)# ip address 10.0.0.1/31

! --- MLAG domain ---
switch1(config)# mlag configuration
switch1(config-mlag)# domain-id DC1_MLAG_PAIR
switch1(config-mlag)# local-interface vlan 4094
switch1(config-mlag)# peer-address 10.0.0.2
switch1(config-mlag)# peer-link port-channel 10
switch1(config-mlag)# reload-delay mlag 300
switch1(config-mlag)# reload-delay non-mlag 330

On switch2 every value mirrors except the local address and the peer address, which swap. The reload-delay values give the peer time to restore its MLAG state after a reload before the non-MLAG interfaces start forwarding — 300 seconds is the standard recommendation, with the non-MLAG delay set slightly longer so that upstream-facing links come up last. Without a reload delay, a rebooted switch can bring up its uplinks before its peer link, briefly creating a black hole for traffic that arrives on the wrong side.

Then create the MLAG interfaces that face dual-homed devices:

switch1(config)# interface port-channel 20
switch1(config-if-Po20)# switchport mode trunk
switch1(config-if-Po20)# switchport trunk allowed vlan 100
switch1(config-if-Po20)# mlag 20
switch1(config)# interface ethernet 3-4
switch1(config-if-Et3-4)# channel-group 20 mode active

The mlag statement on the port-channel is what binds the local LAG into the domain; the LAG ID configured here must match on both peers. Note the deliberate difference from simply trunking two links: without the mlag command you have built two independent LAGs across two switches, and a server bonding to both will see an LACP mismatch rather than one logical link.

Failure Scenarios: What Actually Happens

MLAG is judged by its behaviour under failure, not by its steady state. Each scenario below is worth testing in a lab before trusting it in production.

The peer-link failure case is where most surprises live. When the peer link goes down, each peer must decide whether it is still the one that should forward traffic for dual-homed devices. EOS selects one peer to keep the MLAG ports active and disables them on the other, which is why a peer link sized for control traffic only can become a bandwidth limit if it also carried orphan-device data. Size the peer link for the orphan traffic it must carry, and monitor its utilisation as a first-class metric.

Dual-Homed Servers and LACP Behaviour

Servers, firewalls and storage arrays typically dual-home to an MLAG pair rather than to a single switch, and they validate the design every day by running LACP against the MSI.

• Configure LACP active on the switch side (channel-group N mode active) unless the peer is passive-only; active/active is the normal case for servers.
• Verify the server's view. From the server side, /proc/net/bonding/bond0 on Linux should show a single aggregator with both members in "selected" state and an 802.3ad partner system ID equal to the MSI.
• Keep VLAN membership identical on both peers for the MLAG port-channel, or the LACP bond comes up while one member silently drops a VLAN.
• Do not mix single-attached and dual-attached devices on the same MLAG port-channel. A single-attached device should be on its own ordinary access port; if it must be dual-attached without LACP, it depends on the peer link for reachability.

MLAG Compared with the Alternatives

MLAG remains the default choice for leaf-spine fabrics where dual-homing is straightforward, because it is simple to reason about and supported everywhere. EVPN multihoming becomes attractive when you need more than two leaves on one segment, or when you want the multihoming state to be carried by BGP instead of a peer link. The trade-offs are covered in EVPN multihoming vs MLAG: ESI, DF election and Clos, and the equivalent Nexus constructs in Nexus vPC: peer-gateway, orphan ports and health checks.

Verification Commands

Confirm MLAG health with the show mlag family of commands:

switch# show mlag
MLAG State:           active
Peer Link Status:     up
Peer Keepalive:       ok
MLAG Ports:           6 active, 0 inactive

Other useful variants include show mlag interfaces (per-port-channel MLAG status), show mlag peer-link (peer-link health), and show mlag issu warnings (upgrade compatibility before an ISSU).

Add a few more commands to the standard check to make the verification complete:

switch# show mlag detail
switch# show mlag configuration
switch# show mlag interfaces
switch# show run mlag configuration
switch# show lacp neighbor
switch# show interfaces port-channel 20
switch# show logging | grep -i mlag

Read them as a sequence. show mlag answers "is the domain healthy"; show mlag interfaces answers "which MLAGs are active and which are idle"; show lacp neighbor proves the downstream bond sees the MSI rather than one physical switch; and the log answers the question nobody thinks to ask until an outage — whether the domain has been quietly flapping for weeks.

What a Healthy Domain Looks Like

• MLAG State reports active on both peers, not primary/secondary alone.
• Every expected MLAG port-channel is active on both peers, with matching LAG IDs.
• Peer-link utilisation is well below capacity and its error counters are clean.
• The MAC address table contains entries learned via both the local ports and the peer link.
• show mlag issu warnings returns no blocking conditions before an upgrade.

Operational Best Practices

• Automate config comparison between peers. Diff the running-config of both switches on a schedule; drift is the leading cause of MLAG outages, and it is trivially detectable.
• Test the failure modes, not the happy path. Shut one MLAG member, then the peer link, then a whole peer, in a lab or during a maintenance window, and record the convergence behaviour.
• Keep the peer link dedicated. Its job is control-plane synchronisation plus orphan data; running production VLANs across it invites exactly the congestion that causes sync loss.
• Always configure reload delays on both peers so a simultaneous reboot does not black-hole traffic.
• Check ISSU compatibility before any upgrade with show mlag issu warnings; MLAG pairs have upgrade sequencing rules.
• Document the domain ID and LAG IDs in your IP plan. Two adjacent domains sharing a domain ID is a subtle misconfiguration that produces strange pairing behaviour.

Why It Matters

MLAG provides Layer 2 multipathing with sub-second failover: when one peer or one link fails, the remaining paths keep forwarding and the peer keeps MAC/ARP state synchronized. It is the foundation of most Arista leaf-spine designs. See 叶脊数据中心网络架构设计 and Arista EOS CLI 模式指南 for more on Arista architectures and CLI foundations.

原文链接：https://www.arista.com/en/um-eos/eos-multi-chassis-link-aggregation