Arista EOS MLAG Troubleshooting: Peer-Link and Dual-Primary

MLAG is the reason a pair of Arista switches can be replaced one at a time during a maintenance window. It is also the reason a peer-link failure can melt a Layer 2 domain if the dual-primary safeguards are not configured. This runbook walks through the MLAG verification commands, what each state means, and the recovery options that keep traffic flowing without creating a loop.

The five commands that answer most MLAG questions

switch# show mlag
switch# show mlag detail
switch# show mlag interfaces
switch# show mlag config-sanity
switch# show mlag peer-link

show mlag gives the domain state, the peer address, and peer-link status. show mlag interfaces adds the local/remote state per MLAG — the pair you are looking for is active on both sides. A state of active-partial with up/down for local/remote means the local peer-link is down while the local member links are still up: forwarding continues on the surviving switch, but traffic destined for peer-attached hosts can be lost or flooded until the peer-link is restored.

What the reload-delay timers are protecting

mlag configuration
   domain-id DC1
   local-interface Vlan4094
   peer-address 192.168.255.1
   peer-link Port-Channel9999
   peer-address heartbeat 172.16.1.23 vrf MGMT
   dual-primary detection delay 1 action errdisable all-interfaces
   dual-primary recovery delay mlag 30 non-mlag 15
   reload-delay mlag 300
   reload-delay non-mlag 360

When a switch reloads, it keeps its MLAG port-channels and non-MLAG ports down for reload-delay seconds so the peer can finish programming forwarding state. Set it too low and you get a blackhole window at every upgrade; set it too high and recovery takes longer than your SLA. For EOS upgrades the reload prompt itself warns when the configured delay is below the 300-second default, and when MLAGs are not in full active state — traffic to those ports will be lost during the upgrade.

Dual-primary: preventing two active peers

The heartbeat runs out-of-band (a separate VRF over the management network) precisely because it must survive a peer-link failure. If both the peer-link and the heartbeat fail, the two switches may both claim active. Dual-primary detection compares the two views and takes action:

• dual-primary detection delay N — how long to wait before declaring dual-primary.
• action errdisable all-interfaces — the aggressive but loop-free option: the losing switch disables its ports instead of forwarding duplicates.
• dual-primary recovery delay mlag/non-mlag — staggered recovery so MLAG ports come back after the peer relationship is re-established.

Without dual-primary detection, a simultaneous peer-link and heartbeat failure leaves two switches advertising the same anycast/VARP MAC and the same LACP partner ID. That is the failure mode that produces duplicate MAC entries and intermittent packet loss reported as “random” application timeouts.

Recovering from a peer-link failure

1. Confirm the arithmetic with show mlag and show mlag interfaces — is the peer-link down (Port-Channel9999) or is the heartbeat down?
2. Check LACP on the peer-link members: show lacp interface, show port-channel 9999 detailed. MLAG peers also exchange a domain ID and system MAC; a change in either breaks the relationship silently.
3. Inspect logging and errdisable state: show logging, show interfaces status errdisabled.
4. Restore the peer-link. MLAG ports only return to full active state after the peer relationship is fully re-established — forcing them up manually is a good way to build a loop.
5. After recovery, run show mlag config-sanity on both peers and compare; configuration drift between MLAG peers is the most common root cause of the next outage.

Reading show mlag field by field

Almost every MLAG incident is diagnosed from the first fifteen lines of show mlag. The output is short, but each line answers a different question, and confusing them costs time during a maintenance window. An abridged example from a healthy pair:

switch-1# show mlag
MLAG Configuration:
domain-id                 : DC1
local-interface           : Vlan4094
peer-address              : 192.168.255.2
peer-link                 : Port-Channel9999, active
peer-address heartbeat    : 172.16.1.24 vrf MGMT
local-intf                : 192.168.255.1/30

MLAG Status:
state                     : Active
negotiation status        : Connected
peer-link status          : Up
local-intf status         : Up
peer-intf status          : Up
peer-address heartbeat    : Up

Work through it in this order:

• state — the domain role. Active on both peers is the goal. active-partial means the peer link is not fully functional but member links are still forwarding — treat it as an outage in progress, not a warning.
• peer-link status — whether the LAG carrying the control traffic and peer-attached host traffic is up. When it is down, the surviving switch cannot learn the peer's MACs.
• negotiation status — whether the two switches agree on the domain. Connected is healthy. A stuck negotiation almost always means a domain-id mismatch, a changed peer-address, or an MTU / LACP problem on the peer link itself.
• heartbeat — the out-of-band liveness check. It must be Up even when the peer link is down, because it is the only thing that prevents dual-primary.
• local-intf / peer-intf — the Vlan4094 peer interface on each side. Both must be up; a down peer interface usually means the VLAN is missing from the peer-link trunk or the SVI is shut.

show mlag interfaces answers the second question: for every MLAG port-channel, is the local side and the remote side active? The pair you want is active/active. active-partial with up/down on the local/remote column is the peer-link failure case described above. show mlag detail adds the negotiated version and the peer's own view of the world, which is where you confirm that both switches see the same domain.

Anti-loop rules for the peer-link itself

The peer-link is an ordinary port-channel with an unusual job: it carries MLAG control traffic and, by design, is allowed to carry traffic for MLAG VLANs that would otherwise loop. That is exactly why its configuration must stay boring and identical on both peers.

• Two or more physical members. A single-member peer-link turns one cable into a single point of failure for the whole domain.
• Never route between the peers over the peer-link. No L3 interface on the peer-link VLAN, no routing of shared VLANs across it. The peer link is a Layer 2 extension, not a transit path.
• Keep the heartbeat out of the peer-link's failure domain. A separate management VRF over an independent path is the point. If the heartbeat rides the same uplink, the same line card or the same power feed as the peer link, a single physical fault defeats both.
• Match the MTU end to end. A peer-link that carries jumbo frames on one side and 1500 on the other will come up, pass control traffic, then drop large peer-attached traffic with symptoms that look like application timeouts.
• Apply the same VLAN list on both sides. Drift here is caught by show mlag config-sanity, which is the command most teams run only after an outage.

interface Port-Channel9999
   switchport mode trunk
   switchport trunk allowed vlan 4094
   no spanning-tree vlan 4094

Keep the member count, the allowed VLAN list, and the port-channel mode identical on both peers; a passive/active mismatch across the peers is a common cause of a peer-link that flaps under load.

Dual-primary detection: the full configuration

Dual-primary detection compares the two peers' views of the world over the heartbeat path. If both switches believe they are the surviving active peer, the one that loses the comparison takes an action — and the only action that is reliably loop-free is to stop forwarding.

mlag configuration
   domain-id DC1
   local-interface Vlan4094
   peer-address 192.168.255.1
   peer-link Port-Channel9999
   peer-address heartbeat 172.16.1.23 vrf MGMT
   dual-primary detection delay 500 action errdisable all-interfaces
   dual-primary recovery delay mlag 30 non-mlag 15

Two numbers deserve attention. The detection delay is a trade-off between speed and false positives: too short and a transient heartbeat loss errdisables a perfectly healthy switch, taking down every host behind it; too long and duplicate MAC advertisements survive long enough to corrupt neighbour tables. Five hundred milliseconds is a reasonable starting point for a management-network heartbeat. The recovery delay is what prevents the interface state from oscillating: MLAG ports wait 30 seconds after the peer relationship is re-established, non-MLAG ports wait 15, so the forwarding state is stable before traffic is allowed back in.

Note what the action does not do. It does not shut down the peer link, and it does not create a new control plane — it disables the data ports on the switch that lost the arbitration, which is why traffic keeps moving through the surviving peer instead of being duplicated by both.

Recovering a dual-primary event in order

1. Confirm the event before you touch anything. show logging on both peers and look for the dual-primary messages; show interfaces status errdisabled tells you which side took the action. If both switches errdisabled their ports, the failure domain was common to both and you should fix that first.
2. Find the common cause. Ask what broke both the peer link and the heartbeat. In practice the answer is a shared upstream switch, a shared power feed, or a management-network change made on one peer only.
3. Clear the errdisabled state on the correct side. Use errdisable recovery or shut / no shut the interface group deliberately — do not bring up ports on both switches at once.
4. Re-establish the peer link and wait. MLAG ports return to full active only after the peer relationship is complete. Forcing them up manually is how a dual-primary incident becomes a broadcast storm.
5. Compare configurations. Run show mlag config-sanity on both peers and diff the output. Configuration drift between peers is the most common root cause of the next outage.

switch-1# show mlag
switch-1# show mlag detail
switch-1# show mlag interfaces
switch-1# show mlag config-sanity
switch-1# show interfaces status errdisabled
switch-1# show lacp neighbor
switch-1# show port-channel 9999 detailed
switch-1# show logging | grep -i mlag

What a peer-link failure looks like downstream

When the peer link goes down while both switches stay up, the domain enters active-partial. Each switch keeps forwarding on its own MLAG member links, which is intentional — hosts dual-homed to the pair keep working. What breaks is traffic that depends on the peer: MACs learned on the far switch are no longer synchronised, so a frame arriving on switch-1 for a host attached to switch-2 has nowhere to go and is flooded or dropped until the peer link returns. Downstream, the symptom is reported as intermittent loss to specific servers, not as a clean outage, which is why it is often misdiagnosed as an application problem. The fix is in the design, not the configuration: keep every dual-homed host attached to both peers, and never attach a single-homed device that other subnets depend on.

False alarms that are not MLAG failures

• A single member link of the peer-link flaps. The port-channel stays up; only the aggregate bandwidth drops. Check the member state with show port-channel 9999 detailed and the optic with show interfaces transceiver.
• Version negotiation warnings after an upgrade. Upgrading one peer at a time is the point of MLAG, but the pair must return to the same negotiated state before the next change window.
• Heartbeat packets dropped by an ACL or a management firewall. The heartbeat is easy to filter accidentally because it traverses a management path that security teams also own.
• Reload-delay starting the timer. A peer that just reloaded keeps its ports down for the configured delay; that is the design working, not a failure.

Post-change verification checklist

1. show mlag on both peers: state Active, peer-link Up, heartbeat Up.
2. show mlag interfaces: every MLAG shows active/active.
3. show mlag config-sanity on both peers, compared line by line.
4. show lacp neighbor on the peer-link members: the expected neighbours and the same system ID on both sides.
5. A test host behind each peer pings a host behind the other peer across the MLAG — and keeps pinging while one member link is shut.

Design guidance: keep MLAG domains small (two switches plus downstream dual-homed devices), never route MLAG VLANs between the peers over the peer-link, and make sure the peer-link and heartbeat never share a failure domain — including the power feed and the upstream switch they both traverse.

Related reading: Arista EOS MLAG peer-link and domain setup, MLAG multi-chassis link aggregation and VARP active-active gateway with MLAG. For the alternative design that removes the peer-link entirely, see EVPN multihoming vs MLAG: ESI and DF election; the equivalent discussion on Nexus is in Nexus vPC: peer-gateway, orphan ports and health checks, and MAC learning behind an MLAG is covered in Arista EOS MAC address table commands.

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