The very first redundancy protocol I ever configured on a production network was HSRP, and honestly, it’s still the one I reach for most often on Cisco-only networks. It’s mature, well-documented, predictable, and every Cisco engineer I’ve ever worked with already understands it. If you’re running an all-Cisco distribution or core layer and just need a dependable default gateway failover mechanism, HSRP is usually the simplest path there.
Let me walk you through how it works and how to actually configure it correctly, because there are a few details that trip people up.
What Problem HSRP Solves
Hosts on a LAN are configured with one default gateway IP. If that gateway device fails, every host loses connectivity off-subnet until someone manually intervenes — unless there’s a redundancy protocol backing it up. HSRP creates a virtual IP and virtual MAC address shared by a group of routers, with one router (the Active) doing the actual forwarding and another (the Standby) ready to immediately take over.
Core Concepts You Need First
- Default gateway: hosts don’t discover gateways dynamically; they’re statically pointed at one IP.
- ARP resolution: whichever router answers ARP for the gateway IP is the one that actually forwards traffic.
- Virtual MAC address: HSRP virtual MACs follow the format
0000.0C07.ACxx, wherexxis the HSRP group number in hex.
How HSRP Works
- Routers in an HSRP group are configured with the same virtual IP address.
- Each router has a priority (0–255, default 100). The highest priority wins the Active role; ties are broken by highest real interface IP address.
- The Active router responds to ARP requests with the virtual MAC and forwards all traffic sent to it.
- The Standby router listens for hello messages (default every 3 seconds) from the Active. If it misses hellos for the hold time (default 10 seconds), it takes over as Active.
- HSRP has two versions: HSRPv1 (group range 0–255, one multicast address for all groups) and HSRPv2 (group range 0–4095, separate multicast address, supports IPv6, and includes a 6-byte virtual MAC scheme that avoids some collision issues v1 had at scale).
Basic HSRP Configuration
I’ll set up the same style of lab I always use: two routers, R1 and R2, on a shared LAN segment, sharing virtual IP 192.168.30.1.
On R1 (intended Active):
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 192.168.30.2 255.255.255.0
R1(config-if)# standby 30 ip 192.168.30.1
R1(config-if)# standby 30 priority 150
R1(config-if)# standby 30 preempt
R1(config-if)# no shutdown
On R2 (Standby):
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip address 192.168.30.3 255.255.255.0
R2(config-if)# standby 30 ip 192.168.30.1
R2(config-if)# standby 30 priority 100
R2(config-if)# no shutdown
Unlike VRRP, HSRP does not preempt by default — you have to explicitly enable it with standby 30 preempt, or your intended primary router won’t reclaim the Active role after coming back from a reboot or failure.
Verifying HSRP
R1# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Gi0/0 30 150 P Active local 192.168.30.3 192.168.30.1
R1# show standby
GigabitEthernet0/0 - Group 30
State is Active
2 state changes, last state change 00:03:47
Virtual IP address is 192.168.30.1
Active virtual MAC address is 0000.0c07.ac1e
Local virtual MAC address is 0000.0c07.ac1e (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.472 secs
Preemption enabled
Active router is local
Standby router is 192.168.30.3, priority 100 (expires in 8.816 sec)
Priority 150 (configured 150)
Group name is "hsrp-Gi0/0-30" (default)
Enterprise Scenario: Data Center Distribution Layer
On one project, I had a pair of Catalyst switches acting as the SVI gateway for several server VLANs. Since it was an all-Cisco environment, HSRP was the obvious fit. I used HSRPv2 because it supports both IPv4 and IPv6 gateways in the same framework, and gave me a much larger group number range, which mattered since we had over a hundred VLANs across the data center and needed unique group numbers to avoid virtual MAC collisions.
R1(config-if)# standby version 2
R1(config-if)# standby 30 ip 192.168.30.1
R1(config-if)# standby 30 priority 150
R1(config-if)# standby 30 preempt delay minimum 30
The preempt delay is worth calling out — it tells the router to wait 30 seconds after coming back up before reclaiming Active status, giving routing protocols and ARP tables time to fully converge first. Without this, I’ve seen routers preempt back into Active before their routing table was actually populated, causing a brief blackhole.
Interface Tracking
Just like VRRP, HSRP supports object tracking so a router gives up Active status if its uplink fails, even though its LAN-facing interface is still healthy.
R1(config)# track 1 interface GigabitEthernet0/1 line-protocol
R1(config-track)# exit
R1(config)# interface GigabitEthernet0/0
R1(config-if)# standby 30 track 1 decrement 60
Securing HSRP
HSRP hellos are unauthenticated multicast by default. I always add authentication on any segment I don’t fully control:
R1(config-if)# standby 30 authentication md5 key-string MyHsrpKey789
R2(config-if)# standby 30 authentication md5 key-string MyHsrpKey789
Plaintext authentication (standby 30 authentication text PASSWORD) exists too, but MD5 is the one I actually use in production.
HSRP Groups and Load Sharing
A common trick I use to avoid the “one router always idle” problem without switching to GLBP: run two HSRP groups on the same VLAN, with each router Active for one group and Standby for the other. Half the hosts (via DHCP option or manual gateway assignment) point to group 30’s virtual IP, and half point to a second group’s virtual IP.
R1(config-if)# standby 30 ip 192.168.30.1
R1(config-if)# standby 30 priority 150
R1(config-if)# standby 31 ip 192.168.30.4
R1(config-if)# standby 31 priority 100
R2(config-if)# standby 30 ip 192.168.30.1
R2(config-if)# standby 30 priority 100
R2(config-if)# standby 31 ip 192.168.30.4
R2(config-if)# standby 31 priority 150
This achieves rough load sharing without needing GLBP, though it does require splitting your host gateway assignments manually — GLBP does this automatically and is usually cleaner if you need true dynamic load balancing.
Common Configuration Mistakes
- Forgetting
preempt— this is the single most common HSRP mistake I see; without it, a router that reboots stays Standby forever even at higher priority. - Mismatched group numbers or virtual IPs between routers, silently preventing group formation.
- Using HSRPv1 with more than 255 groups, hitting a hard platform limit.
- Not setting a preempt delay, causing traffic blackholing during premature preemption before routing tables converge.
- Ignoring interface tracking, leaving a router claiming Active status despite a dead uplink.
Troubleshooting HSRP
show standby brief
show standby
show standby all
debug standby events
debug standby packets
If two routers both claim Active, check for a Layer 2 loop or multicast filtering issue preventing hello exchange, and double check authentication strings match exactly.
Performance Tuning
- Tighten hello/hold timers for faster failover on critical segments:
standby 30 timers 1 3, but balance this against added control-plane load. - Use
preempt delayin any environment where routing convergence takes longer than a few seconds after a router reboots. - Prefer HSRPv2 for new deployments — it supports more groups and IPv6, with no real downside on modern IOS/IOS-XE.
FAQs
Is HSRP better than VRRP? Neither is objectively better — HSRP is Cisco-only but has a few extra knobs (like preempt delay), while VRRP is vendor-neutral. In an all-Cisco shop, either works well; I lean HSRP out of familiarity and slightly finer control.
Does HSRP support load balancing? Not natively the way GLBP does, though running multiple groups with alternating priorities achieves a manual form of load sharing.
What’s the difference between HSRPv1 and HSRPv2? v2 supports more groups (0–4095 vs 0–255), IPv6, and a different virtual MAC/multicast scheme; there’s little reason to use v1 on modern hardware.
How fast can HSRP fail over? With default timers, up to 10 seconds. With sub-second timers on supported platforms, failover can happen in under a second.
Summary
HSRP has been my default gateway redundancy protocol for years on Cisco-only networks, mostly because it’s predictable and every engineer I hand it off to already understands it. The key things I always double-check are preempt behavior, authentication, and interface tracking — get those three right and HSRP is about as “set it and forget it” as networking gets.
