Changing the mst region name--will the configuration change cascade or block spanning tree updates?

[Marcus_Florido]

Ladies and Gentlemen,

I have a network setup with several hundred Enterasys switches, ranging from D series all the way up to the S series. Because of the physical topology, we've been content with using the default settings for MST, and using the default instance (IST 0) to propagate Mrecord information, which has the default configuration name of the MAC address of the root bridge. Because I need to integrate other vendor equipment, and because the network is maturing to the point where a proper MST configuration is necessary, I would like to change the configuration name of the default instance. My question is as follows:

If I change the name in the root bridge, will the change propagate to the switches below, or will that change prevent the rest of the switches from communicating with the root bridge, and force the election of a new one? In short, will I have to manually re-configure all of the switches below the root bridge?

Thank you,

Marcus

[Martin_Kalcak]

Hello.
I know I might be digging a corpse long dead, but, as I have just reconfigured MST in network comprising of several hundred switches I willl add my two cents.
All stated above is true, incosistent setup of MST durig reconfiguration will cause revert to 802.1D link with it's horribly long service outage. There is heavy traffic on out network and 50 secs convergence time for 802.1D was unacceptable.
I have avoided this by doing (much) more work but result were no outages at all.

1. disable redundant links by shutting down ports that have "Alternate" MSTP status. You will get loop-free topology. There must be NO loops, or you will pay dearly, trust me.
2. disconnect whole network STP wise.
root bridge (porfast trunk, bpdufilter) <-> (portfast trunk) bridge (portfast trunk, bpdufilter) <-> (portfast trunk) bridge.
Start from edge of network, to avoid root port changes accross network.
Hope schema is comprehensible.
3. reconfigure MST in each switch. Remember to set up root priority on all instances for core switch.
4.reconnect whole network back, starting from core of network. Remember to set up root priority on all instances for core switch.
5. reenable redundant links

ad point 2: it is necessary to first set up pfast than bpdufilter on disconnecting, and conversely disable bpdufilter before pfast on reconnecting to achieve fast convergence and no outages.

WARNING. all this is extremely dangerous. Your network will be without backup links and error or misconfiguration may float up well later than error is made, on most unfortunate time. Thorough planning and step by step checklist is a must. Of course if there is more admins, all must be aware of network being in very fragile state and allow for this.

[Marcus_Florido1]

Update for those who may wish to do this in the future:

The configurations for each switch must be changed. We did this by using the NetSight Command Scripting tool. The requirements were to make sure all VLANs were present for all participating switches (ensures that the configuration digest will be the same), MST Region Name, and the revision number (we left the defaults).
This worked flawlessly, with the exception of the DFE-based switches we still own. Any change to spanning tree on the DFE systems would cause a spanning-tree re-convergence, which would kill the SSH session after each command was entered. For those of you planning the same, I recommend that the pertinent lines be added to a configuration file, and the switch re-configured using the "configure slot/configfile" command. This will require a reboot. Alternatively, and if you can risk it, you can turn spanning tree off altogether and apply the changes.

[Simon_Vosper]

Marcus Yes be very careful how you deploy this and be prepared for service outage. if you were to alter the digest of a remote switch it will fall out of the mst instances and you could lose contact with it. I have heard horror stories of just that type of thing. It might be a good idea to consider future expansion and addition of vlans at this time too, as adding them later and changing the digest again will be a massive ball ache.

[Marcus_Florido1]

I should have put some money on this. My thinking is that as soon as I change the region name, the switches connected to it will see it as an out-of-region switch, and will only pass CIST BPDU's. The region/rev#/digest are easily configured using NetSigtht, so if we're smart about this, there won't be much leg work unless spanning tree starts shutting off ports required for connectivity.

Thanks Simon.