MST in a large data center

Unanswered Question
Jul 3rd, 2007
User Badges:

Has someone worked with MST in a large environment such as data centers? If so, what are the limitations of it in as far as impact on making changes. Below is an excerpt from one of the Cisco documentations. I would appreciate it if you can share your experience or ideas with MST. Thank you.

"Complete any MST configuration involving a large number of either existing or new logical VLAN ports during a maintenance window because the complete MST database gets reinitialized for any incremental change (such as adding new VLANs to instances or moving VLANs across instances)."

Based on the above, is there a typical number of VLANs that you can configure without having any impact at all? Thanks again.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Konstantin Dunaev Tue, 07/03/2007 - 23:23
User Badges:
  • Bronze, 100 points or more


we're using MST in our network, it's not too big, but anyway.

The two biggest problem that I see in MST reconfiguration are:

1. you should configure _each_ switch "manually", it's not enouh to configure the root bridge, but as you can't change all switches at the same time, the MST configuration will differ among them, and according MST rule, the switches with different MST configuration will be put in different region and they will be use only MST0 (usuall STP) to communicate. If you have parallel links between the switches in different regions, and if those links are in different MST instances, then only one link will be put in active state, all other paralell links will be put in blocked.

2. MST has no "VLAN inconsistency check", it means that if the trunk has different VLAN configuration on both side , MST will not notice it and the loop can happen.

third problem, I think it's usuall for STP but with MST it has much more influance on the network - during the MST reconfiguration, the MST instance, which was reconfigured should be, let say, "restarted". it means all links, which belong to this instance should go through usuaul RSTP states: blocked-speak-[active or alternative] and it means loss of connectivity onthose links.

Francois Tallet Thu, 07/05/2007 - 15:32
User Badges:
  • Gold, 750 points or more

I agree with Konstantin. The limitations with MST are not in the number of vlan it can support (MST scales much better than PVST in this regard) but rather in the required configuration. In order to keep the benefit of MST, you need to have to configure all the bridges as part of the same region. As a result, if you need to change the vlan to instance mapping, you have to configure this change on each and every bridge in the network. That this administrative task that is not scaling well in term of number of switches. When moving a switch to a different region, you are restarting its MST, which means an impact on all the instances, thus all the vlans.

We have introduced in CatOS a way of propagating the MST configuration using VTP3. This functionality has been coded in IOS (but is not yet scheduled for a particular release). That would allow you to make an MST configuration change an propagate it instantly to the VTP domain, minimizing the traffic interruption (as all the switches would restart their MST together).

Another solution, that I often recommend in the meantime, is to pre-allocate instances and vlans in your MST configuration. Even if you don't use 4k vlans and 65 instance, just configure say 20 instances with 200 vlans mapped to each of them. As long as the vlans are not created or not configured on any ports, there will be no resource wasted. If you need to add a vlan on a particular instance, you will have a pool of vlan and instances available for you to choose from.

If it's not clear, it's only the global MST configuration (the vlan to instance mapping) that needs to be consistently configured across the network. The different instance parameters (like timers, priority etc...), are used independently on each switch, just like it is with PVST.




coming back to this old discussion as I have similar questions...

I'm running a L2 ring with 2960G switches and quite a few vlans for my different customers.

I'm still using PVST and would like to migrate to RPVST or MST.

MST looks interesting as it would allow me to group all similar vlans into a single instance and balance the traffic over the ring.

My issue here is that the MST region consitency depends on the MST config (vlan to instance mapping) between all switches.

Even though I could preallocate blocs of vlans per instance I will need at some point to add a new vlan to an instance.

As I need to do this config change manually on each switch my network will be split into 2 regions from the moment I start on the first switch until the last. Traffic will be dropped.

Is there a way to avoid this?

Is there a way to preconfigure all switches with an "alternative" MST config like on HP procurve switches?

Is there a way to do this change simultaneously on all switches?

Thanks for any pointers or ideas..


Peter Paluch Tue, 08/17/2010 - 07:40
User Badges:
  • Cisco Employee,

Hello Eric,

I would like very much to see Francois respond to your query as I am myself in stage of learning the benefits and limitations of MSTP but till then, these are my thoughts.

Even though I could preallocate blocs of vlans per instance I will need at some point to add a new vlan to an instance.

Theoretically, if you preallocate all 4094 VLANs into instances (note that the current IOSes support up to 64 MST instances so the number of VLANs per instance does not need to be higher than 64), you will never need to add another VLAN to an instance. This of course depends on your needs - whether it is feasible for you to preallocate the entire VLAN ID space statically among instances.

Is there a way to avoid this?

By MSTP design, two switches having different MSTP configurations will be placed in two regions and on the link between them a normal RSTP Proposal/Agreement exchange will take place. Unfortunately, the PVST Simulation in Cisco Catalyst switches complicates this issue, and, when combining this with the Extended System ID, it can result in a link being blocked permanently as opposed to a momentary blocking during the Proposal/Agreement exchange.

The only sensible way I see is to use the VTPv3 which is now routinely present on new Catalyst switches with recent IOSes to distribute and synchronize the MSTP configuration throughout the VTP domain. As the change to the MSTP configuration will be done almost instantly on all switches, the interruptions should be minimal. I have never made precise packet loss measurements with VTPv3 and MSTP, though. Clearly a fine space for experimentation.

Oh, and perhaps SNMP could be used to modify the MSTP configuration simultaneously on all Catalyst switches - never tried that, neither, but is worth looking for a suitable MIB.

Is there a way to preconfigure all switches with an "alternative" MST config like on HP procurve switches?

I am not aware of such feature on Cisco switches. HP ProCurve switches unfortunately have a different limitation: they do not allow you to assign a non-existent VLAN into an MST instance. As a result, it is impossible to preallocate VLANs into instances without actually creating those VLANs.

Is there a way to do this change simultaneously on all switches?

The VTPv3 does just that, and perhaps there is a MIB for SNMP to do this, too. I don't know of another available mechanism.

Best regards,


Hello Peter,

thanks for the quick reply.

preallocating 4000 vlans isn't the issue anyway since 2960 switches only support 128 vlan instances.

VTPv3 could be an option... as it also would take care of the other problem I was thinking about:

Moving one vlan from one instance to another would typically also result in a region split.

I have little experience with VTP and only the older versions...  but I see that v3 allows a better control of who gets what.

now I need to test such a config in a (virtual) lab.


Peter Paluch Tue, 08/17/2010 - 13:27
User Badges:
  • Cisco Employee,

Hello Eric,

preallocating 4000 vlans isn't the issue anyway since 2960 switches only support 128 vlan instances.

Well, I did not mean creating 4000 VLANs I just meant having a MST configuration in the following form:

spanning-tree mst configuration

name MyRegion

revision 1

instance 1 vlan 1-64

instance 2 vlan 65-127

instance 3 vlan 128-191


instance 64 vlan 4032-4094

i.e. having all VLANs, both existing and nonexisting, mapped to a predefined set of instances.

Regarding the VTPv3, have a look on these two URLs:

Best regards,



This Discussion