MST Discussion

[Patrick McHenry]

I've been thinking about changing our spanning tree configuration from RSPT to MST. I've gone around and replaced all of our 3500s with 3560s and 3750s and upgraded all the images with the latest ipbase code so, I believe the network is ready. I would like to make use of both cores (at present only one core is the HSRP active and the other is standby for all VLANS in our collapsed-core environment) and both uplinks on our switches by making two instances, one for odd VLANs and one for even VLANs and also reducing the overall processing of all the VLANs on the switches. I don't think we have all that many VLANs (around 55 at present) but, we keep on adding new ones and it wouldn't hurt to reduce any burden on the switches, correct? And I like the idea of automating the convergence of spanning tree rather than manipulating it with cost or priorities to make use of both uplinks.  The odd VLANs will traverse one uplink and the even VLANs will traverse another. After drawing this out and calculating the cost the paths will have on our network, it seems to me that it will increase the cost for some of the streams of data when going from an odd VLAN device to a even VLAN server. Do you think this added cost to some of the paths is a worthwhile trade off for the reduction of processing power on the switches and dividing the HSRP burden between the cores. I've attached a doc for clarity.

Thanks, Pat.

[Reza Sharifi]

Pat,

In my opinion, dividing the vlans add more complicity specially if you only have 50 to 60 vlans.  If you divide them then you need to know for example for vlan 1 switch 1 is the HSRP master and also the same switch is your root bridge.  For vlan 2 switch 2 is the HSRP master and also the same switch is your root bridge. I have seen people deploying it this way and end up removing it after a while due to complexity of configuration and admin work.

HTH

[Patrick McHenry]

Reza,

I appreciate your response and opinion but, why would it increase the complexity? To me, it seems as if it reduces the complexity of the core switch configuration.

If you do not recommend having one core switch be the active for the odd VLANs and on for even, how about having one switch the active for all VLANs, like we have now but, use MST with one instance(0)?

Then, make use of both uplinks with cost or priority?

Thanks, Pat.

[Reza Sharifi]

Pat,

If you are planning in dividing your vlans, you would need to use one instance for let say odd vlans and a different instance for your even vlans to achieve load balancing. With only one instance, misconfiguration can easily cause outage in your network.

Have a loot at this doc for more details:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml#two_vlans_same

HTH

[Patrick McHenry]

Reza,

I don't think you are reading my response closely enough. I understand how MST and HSRP work. And I also understand how they must work in tandem.  I just weighing my options.

Thanks, Pat.

[Arun Nair]

Patrick,

Based on your latest reply, there are two options you can look into:

1. If you are planning to do the odd vlan - even vlan thingy, make sure that configurations are perfect. Also, make sure you       have link redundancy per core-switch in the multiples of two(for each core switch, so that would be 2xX links per MST instance), so that even if one link fails, the other gets the traffic through(Most places, this is the standard method being followed). Make sure you have a good pair of core switches for the purpose.

2. There is really no need to be anxious regarding the cost related behaviour of traffic being sent across instances, since         that is not really a strong parameter when direct uplinks to core switches are concerned, as your diagram depicts.

3. (Sorry I am bad at mathematics, hence the third option , rather an insight)-I would really go against the decision of splitting up VLANs, unless the fate of the whole world rests on the design, since apart from the configuration related hazards that Reza suggested, we have to consider the fact that CIST(MST0) will have to run across two core switches. Not that it will bring in any evil delays in STP, but if the link between the core switches fail, it will affect STP operation in a negative way.

Hence, if you are to go for the second option that you suggested, I think you will be "safer". It really does not depend on the number of VLANs your switch has, but basically what type of data your VLANs carry, what is the SLA your company has decided, if you have voice VLANs, etc, etc. phew....You ought to think 'bout it...

HTH

Cheers

Arun

[Patrick McHenry]

Arun,

With your observation of the first option you say that there should be redundant links between the cores to protect against traffic having to take some unexpected path to get to their respective gateways in the event of link failure but, I could always use HSRP priorities and preempts so, in the event that the link between the cores fail, one core will become the active for all VLANs, correct? Then all traffic will use to that new core's uplink.

With the second option - with only one MST instance , I was thinking about having one core be active for all VLANs and changing the cost of one of the uplinks for half of the VLANs on the access switches uplinks and server switches uplinks to make use of the second link - for half of the VLANs. If one of the links fail, either a link going to the core from a access or server switch or the link between cores  I don't see what problems would arise - I'm thinking spanning-tree will take care of the details. If one link on the access switches goes down then, the other link will carry all VLANs. If the link between cores goes down then, the same thing will occur, no?

Thanks, Pat.

[Arun Nair]

Pat,

Sorry to have misread your scenario as I thought, based on the diagram that you have attached, that you were planning to configure vlan1 in core 1 and vlan 2 in core 2 resp. Yes, you can definitely exercise your options with HSRP if you are going to create the all VLANs in both cores.

With regards to the second option, I wanted to emphasize on the point that if the link(aggregation or whatever) between the cores went down, which one actually would take up the role of the Root bridge? Lets say you hard coded the priority for CSW-01 as the root and CSW-02 as secondary root. If the aggregation between them went down, how does STP deal with the VLANs that are routed through CSW-02? Remember you are planning to run MST wherein you plan to send specific set of VLANs through a specific core switch. Traffic from end stations connected to access-switches will pass through to CSW-02 and then??? Topology Change notifications will be sent out by CSW-01 and this will cause large changes in the MST behavior, maybe even lead to loops.

I hope it is more clear to you now.

Please feel free to enquire more.

Cheers

Arun

[Patrick McHenry]

I think I am confusing myself with the one instance of MST. I thought that I would be able to create one instance, thefore making the topology more simple then, make use of the second uplink to the core by decreasing the cost for half of the VLANS. I am now thinking that this is impossible as one instance of MST is just that - one topology? But, let's forget about that for now.

If you read my original post, my first idea was to have two instances of MST, one for odd VLANs and one for even. Then have one core be the root bridge and HSRP active for odd VLANs and one core the root bricge and HSRP active for even VLANs. This way, odd VLANs traverse one uplink and even VLANs traverse the other uplink. Reza's comment that MST added complexity to the network kind of through me off. In my opinion it, it is in some ways less complex and a more efficient way to make use of uplinks than doing it with cost or priorities. And, there will be less instances of spanning-tree and less CPU usage.

If, by chance the link between the Core switches does go down, it probably would be wise to have the priority of one of the core switches decrease with weighting, so one switch can be the HSRP active for all VLANs, correct?

Thanks, Pat.

[Arun Nair]

Pat,

You are right. In case one of the links fails, the HSRP+STP failover will take care of the smooth flow of traffic.

I think what Reza implied was the work that goes into proper configuration of the MST instances, and the work that has to be put in later on when, lets say 10 more VLANs come into picture. Moreover, remember that STP configurations should be always frozen right from network design phase, and changes should be minimal thereafter, so as to reduce network downtime.

Ofcourse, doing it with links is more easier than with costs. Cost is just a defacto way of coming up with an adhoc solution, sort of a work around you may say when all else fails. So it is better to use it in crunch scenarios where you do not have much of a choice.

Cheers

Arun

[Patrick McHenry]

Arun,

Your first sentence of your last post,"You are right. In case one of the links fails, the HSRP+STP failover will take care of the smooth flow of traffic."

I'm not sure if this is correct now.

If one of the cores dies completely, HSRP and STP will gracefully move all VLAN traffic to the remaining core and all will still be good.The one remaining core will be the active for HSRP and will be the root for all STP VLANs but,

if I configure HSRP, I will configure one of the HSRP cores to reduce in prioroity when the link between the cores fails. If the link between the cores fails then one of the cores will be the active for all VLANs, yes?

If this is true, then there will be a problem because the core switch that has the lower HSRP priority(standby) will still be the SPT root switch for half of the VLANs, yes? And traffic will have to go to it's STP root core switch and then come back to get to a vlan that is STP rooted on the other core.

If that is true, is there a way to automate the changing of the STP root when the link between the cores go down?

If not, is the only safe way to implement this, is to have a redundat link between the cores on different blades in case of such a failure?

This is getting complicated.

Thanks, Pat.

[Arun Nair]

Pat,

You are in the right direction with the design. Dont worry about HSRP operation.

HSRP active switch and STP root bridge will always be the same.

Suppose, HSRP active is core 1 and standby is core 2.

Let us say that the link between the cores fail:

What happens? HSRP active is still active and standby is still standby, since hello packets which were sent through the back to back aggregation between cores will now be sent through the access-switch L2 path. Just make sure that you do not reduce HSRP priority on failure in link aggregation*. That will surely mess up things as you described above.

*You need to configure priority reduction only for access-uplink failure(here HSRP active does need to change for the VLANs that run over the failed link), since link failure between core does not have any effect on the connectivity of the servers to the end-users.

What about MST root bridges for each instance?

It remains the same, wherein root for one instance is core 1 and for the other, it is core 2, as fundamentally, the aggregation link does not have anything to do with the MST running through the switches.(the bpdus for CIST start flowing through the uplinks from access to core rather than through the aggregation, which was previously the case.

Yes, failure of aggregation link between the cores does mean that now, both the root bridges are totally dependent on the access-switch for bpdu communication, and this is bad for the network.(This is one of the disadvantages of splitting up VLANs into MST instances, although such a case rarely occurs). Now suppose your uplink to core from one of the access-switches goes down. What happens now is that traffic from server comes to the root bridge for that VLAN, crosses over the aggregation link and onto the second core switch and comes down to the access-switch. Easy??

Dont sweat over MST, it takes care of itself. Neither do we have to worry about HSRP, since HSRP active for each set of VLANs that you will be configuring aint gonna change.

I missed one thing: Routing from one core to another in case of link failure that you mentioned: Yes, that is an overhead, but thats why we do link aggregation between core switches(I usually use 4Gigs for a good large network).

Please let me know if this does not clarify your doubt. I will try getting a detailed explanatiion in a day or two.

Cheers

Arun

[Patrick McHenry]

Arun,

"You need to configure priority reduction only for access-uplink failure(here HSRP active does need to change for the VLANs that run over the failed link), since link failure between core does not have any effect on the connectivity of the servers to the end-users."

I don't understand your logic here. From what I understand, and correct me if I am wrong, I think it is the exact opposite of what you say. I wouldn't think I would need to configure priority reduction on the access uplinks as STP will find the backup redundant path after an uplink goes down. Now, if the link between the cores goes down, and I don't configure priority reduction, the traffic will probably work but, it will have to make a winding path to get to a VLAN that is part of the other instance unless I do configure priority reduction so all traffic will go to the new HSRP active for all VLANs. The problem I see is that I need to get the spanning-tree root to also move to the HSRP active switch.

Is my description clear enough? Let em know.

If you don't agree with me could try to pin-point where my logic is wrong?

Thanks, Pat.

[Arun Nair]

Pat,

What i meant to say was that we need not configure priority reduction in HSRP for link aggregation, since path from server to end machine(both in different vlans) will still be there. HSRP active switch still remains active. You are right when you say that to reach the other path " it will have to make a winding path to get to a VLAN that is part of the other instance unless I do configure priority reduction so all traffic will go to the new HSRP active for all VLANs". And this is the trade-off that we are talking about. The whole point that we'd miss if both HSRP actives get shifted to one switch is that of load-balancing, which is actually our requirement. Either you have your traffic take a long trip to the other vlan, or you shift the HSRP actives to the same switch and increase the load on a single switch.

And yes, I did get you confused on the first part. The reason is that I was going through your first post, where you have said that the odd VLANs will travel through one link and the even VLANs the other, and I thought you were planning to do some pruning of trunks, like to not allow the specific set of VLANs through each of the links, and that would not make the priority reduction to function, as even though the HSRP shifts across, the VLANs will not have a path through the uplinks, since they are already pruned out. I mean, given you have two HSRP actives, if one uplink from access-switch fails, and if you have configured trunk pruning by removing VLANs which are HSRP standby to that switch, you cannot shift across to the other switch as the other uplink trunk does not carry those VLANs.

Hope its more clear. And I got your point of approach for sure.

Cheers

Arun.

[Patrick McHenry]

Arun,

It is making more sense to me now. You are saying that whether I use priority reduction or not, it will still work.

There is one more question, though. If I used priority reduction for when the link between the cores goes down, how will STP converge. I'm guessing it won't - meaning, the topology will stay the same. The root for half of the VLANs will be the switch that is now not active for any VLANs anymore. So, again it will be a winding path, correct?

If this were to happen, it would only be a temporary issue as we would fix the interface fairly quickly.

If so, which is the better option? Configuring priority reduction or not?

I don't know if you remember but, I asked the question before, is there a way to automate the root switch preemption like HSRP does during a link failure - as it would be ideal if both HSRP and STP would match up during a failure.

Thanks, Pat