HSRP fails in two shapes that look nothing alike from the CLI. Either both routers are permanently convinced they are the Active gateway, or the pair cannot stop swapping roles. Both come back to the same question: can these two routers actually hear each other?
The trap in dual-active is that each router looks completely healthy on its own. Active state, owns the virtual IP, interface up. Nothing says "broken" until you put the peer's output next to it. This article walks a real capture from a lab built to break that way, then covers flapping, the version and authentication mismatches that produce the same silence, and the preempt behaviour that inverts your design intent without ever logging an error. If the election mechanics are still fuzzy, the guide to how first-hop redundancy protocols pick a gateway is the background this assumes.
Everything below was captured on two iol-xe routers running IOS XE 17.18.2 in Cisco Modeling Labs, sharing one Ethernet segment, with an inbound ACL on one router dropping HSRP hellos in one direction. No output on this page was typed by hand.
The symptom: two routers, both Active, no Standby
Here is the broken state, held long enough to prove it was not a transient:
R1# show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Et0/0 1 110 P Active local unknown 10.0.0.254
R2# show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Et0/0 1 100 P Active local unknown 10.0.0.254Both routers report State = Active and Active = local, both report Standby = unknown, and both advertise the same virtual IP.
That unknown column is the whole diagnosis. A healthy HSRP group always knows its partner, so a blank there says this router has never received a single hello from the other side. Notice too that priority is doing nothing: R1 sits at 110 and R2 at 100, and yet both are Active. Priority is only meaningful between routers that can talk to each other.
On the wire this is worse than an outage. Two routers answer ARP for the same virtual MAC, so the upstream switch relearns that MAC on whichever port sent the last frame and flips back and forth. Host traffic lands on one router or the other at random, and you get intermittent loss plus MAC flap messages that look like an L2 problem.
Why a silent peer promotes itself
HSRP is a hello-driven election with no tie-breaker outside the hello stream. A router coming up runs through Initial, Listen and Speak, and every decision on the way rests purely on the hellos it receives. Hear a superior Active router and you settle into Standby or Listen. Hear nothing and you conclude there is no gateway here, so you take the job.
That is correct behaviour when the peer genuinely is dead. The problem is that "the peer is dead" and "I cannot receive the peer's packets" are indistinguishable from inside the protocol, so both routers reach the same conclusion at the same time. The state name tells you which half of the conversation is missing, so the breakdown of what each HSRP state means and what moves a router between them is worth keeping beside the CLI. HSRP hellos ride UDP 1985, sent to 224.0.0.2 in version 1 and 224.0.0.102 in version 2. Anything that stops that traffic either way produces the capture above.
What actually stops the hellos
The search space is small and splits into two families: the hellos are not delivered at all, or they are delivered and rejected. The tells differ, so work out which family you are in first.
A version mismatch is the cruellest, because it produces perfect silence: the two routers subscribe to different multicast groups, so neither ever sees a malformed packet to complain about. Version 2 also uses a different virtual MAC range and allows groups up to 4095, which is why a group above 255 will not configure under version 1. An authentication mismatch is the friendliest, because the packets arrive and the receiver logs %HSRP-4-BADAUTH (version 1 defaults to the plaintext string cisco, so a router with a key string silently rejects one without).
The group and VIP case splits in two. Same group with different virtual IPs gives you %HSRP-4-DIFFVIP1, which names the problem for you. Different groups with the same virtual IP is the quiet one: each router builds its own group with its own virtual MAC (the group number is encoded in the last byte), and both answer ARP for the same address with no log at all.
Take the layer 2 causes seriously in a campus. A blocked STP port between two distribution switches, or a VLAN left out of switchport trunk allowed vlan, cuts the HSRP conversation as cleanly as an ACL does. That is why the STP root bridge and the HSRP active router should be the same box for a given VLAN: if they are not, a topology change is far more likely to isolate the pair.
The fix, and the state machine that proves it
The lab break was an inbound ACL on R2 dropping HSRP from R1. Removing it recovered the pair in real time:
R2(config)# interface Ethernet0/0
R2(config-if)# no ip access-group BLOCK-HSRP in
*HSRP-5-STATECHANGE: Ethernet0/0 Grp 1 state Active -> Speak
*HSRP-5-STATECHANGE: Ethernet0/0 Grp 1 state Speak -> StandbyThose two lines are the protocol working as designed. The instant R2 received a hello from a router with priority 110, higher than its own 100, it gave up the Active role and dropped to Speak, where it advertises itself as a candidate, then settled into Standby as the best remaining candidate. No reload, no clear, and R1 was never touched.
Confirm on both routers, never just one:
R2# show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Et0/0 1 100 P Standby 10.0.0.1 local 10.0.0.254
R1# show standby brief
Et0/0 1 110 P Active local 10.0.0.2 10.0.0.254The important change is not the state names. It is that each router now names the other: R2 lists Active = 10.0.0.1, R1 lists Standby = 10.0.0.2. Those peer addresses are your proof that hellos cross both ways. If either reads unknown, you still have a one-way path.
Preempt is not "the highest priority wins"
Look at the P column above. Both routers have preempt configured, which is why the higher-priority R1 holds the Active role. Take that P away and the behaviour changes in a way that catches people out.
Priority does not decide who is Active. It decides who wins an election, and an election only happens when there is no Active router, or when a router with preempt enabled hears an Active router of lower priority than its own. Without standby 1 preempt, a router that is already Active is never displaced by a better candidate. It stays Active until it dies.
So with no preempt, the first router to boot keeps the Active role permanently, even if it is the one you gave the lower priority. Reload your primary and the secondary takes over correctly, but when the primary returns it hears an Active hello, decides the segment already has a gateway, and quietly becomes Standby. Your config still reads priority 110 on the box you think of as primary, and nothing is logged, because nothing is wrong. If you want a defined primary you must configure preempt, so setting HSRP priority and preempt on an interface is worth getting right once.
Flapping is the same fault at a different duty cycle
Stable dual-active means hellos never arrive. Flapping means they arrive sometimes, or that something keeps re-running the election. Repeated %HSRP-5-STATECHANGE messages are the symptom, and the log matters more than the current state, because by the time you type show standby brief the pair may look perfect.
Three causes account for most of it. First, a tracked object bouncing: every time it goes down the router's priority drops and the peer preempts, then when it recovers the priority rises and the original router preempts back, so one marginal uplink gives you two failovers per event. This is why driving the tracked object from an IP SLA probe beats tracking a raw interface: an SLA lets you set thresholds and require consecutive failures before your gateway moves.
Second, preempt with no delay: a rebooted router brings its interfaces up and preempts before its routing table has converged, becoming the gateway for a segment it cannot yet forward for. Use standby 1 preempt delay minimum 90 on top of an interface-level standby delay minimum 30 reload 60. Third, intermittent hello loss. The default 3 second hello and 10 second hold time mean three lost hellos trigger a failover, so sub-second timers also tighten your tolerance for a busy control plane. Check interface counters and CPU before blaming HSRP.
Clearing HSRP config without making it worse
One command trap can turn a small problem into a dual-active outage while you are troubleshooting. no standby version 2 does not remove an HSRP group. Version is an interface-level property, so negating it reverts the interface to version 1 and leaves the group, its priority, its virtual IP and its tracking fully configured. You have not cleaned anything up, you have moved that interface onto the version 1 multicast address while the peer is still on version 2.
To remove a group, negate the group: no standby 1 takes the whole group off the interface, and no standby 1 ip removes only the virtual IP. Verify with show run interface rather than assuming, and note that changing version deliberately bounces every group on that interface.
What this was captured on
Two iol-xe routers in Cisco Modeling Labs running IOS XE 17.18.2 on one Ethernet segment, 10.0.0.0/24. R1 is 10.0.0.1 with HSRP group 1, priority 110 and preempt; R2 is 10.0.0.2 with priority 100 and preempt; virtual IP 10.0.0.254. The fault was an inbound ACL on R2's Ethernet0/0 denying UDP 1985 to 224.0.0.2 and 224.0.0.102 from R1, which stops R2 hearing R1 while leaving the rest of the segment normal. Both show standby brief outputs were collected simultaneously by on-box EEM applets writing to syslog, which is why the side-by-side comparison above is honest rather than two snapshots a minute apart.
Gotchas
- One router's output cannot show you dual-active. R1 alone looks like a perfectly healthy Active gateway. You need both tables, ideally captured at the same moment.
- An ACL that permits everything else passes every test you run. Pings between the router interfaces succeed and the segment looks clean while HSRP is dead. Test the actual traffic, UDP 1985 to a multicast address.
- A version mismatch logs nothing. Authentication and virtual IP mismatches generate
%HSRP-4-BADAUTHand%HSRP-4-DIFFVIP1, but a version mismatch is a clean, quiet, total failure. Check it explicitly.
Key takeaways
- Dual-active means the hellos are not crossing. Both routers show Active with
Standby = unknown, and that second column is what gives it away. - HSRP hellos are UDP 1985 to
224.0.0.2for version 1 and224.0.0.102for version 2. Confirm that traffic passes both ways before touching any config. - Split the causes into "not delivered" (ACL, missing VLAN, STP block, version mismatch) and "delivered but rejected" (authentication, group or VIP mismatch). The second family logs something, the first usually does not.
- Without preempt, the first router to boot keeps the Active role forever, even at a lower priority. No election runs while an Active router already exists.
- Flapping is normally a tracked object bouncing or preempt firing before a rebooted router is ready. Use IP SLA thresholds and
standby preempt delay minimum, not tighter timers. no standby version 2reverts the interface to version 1, it does not remove the group. Useno standby <group>to delete it.
Dual-active is one of the rare faults where the fix is almost never in the protocol configuration. The HSRP config on both routers in this lab was correct the whole time. For the wider picture, including how HSRP differs from VRRP and GLBP when choosing a protocol, work through the complete first-hop redundancy configuration and troubleshooting guide.