HSRP is commonly used as a router failover mechanism, where one router in the group is active and all other group members are in standby. A standby router will take over as the active router when connectivity to the active router is lost.
Today I encountered a strange problem where I had a HSRP group setup with two routers one active and one standby. I had used SVI interfaces (Vlan interfaces) to setup the HSRP and made sure that the active router has been setup with a higher priority as shown below:
interface Vlan82 ip address 10.1.82.3 255.255.255.0 ip access-group ACL_VLAN82_IN in ip access-group ACL_VLAN82_OUT out standby 82 ip 10.1.82.1 standby 82 priority 120 standby 82 preempt
interface Vlan82 ip address 10.1.82.2 255.255.255.0 ip access-group ACL_VLAN82_IN in ip access-group ACL_VLAN82_OUT out standby 82 ip 10.1.82.1
However, upon verifying the status of the HSRP instance on each of the SVIs by issuing
sh standby vlan 82
I noticed that both routers were in an active state!!
Vlan82 - Group 82 State is Active 1 state change, last state change 3d03h Virtual IP address is 10.1.82.1 Active virtual MAC address is 0000.0c07.ac52 Local virtual MAC address is 0000.0c07.ac52 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 2.208 secs Preemption enabled Active router is local Standby router is 10.1.82.2, priority 100 (expires in 10.208 sec) Priority 120 (configured 120) Group name is "hsrp-Vl82-82" (default)
Both routers had “Active router is Local” and were in “Active state” even though the active router has a higher priority.
This infact was a simple problem related to how HSRP members communicate. HSRP packets uses multicast address 188.8.131.52 and UDP port 1985 to communicate with peers.
When I had applied access-lists on the SVI, I had forgotten to permit HSRP multicast packets. This caused the members of the group to be have lost communication with each other and thus each router took an active state as the routers did not see it’s peer.
It is fundamentally important that HSRP peers are on the same network segment and are able to reach each other. Therefore if you were to implement ACLs on your interfaces, make sure you allow UDP multicast packets to 184.108.40.206 on port 1985!