HSRP flapping: reading the state changes before users notice

HSRP flapping occurs when the active router repeatedly transitions to standby and back, creating a state-change loop that disrupts traffic and exhausts CPU cycles. Unlike a clean failover, flapping is chaotic: clients see gateway MAC address changes in rapid succession, ARP tables become stale, and TCP connections drop. The key to stopping flapping before users notice is learning to read the syslog patterns and debug output that precede visible outages.

Why HSRP flaps: the root causes

HSRP flapping has a short list of culprits. The active router loses connectivity to the standby (often a Layer 2 or physical link issue), triggering a failover. Then the active router recovers and reclaims its role, only to lose connectivity again. This cycle repeats. Other causes include mismatched HSRP timers between peers, unstable interface states (flapping physical links), CPU spikes on the active router, or misconfigured preemption with unequal priorities.

• →Layer 2 connectivity loss between HSRP peers (VLAN misconfiguration, port channel issues)
• →Mismatched hello and hold timers
• →Active router CPU overload or memory pressure
• →Physical interface instability (errors, resets, MTU mismatches)
• →Preemption enabled with priority inversions or unequal standby priorities
• →Routing protocol instability causing interface state changes

Reading HSRP state changes in real time

Enable HSRP debugging and syslog capture before flapping occurs. The debug output reveals the exact moment transitions happen and why. Use 'debug standby events' on both active and standby routers to see state machine transitions, hello packet loss, and priority comparisons.

! Enable HSRP event debugging
Router# debug standby events

! Capture syslog with timestamps
Router# logging buffered 32768 debugging
Router# service timestamps log datetime msec

! Monitor in real time
Router# terminal monitor
Router# show debug

Watch for these telltale patterns in the output: 'STANDBY: Standby -> Active' followed quickly by 'STANDBY: Active -> Standby' indicates the active router is losing quorum or hello packets. If you see 'STANDBY: Standby -> Speak' cycling, the standby is not receiving hellos consistently. Each transition also triggers a syslog entry with timestamp; count transitions over a 60-second window to quantify flapping severity.

Isolating the cause with show commands

Before flapping starts, gather baseline data. After it begins, compare state and counters to spot the breaking point.

! Check HSRP group status and transitions
Router# show standby brief
Router# show standby detail

! Count state changes (transitions field)
Router# show standby | include transitions

! Verify timers match between peers
Router# show standby | include "Hello Time|Hold Time"

! Check interface status and errors
Router# show interface status
Router# show interface counters errors

! Look for CPU or memory spikes during flapping
Router# show processes cpu sorted
Router# show memory statistics

If the active router shows high CPU or memory, flapping is likely caused by resource exhaustion. If interface error counters are climbing, Layer 2 connectivity is unstable. If hello and hold timers differ between peers, update the standby router's timers to match. If preemption is enabled and priorities are unequal, either disable preemption or equalize priorities.

Stopping the flap: immediate actions

• →Disable preemption temporarily: 'no standby [group] preempt' on the active router
• →Increase hold time to allow more hello misses: 'standby [group] timers [hello] [hold]'
• →Verify Layer 2 connectivity between peers: ping the standby IP from the active router
• →Check for interface MTU mismatches or VLAN tagging issues
• →Isolate CPU load: stop unnecessary processes or redistribute traffic
• →Ensure both routers have identical HSRP configuration (timers, priorities, authentication)

After stabilizing, re-enable preemption only after confirming the root cause is fixed. Document the transition count and timestamps so you can correlate flapping with other events (link failures, config changes, software updates).