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<[email protected]> wrote: > Tim Durack wrote: >> On Tue, Jul 14, 2009 at 2:22 PM, Geoffrey Pendery <[email protected]> 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 [email protected] >> 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. > > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
