An Arista MLAG pair is a short config, and show mlag will tell you when it is healthy. It will not tell you how long your traffic stops when a peer dies. So this lab builds the pair on cEOS, then stops a switch and measures it, three times, changing one setting each time.
Default timers lost traffic for 79 seconds. Two lines of config brought that to about 3.5.
Everything here ran on cEOS-lab 4.36.1F, on containerlab v0.82.0 and v0.77.0, on Ubuntu 24.04. Forwarding in cEOS is software, so these numbers prove the config and the timers, and they do not describe switch hardware. The lab is public at netpilot-labs/arista-labs, and you bring your own cEOS image. Run Arista cEOS in containerlab covers getting one.
The topology
Port-Channel10
leaf1 ================ leaf2
Et3 Et4 Et4 Et3
leaf1:Et3 + leaf2:Et3 -> h1 bond0 (MLAG 1, VLAN 10)
leaf1:Et4 + leaf2:Et4 -> sw3 Port-Channel1 (MLAG 2) -> h2 (VLAN 20)leaf1andleaf2are the MLAG pair, with VARP gateways on VLAN 10 and VLAN 20.h1is a Linux host in VLAN 10 on an LACP bond to both leaves.sw3is a cEOS switch on an LACP port channel to both leaves, withh2in VLAN 20 behind it.
Ask NetPilot for the same thing and the agent builds it:
"Build an Arista MLAG pair with VARP on VLANs 10 and 20, a dual-homed Linux host and a downstream switch, then stop one leaf and measure the outage."
The agent writes the configs, deploys them and reads the result from the devices. Direct CLI is always there, so you can type what follows by hand. That prompt is an example, and the run below used containerlab directly.
The MLAG config
leaf1 from the lab. leaf2 swaps the two peering addresses and uses .3 on the SVIs.
hostname leaf1
!
username admin privilege 15 role network-admin secret admin
!
ip routing
!
vlan 10,20
!
vlan 4094
trunk group mlagpeer
!
no spanning-tree vlan-id 4094
!
interface Port-Channel10
description MLAG peer link
switchport mode trunk
switchport trunk group mlagpeer
!
interface Ethernet1
channel-group 10 mode active
lacp timer fast
!
interface Ethernet2
channel-group 10 mode active
lacp timer fast
!
interface Vlan4094
ip address 10.255.255.0/31
!
mlag configuration
domain-id lab
local-interface Vlan4094
peer-address 10.255.255.1
peer-link Port-Channel10
!
interface Port-Channel1
description h1 dual-homed
spanning-tree portfast
switchport access vlan 10
mlag 1
!
interface Ethernet3
channel-group 1 mode active
lacp timer fast
!
interface Port-Channel2
description sw3 dual-homed
switchport mode trunk
switchport trunk allowed vlan 10,20
mlag 2
!
interface Ethernet4
channel-group 2 mode active
lacp timer fast
!
ip virtual-router mac-address 00:1c:73:00:00:99
!
interface Vlan10
ip address 10.10.10.2/24
ip virtual-router address 10.10.10.1
!
interface Vlan20
ip address 10.20.20.2/24
ip virtual-router address 10.20.20.1
!
endThree lines do most of the work:
trunk group mlagpeerkeeps VLAN 4094 on the peer link and off every other trunk.peer-addressandlocal-interfacegive the peers their control session, over the SVI on VLAN 4094.mlag 1on both switches makes the twoPort-Channel1interfaces one logical port channel toh1.
The downstream side needs nothing special. h1 sees one LACP partner, because both leaves answer with the same system ID, and the same goes for sw3:
h1:
kind: linux
exec:
- ip link add bond0 type bond mode 802.3ad lacp_rate fast miimon 100
- ip link set eth1 down
- ip link set eth2 down
- ip link set eth1 mtu 1500
- ip link set eth2 mtu 1500
- ip link set eth1 master bond0
- ip link set eth2 master bond0
- ip link set bond0 up
- ip addr add 10.10.10.10/24 dev bond0
- ip route replace 10.20.20.0/24 via 10.10.10.1Deploy and verify
git clone https://github.com/netpilot-labs/arista-labs
cd arista-labs/02-mlag-pair
sudo containerlab deploy -t mlag-pair.clab.ymlDeploy returned in about 30 seconds, and h1 could reach h2 55 to 57 seconds from the start. Then on leaf1:
leaf1#show mlag
MLAG Configuration:
domain-id : lab
local-interface : Vlan4094
peer-address : 10.255.255.1
peer-link : Port-Channel10
hb-peer-address : 0.0.0.0
peer-config : consistent
MLAG Status:
state : Active
negotiation status : Connected
peer-link status : Up
local-int status : Up
system-id : 02:1c:73:c8:ef:4f
dual-primary detection : Disabled
dual-primary interface errdisabled : Falseleaf1#show mlag interfaces
local/remote
mlag desc state local remote status
-------- ------------------ --------------- ---------- ----------- ------------
1 h1 dual-homed active-full Po1 Po1 up/up
2 sw3 dual-homed active-full Po2 Po2 up/upleaf1#show mlag config-sanity
No global configuration inconsistencies found.
No per interface configuration inconsistencies found.leaf1#show port-channel
Port Channel Port-Channel1:
Active Ports: Ethernet3 PeerEthernet3
Port Channel Port-Channel2:
Active Ports: Ethernet4 PeerEthernet4
Port Channel Port-Channel10:
Active Ports: Ethernet1 Ethernet2PeerEthernet3 is the member on the other switch. If you came from Cisco, show port-channel summary is % Invalid input on EOS. VARP answers on both peers:
leaf1#show ip virtual-router
IP virtual router is configured with MAC address: 001c.7300.0099
IP virtual router address subnet routes not enabled
MAC address advertisement interval: 30 seconds
Protocol: U - Up, D - Down, T - Testing, UN - Unknown
NP - Not Present, LLD - Lower Layer Down
Interface Vrf Virtual IP Address Protocol State
--------------- ------------- ------------------------ -------------- ------
Vl10 default 10.10.10.1 U active
Vl20 default 10.20.20.1 U activeStop a switch and measure
The test: h1 pings h2 every 200 ms while docker stop kills the leaf carrying the traffic. docker stop does not take the link down. The veth on the neighbor stays up, so this is a switch that dies silently, the hard case. Nothing detects it but timers.
Which leaf carries a flow depends on the hash, and it changed between deploys. In each run below the stopped leaf was in the path, which the loss shows.
| Run | Config | Outage | What ended it |
|---|---|---|---|
| 1 | Default LACP timers, no portfast | 79 seconds | sw3 removed the dead member |
| 2 | lacp timer fast, no portfast | 24 seconds | The host port left spanning tree discarding |
| 3 | lacp timer fast and spanning-tree portfast | about 3.5 seconds | LACP fast timeout on the bond |
Run 1. The switch stopped at 19:57:25. sw3 kept sending to it until the slow LACP timer ran out:
Oct 30 19:58:43 sw3 Lag: %LAG-5-MEMBER_REMOVED: Interface Ethernet2 has left Port-Channel1 (uplink to the MLAG pair)Run 2. With lacp timer fast on every member, the MLAG side saw the failure in about 3 seconds. Traffic still stopped for 24, and show spanning-tree on the surviving leaf showed why. When the peer goes, the port channel rejoins spanning tree as an ordinary port:
Interface Role State Cost Prio.Nbr Type
--------- ----------- ----------- ----- -------- ----
Po1 designated discarding 19999 128.101 P2p
Po2 root forwarding 19999 128.102 P2pOct 30 20:02:54 leaf1 Stp: %SPANTREE-6-INTERFACE_STATE: Interface Port-Channel1 instance MST0 moving from discarding to learning
Oct 30 20:02:56 leaf1 Stp: %SPANTREE-6-INTERFACE_STATE: Interface Port-Channel1 instance MST0 moving from learning to forwardingRun 3. Port-Channel1 faces a host, so it can be an edge port. With spanning-tree portfast on both leaves, 17 pings went unanswered at 200 ms, about 3.5 seconds, the fast LACP timeout on the host's bond. The config above is this version.
In one run the stopped leaf was outside the path, and all 100 replies came back.
What we did not test
- A link that really drops. A pulled cable takes carrier down, and neither
docker stopnorshutdownon a cEOS port did that to the host's bond here. So 3.5 seconds is the silent case, and we did not measure the carrier-loss case. - Dual-primary detection.
show mlagshows it disabled here, and this lab has no heartbeat path. If the peer link fails while both switches live, you want it. Arista's MLAG documentation is the place to start. - A peer coming back. The lab rebuilds with destroy and deploy, because
docker restarthangs a cEOS node. Recovery andreload-delaybehavior were not measured.
FAQ
How do I configure MLAG on Arista?
Give two switches a trunk port channel between them, a VLAN with a trunk group for peer traffic, and an SVI on that VLAN. Set domain-id, local-interface, peer-address and peer-link under mlag configuration. Then add the same mlag ID to the matching port channel on both switches.
How do I check that Arista MLAG is working?
Run show mlag and look for state Active, negotiation status Connected, peer-link status Up and local-int status Up. show mlag interfaces lists each MLAG as active-full, and show mlag config-sanity reports inconsistencies between the peers.
Does MLAG work on Arista cEOS?
Yes. We ran MLAG with LACP port channels, VARP and peer failover on cEOS-lab 4.36.1F. Forwarding is in software, so it proves the control plane and the config, and it does not measure switch hardware.
Why does traffic stop for so long when an MLAG peer fails silently?
In our lab two timers caused it. Default LACP timing kept a dead member in the port channel for 79 seconds, and a host port that was not edge spent about 20 seconds in spanning tree. lacp timer fast and spanning-tree portfast brought the outage to about 3.5 seconds.
What is VARP on Arista?
VARP, the virtual ARP feature, gives both MLAG peers one shared gateway IP and MAC, set with ip virtual-router. Both peers answer and route for that address, so a host keeps its gateway when one peer fails.
Next steps
- Run Arista cEOS in containerlab: the image, the first lab and five traps
- Spine-leaf architecture lab: the routed design beside an MLAG pair
- EVPN-VXLAN data center guide: the overlay many MLAG designs now sit under
- containerlab in the cloud: the engine, hosted for you
- Supported devices: every network OS you can run on NetPilot