How to Configure HSRP on Cisco for Gateway Redundancy (Step by Step)

Step 1 — Configure the virtual IP on both routers

Both routers sit on the same LAN subnet and each keeps its own real interface IP — HSRP layers a shared virtual IP (VIP) on top that the group hands to whichever router is active. The VIP must fall inside that subnet, and it's the address hosts use as their default gateway, never a router's individual interface IP.

Enable version 2 first — it supports group numbers above 255 and is the version you should default to on new configs. Then define the HSRP group and its virtual IP on the LAN interface. Configure the second router (R2) with the same group number, version, and virtual IP, but its own real interface IP (10.0.0.3 here) — both routers' configs are shown below.

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 10.0.0.2 255.255.255.0
R1(config-if)# standby version 2
R1(config-if)# standby 1 ip 10.0.0.1
R1(config-if)# exit

R2(config)# interface gigabitethernet0/1
R2(config-if)# ip address 10.0.0.3 255.255.255.0
R2(config-if)# standby version 2
R2(config-if)# standby 1 ip 10.0.0.1

Step 2 — Set priority and preempt on both routers

Without any priority configured, both routers default to 100 and the one with the higher real interface IP wins the active role — not something you want to leave to chance. Set a higher priority on the router you want active by default (R1 here); higher priority always wins the election.

Preempt has to go on every router in the group, not just the one you want active. It's what lets a router claim — or reclaim — the active role as soon as its priority is higher than the current active's, whether that's because it just reloaded after an outage or because object tracking (Step 3) just knocked the current active's priority down. Set an explicit, lower priority on R2 too, so the intended order is documented in the config instead of left to the defaults.

R1(config)# interface gigabitethernet0/1
R1(config-if)# standby 1 priority 110
R1(config-if)# standby 1 preempt
R1(config-if)# exit

R2(config)# interface gigabitethernet0/1
R2(config-if)# standby 1 priority 90
R2(config-if)# standby 1 preempt

Step 3 — Track the uplink and verify

Priority alone only protects against the LAN interface going down. If R1's WAN or uplink interface fails while its LAN side stays up, R1 will happily keep forwarding traffic into a dead end. Enhanced Object Tracking fixes that, in two steps: first create a numbered track object in global config that watches the uplink's line protocol, then reference that object number from the HSRP interface with the decrement keyword.

When the tracked interface goes down, IOS decrements R1's HSRP priority by the amount you specify (25 here, dropping 110 to 85 — clearly below R2's 90). Once that drop puts R1 below R2's priority, R2 — which already has preempt enabled from Step 2 — takes over as active, even though R1's LAN interface never went down.

Confirm the result with show standby brief — it lists the group, state (Active/Standby), priority, and the virtual IP in one line per interface. Run it on both routers: you should see exactly one Active and one Standby, agreeing on the same virtual IP. Practicing this on a real IOS topology — and having something check your config against a known-good answer key — is the fastest way to catch a group-number or version typo before it costs you on the exam.

R1(config)# track 1 interface gigabitethernet0/0 line-protocol
R1(config)# interface gigabitethernet0/1
R1(config-if)# standby 1 track 1 decrement 25
R1(config-if)# end
R1# show standby brief

Common problems (and the fix)

If both routers show Active, check the group number and version first — a mismatched HSRP group number (or one router on v1 while the other's on v2) keeps them from peering at all, so each independently elects itself active. Because the virtual MAC is derived from the group number and version (v1: 0000.0C07.ACxx, v2: 0000.0C9F.Fxxx), a mismatch here actually produces two DIFFERENT virtual MACs behind the same VIP — hosts get inconsistent ARP replies and the gateway appears to flap, rather than a clean duplicate address. A true dual-active condition — same VIP AND the same virtual MAC, with both routers forwarding — shows up when the group number and version DO match but the routers still can't see each other's hellos: mismatched HSRP authentication, hellos filtered by an ACL, or the two 'peers' actually sitting on separate physical segments. That's the case that's genuinely worse than no redundancy, since hosts can't tell which router is answering.

If failover happens but the 'wrong' router stays active after the primary recovers, check preempt on the primary — without it, a recovered router just rejoins as standby forever. And remember preempt has to be on the standby router too if you want tracking-triggered failover to actually take effect; a tracked priority drop doesn't help if the router that's supposed to take over was never allowed to preempt.

If hosts don't fail over cleanly during a real outage, check their configured default gateway: it needs to be the HSRP virtual IP, not either router's individual interface address. Pointing hosts at a real IP defeats the whole point of the virtual gateway.