[c-nsp] Maximum spannig tree instances

[Christopher E. Brown]

Tim Durack wrote:
> On Tue, Jul 14, 2009 at 2:22 PM, Geoffrey Pendery <geoff at pendery.net> wrote:
> 
>>> Will adding new VLANs to an MST instance disrupt traffic flow for other
>>> VLANs in that MST instance?
>> Yes.  We've verified this.
>> A trunk port carrying only VLAN 30, or even an access port carrying
>> only VLAN 30.
>> VLAN 30 is in instance 2.  You go into config mode and add VLAN 50 to
>> instance 2 (or remove it from instance 2)
>> The port, be it access or trunk, goes to blocking, learning, forwarding.
>>
> 
> ...and if that doesn't make you nervous, you probably shouldn't be running
> spanning-tree...
> 
> Tim:>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


Come on guys, study the proto a little before going off.



In order for MST to work all members of an MST domain *MUST* agree on
the VLAN -> MST group mapping.


If you change the mapping it must update across all members of the domain.

YOU ARE REDEFINING THE STP TOPOLOGY


_Pick a topology_


MST group pre-assign...


0	VLAN 1
1	VLAN 2-999
2	VLAN 1000-1999
3	VLAN 2000-2999
4	VLAN 3000-3999
5	VLAN 4000-4094


Or whatever grouping youl want, even/odd, by hundreds, whatever.



You are now free to pick a different root and set link costs for each of
the groups independent of the others, just like pvst but by group.


If you *cannot* manage vlans by group, then stick with a rapid per vlan
variant.


If you need to move vlans in bulk across the core, and can afford to
pre-assign membership in the group then MST can be lower overhead.


The only real rules here

Leave group zero for vlan one *only*

If you have to change the base MST config more than once a year you are
not planning correctly, or you should not be using MST.