Arista EOS MLAG Dual-Primary Detection & Split-Brain

MLAG on Arista EOS makes two switches look like one for downstream LACP devices, but it
introduces a failure mode that a plain LAG does not have: if the peer-link fails while both
switches are still healthy, both believe they are primary and the pair starts forwarding
duplicates. This is the dual-primary condition. Arista ships two mechanisms against it —
dual-primary detection, which err-disables interfaces on the secondary, and
dual-primary recovery delay, which staggers how interfaces come back so L3 can
converge first. This article covers the MLAG build, both timers, and what the documentation's
error-handling section hints at when detection cannot help.

How MLAG Failover Actually Works

MLAG pairs exchange two things: a TCP peer-link session carrying control messages, and a
UDP heartbeat. The TCP peer-link carries the L2 state — MAC entries, MLAG configuration, and
the MLAG peer-link SVI. The heartbeat is what proves the peer is alive when the peer-link is
not.

Peer-link failure is the trigger for dual-primary. Juniper's MC-LAG uses ICCP for the same
purpose; the concepts map one-to-one, and the failure taxonomy is worth reading in parallel
(see Juniper MC-LAG: ICL vs ICCP failure behaviour).

Known triggers for a peer-link break on EOS:

• MLAG configuration changes that are not applied symmetrically
• The TCP connection dropping because the MTU of the MLAG peer-link SVI is larger than the L2 MTU
• The peer-link or the local interface going down

That MTU case is easy to create and hard to spot: the peer-link SVI must be able to carry
the largest frame the MLAG carries.

Building the MLAG Pair

! Peer-link: a port-channel carrying all VLANs, on both switches
interface Port-Channel1000
   description MLAG-PEER-LINK
   switchport mode trunk
   switchport trunk group MLAG-TRUNK
   no shutdown
!
interface Ethernet1-2
   channel-group 1000 mode active
!
! MLAG domain
mlag configuration
   domain-id DC1-PAIR
   local-interface Vlan4094
   peer-address 10.255.0.2
   peer-link Port-Channel1000
   reload-delay mlag 300
   reload-delay non-mlag 330
!
! Peer-link SVI — MTU must match the L2 MTU everywhere in the path
interface Vlan4094
   description MLAG-PEER-SVI
   ip address 10.255.0.1/30
   mtu 9214
   no autostate
!
! The MLAG port-channel towards access switches
interface Port-Channel10
   description MLAG-DOWNSTREAM
   switchport mode trunk
   switchport trunk allowed vlan 100,200,300
   mlag 10
!
interface Ethernet3-4
   channel-group 10 mode active

Verify the pair with:

show mlag
show mlag config-sanity
show mlag detail
show lacp neighbor
show vlan 4094

show mlag config-sanity is the command to run first in any MLAG incident: it
compares the two sides and reports mismatches before they become an outage.

Dual-Primary Detection

Detection is configured in MLAG configuration mode and must be identical on both peers.
When the condition is detected, the secondary err-disables its member interfaces — optionally
including every Ethernet port except the peer-link, which is the safest posture for a routed
secondary.

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

! Remove the feature
switch(config-mlag)# no dual-primary detection
show mlag detail | include dual
show interfaces status errdisabled

A five-second delay is a reasonable starting point. Too low and you react before the
heartbeat has had a chance to prove the peer is alive; too high and duplicates have time to
reach the L3 boundary.

Dual-Primary Recovery Delay

Recovery delay controls how interfaces come back after the condition clears. Two values are
configurable — one for MLAG interfaces and one for non-MLAG interfaces — and the rule stated
in the Arista manual is that the non-MLAG delay must always be shorter than the MLAG delay.
That ordering gives L3 time to converge before L2 MLAG ports start forwarding.

mlag configuration
   dual-primary recovery delay mlag 30 non-mlag 10

! Reset to defaults
switch(config-mlag)# default dual-primary recovery delay mlag 30 non-mlag 10

Negating the configuration or setting the defaults returns both values to zero, which means
both sets of interfaces come up together. Only do that if your routing protocol converges in
well under a second.

The Case Detection Cannot Cover

There is a well-documented gap: if the MLAG pair never forms because of a configuration
error, detection never fires. Both switches running standalone means L2 protocols such as STP
and LACP still behave normally, which prevents loops — but in an EVPN/VXLAN design each switch
may form its own VTEP and duplicate MAC addresses, producing
%EVPN-3-SUPPRESSED_DUPLICATE_MAC events. The practical protection is process, not
timing:

• Validate with show mlag config-sanity before enabling a new MLAG pair.
• Alert on MLAG state changes to Active on only one side.
• Check the EVPN duplicate-MAC counters when you build MLAG under a VXLAN fabric.
• Keep the MLAG peer-link on dedicated, MTU-matched ports and treat it as a critical link in
  your monitoring.

This is the same class of problem as MC-LAG ICCP failure scenarios and LACP system-ID behaviour on Juniper and LACP fallback and static LAG configuration is a useful complement when you mix MLAG upstream with static bundles downstream.

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