[c-nsp] Maximum spannig tree instances

[Geoffrey Pendery]

Well sure, I'm aware of the logic behind the behavior - I'm not saying
it's a bug.  But the result is that it is a good choice protocol for a
very specific scenario, while RPVST is a much superior choice for
certain other scenarios.

So having been provided with a lovely open standard car and a
proprietary boat, we're understandably vexed to be told we must cross
the ocean in cars - since they're open standard.


-Geoff


On Tue, Jul 14, 2009 at 11:58 PM, Christopher E.
Brown<chris.brown at acsalaska.net> wrote:
> 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.
>
>
>
>