Both HSRP Routers in Active State — Split Brain
Presenting Symptom
Both HSRP routers show the Active state for the same standby group, causing duplicate default gateway IPs and intermittent connectivity.
Network Context
Two Cisco Catalyst 3560 switches (SW1 and SW2) are configured as HSRP gateways for VLAN 10 in a small branch office. Both run IOS 15.0(2) and are connected via a trunk link. The network has about 50 hosts. The problem occurs after a recent configuration change.
Diagnostic Steps
Check HSRP status on both routers
show standbySW1:
Vlan10 - Group 10
State is Active
2 state changes, last state change 00:01:23
Virtual IP address is 192.168.10.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.432 secs
Preemption enabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
Group name is "hsrp-Vlan10-10"
SW2:
Vlan10 - Group 10
State is Active
1 state change, last state change 00:00:45
Virtual IP address is 192.168.10.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.234 secs
Preemption enabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
Group name is "hsrp-Vlan10-10"Both routers show 'State is Active' and 'Standby router is unknown', indicating they are not seeing each other's HSRP hellos. This is abnormal; one should be Standby.
Verify HSRP hello packets are being exchanged
debug standby terseSW1: HSRP: Vlan10 Grp 10 Hello out 192.168.10.2 -> 224.0.0.2 (Vlan10) HSRP: Vlan10 Grp 10 Hello in (no output for incoming from SW2) SW2: HSRP: Vlan10 Grp 10 Hello out 192.168.10.3 -> 224.0.0.2 (Vlan10) HSRP: Vlan10 Grp 10 Hello in (no output for incoming from SW1)
Each router is sending hellos but not receiving any from the peer. This confirms a Layer 2 or Layer 3 connectivity issue between the routers.
Check IP connectivity between the two routers
ping 192.168.10.3 source 192.168.10.2 (on SW1)
ping 192.168.10.2 source 192.168.10.3 (on SW2)SW1: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5) SW2: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5)
Pings succeed, so IP connectivity is fine. The issue is likely that HSRP multicast (224.0.0.2) is being blocked or not forwarded.
Check VLAN and trunk configuration
show interfaces trunkSW1: Port Mode Encapsulation Status Native vlan Gi0/1 on 802.1q trunking 1 Port Vlans allowed on trunk Gi0/1 1-1005 Port Vlans allowed and active in management domain Gi0/1 1,10 Port Vlans in spanning tree forwarding state and not pruned Gi0/1 1,10 SW2: Port Mode Encapsulation Status Native vlan Gi0/1 on 802.1q trunking 1 Port Vlans allowed on trunk Gi0/1 1-1005 Port Vlans allowed and active in management domain Gi0/1 1,10 Port Vlans in spanning tree forwarding state and not pruned Gi0/1 1,10
Trunk is up and VLAN 10 is allowed. However, check if the trunk is blocking multicast due to VLAN ACL or storm-control. Also verify that the native VLAN matches on both sides.
Check for VLAN ACLs or storm-control that might block HSRP multicast
show vlan access-map
show storm-controlSW1: No VLAN access maps configured. SW2: No VLAN access maps configured. SW1: Interface Gi0/1 Broadcast suppression level: 100 Multicast suppression level: 100 Unicast suppression level: 100 SW2: Interface Gi0/1 Broadcast suppression level: 100 Multicast suppression level: 100 Unicast suppression level: 100
No ACLs or storm-control blocking multicast. The issue might be that the routers are using different HSRP group numbers or virtual IPs, but the show standby output shows same group 10 and same virtual IP. Another possibility: the routers are in different VLANs or the trunk is not forwarding HSRP multicast due to spanning-tree issues.
Check spanning-tree state for VLAN 10 on the trunk
show spanning-tree vlan 10SW1:
VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 32778
Address 0001.1111.1111
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 0001.1111.1111
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.1 P2p
SW2:
VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 32778
Address 0001.1111.1111
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 0002.2222.2222
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.1 P2pBoth switches show the trunk port in Forwarding state for VLAN 10, so STP is not blocking. The issue is likely that the HSRP multicast group address 224.0.0.2 is not being forwarded because the routers are not in the same broadcast domain or there is a Layer 2 segmentation issue.
Verify that both routers are in the same VLAN and subnet
show ip interface brief | include Vlan10SW1: Vlan10 192.168.10.2 YES manual up up SW2: Vlan10 192.168.10.3 YES manual up up
Both are in VLAN 10 with correct IPs. The problem is that HSRP hellos are not being received. This could be due to a misconfiguration of the HSRP version or authentication mismatch.
Check HSRP version and authentication
show standby vlan 10SW1: Vlan10 - Group 10 State is Active Virtual IP address is 192.168.10.1 Active virtual MAC address is 0000.0c07.ac0a Local virtual MAC address is 0000.0c07.ac0a Hello time 3 sec, hold time 10 sec Preemption enabled Active router is local Standby router is unknown Priority 100 Authentication text, string "cisco" SW2: Vlan10 - Group 10 State is Active Virtual IP address is 192.168.10.1 Active virtual MAC address is 0000.0c07.ac0a Local virtual MAC address is 0000.0c07.ac0a Hello time 3 sec, hold time 10 sec Preemption enabled Active router is local Standby router is unknown Priority 100 Authentication text, string "cisco123"
The authentication strings do not match: SW1 uses 'cisco' and SW2 uses 'cisco123'. This mismatch causes the routers to ignore each other's HSRP hellos, leading to both becoming Active.
Root Cause
The HSRP authentication strings on the two routers do not match. SW1 is configured with authentication text 'cisco' while SW2 is configured with 'cisco123'. Because HSRP hellos are authenticated, the mismatch causes each router to discard the other's hello packets. Consequently, neither router sees a peer, and both assume the Active state, resulting in a split-brain scenario where both routers respond to the virtual IP, causing duplicate packets and intermittent connectivity.
Resolution
Verification
After applying the fix, verify HSRP state on both routers: SW1# show standby vlan 10 Vlan10 - Group 10 State is Active 3 state changes, last state change 00:00:15 Virtual IP address is 192.168.10.1 Active virtual MAC address is 0000.0c07.ac0a Local virtual MAC address is 0000.0c07.ac0a Hello time 3 sec, hold time 10 sec Next hello sent in 0.123 secs Preemption enabled Active router is local Standby router is 192.168.10.3, priority 100 (expires in 8.456 sec) Priority 100 (default 100) Authentication text, string "cisco" Group name is "hsrp-Vlan10-10" SW2# show standby vlan 10 Vlan10 - Group 10 State is Standby 2 state changes, last state change 00:00:10 Virtual IP address is 192.168.10.1 Active virtual MAC address is 0000.0c07.ac0a Local virtual MAC address is 0000.0c07.ac0a Hello time 3 sec, hold time 10 sec Next hello sent in 0.456 secs Preemption enabled Active router is 192.168.10.2, priority 100 Standby router is local Priority 100 (default 100) Authentication text, string "cisco" Group name is "hsrp-Vlan10-10" Expected: SW1 is Active, SW2 is Standby. Both show the same authentication string and see each other.
Prevention
1. Use a consistent HSRP authentication string across all routers in the group, preferably via a configuration template or automation. 2. Always verify HSRP configuration after changes using 'show standby' to ensure both routers see each other. 3. Consider using HSRP version 2 which supports MD5 authentication for better security and consistency.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario tests understanding of HSRP operation and troubleshooting. Questions may present a scenario where both routers are Active and ask for the root cause. The exam expects candidates to know that HSRP uses multicast hello packets (224.0.0.2) and that authentication mismatch causes hellos to be ignored. Candidates must be able to interpret 'show standby' output and identify the authentication mismatch. The exam may include drag-and-drop steps to troubleshoot or multiple-choice questions asking for the cause.
Exam Tips
Memorize that HSRP uses multicast address 224.0.0.2 and UDP port 1985.
In 'show standby', look for 'Standby router is unknown' — this indicates no peer is heard.
Always check authentication strings if both routers are Active; they must match exactly.
Commands Used in This Scenario
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions