Cisco HSRP Configuration: Priority, Preempt and Track

Hot Standby Router Protocol (HSRP) gives an IP subnet a virtual default gateway that is served by two real routers, so a single router failure does not strand the hosts. The protocol elects one active router and one standby from a group, and the election is controlled by priority, preemption and interface tracking. This article builds a two-router HSRP pair with an uplink-tracking failover policy and shows exactly what happens in the output when the active router loses its upstream.

HSRP Election Basics

Every router in the group gets a priority from 1 to 255 (default 100); the highest priority becomes active. preempt lets a router reclaim the active role when its priority becomes highest again — without it, the first router to come up stays active forever. Tracking lowers a router's priority when a monitored object (usually an uplink interface) goes down, which hands the gateway to the healthy peer.

Ties are broken by the highest IP address on the interface, which is why an accidental priority tie can produce a different active router than the design intended. If two routers report the same priority in show standby brief, the higher interface IP wins quietly. Rule out that ambiguity by giving the preferred router a priority that is at least 10 higher than the peer.

Full Configuration Example

R1 is the preferred active router: virtual IP 172.16.6.100 in group 1, priority 105, preempt enabled, and it tracks its server-facing uplink FortyGigabitEthernet0/2/4 with a decrement of 10. When that uplink drops, R1's priority falls to 95 and R2 takes over:

R1# configure terminal
R1(config)# track 10 interface FortyGigabitEthernet0/2/4 line-protocol
R1(config-track)# exit
R1(config)# interface FortyGigabitEthernet0/2/0
R1(config-if)# ip address 172.16.6.5 255.255.255.0
R1(config-if)# standby 1 ip 172.16.6.100
R1(config-if)# standby 1 priority 105
R1(config-if)# standby 1 preempt
R1(config-if)# standby 1 track 10 decrement 10
R1(config-if)# end

R2# configure terminal
R2(config)# track 20 interface FortyGigabitEthernet0/2/4 line-protocol
R2(config-track)# exit
R2(config)# interface FortyGigabitEthernet0/2/0
R2(config-if)# ip address 172.16.6.6 255.255.255.0
R2(config-if)# standby 1 ip 172.16.6.100
R2(config-if)# standby 1 preempt
R2(config-if)# standby 1 track 20 decrement 10
R2(config-if)# end

R2 keeps the default priority 100, so it is the standby while R1 is healthy, and it takes over the moment R1's tracked uplink fails and its priority drops to 95. Notice that R2 also tracks its own uplink: a symmetric design means that if R2's path fails while R1 is already degraded, neither router will claim a gateway it cannot actually serve.

How the Election Really Happens

Three independent things decide who forwards traffic, and confusing them is the root of most "HSRP is not failing over" tickets:

1. Priority (1-255) sets the ranking. It is configured per interface per group and never changes by itself — only tracking changes it, and only as a decrement.
2. Preemption decides whether a router with a better priority may take the active role from an incumbent. The single most common misconfiguration is enabling preempt on one member only.
3. State machine requires the group's IP to be configured and both routers to hear each other's hellos. If hellos are lost, the standby promotes itself after the hold timer expires, regardless of priority.

A router moves through Disabled, Init, Listen, Speak, Standby and Active. The Speak state is worth knowing: a router that has not yet heard an active router stays silent for the hello interval before offering itself, which is why an isolated router takes a few seconds to take over from a cold start.

Virtual MAC, ARP and Host Behaviour

HSRP answers ARP for the virtual IP using a virtual MAC, so hosts never learn about the failover at all — no ARP cache flush, no client timeout, no DNS change. The MAC is derived from the version and group number:

HSRPv1, group 1   ->  0000.0c07.ac01
HSRPv2, group 1   ->  0000.0c9f.f001

Because the virtual MAC is deterministic, it is also easy to search for in a switch MAC address table when you are chasing a duplicate virtual IP. If two routers are configured with the same group number and virtual IP on different subnets, they will both answer for the same MAC and you will see MAC flapping on the switch between their two uplinks. Use a different group per subnet and keep the virtual IPs distinct.

Tracking Options in Depth

Interface line-protocol tracking is the starting point, but it only detects a failure at the local port. When the failure is further away, track something that reflects the real path:

R1(config)# track 100 ip route 10.20.0.0 255.255.0.0 reachability
R1(config)# track 101 ip sla 1 reachability
R1(config)# track 200 list boolean and
R1(config-track-list)# object 100
R1(config-track-list)# object 101
R1(config-track-list)# exit
R1(config-if)# standby 1 track 200 decrement 20

A reachability track is up only while a matching route exists in the routing table, which makes it a genuine end-to-end indicator: if the uplink stays physically up but BGP withdraws the route, the track goes down and the gateway moves. The ip sla form goes one step further and pings an address beyond the first hop. A boolean list combines several objects into one track ID so a single standby track statement with one decrement covers the whole policy.

Decrements are not additive on a single object — each tracked object applies its own decrement, and multiple tracked objects sum. Design the arithmetic so the degraded priority lands below the peer's priority but above zero:

• R1 healthy: 105. R2: 100.
• One uplink down on R1: 105 - 10 = 95 (below R2, so R2 goes active).
• Two uplinks down on R1: 105 - 10 - 20 = 75 (R2 stays active with margin).

Decrementing too much is not harmful for failover, but it can push a router so low that when the peer fails, the router with the better paths still refuses to take over because its own degraded priority is now the lower one. Never decrement below the point where the router could still be the best candidate.

Preempt Delay, Reload Delay and Timers

On a router that runs BGP or OSPF, preempting immediately after boot is a trap: the interface comes up before the routing table is populated, the router takes the active role, and then black-holes traffic until convergence finishes. Preempt delay solves that:

R1(config-if)# standby 1 preempt delay minimum 30 reload 120

minimum applies after any state change that makes this router eligible again; reload only applies after a device reload and overrides the minimum in that case. Pair it with interface hold-down when the interface is flapping:

R1(config-if)# standby 1 delay minimum 30 reload 120
R1(config-if)# standby 1 timers 1 3
R1(config-if)# standby 1 timers msec 200 msec 750

Defaults are 3-second hello and 10-second hold. Tightening them to 1/3 or to milliseconds shortens the failover window at the cost of more control-plane chatter and more sensitivity to a congested or heavily policed link. Use sub-second timers only on links you control end to end.

Multiple Groups, Load Sharing and Authentication

A router pair does not have to leave one device idle. Run two groups on the same interfaces with inverted priorities, and hand half the subnets to each router as the preferred active:

R1(config-if)# standby 1 ip 172.16.6.100
R1(config-if)# standby 1 priority 105
R1(config-if)# standby 1 preempt
R1(config-if)# standby 2 ip 172.16.6.101
R1(config-if)# standby 2 priority 95
R1(config-if)# standby 2 preempt
R1(config-if)# standby 1 authentication md5 key-string Str0ngKey

Hosts get a 50/50 traffic split while each group still has full redundancy. Add MD5 authentication as a matter of course: without it, any device on the segment can send a higher-priority hello and steal the gateway. Plain-text authentication is only marginally better than none and should not be used on a routed access segment that carries user traffic.

Verification

show standby brief
show standby
show track brief
show standby delay

Healthy state: active router 172.16.6.5 (R1, priority 105), standby 172.16.6.6 (R2, priority 100). After the tracked uplink on R1 fails, R1's priority shows 95 (configured 105), the track object reports Down with decrement 10, and R2 becomes the active router because preemption is enabled on both sides. When the uplink recovers, R1 preempts back to active. For multiple tracked objects, each gets its own decrement value and they add up — the Cisco example shows two tracks decrementing 10 and 20 for a combined drop to 75.

show standby brief is the first command to run, because the State column and the Active / Standby columns together tell you whether the election matches your design intent. Then read show standby for the per-group detail: virtual MAC, preempt flag, timers, and which tracked objects are up or down. If a group is stuck in Listen, it is not hearing hellos - suspect a VLAN mismatch, a blocked L2 path, or HSRP version mismatch between the two routers.

HSRP Version 2 and IPv6

HSRPv2 expands the group range from 256 to 4096, uses the 224.0.0.102 multicast address, carries an 8-bit group identifier plus a 24-bit field in the MAC (0000.0c9f.fXXX), and supports IPv6 through standby 1 ipv6 autoconfig. Both routers must run the same version for a group to function, and the version is configured globally:

R1(config)# standby version 2
R1(config-if)# standby 1 ipv6 autoconfig

Mixing versions produces two separate elections on the same segment with two different virtual MACs, a classic dual-active black hole. Check the version explicitly with show standby before declaring an election problem a routing problem.

Troubleshooting: Symptom to Cause

Design Notes

• Always enable preempt on both routers or failback after a repair will not happen automatically.
• Track the path, not just the local interface: combine interface tracking with track ip route when the failure is beyond the first hop.
• Hello/hold timers default to 3/10 seconds; on Catalyst switches use the same group ID and virtual IP on both members of an access pair.
• HSRP answers ARP for the virtual IP, so hosts keep one static default gateway — this complements rather than replaces routing redundancy such as MLAG with a VARP/VRRP gateway at the access layer.
• Decide the priority arithmetic on paper before you configure it, and record the expected degraded priority in the change ticket so the on-call engineer can verify it in one command.
• Compare your design against the ArubaOS-CX equivalent in our ArubaOS-CX VRRP active gateway guide if the campus has mixed vendors.

For related first-hop redundancy on Nexus, see our Nexus vPC failover troubleshooting article, the campus access design in Cisco inter-VLAN routing, and IP SLA and track objects for the probing side of the tracking policy.

原文链接：https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/13780-6.html