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 126.96.36.199, which should be through VRRP1. Let’s check:
So far, so good. Now I will start pinging from Client to 188.8.131.52, 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
In this video, you will gain an understanding of Agile and Scrum Master Certification terminologies and concepts to help you make better decisions in your Project Management capabilities. Whether you’re a developer looking to obtain an Agile or Scrum Master Certification, or you’re a Project Manager/Product Owner who is attempting to get your product or … Continue reading Agile Methodology in Project Management
How does an investigator hunt down and identify unknown malware? In this recording of our IT Security training webinar on April 21, 2015, Security expert Mike Danseglio (CISSP / CEH) performed several malware investigations on infected computers and identify symptoms, find root cause, and follow the leads to determine what’s happening. He demonstrated his preferred … Continue reading Detailed Forensic Investigation of Malware Infections – April 21, 2015