How to Configure HSRP (Hot Standby Router Protocol) on Cisco Switches: Redundancy Setup Guide

How to Configure HSRP (Hot Standby Router Protocol) on Cisco Switches

There’s a particular kind of outage that teaches every network engineer the value of gateway redundancy: the moment a core router’s power supply fails and every host on that subnet simultaneously loses its default gateway, even though a second, perfectly healthy router sits right next to it doing nothing. HSRP was Cisco’s original answer to that scenario, and even in a world with newer options like VRRP and GLBP, it remains one of the most widely deployed first-hop redundancy protocols out there — largely because it’s simple, mature, and extremely well understood.

What HSRP Provides

HSRP (Hot Standby Router Protocol) allows two or more routers to share a single virtual IP address and virtual MAC address, presenting themselves to hosts as one reliable default gateway. Under the hood, one router is elected active, actually forwarding traffic for the virtual IP, while another is elected standby, ready to take over instantly if the active router fails. Additional routers in the group (if any) sit in a listen state.

Key characteristics:

  • Virtual MAC format: 0000.0c07.acXX where XX is the HSRP group number in hex
  • Default hello timer: 3 seconds; default hold timer: 10 seconds
  • Active/standby election based on configurable priority (higher wins, default 100)
  • Failover typically completes within the hold-timer window, though sub-second failover is achievable with tuned timers

Topology for This Guide

Two routers, R1 and R2, on the same LAN (VLAN 10, 192.168.10.0/24), sharing virtual IP 192.168.10.1 as the default gateway for hosts.

Hosts (192.168.10.0/24) --- R1 (.2) --- R2 (.3) --- Upstream
                Virtual IP: 192.168.10.1

Step 1: Basic HSRP Configuration on R1 (Intended Active)

R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip address 192.168.10.2 255.255.255.0
R1(config-if)# standby 10 ip 192.168.10.1
R1(config-if)# standby 10 priority 150
R1(config-if)# standby 10 preempt

Step 2: Basic HSRP Configuration on R2 (Intended Standby)

R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip address 192.168.10.3 255.255.255.0
R2(config-if)# standby 10 ip 192.168.10.1
R2(config-if)# standby 10 priority 100
R2(config-if)# standby 10 preempt

Because R1 has the higher priority (150 > 100), it becomes active. The preempt command is critical — without it, R1 won’t reclaim active status automatically after recovering from a failure, leaving R2 as active indefinitely even once R1 is healthy again.

Step 3: Configure HSRP Version 2 (Recommended)

HSRPv2 supports millisecond timers, a larger group number range (0-4095 vs. 0-255), and IPv6 support. Configure it explicitly for new deployments:

R1(config-if)# standby version 2
R2(config-if)# standby version 2

Step 4: Tune Hello/Hold Timers for Faster Failover

R1(config-if)# standby 10 timers msec 200 msec 750
R2(config-if)# standby 10 timers msec 200 msec 750

This sets a 200ms hello interval and 750ms hold time, achieving sub-second failover detection — appropriate for latency-sensitive environments, though it increases control-plane chatter slightly.

Step 5: Object Tracking for Uplink Failure

A router can be “active” for HSRP purposes yet have a dead upstream WAN link, silently blackholing traffic. Object tracking solves this:

R1(config)# track 1 interface GigabitEthernet0/2 line-protocol
R1(config)# interface GigabitEthernet0/1
R1(config-if)# standby 10 track 1 decrement 60

If GigabitEthernet0/2 fails, R1’s HSRP priority drops by 60 (from 150 to 90), falling below R2’s priority of 100, triggering an automatic failover to R2.

Step 6: Authentication (Strongly Recommended)

Plaintext (legacy, avoid in production):

R1(config-if)# standby 10 authentication text MyHsrpKey

MD5 authentication (preferred):

R1(config-if)# standby 10 authentication md5 key-string HsrpSecure123
R2(config-if)# standby 10 authentication md5 key-string HsrpSecure123

This prevents a rogue or misconfigured router from joining the HSRP group and disrupting the active/standby election.

Step 7: Verification

R1# show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi0/1       10   150 P Active  local           192.168.10.3    192.168.10.1

Detailed state:

R1# show standby GigabitEthernet0/1 10
GigabitEthernet0/1 - Group 10 (version 2)
  State is Active
    6 state changes, last state change 00:22:10
  Virtual IP address is 192.168.10.1
  Active virtual MAC address is 0000.0c9f.f00a
    Local virtual MAC address is 0000.0c9f.f00a (v2 default)
  Hello time 200 msec, hold time 750 msec
    Next hello sent in 0.140 secs
  Preemption enabled
  Active router is local
  Standby router is 192.168.10.3, priority 100 (expires in 0.660 sec)
  Priority 150 (configured 150)
    Track object 1 state Up decrement 60
  Group name is "hsrp-Gi0/1-10" (default)

Verify authentication is active and matched:

R1# show standby GigabitEthernet0/1 10 | include Authentication
  Authentication MD5, key-string

Real-World Enterprise Scenario: Multi-VLAN Distribution Layer

Consider a distribution layer pair serving 20 VLANs across a campus. Rather than making one router active for all 20 VLANs (wasting the second router’s uplink capacity entirely), a common design pattern splits HSRP active roles across the two distribution switches — R1 is active for even-numbered VLAN groups, R2 is active for odd-numbered VLAN groups — achieved simply by alternating which router has the higher priority per VLAN/group:

! On R1
interface Vlan10
 standby 10 priority 150
interface Vlan20
 standby 20 priority 100

! On R2
interface Vlan10
 standby 10 priority 100
interface Vlan20
 standby 20 priority 150

This “HSRP load sharing” pattern gives you the operational simplicity of HSRP’s single active/standby model per group while still using both routers’ uplinks productively across the aggregate of all VLANs — a very common alternative to GLBP when teams prefer HSRP’s simplicity and well-understood failover behavior.

Security Best Practices

  • Always enable MD5 authentication — plaintext authentication offers essentially no real protection
  • Use object tracking on every HSRP-enabled interface with an upstream dependency, not just as an afterthought
  • Restrict which interfaces can participate in HSRP via physical/VLAN access control, since a rogue device advertising HSRP hellos with a higher priority can hijack the active role
  • Monitor %HSRP-5-STATECHANGE syslog messages centrally to detect unexpected flapping early

Common Configuration Mistakes

  • Forgetting preempt, leaving a recovered primary router stuck in standby indefinitely
  • Mismatched HSRP group numbers or virtual IPs between routers, silently creating two separate groups instead of one shared group
  • Not configuring object tracking, so a dead WAN uplink doesn’t trigger failover even though the router itself remains healthy
  • Using HSRPv1 in new deployments, missing out on millisecond timers and larger group ranges available in HSRPv2
  • Overlapping virtual MAC addresses when running many HSRP groups without version 2’s expanded group range, causing MAC conflicts on busy VLAN trunks

Troubleshooting Checklist

  1. show standby brief — quick view of active/standby state across all groups
  2. show standby <interface> <group> — detailed state, priority, and tracking status
  3. Confirm hello/hold timers match exactly between routers, since mismatches can cause instability
  4. Verify authentication configuration matches on both routers if a peer refuses to form
  5. Check track object status (show track) to confirm interface/route tracking is functioning as expected

Performance Tuning

  • Use HSRPv2 with millisecond timers in latency-sensitive environments (VoIP, trading floors) to minimize failover-induced packet loss
  • Don’t over-tune timers unnecessarily in stable, non-latency-critical LANs — very aggressive timers increase CPU and control-plane load for a failover benefit you may not need
  • When running many HSRP groups on a single router (e.g., per-VLAN gateway redundancy across dozens of VLANs), monitor CPU utilization, since each group runs its own independent hello/hold state machine

FAQs

What’s the difference between HSRP and VRRP? HSRP is Cisco-proprietary; VRRP is an open IETF standard supporting multi-vendor environments. Functionally they’re very similar in the active/standby model.

Can more than two routers participate in one HSRP group? Yes — additional routers sit in “listen” state, ready to be promoted to standby if the current standby fails, though only one router is ever active per group.

Does HSRP support IPv6? Yes, HSRPv2 supports IPv6 virtual addressing in addition to IPv4.

Is preempt enabled by default? No — you must explicitly configure standby preempt on any router you want to reclaim active status automatically after recovering from a failure.

Summary

HSRP remains one of the most reliable and easiest-to-reason-about first-hop redundancy protocols available, precisely because its active/standby model is simple to configure, verify, and troubleshoot. Get the fundamentals right — matching group numbers and virtual IPs, enabling preempt deliberately, adding MD5 authentication, and tracking upstream interface health — and you’ll have a gateway redundancy setup that fails over cleanly without any surprises during a real outage.

References

  • Cisco: Configuring HSRP
  • Cisco IOS-XE First Hop Redundancy Protocols Configuration Guide
Total
1
Shares

Leave a Reply

Previous Post
How to Set Up Frame Relay on Cisco Routers

How to Set Up Frame Relay on Cisco Routers: Configuration and Troubleshooting Guide

Next Post
How to Set Up VTP (VLAN Trunking Protocol) Pruning

How to Set Up VTP (VLAN Trunking Protocol) Pruning on Cisco Switches for Optimized Traffic

Related Posts