Arista EOS VRRP Configuration and Verification

EOS offers two first-hop redundancy mechanisms and they solve different problems. VARP makes every switch announce the same virtual address with its own MAC, so hosts use the closest device with no election at all. VRRP elects a single master and gives you a deterministic failover with priority and tracking. Choosing between them is a design decision, but the configuration details of VRRP — version, priority, preemption and tracking — are where deployments actually go wrong. This article covers a complete VRRP configuration and the verification that proves failover will work before you need it.

Version 2 versus version 3

EOS defaults to VRRP version 2, which is IPv4 only. Version 3 supports both address families. The version can differ between group members, but keeping every member on the same version is the only sensible operational choice.

switch(config)# interface vlan 20
switch(config-if-vl20)# vrrp 1 ipv4 version 3

Configuring a virtual router

switch(config)# interface vlan 20
switch(config-if-vl20)# ip address 10.20.0.2/24
switch(config-if-vl20)# vrrp 20 ipv4 10.20.0.1
switch(config-if-vl20)# vrrp 20 priority-level 150
switch(config-if-vl20)# vrrp 20 preempt delay minimum 60
switch(config-if-vl20)# vrrp 20 description Core-Gateway-VLAN20
switch(config-if-vl20)# no shutdown

The virtual address must sit inside the interface's subnet, because the command enables the virtual router only if that condition holds. Priority ranges from 254 to 1 with a default of 100; on the device whose interface address is the virtual address, the effective priority is 255 and it wins by definition.

Preemption is the setting most often left at default and most often wrong. With preemption enabled and no delay, a switch that reboots and wins the election can take over immediately — which is usually what you want, except when it reboots repeatedly or when routing has not converged. A delay of 30 to 60 seconds is a standard mitigation.

Tracking

! Track an interface: lose the uplink, lose the master role
switch(config-if-vl20)# vrrp 20 tracked-object interface Ethernet6/48 shutdown

! Track an object defined with the track command
switch(config)# track ETH8 interface Ethernet8 line-protocol
switch(config-if-vl20)# vrrp 20 tracked-object ETH8 shutdown

! Or reduce priority instead of shutting down the group
switch(config-if-vl20)# vrrp 20 tracked-object interface Ethernet6/48 decrement 40

Tracking is what makes VRRP useful in a real topology. Without it, the master keeps advertising that it owns the virtual address even after its uplink has failed, and traffic is forwarded into a black hole until the interface itself goes down. Tracking the uplink and either shutting down the virtual router or decrementing priority ensures the peer takes over.

For IPv6, the same virtual router can carry both families:

switch(config-if-vl20)# vrrp 20 ipv6 2001:db8:20::1

IPv6 does not need a version statement because it only supports version 3.

Verification

switch# show vrrp
switch# show vrrp detail
switch# show vrrp interface vlan 20
switch# show vrrp 20
switch# show track
switch# show ip arp vlan 20

The summary view shows state, priority and the virtual address; a group that is Initialize or that stays Backup on both switches is the classic sign of a subnet mismatch in the virtual address or a duplicate virtual router ID elsewhere in the VLAN. The detail view adds the timing parameters and the tracked objects with their current state, which is what you need to prove that tracking is wired up rather than merely configured.

Testing failover deliberately

! On the master, force a failover by lowering priority
switch(config-if-vl20)# vrrp 20 priority-level 90
switch# show vrrp | include "Vlan20|State|Master|Priority"

! Restore
switch(config-if-vl20)# vrrp 20 priority-level 150

Lowering priority below the peer is a clean way to trigger a real election without touching cables. Watch for three things: the peer transitions to Master, gratuitous ARP updates the hosts' caches, and traffic resumes within the convergence window. Then restore the priority and confirm the master role returns after the preemption delay — if it does not, preemption is disabled somewhere you forgot.

VRRP versus VARP in practice

• VARP — all switches advertise the virtual address, hosts learn the nearest one, no election and no failover event. Active-active for traffic, and no timers to tune. The right choice for most data-centre leaf pairs.
• VRRP — one master, deterministic and well understood, with priority and tracking semantics that other vendors share. Better where you need explicitly controlled behaviour or where operational familiarity matters more than perfect load distribution.

Most EOS deployments end up using VARP, and the design patterns for that are covered alongside MLAG in Arista EOS VARP active-active gateway with MLAG. Whichever you choose, verify that the hosts actually learned the address you expect — a first-hop gateway that only works for half the VLAN is a subtle failure that shows up as intermittent connectivity rather than a clean outage, and the interface and MAC-table inspection techniques in Arista EOS MAC address table commands are how you confirm it.

原文链接：https://www.arista.com/en/um-eos/eos-vrrp-and-varp