Configure HSRP in Cisco IOS Router

HSRP or Hot-Standby Routing Protocol is a mechanism developed by Cisco to add redundancy at the gateway of a subnet. The idea of HSRP is using multiple routers to serve as a gateway using one virtual IP address. One of the routers will be designated as the active gateway, and if it’s become unreachable there are other routers that ready to take its role as the active gateway; thus, providing redundancy. In this post, we will learn how to configure HSRP in Cisco IOS router.

Configure HSRP in Cisco IOS Router

In this example, we will use two routers as member of HSRP group. We will configure each router with unique physical IP but they must have the same group number and virtual IP. This virtual IP will be used by all end-devices as their default gateway.

Configure HSRP in Cisco IOS Router

Now let’s start the configuration from interface f0/0 on R1:

R1(config)#interface f0/0
R1(config-if)#ip address 10.1.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#standby 123 ip 10.1.1.100
R1(config-if)#standby 123 preempt

The command standby 123 ip 10.1.1.100 means that we add R1 to HSRP group number 123 with the virtual IP address of 10.1.1.100. The second command is preempt, but we’ll get to that later. Now let’s add R2 to the same HSRP group and give it the same virtual IP address. Below is the configuration for R2 interface f0/0:

R2(config)#interface f0/0
R2(config-if)#ip address 10.1.1.2 255.255.255.0
R2(config-if)#no shutdown
R2(config-if)#standby 123 ip 10.1.1.100
R2(config-if)#standby 123 priority 90

Notice there is something different on R2 config. The command priority 90 means we give R2 lower priority than R1 (default priority is 100, if unspecified). As result of this configuration R2 will be the standby gateway because it has lower priority, and R1 will be the active gateway because it has higher priority.

HSRP will work when R1 become unreachable, R2 will receive the notification and take the active gateway role to from R1.

Verification

The command to verify HSRP configuration is show standby brief with the output shown below.

On R1:

R1#show standby brief
                   P indicates configured to preempt.
                   |
Interface Grp  Pri P State   Active          Standby         Virtual IP
Fa0/0     123  100 P Active  local           10.1.1.2        10.1.1.100

On R2:

R2#show standby brief
                   P indicates configured to preempt.
                   |
Interface Grp  Pri P State   Active          Standby         Virtual IP
Fa0/0     123  90    Standby 10.1.1.1        local           10.1.1.100

From R1 ouput above, we can its state is active, active IP is local (means R1 itself), and the standby IP is 10.1.1.2 (R2 physical IP). Otherwise on R2, the state is standby and standby IP is local (R2 itself), while the active IP is 10.1.1.1 (R1 physical IP). We can conclude that R1 is now the active gateway. Let’s verify using traceroute using client PC to one of the loopback addresses on the cloud as shown below:

Client-PC>tracert -d 8.8.8.8

Tracing route to 8.8.8.8 over a maximum of 30 hops

1 11 ms 10 ms 9 ms 10.1.1.1
2  9 ms 11 ms 9 ms 8.8.8.8

Trace complete.

From the traceroute result we can see that we successfully reach the cloud loopback IP address and you can see the first hop address on the traceroute result is 10.1.1.1 (R1 physical IP), means the packet transferred using route via R1.

HSRP Failover Test

Now let’s try making R1 unreachable by disabling its f0/0 interface and verify HSRP status on both routers.

R1(config)#interface f0/0
R1(config-if)#shutdown
R1(config-if)#end

Verification from R1:

R1#show standby brief
                   P indicates configured to preempt.
                   |
Interface Grp  Pri P State   Active          Standby         Virtual IP
Fa0/0     123  100 P Init    unknown         unknown         10.1.1.100

Probably you won’t see any useful output from R1, both active and standby are unknown at this time.

Verification from R2:

R2#show standby brief
                   P indicates configured to preempt.
                   |
Interface Grp  Pri P State   Active          Standby         Virtual IP
Fa0/0     123  90    Active  local           unknown         10.1.1.100

You see output on R2 now has active state, means R2 has taken the role as active gateway since R1 has become unreachable. The standby IP on R2 is unknown because the interface on R1 has been completely disabled. But that doesn’t matter for now, because client PC can still reach cloud loopback IP address. Let’s do traceroute once again to verify with command as follows:

Client-PC>tracert -d 8.8.8.8

Tracing route to 8.8.8.8 over a maximum of 30 hops

1 10 ms 10 ms 9 ms 10.1.1.2
2  9 ms 11 ms 9 ms 8.8.8.8

Trace complete.

Yup! Cloud loopback IP is still reachable, but this time the first hop address is 10.1.1.2 (R2 physical IP). That means packet is now transferred using route via R2. HSRP failover works perfectly!

HSRP Preemption Test

And now is the interesting part. As you have noticed, we use command preempt on R1 configuration. What it actually does is ensuring that R1 will take back the active gateway role from R2 when it comes back alive after an event that triggers HSRP failover. To prove that, we will re-enable f0/0 interface on R1 and not long after that it should have claimed back the active gateway role.

R1(config)#interface f0/0
R1(config-if)#no shutdown

Verification from R1:

R1#show standby brief
                   P indicates configured to preempt.
                   |
Interface Grp  Pri P State   Active          Standby         Virtual IP
Fa0/0     123  100 P Active  local           10.1.1.2        10.1.1.100

Verification from R2:

R2#show standby brief
                   P indicates configured to preempt.
                   |
Interface Grp  Pri P State   Active          Standby         Virtual IP
Fa0/0     123  90    Standby 10.1.1.1        local           10.1.1.100

Verification from client PC:

Client-PC>tracert -d 8.8.8.8

Tracing route to 8.8.8.8 over a maximum of 30 hops

1 9 ms 10 ms 9 ms 10.1.1.1
2 9 ms  9 ms 9 ms 8.8.8.8

Trace complete.

Okay, traceroute result showing that we’re now back using route via R1, and that means preemption also works perfectly!

Conclusion

That’s pretty much how we configure HSRP in Cisco IOS router. You sure have seen that besides providing gateway redundancy, the other benefit of using HSRP is the process is completely invisible to the end-devices. There is no need for any configuration changes on the end-device side whenever failure happens at the gateway and HSRP failover kicks in, because all end-devices are using the virtual IP address as their default gateway.

The following two tabs change content below.
Arranda Saputra

Arranda Saputra

CCNA, CCDA
An IT infrastructure practitioner with specialization in network engineering. Cisco is his first love. He enjoys living anywhere within the three phases of plan, build, and manage.
Arranda Saputra

Latest posts by Arranda Saputra (see all)