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.
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.
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.
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...