How to configure gateway redundancy with VRRP in IOS
How to configure gateway redundancy with VRRP in IOS
I recently posted a blog (How to configure gateway redundancy with HSRP in IOS) about how to configure HSRP for gateway redundancy. In that blog I mentioned that there is an alternate protocol which performs the same functionality as HSRP, but it is not Cisco-proprietary. This protocol is Virtual Router Redundancy Protocol (VRRP). Figure 1 shows the scenario in which VRRP will provide default gateway redundancy:
You will note that the network is identical to the network used in the HSRP blog I referenced earlier. This is done on purpose to validate the point that VRRP is functionally equivalent to HSRP. You may find sources that suggest that VRRP is faster than HSRP. This is a misconception related to the default settings of the two protocols. The default hello interval with HSRP is 3 seconds with a hold time of 10 seconds. The default hello time for VRRP is one second with a hold time of 3 seconds. With these settings, VRRP will recover faster than HSRP. What is omitted is that the timers for HSRP can be tuned, just like those of VRRP, to achieve much faster convergence than the default settings provide. Check my previous blog for the HSRP settings configuration.
Let us focus our attention on VRRP. Figure 1 shows that I have configured a virtual IP address of 10.1.1.5. One of the differences between HSRP and VRRP is that you can configure one of the physical participants in the VRRP group to possess the actual IP address that is being presented to clients as the gateway address. In HSRP you cannot do this. HSRP requires that the virtual IP address not match any of the real addresses in use. In the given scenario, the VRRP group number is 1, and VRRP1 has been configured with a higher priority value than VRRP2, ensuring that it will be the active router in the network while it is functional (also known as the master virtual router). This will make more sense when we look at the configs of the two routers that comprise the VRRP group. Here is the config on VRRP1:
Here is the config on VRRP2:
Figure 2 shows that VRRP1 is configured with a priority value of 110. The default priority value is 100. This gives the network admin the power to control which router does the packet forwarding. Since the higher priority wins, VRRP1 should be the master virtual router. Let’s check that:
Now to test the failover capability of VRRP, I will begin by verifying the current path from Client to 22.214.171.124, which should be through VRRP1. Let’s check:
So far, so good. Now I will start pinging from Client to 126.96.36.199, and I will send 5000 pings to give myself time to break the network. To break it, I will shut down interface F1/0 on VRRP1. Since the timer values have been left at the default, VRRP should be sending hellos once per second with a 3 second hold time. Another piece that has a bearing is that ISP is an EIGRP neighbor with both VRRP1 and VRRP2, but the VRRP routers are not EIGRP neighbors with each other. I will start the pings and then break the network. Here is what happened on the Client:
Based on the above output, it took my network about 3.04 seconds to recover from the topology change and for pings to be restored. How did recovery occur? Notice in Figure 2 that one of the configuration commands looks like this:
vrrp 1 track 1 decrement 15
It turns out that, while HSRP can track an interface directly, VRRP can only do so indirectly. It does this by tracking an object. The object is, of course, tracking an interface. This is done by configuring ip sla. (For more on ip sla and tracking configuration, see my previous blog: GNS3 and IP SLA with default route tracking) Let’s see the running-configuration on VRRP1:
So once per second, VRRP1 verifies that it can reach its next hop IP address using ip sla monitor 10. Then we set up tracking to use that information to our advantage. Let’s see that:
So when the VRRP1 config says track 1, it is referring to the above tracking object, which is numbered with the ID of 1.
With all this working in tandem, we have a network that is reliable and resilient – all by using the First Hop Redundancy Protocol (FHRP) known as VRRP. I have not covered every subtle nuance of VRRP, but this blog serves to introduce the topic and some of the coolness of this protocol. Lab it up and try it for yourself!
Until next time…
You May Also Like
Mark Jacob, Cisco Instructor, presents an introduction to Cisco Modeling Labs 2.0 or CML2.0, an upgrade to Cisco’s VIRL Personal Edition. Mark demonstrates Terminal Emulator access to console, as well as console access from within the CML2.0 product. Hello, I’m Mark Jacob, a Cisco Instructor and Network Instructor at Interface Technical Training. I’ve been using … Continue reading A Simple Introduction to Cisco CML2
This content is from our CompTIA Network + Video Certification Training Course. Start training today! In this video, CompTIA Network + instructor Rick Trader demonstrates how to use cable testers in network environments. Let’s look at some tools that we can use to test our different cables in our environment. Cable Testers Properly Wired Connectivity … Continue reading Cable Testers and How to Use them in Network Environments
Hi, my name is Mike Danseglio. I’m an instructor here at Interface Technical Training. I want to talk a little bit about encrypting USB flash drives with Windows 10. The concept of protecting data when it’s on a USB flash drive is not a new concept. BitLocker 2-day instructor-led training is now available at Interface: … Continue reading Encrypting a USB Flash Drive in Windows 10