Virtual Router Redundancy Protocol (VRRP) makes your network more reliable

David Davis introduces the Virtual Router Redundancy Protocol (VRRP), which enables you to set up a group of routers as a default gateway router for backup or redundancy purposes.

While there are methods like proxy ARP and IRDP that can help PC clients find their default router, most of us just configure a static route to a single router on each PC because it is easiest. However, by doing that, if that single router goes down, the PC client will be unable to reach other networks (like the Internet).

Virtual Router Redundancy Protocol (VRRP) enables you to set up a group of routers as a default gateway router (VRRP Group) for backup or redundancy purposes. This way, the PC clients can actually point to the IP address of the VRRP virtual router as their default gateway. If one of the master routers in the group goes down, one of the other routers can take over.

Routers can function as master or backup routers, and you can actually configure up to 255 virtual routers on a router interface. Of course, there are platform constraints like router memory, for instance. Additionally, VRRP is intended for use with IPv4 routers only.

Is there a version of the IOS that works on your router? Refer to my article "Get to Know the Cisco IOS Feature Navigator" to see if your current router IOS offers VRRP or if you need to upgrade your IOS.

Virtual Router Redundancy Protocol in greater detail

Let's take a close look at Figure A to understand a little better how VRRP works.

Figure A


Graphic courtesy of Cisco Systems

In this case, because VRRP uses the IP address of the Ethernet interface, Router A has assumed the position of Master or IP address owner (this is configurable). Clients 1-3 are configured with the default gateway IP address of and Routers B and C have become backup virtual routers. If Router A fails, then based on priority (this is also configurable), Router B automatically assumes the Master until Router A becomes available again. One of the main characteristics about VRRP is the router priority. You can set up different priorities for each of your routers, which would enable them to become masters or backup routers to keep your network up and running in case of a hardware or natural failure. This would also help you balance out the work load on your routers.

To configure the priority, use the following command in global configuration mode. In this example, I've set Router A with a priority of 300.

RouterA(conf-if)# vrrp 1 priority 300

What's the difference between VRRP and HSRP?

Does VRRP sound a little like Hot Standby Router Protocol (HSRP)? There are many similarities, such as load balancing and redundancy, but the greatest difference is that HSRP is a Cisco proprietary method whereas VRRP is an industry standard (based on RFC 2338). Both of these have some minor technical differences, but the resulting functionality is the same.

For more information on HSRP, please see the Cisco's "Configuring IP Services" documentation.

How do you configure VRRP?

Configuring VRRP can happen in a few commands. Here is the basic command syntax:

 vrrp [group] [timers advertise msec] [timers learn] [preempt delay] [priority] [description]

To enable VRRP on an interface, follow these steps in global configuration mode:

Router(config)# interface Fa0/0
Router(config-if)# vrrp (group) ip (ip address of the virtual router)

You would, of course, do this on a minimum of two routers (the smallest amount of routers you would want in your VRRP group).

To view the status of your VRRP group, use show vrrp, like this:

Router# show vrrp
Ethernet1/0 - Group 1
State is Master
Virtual IP address is
Virtual MAC address is 1234.5678.90ab
Advertisement interval is 3.000 sec
Preemption is enabled
min delay is 0.000 sec
Priority 100
Master Router is (local), priority is 140
Master Advertisement interval is 3.000 sec
Master Down interval is 5.33 sec

Using VRRP with your routers can keep your network up and running by configuring the Virtual Router Redundancy Protocol. VRRP can very quickly move all traffic over to a backup router in the event that the master fails. With mission-critical applications like VoIP, video, and e-mail, you need to do whatever you can to ensure that your network never goes down.

For more information on VRRP, please see "Cisco Virtual Router Redundancy Protocol."


I know this article is a little old now, but for those that are doing some research I believe the author was incorrect in reference to priority settings: Author says: "To configure the priority, use the following command in global configuration mode. In this example, I’ve set Router A with a priority of 300. RouterA(conf-if)# vrrp 1 priority 300" but... you can only set the priority to 255 max and since RouterA has both the virtual and physical ip address of, it's priority must be set to 255. If RouterA was let's say, then the priority could be something else between 1-254, with a virtual IP of "Priority. 8 bits, unsigned. (RFC 2338) Specifies the sending VRRP router's priority for the virtual router. Higher values equal higher priority. The priority value for the VRRP router that owns the IP address(es) associated with the virtual router MUST be 255. VRRP routers backing up a virtual router MUST use priority values between 1 and 254. The default priority value for VRRP routers backing up a virtual router is 100. The priority value zero (0) has special meaning indicating that the current Master has stopped participating in VRRP. This is used to trigger Backup routers to quickly transition to Master without having to wait for the current Master to timeout."


So presumably each VRRP Router must be connected to the "Cloud", or at least to another network that goes to the cloud (or another destination network should you decide to implement for inter-LAN routing. Am I right?


What about GLBP or HSRP - I think they are both better at the job than VRRP


Great article - however what is your stance on using combo router/switches? I was using two Dell PowerConnect 6024 switches as both my core switches and core routers. Both VRRP and RSTP worked great if one whole switch when down, but it seemed to have problems if one of the uplinked switches went down. Both VRRP and RSTP would detect the outage, but instead of VRRP waiting until the spanning tree reconverged, it just went ahead and made its own decisions, which never seemed to work right. As a result, I pulled the configuration in favor of just having the spare 6024 sitting for cold-failover. Any ideas on how I could have improved this?


The issue I have with both VRRP and HSRP is that if your primary router has the only access to the Cloud; when that router fails your outside access is down despite these protocols. So, multiple connections to the Cloud is a necessary ingredient to keep your network up online when the primary fails.

at least GLBP looks like it supports IPv6




We have bit similar situation. We have two cisco router in our MPLS could and HSRP is running on these routers for redundancy. We have single HP 5406 core switch. Now we want redundancy on our core level. So we decided to add second HP 5406 switch as backup switch and use VRRP redundancy protocol. During our testing, as soon as we enable VRRP on our core switch, it bring down whole network. It seems that primary MPLS router is trying to fail-over. We disabled VRRP, still network was down. When we disconnected link between core switch and secondary mpls router (backup router in mpls cloud), whole network starts working again.. We are not sure why this is happening. Can any one suggest?   

Thanks in advance



Unless you have VRRP or HSRP running on your outside interface with the physical connections going through a switch to present one physical port to the ISP. I know you say what if the switch goes down? Well most good network admins will have spare switches on-hand, and I'm sure most of you will agree that a switch is much easier to replace in a hurry than a router. This layout actually works surprisingly well. Of course this is only for Ethernet WAN connections.


Yes, I agree this article doesn't address how to do failover to a different link. How does the IP addressing work? How does the PC that is communicating over a VPN to a database over the internet re-establish that link when the primary link fails? Does the application need to be re-started? Does the PC perhaps have to be re-booted? Of course if all you are doing is accessing a webpage and you have a link that goes down, and then failover to a new link, all you do as a user is re-request the page and it'll come to you. How does the IT guy set this all up so that DNS servers don't have to be changed on the PC (we program the DNS server IP addresses into each PC when we program a static route to the router)? VRRP is just a single small step in the process of failover.


Guys, I think you're being a bit harsh on David Davis with this article. I don't think he claimed it'll make your whole network resilient just by adding VRRP / HRSP. But adding it to deal with situations where devices are unable to participate in "proper" routing protocols (unlike RIP) such as OSPF, BGP etc (or even Cisco's proprietary EIGRP) means use of VRRP / HSRP to find a default gateway out of the network in the event of failure of the current default gateway is a good thing. Anyway, Windows OSes don't seem to cope very well with large routing tables that would be populated by listening to routing updates, so having a single default gateway seems better (IMHO). Yes, of course resilient network design requires more than just this (appropriate switch resilience, multiple path management, diverse cable / link routing, multiple physical WAN paths and suitable SLAs from the service providers and maintainers - to name a few items - you correctly point to name resolution as one). And some decent design and on-going network management. Of course, if you've got a specific problem in mind, I'm sure there's quite a few TR listeners (like me!) who'd be only too happy to help..... One thing the article doesn't mention is that (IIRC) HSRP and VRRP both use multicasts to exchange information, so you may need to watch for reports of high broadcast levels depending how your switches handle flooding of multicasts - and whether your management tools look for that sort of metric (they should).

Photogenic Memory
Photogenic Memory

You made some valid points on everything. Thank you so much! I'll try to send some California sunshine your way!! Not to be a tease but I haven't seen real rain since February. It's been a nice long run! And yes, the surf's up dude! There's a good swell coming in. See ya!


This is my understanding, so happy to be shot down in flames if I'm wrong.... 1) Broadcasts are a special case of multicasts 2) Broadcast storms (e.g. ARPs and many, many others) are a bit of a misnomer since they could be multicasts 3) When a packet arrives at a switch port, it has to make a decision where to send it. If the I/G (individual / group) bit is set in the destination address, then it's a multicast and should be forwarded to all ports in the same VLAN(s) as the source port. If it's not set, then look in the bridge table (CAM in Cisco parlance) and if there's an entry, send it to the relevant port. If there's no entry, we're back to "flood" to all ports in the same VLAN as the source port. Only some switches have the ability to shut down a port to do rate throttling (but I'm not sure if they do actually make a distinction between broadcasts and all other multicasts). If you've a network with HSRP / VRRP, then you'd probably want to disable rate throttling on the router port (or set it to be no lower than an upstream WAN link bandwidth equivalent) I'm not saying Windows can't handle large routing tables, but my experience has been that large tables (1K +) seem to impact IP throughput, certainly up to W2K3 and XP, perhaps W2K8 and Vista improve things. What's the phrase, "your mileage may vary"? Given my description above, putting a switch in the middle has no effect on controlling multicasts versus a hub (is anyone really using those now? Okay handy for cheap port mirroring, but with network taps and even bottom end 5 port GE "smart" switches you can mirror one port for under USD100, why not use a switch?) Can't comment on large routing table performance of Windows versus open source, but given that many routers are or were based on the same sources as current day open source (we mean Linux, c'mon let's be honest), I'd say, there's a distinct possibility of their performing better (whether this is noticeable remains to be seen). Hope that helps. If you're at the beach, perhaps we can trade places - you can perhaps surf your water, here (UK) we're just bailing it out of everything at the moment.

Photogenic Memory
Photogenic Memory

With that high multi-cast traffic could be interpreted as some type of packet storm ( ARP or whatever ) and shutdown the interface, correct? Also, why can't Windows handle large routing tables from the router? What if you use a managed switch as a go between? That should reduce the OS burden, right? Can open source systems cope any better? Apologies? Clueless at the beach, LOL!

Editor's Picks