Two routers, R1 and R2, have been configured with HSRP for VLAN 10 to provide default gateway redundancy to hosts. The virtual IP address is 192.168.10.1. After configuration, end hosts report inconsistent connectivity to the gateway, and a failover test reveals that when the active router is shut down, connectivity is lost. The network administrator checks the HSRP status on both routers. R1 shows HSRP group 10 as Active with no standby router, and R2 shows HSRP group 20 as Active with no standby router. What is the most likely cause of the redundancy failure?
Exhibit
R1# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vlan10 10 110 Active local 192.168.10.2 192.168.10.1
R2# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vlan10 20 100 Active local unknown 192.168.10.1Trap 1: R2 has a lower HSRP priority than R1, so it cannot become standby.
A lower priority does not prevent a router from becoming standby; it simply makes it less likely to become the active router if preemption is enabled. Here the issue is not priority—both routers are active in different groups.
Trap 2: The HSRP authentication strings do not match.
HSRP authentication mismatch would cause the routers to reject each other's hello messages, but the routers would still be configured with the same group number. The failure symptom would be both routers attempting to become active for the same group (or remaining in a non-active state), not the group 10 vs. group 20 configuration seen in the outputs. Since the show standby output explicitly displays different group numbers, authentication is not the root cause; the group mismatch fully explains the lack of failover.
Trap 3: HSRP version 1 is used on R1 while version 2 is used on R2.
A version mismatch would cause the routers to ignore each other’s hello packets and both become active, but they would still be in the same configured group number. The output shows different group numbers (10 vs 20), which is a more explicit misconfiguration.
- A
R2 has a lower HSRP priority than R1, so it cannot become standby.
Why it fails: A lower priority does not prevent a router from becoming standby; it simply makes it less likely to become the active router if preemption is enabled. Here the issue is not priority—both routers are active in different groups.
- B
The HSRP group number is mismatched between R1 and R2.
HSRP group numbers define distinct virtual router instances; R1 is active for group 10 with virtual IP 10.1.1.10, while R2 is active for group 20 with virtual IP 10.1.1.20. Because they belong to different groups, neither router accepts or processes the other's hello packets, so they form separate HSRP domains with no shared virtual MAC address. Consequently, the standby router cannot take over if the active fails, which is exactly the redundancy failure observed.
- C
The HSRP authentication strings do not match.
Why it fails: HSRP authentication mismatch would cause the routers to reject each other's hello messages, but the routers would still be configured with the same group number. The failure symptom would be both routers attempting to become active for the same group (or remaining in a non-active state), not the group 10 vs. group 20 configuration seen in the outputs. Since the show standby output explicitly displays different group numbers, authentication is not the root cause; the group mismatch fully explains the lack of failover.
- D
HSRP version 1 is used on R1 while version 2 is used on R2.
Why it fails: A version mismatch would cause the routers to ignore each other’s hello packets and both become active, but they would still be in the same configured group number. The output shows different group numbers (10 vs 20), which is a more explicit misconfiguration.