We know that most networks are designed to mitigate downtime by ensuring there are no single points of failure. For example, Spanning Tree Protocol provides redundancy at layer 2, in addition to mitigating loops and broadcast storms. Link aggregation provides link redundancy by ensuring data stills has a path to take in the event a link goes down. In this post, we’ll take a look at how we can achieve router redundancy to eliminate single points of failure at layer 3.
What about Layer 3?
If a network only has one device acting as the default gateway, what happens if that device goes down? Users on the network wouldn’t be able to reach the internet. This is where router redundancy and First Hop Redundancy Protocols (FHRPs) come in. FHRPs are types of protocols that enable two or more routers to share a single, virtual IP address. This IP address can be configured on end devices as the default gateway. A primary router is elected to handle routing, and other routers are in standby. If the primary router goes down, a standby router takes over and continues processing traffic. As of writing, you only need to know the purpose of FHRPs for the CCNA 200-301 exam. Configuration comes in at the CCNP level. However, I believe it is best to learn about protocols practically.
First Hop Redundancy Protocols
As stated before, FHRPs are a type of protocol. There are three main FHRPs you should be aware of:
1. HSRP (Hot Standby Router Protocol)
- Cisco Proprietary.
- Two versions of HSRP. Version 2 has a couple differences compared to version 1: more number of groups, more timer tuning options, uses a different virtual MAC address, and adds support for IPV6.
- Active/Standby terminology.
- Uses multicast 224.0.0.2 (common multicast for all routers) for v1, and 224.0.0.102 for v2.
- Uses virtual MAC 000.0c07.acxx for v1, and 0000.0c9f.fxxx for v2, where xx is the group number.
- Preemption is disabled by default.
2. VRRP (Virtual Router Redundancy Protocol)
- Open Standard FHRP that is functionally the same as HSRP.
- There are several versions of VRRP, however they all share the same MAC address and multicast address.
- Master/Backup terminology
- Uses multicast 224.0.0.18.
- Uses virtual MAC 0000.5300.01xx, where xx is the group ID.
- Preemption is enabled by default.
3. GLBP (Gateway Load Balancing Protocol)
- Cisco Proprietary.
- Load balances multiple routers within the SAME subnet.
This lab covers configuring both HSRP and VRRP, but not GLBP. It is mentioned here as an FYI.
Lab Overview
In this lab, we’ll take a look at how to configure both HSRP and VRRP. We’ll be configuring both HSRP and VRRP, as well as taking a look at how each protocol handles faults in the network. I have provided a Packet Tracer file for this lab in addition to the completed lab for reference. They can be downloaded below.
Note: Packet Tracer does not support the configuring VRRP, though it is VERY similar to HSRP.
(Completed lab available here)

Configuring HSRP
As stated before, HSRP or Hot Standby Router Protocol is a Cisco proprietary FHRP. In this lab, we’ll take a look at how to configure HSRP on two Cisco routers and verify the configuration by removing links to ensure connectivity to the gateway persists.
Objectives:
- Configure HSRP on R1
- Use a group ID of 1
- Use a virtual IP of 10.16.1.252
- R1’s priority should be 150
- R1 should be preemptive
- Configure HSRP on R2
- Use a group ID of 1
- Use a virtual IP of 10.16.1.252
- Enable preemption
- Verify
- Use show commands to verify HSRP configuration
- Verify PC1 can ping the virtual IP address
- Verify HSRP works as intended by simulating a device failure on R1
1. Configure HSRP on R1
The first thing we’re going to do is configure HSRP on R1. HSRP is configured in the interface configuration context using the standby command: standby {group ID} ip {virtual IP}. The objectives state that R1’s priority should be 150 and should be preemptive. Configuring the priority to be 150 will ensure it will become the active router since we will be leaving the priority as default 100 on R2. Preemption will allow R1 to take over as the active router immediately. Meaning, if R1 goes down and R2 becomes active, R1 will take over as active once it comes back online.
Priority can be configured using the standby {group Id} priority {0-255} command, and preemption can be enabled with the standby {group ID} preempt command.
By default, priorities are set to 100. If priorities are the same on participating routers, the router with the highest IP address will become the active router.If no group ID is specified, it will be 0 by default.
interface GigabitEthernet0/0
standby 1 ip 10.16.1.252
standby 1 priority 150
standby 1 preempt
2. Configure HSRP on R2
The configuration for R2 is similar, except we are not going to set a priority. This will leave the priority as default, which is 100. Also you must use the same group ID.
interface GigabitEthernet0/0
standby 1 ip 10.16.1.252
standby 1 preempt
3. Verify
After configuring R1 and R2, lets verify the configuration with the show standby command. This command is great because it shows us the router states, virtual IP address, virtual MAC, timer information, priority, and more.


In the above screenshots, we can see that R1 is active, has a priority of 150, and a virtual IP of 10.16.1.252 as well as a virtual MAC of 00:00:0c:07:ac:01. On the other hand, R2’s state is standby with a priority of 100 (default).
I mentioned earlier in the post that HSRP version 1 uses a virtual MAC of 0000.0C07.ACxx. Notice how “01” is used at the end of he virtual MAC. That is because we used “1” in the standby command as the group ID. You can tell by the MAC that we are using HSRP v1.
Next, let’s verify PC1 can ping the virtual IP. The default gateway on the PC is already set to the virtual IP for you.

Finally, we can verify HSRP is working by running a constant ping from the PC to the virtual IP, and while the ping is going, break the link to R1. By breaking the link, we can simulate R1 as going down. R2 will take over after a few lost pings. Afterward, we can then follow that up by running the show standby command on R2, which will now show the state as active.

By breaking the link from S1 to R1, we can simulate that R1 has gone down. This will prevent HSRP Hello messages from being exchanged between R1 and R2. R2 will wait until it’s hold timer (10 seconds by default) runs out, and if no Hellos are retrieved from the active router, it will take over as active. You can see in the screenshot above that three pings are lost due to having to wait for the timer to run out. It is possible to reduce the timer count, but that is not covered in this lab.


Configuring VRRP
VRRP, or Virtual Router Redundancy Protocol, is an industry standard FHRP. Although Cisco has HSRP, most Cisco devices also support the use of VRRP for multi-vendor environments.
VRRP is not supported in Packet Tracer. For this demo, I use a lab spun up in Cisco Modeling Labs with the same topology as the above graphic.
Objectives:
- Configure VRRP on R1
- Use a group ID of 1
- Use a virtual IP of 10.16.1.252
- R1’s priority should be 150
- Configure VRRP on R2
- Use a group ID of 1
- Use a virtual IP of 10.16.1.252
- Verify
- Use show commands to verify VRRP configuration
- Verify PC1 can ping the virtual IP address
- Verify VRRP works as intended by simulating a device failure on R1
1. Configure VRRP on R1
The configuration of VRRP is VERY similar to HSRP. It is configured in the interface configuration context, and uses the vrrp command. The command syntax is exactly like HSRP, just replace standby with vrrp.
interface GigabitEthernet1
vrrp 1 ip 10.16.1.252
vrrp 1 priority 150
2. Configure VRRP on R2
The configuration on R2 is very simple. All we need to do is configure VRRP on the GigabitEthernet0/0 interface. No need to set a priority here either, as we’ll be sticking with the default 100.
interface GigabitEthernet1
vrrp 1 ip 10.16.1.252
3. Verify
Similarly to HSRP, we can use the show vrrp command to verify VRRP status on both R1 and R2. Notice how preemption is enabled. One difference to note is that VRRP enables preemption by default, unlike HSRP. Since we are setting R1’s priority to 150, it will automatically be preemptive since it has the higher priority.


Recall that I mentioned earlier in the post that the virtual MAC for VRRP is 0000.5e00.01xx, where xx is the group ID as a hex value. In this case, xx is “01” because we are using a group ID of “1”.
Next, we can verify the virtual router is working by pinging the virtual IP from PC1.

Finally, we can repeat what we did for HSRP and simulate a fault to ensure VRRP is working as expected. In this case, I shutdown the GigabitEthernet1 interface on R1. In the below screenshots, we can that some pings from PC1 do drop as the routers switch over. We can also see that R2 becomes master after shutting down the interface on R1.

Similarly to HSRP, VRRP will take a few seconds to figure out that the mater router has gone down, after which a backup router will take over.


Because preemption is enabled by default, we can re-enable the GigabitEthernet1 interface on R1 for it to become the master router again. R2 will fall back to a backup status.


Bonus: Gratuitous ARPs and FHRPs
ARPs are very important when using a FHRP. Because there could be two or more routers configured in an FHRP group, how does the rest of the network know when the primary router goes down, and a standby takes over? On endpoints, there’s no need for the ARP table to be updated because they will have the virtual IP address and virtual MAC address stored, which does not change depending on which router is active.
What does need to change are switch MAC tables. Recall that switch MAC tables store information about which interface a MAC address lives on. While the primary router is online, switches will have an entry in their MAC tables with information on which interface the MAC is reachable. However, if the primary router goes down, it will no longer be available on the interface a switch has associated it with. The standby router that takes over will send out a gratuitous ARP, which is a broadcast frame, that will inform the switches the location of the virtual MAC has changed. This will cause all the switches in the network to update their MAC address table to face the now active router.
Thanks for Reading!
Thanks for checking out my guide on FHRPs. If you believe there is something wrong with the initial configuration or have any suggestions/feedback, please contact me via my contact form to let me know.
Full Configuration
The full configuration for this lab can be found on my GitHub.