HSRP across multiple bridge links

[stuart.webber]

I have an issue where HSRP between two 2600 series routers (both running IOS 12.3(3)) is taking a very long to switch the active router over when the tracked interface is dropped (using a manual shutdown command on the interface). The fastest that I have seen it cutover is about 5 minutes, but on other occasions we have sat there for ten minutes or longer waiting before we decided that it had taken too long and wasn’t worth waiting any longer. The interesting thing is that the slow cutover only occurs when the primary router drops its HSRP priority and the secondary should be taking over. If the secondary router is active, and the tracked interface at the primary router comes back up the cutover back to the secondary is more or less instantaneous.

I have tried similar configs at several other sites and they have all worked fine. The only difference with this one is that the are several bridge links and trunk links in between the two routers (devices include 2948G-L3 switches, 3620's in bridge mode, 350 series wireless bridges and a couple of Hp switches).

When I try to force a cutover, the priority on the primary router drops, but both claim to be the active router. On the secondary (that now has the higher priority address) the following appears from a debug standby (network address replaced with xxx.xxx.xxx):

11w6d: HSRP: Fa0/0 Grp 1 Coup out xxx.xxx.xxx.3 Active pri 100 vIP xxx.xxx.xxx.1

11w6d: HSRP: Fa0/0 Grp 1 Hello out xxx.xxx.xxx.3 Active pri 100 vIP xxx.xxx.xxx.1

11w6d: HSRP: Fa0/0 Grp 1 Hello in xxx.xxx.xxx.2 Active pri 95 vIP xxx.xxx.xxx.1

11w6d: HSRP: Fa0/0 Grp 1 Active: h/Hello rcvd from lower pri Active router (95/xxx.xxx.xxx.2)

My initial thought is that the bridge & trunk links in between may have some thing to do with the problem, but I am unsure as the HSRP debugs generally appear to show the HSRP processes on the two devices as talking to one another as normal. One suggestion that I have not had a chance to try yet was to use the burned in addresses of the routers as the HSRP addresses, and my next thought after that was an IOS upgrade... Any further thoughts? Any further suggestions would be greatly appreciated.

**********************************************

* HSRP config

**********************************************

* Primary Router *

interface FastEthernet0/0

description Inside Interface

ip address xxx.xxx.xxx.2 255.255.255.0

ip access-group Ethernet_IN in

duplex auto

speed auto

standby 1 ip xxx.xxx.xxx.1

standby 1 priority 105

standby 1 preempt

standby 1 track FastEthernet0/1

!

* Secondary Router *

interface FastEthernet0/0

description Inside Interface

ip address xxx.xxx.xxx.3 255.255.255.0

ip access-group Ethernet_IN in

duplex auto

speed auto

standby 1 ip xxx.xxx.xxx.1

standby 1 preempt

standby 1 track FastEthernet0/1

!

[patrick.swackhammer]

Are there any ACLs along the path between the routers that might be blocking the HSRP messages? According to RFC 2281:

"The standby protocol runs on top of UDP, and uses port number 1985. Packets are sent to multicast address 224.0.0.2 with TTL 1."

This doesn't seem plausible since you are seeing the routers talk to one another using debug, but still something to consider.

I did not find any bugs for the 12.3(3) IOS release on 2600 routers for the HSRP feature--what exact IOS image are you using?

You might also try the "standby timers" command. By default, HSRP should be sending hello packets every 3 seconds and waiting 10 seconds for failover.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7eca.html#wp1084215

Good luck.

Swack

[stuart.webber]

Thanks for you help.

The IOS image being used is c2600-i-mz.123-3.bin (C2600-I-M 12.2(3)).

As for ACLs... As you say I don't think thats the issue as they seem to be talking. But since your interested I'll tell you anyway. The only ACLs that would be influencing anything here are on the ethernet interfaces of the two 2600s and each has a :

permit ip xxx.xxx.xxx.0 0.0.0.255 any log

Which should be allowing that multicast through. So I'm fairly certain thats not causing us our problems.

As you can probably tell from the config I'm using default timer values (3 sec Hello, 10 sec Hold time). I might have a play with these next time I'm on site, but what is the theory behind changing them in this situation?

[stuart.webber]

Issue solved using standby use-bia command.