Arista EOS VARP: Active-Active Gateway with MLAG

Traditional first-hop redundancy protocols such as HSRP and VRRP are active-standby: one gateway forwards while the other idles, wasting half the uplink capacity of an MLAG pair. Arista EOS solves this with Virtual ARP (VARP), an L3 anycast gateway where both MLAG peers carry the same virtual-router IP and respond to ARP, so every switch forwards traffic at the same time. This article explains how VARP works and walks through the complete EOS configuration on both peers.

Background: Why Active-Standby Gateways Waste Capacity

Almost every first-hop redundancy design starts with the same problem. A pair of switches terminates one VLAN, hosts need a single default gateway address, and that address must survive the failure of either switch. HSRP and VRRP answer the question with an election: one device becomes active and owns the virtual IP and virtual MAC, the other waits in standby and only takes over when hellos stop arriving.

The failover behaviour is solid, but the resource model is not. In a normal MLAG or VPC pair, the two switches have independent uplinks to the spine layer. With HSRP or VRRP, all northbound traffic from that VLAN egresses through a single elected gateway, so the uplink bundle of the standby switch carries almost nothing for that subnet. You bought two paths and you are using one. The same asymmetry shows up in transient failure: when the active gateway dies, hosts keep sending frames to the old virtual MAC until ARP entries age out or a gratuitous ARP lands, which produces a short but visible packet loss window.

VARP removes the election entirely. Both switches advertise the same virtual IP with the same virtual MAC and both answer ARP and install forwarding state for it. Every host in the VLAN gets an ARP reply from whichever switch answers first, and both switches are valid next hops for the whole subnet. There is no active and no standby, so there is nothing to fail over.

How VARP Works

Each MLAG peer keeps a unique physical SVI IP address but shares one virtual-router IP per VLAN and one global virtual-router MAC. Both switches answer ARP requests and periodically send gratuitous ARPs for the VIP using the virtual MAC. That MAC is receive-only — no packet ever leaves with it as the source. When a host sends a frame to the virtual MAC, the local MLAG peer performs the L3 lookup and forwards to the next hop, so traffic is balanced across both switches and failover is immediate when a link or peer fails.

Three properties make the scheme work:

• The virtual MAC is receive-only. Frames addressed to the virtual MAC are accepted by every VARP switch and forwarded. Frames sourced by the switch always use the physical SVI MAC, so the forwarding pipeline never has to resolve an ambiguous source.
• The virtual IP is shared, not elected. Both peers configure the identical address on the same SVI. There is no priority, no preempt and no hello timer, so no convergence event can happen.
• The virtual MAC is global. One ip virtual-router mac-address value is reused on every VLAN and every VARP switch in the fabric. The switch keeps the address in its MAC table as a local receive entry, which is why the same MAC can appear on both peers without confusing the forwarding tables.

The result is an anycast gateway: the gateway IP exists simultaneously on many switches, and the host's ARP cache resolves it to a MAC that is present on all of them. Any switch that receives the frame can route it, so the host uses whatever path its L2 topology has already selected.

VARP Compared with VRRP, HSRP and EVPN Anycast Gateways

• HSRP / VRRP: active-standby, one forwarding switch, virtual MAC belongs to the elected master, failover driven by timers. Use them when you have no routing pair or no L2 multihoming.
• VARP: active-active on an MLAG (or VLT/VSX) pair, no election, per-host load spreading based on which switch answers ARP first. It is an L2-multihoming feature with a shared gateway address; the peers must see the same VLAN.
• EVPN anycast gateway: the same idea extended across a VXLAN fabric, where the gateway IP/MAC pair is replicated on every leaf and the overlay carries ARP/ND through the control plane. VARP is the right choice for a pure L2/L3 design without VXLAN; EVPN multihoming with ESI is the right choice when you want to retire MLAG completely.

If you are migrating from the Cisco and Dell worlds, the closest equivalents are HSRP for the active-standby school and Dell OS10 VLT peer routing for the active-active school. The design reasoning is identical; only the CLI verbs differ.

Prerequisites: What Must Be True Before VARP Works

VARP is simple, but it depends on a handful of things being in place first. Check each of these before configuring the virtual addresses:

• MLAG is configured and healthy on both peers. Same MLAG domain ID, same peer-link, same system MAC, and show mlag reporting an Active state on both switches. Downstream switches must be dual-homed with LACP port-channels.
• Both peers have the VLAN and the SVI. A VLAN that exists on Switch1 but not Switch2 means only one switch can route it.
• Layer 3 is enabled. ip routing must be present in the running configuration; without it the SVIs will not forward between subnets.
• The virtual MAC is unique in the network. Never use a MAC that a real NIC or another vendor's gateway already claims.
• The SVI IPs differ, the VIP matches. Physical SVI addresses must be unique /32-host addresses inside the subnet; the virtual-router address must be byte-for-byte identical on both peers.
• You know your DHCP and reservation layout. The virtual IP must not be inside a DHCP pool or leased to a host. Exclude it in the DHCP server configuration.

EOS VARP Configuration on Both Peers

Configure the same virtual-router address on each VLAN interface and the same virtual MAC globally on Switch1 and Switch2:

Switch1(config)# interface vlan 10
Switch1(config-if-Vl10)# ip address 10.10.10.2/24
Switch1(config-if-Vl10)# ip virtual-router address 10.10.10.1
Switch1(config-if-Vl10)# interface vlan 20
Switch1(config-if-Vl20)# ip address 10.10.20.2/24
Switch1(config-if-Vl20)# ip virtual-router address 10.10.20.1
Switch1(config-if-Vl20)# exit
Switch1(config)# ip virtual-router mac-address 00:1c:73:00:00:99
Switch1(config)# ip routing

Switch2(config)# interface vlan 10
Switch2(config-if-Vl10)# ip address 10.10.10.3/24
Switch2(config-if-Vl10)# ip virtual-router address 10.10.10.1
Switch2(config-if-Vl10)# interface vlan 20
Switch2(config-if-Vl20)# ip address 10.10.20.3/24
Switch2(config-if-Vl20)# ip virtual-router address 10.10.20.1
Switch2(config-if-Vl20)# exit
Switch2(config)# ip virtual-router mac-address 00:1c:73:00:00:99
Switch2(config)# ip routing

The example MAC 00:1c:73:00:00:99 will not occur naturally. VARP sits on top of an MLAG domain — the peers synchronize MAC and ARP state over the peer link, and the MLAG system MAC is what downstream switches negotiate with LACP.

Two configuration order notes that save time in change windows:

1. Create the VLAN and the MLAG port-channel on both peers before the SVI. If you build the SVI first, the interface stays down until the VLAN exists, and it is easy to misread the down state as a VARP problem.
2. Configure ip virtual-router mac-address before adding virtual addresses, or re-enter the virtual addresses afterwards. The MAC is inherited by the virtual addresses when they are created; adding it late does not retrofit existing entries in every EOS release.

Multiple virtual-router addresses on the same SVI are allowed — repeat ip virtual-router address to support migrating subnets or secondary addressing. You can also remove a single VIP without touching the rest of the interface with no ip virtual-router address 10.10.10.1.

VARP and MLAG: How the Two Features Interact

It is worth being precise about the dependency, because the two features are often confused:

• MLAG provides the L2 dual-homing. It makes the two switches look like one logical switch to downstream hosts, synchronizes the MAC address table across the peer link, and runs LACP with a shared system MAC.
• VARP provides the L3 anycast behaviour. It is a per-SVI gateway address that both switches accept traffic for. Strictly speaking VARP does not need MLAG at all — it will work on any two L3 switches that see the same VLAN — but MLAG is what guarantees both switches are on the forwarding path for the hosts.
• The peer link carries synchronization, not user traffic. MAC and ARP state flows across it, and MLAG suppresses flooding of unknown unicast toward the peer to avoid loops.
• Peer-link failure is still a failure. When the peer link goes down, the MLAG secondary disables its member ports, so hosts lose that path and the local VARP entry stops being useful for them. VARP hides gateway failures, not L2 multihoming failures. That is why dual-primary detection with a heartbeat is a mandatory part of the design.

Verifying VARP

Switch1# show ip virtual-router
Switch1# show ip arp | grep 10.10.10.1

show ip virtual-router lists every configured virtual address with its state; the virtual MAC column should show 00:1c:73:00:00:99. VARP-enabled switches send gratuitous ARP every 30 seconds by default — tune the advertisement interval only if MAC aging on downstream switches demands it.

A complete verification sequence looks like this:

Switch1# show ip virtual-router
! check: virtual MAC, one line per VIP, all interfaces up
Switch1# show interfaces vlan 10
! check: line protocol up, physical IP present, VLAN alive
Switch1# show mlag
! check: state Active, peer-link up, peer connected
Switch1# show ip route 10.10.20.0/24
! check: the remote VLAN is reachable via OSPF/BGP, not via the peer link
Switch1# show ip arp interface vlan 10
! check: hosts resolve; the VIP is our own address

On the host side, confirm that the ARP cache points at the virtual MAC and not at a physical SVI MAC:

host$ arp -n | grep 10.10.10.1
10.10.10.1 dev eth0 lladdr 00:1c:73:00:00:99 REACHABLE

Finally, prove that traffic really is spread across both switches. Clear the ARP caches of several hosts in the VLAN, then check where the return traffic is sourced from — distinct host groups should be served by different peers, and each peer should show traffic counters on its own uplinks.

Troubleshooting VARP

Most VARP incidents fall into a small number of buckets.

• Hosts cannot reach the gateway at all. Check ip routing, then check that the SVI is up on the switch the host is attached to. A VLAN created only on the MLAG primary will pass traffic for hosts on that switch and blackhole it for the other side.
• The VIP answers ARP from one switch only. The virtual MAC values differ between peers. Re-run show ip virtual-router mac (or show running-config | grep virtual-router) on both switches and compare character by character.
• Duplicate address detected. The virtual IP was also assigned as a physical SVI address, or the same VIP is configured on a second pair of switches in the same broadcast domain. Each VIP belongs to exactly one MLAG pair.
• Intermittent drops after a change. Hosts still hold the old MAC in their ARP cache from a previous active-standby design. Clearing the host ARP entry, or waiting for the next gratuitous ARP cycle, resolves it.
• Loss after a peer-link failure. Expected on the MLAG secondary. Verify dual-primary detection and the heartbeat path, and remember that VARP does not survive a lost peer link any better than MLAG itself does.
• Return traffic path is asymmetric. Normal with VARP on a leaf-spine fabric. Routing is per-hop and destination-based, so asymmetric forward and return paths are harmless as long as no stateful device sits in the middle.

Switch1# show ip virtual-router vrf all
Switch1# show ip arp interface vlan 10
Switch1# show mac address-table aging-time
Switch1# show mlag config-sanity

show mlag config-sanity is the fastest way to catch the "one side has an extra VLAN" mistakes that make VARP look broken when it is actually an MLAG asymmetry.

Design Guidance

Deploy VARP consistently: at minimum on every ToR/leaf that participates in the VLAN and on all core/spine switches. Partial deployment still forwards correctly but can force suboptimal hairpin paths. Because VARP relies on a shared MAC advertised by many switches, validate the design in a lab before a mixed-vendor rollout. For an active-standby alternative, compare with Cisco HSRP, and see where VARP fits in leaf-spine data center design. Keep the virtual MAC constant across the fabric, document it as a reserved resource the same way you document loopbacks and VLAN IDs, and exclude every VIP from DHCP scopes before the first production subnet is enabled.

If you are evaluating the alternatives on the same fabric, the Dell equivalent is OS10 VLT peer routing, ArubaOS-CX implements the same concept as active gateway, and EVPN multihoming replaces the MLAG pair entirely with ESI-based multihoming. MLAG-side failures are covered in Arista EOS MLAG troubleshooting.

FAQ

Does VARP require MLAG? No. VARP is an anycast gateway address and works on any set of L3 switches that share a VLAN. MLAG is what makes the pair act as one L2 switch, which is normally why you are deploying VARP in the first place.

Can VARP and VRRP coexist on the same SVI? Not usefully — you would have two gateway mechanisms competing for the same role. Pick one per VLAN and keep the design uniform.

What happens during an EOS upgrade? Use the usual MLAG upgrade procedure. Rolling one peer at a time keeps the other switch forwarding VARP traffic for the whole VLAN; hosts stay reachable because their gateway MAC is still served by the peer.

How is VARP different from an EVPN anycast gateway? Functionally similar, architecturally different. VARP is a local SVI feature whose reachability depends on L2 adjacency; an EVPN anycast gateway distributes the gateway through the overlay control plane and scales across a VXLAN fabric.

Is there an IPv6 equivalent? Yes — EOS provides IPv6 virtual-router addressing and a matching virtual MAC, configured the same way on both peers once IPv6 routing is enabled.

原文链接：https://arista.my.site.com/AristaCommunity/s/article/active-active-router-redundancy-using-varp