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 wasnt 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.
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?
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...