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.
Solved! Go to Solution.
Yes, it will work with or without priority reduction.
When the aggregation goes down, STP will see this as a topology change for sure, but if you remember, both instances are being run over the link between the cores, unlike the access-links. So yes, this would be a temp issue only.
Again, regarding your last question, I believe you need not automate root switch preemption in HSRP, because suppose you set HSRP active and STP root for a set of VLANs on the same switch, it is not gonna change at all. Winding path is going to occur, but that is a trade-off to a simple design that you should be considering. If you are planning to try automation of HSRP active as per the STP root, your HSRP active will never change, since, if any of the link fails in the setup, MSTP root bridges will be the same, and they are not gonna swap. . Think about it.
Also, even if you were planning to automate, I dont really know whether there are any set of commands that can make tie STP to HSRP. I will be happy to know if you can give me any inputs.
"Winding path is going to occur, but that is a trade-off to a simple design that you should be considering"
Are you saying in above quote I should consider not complicating my network with MST or splitting VLANs between Cores?
If so, how would you try to make use of the extra uplinks from the access layer or server switches? At this point, all
vlans are using only one link and the other is just sitting there for redundancy. Are we back to priorities and cost to make use of the links?
"HSRP active will never change, since, if any of the link fails in the setup, MSTP root bridges will be the same, and they are not gonna swap."
In the above quote are you saying that HSRP active will only switch over if MSTP switches over? I know that best practice is to have the HSRP active match up with the STP root but I didn't know they were depndant on each other for any kind of switchover?
What I meant was:
1. You need to implement MSTP with two instances. Do not think about what happens when any link fails. The topology will remain more or less that same.
2. HSRP and MSTP will not be dependent on each other, neither will one change due to changes in the other. So, what I meant is you need to implement HSRP and MSTP, and leave it at that. Do not complicate it further. The basic configurations are enough to take care of the changes in the network.
Let the questions keep pouring till you are satisfied.
Thanks, Arun for all your time and patience. I'm just going to have to lab it out a little and maybe have more questions at a later date.
Here is a link for MST config example using HSRP and 2 instances.
As you noted, the best thing to do is to lab it and clear your doubts, because you can't after downtimes.
Also to note is somethign from the below link. "Unicast flooding"