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/
