FHRP

HSRP Configuration on Cisco IOS XE

HSRP configuration on Cisco IOS XE feature image, PingLabz
Table of Contents
In: FHRP, Fundamentals

HSRP configuration is short - a working setup is two lines per router - but the short config hides the decisions that actually matter. Which router is active, whether it stays active after a reboot, and what happens when its uplink fails are all controlled by commands people skip. This post is a configuration walkthrough on Cisco IOS XE that covers the minimum config and the four settings that make HSRP behave in production.

For the cluster overview, see the FHRP complete guide.

What you are building

HSRP gives a LAN a virtual gateway. Two (or more) routers share a virtual IP address and a virtual MAC address. Hosts point their default gateway at that virtual IP. One router is active and answers for the virtual IP and MAC; the other is standby, waiting. If the active router fails, the standby takes over the same virtual IP and MAC, and hosts never notice - their gateway address did not change.

So the configuration job is: pick a virtual IP, decide which router should normally own it, and decide how it should react to failures.

Minimum viable config

Two distribution-layer routers, R1 and R2, on VLAN 10 (subnet 10.20.0.0/24). The virtual gateway will be 10.20.0.1. Each router has its own real address on the SVI.

! R1
interface Vlan10
 ip address 10.20.0.2 255.255.255.0
 standby version 2
 standby 10 ip 10.20.0.1

! R2
interface Vlan10
 ip address 10.20.0.3 255.255.255.0
 standby version 2
 standby 10 ip 10.20.0.1

That is a complete, working HSRP setup. The 10 is the HSRP group number, the ip 10.20.0.1 is the virtual gateway. Hosts on VLAN 10 use 10.20.0.1 as their default gateway. Without anything else, the router with the higher IP address becomes active (R2 here) - which is rarely the router you actually wanted, hence the next section.

Setting 1: priority - choose the active router

HSRP priority ranges 0-255, default 100. The highest priority becomes active. To make R1 the intended active router, give it a priority above the default:

! R1
interface Vlan10
 standby 10 priority 110

Leave R2 at the default 100. R1's 110 beats it. Always set priority explicitly - relying on the default means the active router is decided by whichever IP address happens to be higher, which is not a design decision.

Setting 2: preempt - the one everyone forgets

Here is the trap. You set R1 to priority 110. R1 reboots. While it is down, R2 (priority 100) becomes active - correct. R1 comes back up. Does R1 take active back?

By default, no. HSRP is non-preemptive. A higher-priority router that comes online after a lower-priority router is already active will sit in standby. R1 has priority 110 and is still standby behind R2's 100. Your carefully chosen "primary" is now the backup, indefinitely.

The fix is preempt. It tells a router to take the active role back as soon as it can, if its priority is higher:

! R1
interface Vlan10
 standby 10 preempt

Configure preempt on the router you want to be primary. Priority chooses the active router; preempt is what makes that choice survive a reboot. The pair is incomplete without it.

Setting 3: interface tracking - fail over for the right reason

HSRP, on its own, only fails over if the active router stops sending hellos - it is watching the LAN side. It does not know if the active router's upstream link is down. Without tracking, R1 can keep happily serving as the gateway while its WAN uplink is dead, black-holing every packet.

Object tracking fixes this. You track the uplink, and HSRP decrements the router's priority when that uplink goes down:

! R1
track 1 interface GigabitEthernet0/0 line-protocol
!
interface Vlan10
 standby 10 priority 110
 standby 10 preempt
 standby 10 track 1 decrement 20

If Gi0/0 fails, R1's priority drops from 110 to 90. R2 at 100 now outranks it, and (with preempt) takes active - failing over because the path to the rest of the network actually broke, not just the router. The decrement must be large enough to push the priority below the peer's: 110 minus 20 is 90, below R2's 100. Get the arithmetic right.

Setting 4: version and timers

Use HSRP version 2. Version 1 supports only group numbers 0-255 and uses a coarser timer; version 2 supports groups up to 4095, has a distinct virtual MAC range, and supports millisecond timers and IPv6. Both ends of a group must run the same version.

Default timers are a 3-second hello and a 10-second hold, so failover takes up to 10 seconds. For faster failover, tighten them - but keep both routers identical:

interface Vlan10
 standby 10 timers msec 250 msec 800

Verifying

R1# show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State    Active          Standby         Virtual IP
Vl10        10   110 P Active   local           10.20.0.3       10.20.0.1

Confirm three things: State is Active on the router you intended, the P flag is present (preempt configured), and the Virtual IP matches what hosts use as their gateway. For the full picture including tracking, use show standby.

Common gotchas

The "primary" router stays standby after a reboot
No preempt. Priority alone does not reclaim the active role.
Both routers think they are active
They are not exchanging hellos - group number mismatch, version mismatch, or a Layer 2 problem between them.
Gateway keeps working but traffic black-holes
No interface tracking. The active router's uplink is down but HSRP does not know.
Tracking configured but failover never happens
The decrement is too small to drop priority below the peer's. Recheck the arithmetic.
Hosts lose the gateway intermittently
Timer mismatch between the two routers, or HSRP version mismatch. Make both identical.

Key takeaways

HSRP configuration is standby <group> ip <virtual-ip> on each router, and that alone gives a working virtual gateway. But the production-grade setup needs four more decisions: set priority explicitly to choose the active router rather than letting IP addresses decide; add preempt so that choice survives a reboot - the single most-forgotten command; configure interface track with a decrement large enough to fail over when the uplink dies, not just when the router dies; and run HSRP version 2 with matching timers on both ends. Verify with show standby brief and confirm the State, the P flag, and the virtual IP.

For the FHRP cluster, see the FHRP pillar.

Written by
More from Ping Labz
GLBP for Active/Active Load Balancing - PingLabz FHRP article title card
FHRP

GLBP for Active/Active Load Balancing

GLBP (Gateway Load Balancing Protocol) is Cisco's load-balancing FHRP. AVG, AVFs, three load balancing methods, configuration, and when GLBP is actually the right answer.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.