Chapter 19. First-Hop Redundancy
First-hop redundancy is the ability for one or more devices to share the same IP address in order to provide multidevice resiliency in default gateway scenarios (though they can be nondefault gateways, too). Usually, this involves one device owning the IP address while other devices stand by, ready to assume control of the address should the owner fail. This is not always the case, however, as we’ll see.
Cisco’s proprietary Hot Standby Router Protocol (HSRP) is probably what most Cisco shops are using to accomplish this, but outside of the Cisco world the Virtual Router Redundancy Protocol (VRRP) is the standard. This is likely due to the fact that it is an open source protocol and therefore supported by multiple vendors. Arista’s Extensible Operating System (EOS) supports VRRP, but also introduces an interesting new feature called Virtual Address Resolution Protocol (VARP). In this chapter, we take a look at both VRRP and VARP, including configuration examples and reasons why you might choose one solution over the other.
VRRP
If all you’ve ever used is Cisco’s HSRP, don’t worry, because VRRP is pretty much the same thing. In fact, it’s so similar that Cisco complained vigorously when the RFC for VRRP was announced. VRRP is defined in RFCs 2338, 3768, and 5798, whereas Cisco’s HSRP is defined in RFC 2281. The RFC for HSRP states the following:
2 Conditions of Use US Patent number 5,473,599 [2], assigned to Cisco Systems, Inc. may be applicable to HSRP. If an implementation requires the use of any claims of patent no. 5,473,599, Cisco will license such claims on reasonable, nondiscriminatory terms for use in practicing the standard. More specifically, such license will be available for a one-time, paid up fee.
Cisco complained to the Internet Engineering Task Force (IETF) with the following:
In Cisco’s assessment, the VRRP proposal does not represent any significantly different functionality from that available with HSRP and also implementation of draft-ietf-vrrp-spec-06.txt would likely infringe on Cisco’s patent #5,473,599. When Cisco originally learned of the VRRP proposal, the Hot Standby Router Protocol was then promptly offered for standardization with the understanding that, if approved, licenses for HSRP would be made available on reasonable, nondiscriminatory terms for implementation of the protocol.
The full text of Cisco’s response to the VRRP RFC is available online. My point in this little legal tangent is that VRRP is very similar to HSRP, so it’s nothing to be afraid of. But surely, there must be differences; otherwise Cisco would be suing every vendor that uses VRRP. Let’s take a look at how to configure VRRP, and we’ll see how things differ as we go.
First, we need to get some terms straight. In VRRP, a virtual router is one or more devices configured as a sort of cluster, wherein one of the devices is the master router, and the rest are backup routers. This is a bit different than HSRP, in that HSRP can have only one active router and one standby router. Any other devices configured in the same HSRP group are in a listening state. When an HSRP event occurs that causes both the active and backup routers to fail, a new election takes place among the listening routers.
With VRRP, you can configure multiple routers to be in the virtual router, and they’ll all be backup routers if not elected as the master.
Note
Even though the primary devices in this book are switches, the term router is used accurately here because VRRP can be configured only on a Layer 3 (L3) interface.
According to RFC 2338, a VRRP virtual router is defined by “A virtual router identifier (VRID) and a set of IP addresses.” In other words, for routers to become part of a virtual router, they must agree on the VRID and IP addresses. The VRID is the group number (just like HSRP), and the IP addresses are the virtual IPs (VIPs) to be shared.
Note
A quick note about Arista’s implementation of VRRP is in order. In many vendors’ implementations, the configured IP address of the interface can be used as the VIP. According to the RFC, this is an option, though as of version 4.21.1F this is not yet supported in EOS.
Additionally, if you’re building this in a lab, make sure that you have ip routing enabled, because although you can configure all of this on your interfaces, the show vrrp won’t produce any output unless ip routing is enabled.
Basic Configuration
Let’s begin by looking at a simple network, as shown in Figure 19-1. There are two switches, both connected to VLAN 99. Each switch has a Switch Virtual Interface (SVI) configured and IP routing enabled. The server will be configured to use these switches as its default gateway.
Figure 19-1. A simple network in need of VRRP
We begin with a simple configuration for the VLAN 10 interface on Arista-A:
Arista-A(config)#int vlan 10 Arista-A(config-if-Vl10)#ip address 10.0.10.2/24
And here’s Arista-B:
Arista-B(config)#int vlan 10 Arista-B(config-if-Vl10)#ip address 10.0.10.3/24
It would be difficult to get much simpler than that! So, let’s add the simplest of VRRP configurations. In its simplest form, VRRP just needs a virtual router group number, and a group IP address, which I will add to the A switch:
Arista-A(config-if-Vl10)#vrrp 10 ip 10.0.10.1
The group number can be any number inclusive of 1 to 255. According to the Arista configuration guide (section 3.1.1), Two virtual routers cannot be assigned the same VRID, even when they are on different VLANs. A virtual router’s scope is restricted to a single LAN. This can seem misleading, but I think the RFC has the answer:
However, there is no restriction against reusing a VRID with a different address mapping on different LANs. The scope of each virtual router is restricted to a single LAN.
In short, you can have the same group number on multiple interfaces, but you cannot have the same group number/IP address combination on two interfaces, which makes perfect sense because you can’t really have the same IP network on two interfaces anyway (VRFs notwithstanding).
At this point, VRRP is active (assuming that there are interfaces active in the VLAN), and we can view the status by using the show vrrp command:
Arista-A(config)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Master Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 100 Master Router is 10.0.10.2 (local), priority is 100 Master Advertisement interval is 1s Skew time is 0.609s Master Down interval is 3.609s
Because this is all it takes to configure a virtual router, many people prefer to add the IP address last if they will be altering any of the default values. If you have devices out there looking for this IP address, it just became available, and when we go in and muck with the default values, the status of the new IP might change.
Speaking of defaults, let’s take a look at them from the previous output. Without configuring anything, the switch has become the master. That makes sense because there are no other switches participating yet. Note that the advertisement interval is one second and that preemption is enabled. By comparison, HSRP sends hello packets every three seconds, which raises another important difference between the two protocols.
With HSRP, both the active and standby routers send hello packets, whereas any routers configured to listen just, well, listen. With VRRP, only the active router sends out advertisements; the backup routers all just listen.
Preemption is enabled by default with VRRP, which I think is great because, honestly, I can’t remember the last time I configured HSRP without preemption enabled. Still, if you’d like to disable preemption, you can do so with the no vrrp group-number preempt command:
Arista-A(config-if-Vl10)#no vrrp 10 preempt
Preemption can also be delayed by using a couple of interesting options, which you can see by using the question mark after the delay keyword, as shown here:
Arista-A(config-if-Vl10)#vrrp 10 preempt delay ?
minimum Specify the minimum time in seconds for the local router to wait
before taking over the active role. Default is 0 seconds.
reload Specify the preemption delay after a reload only. This delay period
applies only to the first interface-up event after the router has
reloaded. Default is 0 seconds.
<cr>
To set the minimum delay for 30 seconds and the reload delay for 60 seconds, you can combine both into the following single command:
Arista-A(config-if-Vl10)#vrrp 10 preempt delay minimum 30 reload 60
The VRRP master router sends out advertisements every one second by default. To change it, use the vrrp group-number timers advertise seconds command. Here, I change the default to 10 seconds:
Arista-A(config-if-Vl10)#vrrp 10 timers advertise 10
Now that I’ve messed with all the defaults, let’s take a look at the output of show vrrp again:
Arista-A(config-if-Vl10)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Master Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 10s Preemption is disabled Preemption delay is 30s Preemption reload delay is 60s Priority is 100 Master Router is 10.0.10.2 (local), priority is 100 Master Advertisement interval is 10s Skew time is 0.609s Master Down interval is 30.609s
OK, that was fun, but let’s put all those values back to their defaults so we can move on:
Arista-A(config-if-Vl10)#vrrp 10 preempt Arista-A(config-if-Vl10)#default vrrp 10 timers Arista-A(config-if-Vl10)#default vrrp 10 preempt delay
Let’s make sure that everything is back to normal:
Arista-A(config-if-Vl10)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Master Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 100 Master Router is 10.0.10.2 (local), priority is 100 Master Advertisement interval is 1s Skew time is 0.609s Master Down interval is 3.609s
Now let’s see what happens when we add Arista-B to the mix, with all of the defaults left untouched:
Arista-B(config)#int vlan 10 Arista-B(config-if-Vl10)#vrrp 10 ip 10.0.10.1
Let’s see what Arista-B thinks about our new VRRP configuration:
Arista-B(config-if-Vl10)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Backup Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 100 Master Router is 10.0.10.2, priority is 100 Master Advertisement interval is 1s Skew time is 0.609s Master Down interval is 3.609s
Looks good, and everything has the same default values. Figure 19-2 shows the new VRRP-enabled network.
Figure 19-2. VRRP enabled on our simple network
So, what made Arista-B decide to become the backup router? It became the backup because a master already existed and that master had the same priority as Arista-B. Here’s what the RFC says on the subject:
The protocol should ensure after Master election that no state transition is triggered by any Backup router of equal or lower preference as long as the Master continues to function properly.
If I were to pull off all of the configurations and configure Arista-B first, it would become the master, and when I then configured Arista-A, it would become the backup. This can be different behavior than that exhibited by HSRP. If two routers are both configured in the same group, on the same VLAN, with the same VIP, they will negotiate who will become the master, and a new master might be chosen (depending on the version of code; this behavior has changed over time).
I like to have a little more control over which switch becomes the master router, so I’ll assign a priority to the VRRP group. Because Arista-B is currently the backup, let’s configure it with a higher priority and see what happens. The default priority is 100. The priority value can be any integer in the range of 1 to 254, so let’s make Arista-B have a priority of 105:
Arista-B(config-if-Vl10)#vrrp 10 priority 105
Note
Higher priorities are better in VRRP. Well, who’s to say what better really means? I suppose that I could say that higher priorities are more desirable, but that makes me think that the master routers should be prettier. Instead, I’ll write that the router with the highest priority will become the master router, and leave it at that. Also, a priority of 255 indicates that the interface IP is the VIP, which is why doing so will force the router to become the master. Only you can’t do that in EOS, so never mind.
The switch quickly becomes the master because it has a higher priority than Arista-A:
Arista-B(config-if-Vl10)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Master Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 105 Master Router is 10.0.10.3 (local), priority is 105 Master Advertisement interval is 1s Skew time is 0.590s Master Down interval is 3.589s
Now that we have Arista-B set with a higher priority, let’s see how preemption works. Here, I just shut down the SVI for VLAN 99 on Arista-B:
Arista-B(config-if-Vl10)#shut
In short order, Arista-A becomes the master router:
Arista-A(config-if-Vl10)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Master Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 100 Master Router is 10.0.10.2 (local), priority is 100 Master Advertisement interval is 1s Skew time is 0.609s Master Down interval is 3.609s
Remember when we added Arista-B, it became the backup because Arista-A was already the master, and the priorities were the same? This time, when Arista-B starts advertising itself with a priority of 105, it should immediately take over master duty:
Arista-B(config-if-Vl10)#no shut
Arista-A gives up its role as master because a better master is available:
Arista-A(config-if-Vl10)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Backup Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 100 Master Router is 10.0.10.3, priority is 105 Master Advertisement interval is 1s Skew time is 0.609s Master Down interval is 3.609s
Technically, the router preempted when we first changed the priority, but I wanted to show that failing the new master and then bringing it back online would force another preemption.
Most VRRP implementations that I’ve used allow the VRRP VIP to be the same as the physical interface’s IP address on the master router. In fact, the RFC specifically mentions that using the physical IP address of a router will automatically make it the master. As of EOS 4.21.1F, the ability to use the physical interface’s IP address as the VIP is not supported and will result in an error:
Arista-A(config-if-Vl10)#vrrp 10 ip 10.0.10.2 % Address 10.0.10.2 is already assigned to interface Vlan10
One of the interesting features of VRRP that I rarely see used is the ability to serve multiple IP addresses within the group:
Arista-B(config-if-Vl10)#vrrp 10 ip 10.0.10.4 secondary Arista-B(config-if-Vl10)#vrrp 10 ip 10.0.10.5 secondary
And here’s the result:
Arista-B(config-if-Vl10)#sho vrrp
Vlan10 - Group 10
VRF is default
VRRP Version 2
State is Master
Virtual IPv4 address is 10.0.10.1
Secondary Virtual IPv4 address is 10.0.10.4
Secondary Virtual IPv4 address is 10.0.10.5
Virtual MAC address is 0000.5e00.010a
Mac Address Advertisement interval is 30s
VRRP Advertisement interval is 1s
Preemption is enabled
Preemption delay is 0s
Preemption reload delay is 0s
Priority is 105
Master Router is 10.0.10.3 (local), priority is 105
Master Advertisement interval is 1s
Skew time is 0.590s
Master Down interval is 3.589s
Of course, we should do any such configuration on all routers within the group.
You can secure VRRP using clear text or encrypted passwords by using the vrrp group-id authentication command. Options for encryptions include text and ietf-md5. Here’s how you configure a clear-text password:
Arista-A(config-if-Vl10)#vrrp 10 authentication text ILikePie
When using a clear-text password, the password is clearly visible, which is likely why they call it clear text. It is also the reason why you shouldn’t use it:
Arista-A(config-if-Vl10)#sho vrrp int vlan 10 | grep Auth Authentication text, string "ILikePie"
If you’re going to bother using passwords, do yourself a favor and encrypt them by using the ietf-md5 key-string string option:
Arista-A(config-if-Vl10)#vrrp 10 authentication ietf-md5 key-string ILikePie
When using MD5 passwords, the password is not shown in the status output, or in the running-config:
Arista-A(config-if-Vl10)#sho active | grep auth vrrp 10 authentication ietf-md5 key-string 7 6m3bUcIbCv6TLQ1FqGARXQ==
Note
Though much of EOS has migrated to using sha512 for password encryption, as of EOS 4.21.1F, VRRP is still limited to MD5.
I’m going to remove that to simplify the configuration for the rest of the chapter:
Arista-A(config-if-Vl10)#no vrrp 10 authentication ietf-md5 key-string
The last thing I cover regarding VRRP is the ability to track other interfaces. Even though I think this has more value on WAN routers for which serial links are likely to fail in colorful and interesting ways, the ability to track another interface is always welcome, and Ethernet handoffs have become the norm for many areas, so let’s see how it works. We begin with a baseline VRRP configuration. Here’s the configuration for Arista-B, which is back to having only one group and a priority of 105:
Arista-B(config-if-Vl10)#sho active interface Vlan10 ip address 10.0.10.3/24 vrrp 10 priority 105 vrrp 10 ip 10.0.10.1
Here’s the status for this switch:
Arista-B(config-if-Vl10)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Master Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 105 Master Router is 10.0.10.3 (local), priority is 105 Master Advertisement interval is 1s Skew time is 0.580s Master Down interval is 3.580s
The first step in tracking another interface is to create an object to track. Currently, as of EOS version 4.21.1F, the only objects that can be created are interface line protocol objects.
Note
In the first edition I wrote, “I can see that Arista, being the forward thinkers that they are, have left the doors open for all sorts of objects in the future. I imagine that I’d be able to track IP routes, ARP entries, MAC-table entries, and all sorts of wonderful things, but for now, let’s ignore my rambling daydreams and focus on the type we have available to us.”
I bring this up not to make a statement about Arista, but to point out that I usually suck at predicting the future.
To create an object, you must specify an object name. I’m going to call mine GAD, because I’m the writer, damn it, and I like seeing my initials in print if you haven’t guessed that by now. Also, it’s late, I’m tired, and thinking of something else seems like real work. After specifying the object name, append the object type to be tracked. Judicious use of tab completion and the question mark will show you that this is the only choice that you can make, unless you’d like to use your own initials, in which case I say, fine be that way:
Arista-B(config-if-Vl10)#track GAD interface e11 line-protocol
After you create the object, you can reference it by using the vrrp group-number track object-name interface command. There are two options: decrement and shutdown. decrement lowers the priority by the specified amount, and shutdown disables the VRRP group entirely. For this example, I decrement the priority by 10:
Arista-B(config)#int vlan 10 Arista-B(config-if-Vl10)#vrrp 10 track GAD decrement 10
With this track configured, should interface e11 go down, the priority for VRRP group 99 will drop 10 points, from 105 down to 95, which would make it five less than Arista-A’s default priority of 100. Let’s shut down interface e11 and see what happens:
Arista-B(config-if-Vl10)#int e11 Arista-B(config-if-Et11)#shut
With that done, let’s see what VRRP looks like on Arista-B:
Arista-B(config-if-Et11)#sho vrrp Vlan10 - Group 10 VRF is default VRRP Version 2 State is Backup Virtual IPv4 address is 10.0.10.1 Virtual MAC address is 0000.5e00.010a Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 95 Master Router is 10.0.10.2, priority is 100 Master Advertisement interval is 1s Skew time is 0.620s Master Down interval is 3.620s
Miscellaneous VRRP Stuff
VRRP has some cool features, as we’ve seen, but for some reason, I’m tickled by the idea that we can shut down a VRRP group like we can an interface. To do so, just use the vrrp group-id shut interface command:
Arista-B(config-if-Et11)#int vlan 10 Arista-B(config-if-Vl10)#vrrp 10 shutdown
To bring it back up, negate the command:
Arista-B(config-if-Vl10)#no vrrp 10 shutdown
We’ve already seen the results of the show vrrp command, but with many groups configured, it can become unwieldy. The command can be modified with the interface keyword, which is useful, but for my money the show vrrp brief command is the go-to command in busy environments:
Arista-B(config)#sho vrrp brie Interface Vrf Id Ver Pri Time State VrIps Vl10 default 10 2 95 3620 Backup 10.0.10.1
With track objects configured, you can see them by using the show track command. This can be very useful, especially when you have an object tracked in more than one place:
Arista-B(config)#sho track
Tracked object GAD is down
Interface Ethernet11 line-protocol
6 change, last change time was 0:05:54 ago
Tracked by:
Vlan10 vrrp v4 instance (10)
This command also has a brief modifier, but be careful because you need to spell out the word brief, or else the parser thinks you’re specifying the name of a track object:
Arista-B(config)#sho track brie % Tracked object brie does not exist Arista-B(config)#sho track brief Tracked object GAD is down
VARP
Virtual ARP, or Layer 3 Anycast Gateway, is a feature that’s so simple, I’m amazed that no one has ever thought of it before. Put simply, multiple devices are configured to respond to ARP and Gratuitous ARP (GARP) requests for a shared virtual IP address using a shared virtual MAC address. Seriously, that’s all it does. So, what’s so great about that?
First, by the very nature of the fact that both switches in a pair respond to ARP requests for the same IP address, this means that some devices will learn the MAC address from one switch, whereas other devices will learn from the other switch (assuming a pair). This also means that both switches can actively receive packets destined for the IP address. This active–active behavior is something that neither VRRP nor HSRP can replicate. Not only that, but VARP is completely standards based.
Cisco’s Gateway Load Balancing Protocol (GLBP) offers ARP load balancing, which is kind of similar at a high level, but much more complicated to configure and understand, which brings me to the second benefit. VARP takes just two lines of configuration on each switch for a single IP address and one additional line for each additional IP to be shared. There are no options, no timers, and no additional features to worry about. There are also no protocols involved. It just works.
Third, because packets that are received on a VARP address are forwarded to the next-hop destination on the same switch on which they were received (assuming IP routing is enabled and properly configured), these packets never need to traverse the peer link, thus reducing traffic latency, not to mention load on switches that don’t really need to carry the traffic in the first place.
This is accomplished by configuring a virtual MAC address globally on each switch. The switches will respond to ARP requests for each of the IP addresses to be shared with this configured MAC address, regardless of the VLAN or interface on which the request is heard.
Let’s take a look at how we might use VARP. First, let’s take a look at VRRP in use on a sample network. In Figure 19-3, there are four servers on VLAN 10, all configured to use the VRRP VIP of 10.0.10.1 as their default gateways. When they communicate with the server at 10.0.20.20, the packets all go to the active router, which is Arista-A, where they are forwarded from the SVI on VLAN 20. Because Multichassis Link Aggregation (MLAG) forwards packets from the switch on which they were received, all of these packets will be forwarded from Arista-A interface to the server at 10.0.20.20.
Figure 19-3. Packet flow using VRRP
Now, let’s compare that flow with the traffic flow for the same network using VARP. In Figure 19-4, because both switches have responded to the ARP requests for the default gateway of 10.10.10.100, both switches receive packets from a random sampling of the servers that sent the ARP requests.
Figure 19-4. A VARP-enabled network
Note
Though Figure 19-4 shows a nice, even distribution of servers, this is due to my neurosis that prevents me from crossing lines in drawings unless absolutely necessary. VARP does not weigh, distribute, or otherwise manage load in any way. The servers just believe whatever ARP response they received first, even if more than one gateway responds (see RFC 1027 if you don’t believe me).
Because MLAG forwards packets out the same switch wherever possible, the packets are then distributed over both switches, thus better utilizing the switches, the uplinks, and the network in general.
One thing to remember about VARP is that traffic is never sourced from the virtual address (with the exception of gratuitous ARPs). This means that the VIP cannot be used in routing, nor can it be used as a source address for protocols or features that support changing the source interface or address.
Configuring VARP
If you’re lucky enough to have a lab full of Arista switches, you should clear all the VRRP stuff that we worked on earlier in this chapter. The configuration for the VLAN 10 SVI on Arista-A should look like this to start:
Arista-A(config-if-Vl10)#no vrrp 10 Arista-A(config-if-Vl10)#sho active interface Vlan10 ip address 10.0.10.2/24
And here’s Arista-B’s fresh VLAN 10 SVI configuration:
Arista-B(config-if-Vl10)#no vrrp 10 Arista-B(config-if-Vl10)#sho active interface Vlan10 ip address 10.0.10.3/24
The first step is to configure the MAC address that our MAC address that our VIPs will use. This MAC will be used for every VIP we create on every VLAN, so make it count. I’ve blatantly stolen this MAC address from the Arista article on VARP because I was too lazy to look up the rules for making up MAC addresses.
Note
What can I say? Writing a book involves looking up a lot of things, and I just couldn’t bear to look up one...more...damn...thing.
The best part about this MAC address is that it’s owned by Arista and exists for your use. It does have the locally administered bit set (that thing I was too lazy to look up), so we’re good to go:
Arista-A(config)#ip virtual-router mac-address 00:1c:73:00:00:99
We need to make it the same on both sides:
Arista-B(config)#ip virtual-router mac-address 00:1c:73:00:00:99
If you don’t do that last step, the next step will fail. The next step is to configure a VIP on an interface, and, if it fails, don’t say I didn’t warn you:
Arista-A(config)#int vlan 10 Arista-A(config-if-Vl10)#ip virtual-router address 10.0.10.1
Warning
You cannot configure VARP on routed Ethernet interfaces, including the management interfaces. You can configure it only on VLAN interfaces. While the Arista Configuration Guide doesn’t specifically say that it won’t work on Ethernet interfaces, to be fair, it only mentions VLAN interfaces in the VARP section. If you need first-hop redundancy on physical interfaces, you’ll need to use VRRP.
That’s it! The switch is now responding to ARP requests for the VIP 10.0.10.1 with the MAC address that we took so much time to research and create. After these two steps are done, you’ll be able to ping the VIP:
pArista-A#ping 10.0.10.1 PING 10.0.10.1 (10.0.10.1) 72(100) bytes of data. 80 bytes from 10.0.10.1: icmp_seq=1 ttl=64 time=0.081 ms 80 bytes from 10.0.10.1: icmp_seq=2 ttl=64 time=0.021 ms 80 bytes from 10.0.10.1: icmp_seq=3 ttl=64 time=0.020 ms 80 bytes from 10.0.10.1: icmp_seq=4 ttl=64 time=0.020 ms 80 bytes from 10.0.10.1: icmp_seq=5 ttl=64 time=0.020 ms --- 10.0.10.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.020/0.032/0.081/0.024 ms, ipg/ewma 0.092/0.056 ms
Note
As an odd bit of history, pinging the VIP didn’t work on EOS versions 4.8.0 and prior, and let me tell you that the inability to ping the VIP will drive you slowly mad. Now you know how I got this way.
After you add the virtual address to Arista-B, you’ll also be able to ping the VARP address from there:
Arista-B(config-if-Vl10)#ip virtual-router address 10.0.10.1 Arista-B(config-if-Vl10)#ip virtual-router mac-address 00:1c:73:00:00:99 Arista-B(config)#ping 10.0.10.1 PING 10.0.10.1 (10.0.10.1) 72(100) bytes of data. 80 bytes from 10.0.10.1: icmp_seq=1 ttl=64 time=0.084 ms 80 bytes from 10.0.10.1: icmp_seq=2 ttl=64 time=0.021 ms 80 bytes from 10.0.10.1: icmp_seq=3 ttl=64 time=0.019 ms 80 bytes from 10.0.10.1: icmp_seq=4 ttl=64 time=0.019 ms 80 bytes from 10.0.10.1: icmp_seq=5 ttl=64 time=0.019 ms --- 10.0.10.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 0ms
Not only is this all we need for VARP to work, that’s about all that can be done. I like this feature because it’s simple, it works, it takes advantage of the way existing, open protocols work, and it’s easy to configure.
By the way, you can add more than one virtual IP address per VLAN. To do so, add another IP address with the ip virtual-router address ip-address interface command. Feel free to add as many as you’d like, up to the limit of 500 per VLAN. I’ll add only three so you won’t need to flip through 10 pages of code. Besides, my editor would just tell me to take them all out anyway:
Arista-B(config-if-Vl10)#ip virtual-router address 10.0.10.11 Arista-B(config-if-Vl10)#ip virtual-router address 10.0.10.12 Arista-B(config-if-Vl10)#ip virtual-router address 10.0.10.13
To see the status of your handiwork, use the show ip virtual router command, which shows you the configured MAC address and all VIPs, along with the real IP address and the interfaces on which they’re operating:
Arista-B(config-if-Vl10)#sho ip virtual-router
IP virtual router is configured with MAC address: 001c.7300.0099
IP router is not configured with Mlag peer MAC address
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.0.10.1 U active
Vl10 default 10.0.10.11 U active
Vl10 default 10.0.10.12 U active
Vl10 default 10.0.10.13 U active
If you configure the interfaces with a virtual router address, but don’t configure the global virtual router MAC address your virtual router won’t work, even though you might think that it should. Here’s what it looks like when starting with no VARP configuration:
Arista-B(config)#no ip virtual-router mac-address 00:1c:73:00:00:99
It looks fine, but the status tells you it’s not. If you’re not used to configuring VARP, this can be confusing. You just configured the virtual router address, and it’s telling you that the virtual router is not configured:
Arista-B(config)#sho ip virtual-router IP virtual router MAC address is not configured IP router is not configured with Mlag peer MAC address
Conclusion
VARP is a very clever solution to an age-old problem. It was one of the things that piqued my interest when visiting Arista the first time because it’s so unique. I encourage you to try it out if at all possible and see how you can use it in your environment. And if you decide that it’s not for you, you can always use VRRP. One of the things that VARP has going for it above VRRP, though, is the fact that there are no timers involved, so there’s no lag during accidental or even intended failovers.