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.
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.100On 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.100From 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.100Probably 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.100You 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.100Verification 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.100Verification 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.
