cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
368
Views
0
Helpful
3
Replies

Vlan HSRP states keep failing over

Mokhalil82
Level 4
Level 4

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

3 Replies 3

Jon Marshall
Hall of Fame
Hall of Fame

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

Hi Jon, that is very good advice I appreciate it, clearly explained.

Yes i am blocking most of the vlans across that link at the moment. But the issue I have is when I look at the logs on the cores, it shows regular hsrp state changes for different vlans so im thinking it only does that when it loses sight of its hsrp neighbor across those vlans.

Now for example vlan 100, it spans across a few switch stacks and not just one stack, and digging deep into it I found that on one of the stacks it had a blocked port, on one switch, and another switch on the same stack was acting as a root bridge for vlan 100 due to having a low mac address as stp on its default settings.

Then some vlans I looked into whose states were changing on the logs, I found that the standby hsrp core was acting as its root bridge for those vlans which I believe should not be the case.

So to stop hsrp state changes via the access switches I wanted to allow them on this trunk.

 

Does this sound like a stp issue of some sort?

If you using the same vlans on multiple switch stacks then yes some of the uplinks on some of the switch stacks will be blocked.

However that doesn't matter for HSRP as long as there is a path between the core switches using the switch stacks that is enough ie. you don't need all switch stacks to have all their uplinks forwarding for the HSRP messages to get through.

Also important to understand that traffic within a vlan does not have to go via the root bridge for that vlan. The root bridge is used as an anchor to create a loop free topology but once the loop free topology has been created it does not mean that all traffic within a vlan has to go via the root bridge.

That said it is a good idea to -

a) make the 6500s root and secondary for all vlans

b) whichever 6500 is HSRP active for a vlan also make it STP root for that vlan

Again though if you want to do this you need to plan some downtime because changing the STP root for example will have an impact on your network.

Because your HSRP messages are going via the switch stacks you may find that at periods of heavy traffic some messages are getting lost.

You could simply increase the timers but i would recommend drawing out your full topology, working out which links are blocked and which switches are acting as root for which vlans and going from there.

Jon

Review Cisco Networking for a $25 gift card