Vlan HSRP states keep failing over

Question

Hi
We have 2 core 6500 switches with a trunk between them. There there are access layer switch stack each stack has 1 link to each core.
Core 1--------------------------------trunk-----------------------------------Core2
     |                                                                                                  |
     |                                                                                                  |
**********************Switch Stacks****************************************
Lately I am having issues where hsrp states for different vlans keeps changing. Now this would be cause the active hsrp switch loses visibility of its neighbor on that vlan for a short period. HSRP timers are set to 1 sec hello, 3 sec dead. My spanning tree needs work done on so im believe it may be the issue as all values are currently defaults.
So my question, the trunk between the cores only has a few vlans running over it. Can I solve this issue by allowing all vlans to run over that trunk so to ensure the hsrp core do not lose visibiity of each other, is that a good networking practice
Thanks

Answer 1

So my question, the trunk between the cores only has a few vlans running over it. Can I solve this issue by allowing all vlans to run over that trunk so to ensure the hsrp core do not lose visibiity of each other, is that a good networking practice
So currently for a lot of the vlans you are not allowing them across the trunk link between the core switches. Is that correct ?
If so it is a common design (** see below) to have an etherchannel trunk between the core/distro switches and have all vlans running across it if you are running HSRP for those vlans on the core switches.
However please don't go and do that before you understand what the implications are.
Looking at your schematic if you had a vlan on the 6500s and the switch stack and you are running HSRP for that vlan but the vlan was not allowed across the trunk between the cores what that means is both uplinks from the switch stack are forwarding because there is no loop.
If you then allowed the vlan across the 6500 interconnect you then have a loop. So STP has to block one of the links. With this design it should block one of the uplinks from the switch stack providing your trunk between the 6500s has more bandwidth (which is why you use an etherchannel ).
Because you are running HSRP you would not lose throughput from the switch stack to the core switches because it should always use the uplink to the HSRP active core switch but return traffic from the core switches can at the moment use either link to the switch stack. If STP blocks one of those links then you may well lose throughput back to the switch stack depending on how the rest of your network looks.
** As I say this is a common design practice but it is gradually being replaced because you can now run MEC (Multichassis Etherchannel) to the core/distro switches providing the switches support it.
MEC would allow you to treat both uplinks from the switch stack to the cores as one logical link and so STP does not need to block any of the uplinks.
MEC is supported on 6500 switches running VSS (which yours aren't by the sounds of it). VSS would also mean you didn't need to individually configure HSRP on each switch ie. you only configure one of the 6500s with HSRP and the configuration is "active" on both.
So the general answer is yes, if you cannot run MEC, what you propose is a valid design but if you do it you could lose throughput and you would also need downtime because for every vlan you allowed across the trunk between the 6500s that wasn't already allowed there would be an STP recalculation.
It may not therefore be what you really want to do.
Edit - the above does not take into account the rest of your network topology ie. if you have multiple switch stacks with the same vlans on them you would be blocking on some of those links already due to the fact you would have loops with or without the vlans going across the trunk between the 6500s.
Jon