Is MST a scaling nightmare waiting to happen??

[jlixfeld]

In the PVST world, life seemed simple - Figure out what bridges you want to act as your root and secondary root, set the priorities accordingly, make sure PVST is enabled, set your port to trunk all VLANs, set and enable VTP and away you go. You never have to worry about it again.

The MST world seems much more complicated - Each switch has to be configured for the region it's supposed to be in, and each switch is supposed to match the configuration of all other switches in the region. That means that if you make a change, for example add a VLAN and want to put it in an instance != 0, you have to make that change on *every-single-mst-switch-in-the-region*. This seems to me like a scaling nightmare waiting to happen as the number of bridges in your network grows.

Is there an easier way to provision with MST or is this "just the way it is (tm)"?

[Mohamed Sobair]

Hi,

what do you mean by provision with MST?? If you mean migrating from PVST+ to MST , then the following steps should be followed as recommended:

1) Always Keep the root of the CST and IST inside the region.

2) Always keep the MST bridge is the root bridge for all vlans.

3) Dont disable spanning-tree for any vlan in the PVST bridge.

4) Its recommended to manually set the MST bridges to be as primary/secondary root for IST (0).

MST relies On RSTP in its operation, when you enable MST , RSTP is performed for each instance.

You would need to remove PVST features like:

1) Backbonefast from all bridges.

2) uplinkfast from the Access Switches.

Instance (0) in MST is the (CST), you dont need to have every vlan in instance 0, Instance 0 was choosen to forward the MST BPDUs to the (IEEE address) (specifically Vlan 1).

HTH

Mohamed

[jlixfeld]

No. Assume I have a network running an MST region that contains 50 switches. A switch inside this region is the root for the CST and the IST. Assume I have VLANs 10 and 20 inside this region. Each switch inside the region would have a configuration that looked something like this:

!

spanning-tree mode mst

!

spanning-tree mst configuration

name region1

revision 10

instance 1 vlan 20

!

vlan 10,20

!

Let's say I wanted to add vlan 30 to instance 1. On all 50 switches, I'd have to do:

conf t

vlan 30

spanning-tree mst configuration

instance 1 vlan 30

That is what I mean by provisioning, and that sure is an awful lot of configuration to do just to add one VLAN to an MST instance. There is no mechanism built into MSTP to propagate region changes to other devices inside the region? Every change has to be performed on every switch in the MST region? Maybe VTP would propagate the VLAN to all the switches within the VTP domain, but what about the actual MST configuration to add vlan 30 to instance 1?!

Is there no easier way to do it?

[Mohamed Sobair]

Hi,

MST is similar to RSTP and PVST+ in its operation with different approach..

If I ask you, Is there a way to provision RSTP or PVST as you mentioned? The answer would be no, and this would also be applicable for the MST as well.

HTH

Mohamed

[jlixfeld]

Assume my previous example is 50 switches in a PVST+ network:

#switch1

!

spanning-tree mode rapid-pvst

spanning-tree vlan 10,20 root primary

!

#switch2-50

!

spanning-tree mode rapid-pvst

!

Now assume down the road, I wanted to add a third VLAN, call it VLAN20 but I wanted to load balance that VLAN by moving it to another switch and making that switch the root for this new VLAN. Simple:

#switch2

!

spanning-tree vlan 30 root primary

!

One line on one switch is *ALL* I ever have to do to load balance. I just have to add the root priority for VLAN30 on the switch that I want VLAN30s traffic to be received on. I don't have to change *ANY* of the other 49 switches in the network.

In an MST network, it's quite a bit more complicated:

#switch2

!

spanning-tree mst configuration

instance 2 vlan 30

!

spanning-tree vlan 30 root primary

#switch1,3-50

!

spanning-tree mst configuration

instance 2 vlan 30

!

That's a whole lot of work to have to do just to get the same functionality out of MST that I could otherwise do in PVST with just one command on one switch.

That's what I mean by provisioning, and that's what I mean by a provisioning nightmare :(

[Francois Tallet]

Maintaining the MST configuration is a big overhead for sure. The idea of leaving the burden of handling this configuration to the user has greatly simplified the protocol itself though... and I think MST is a positive step from its Cisco proprietary predecessor MISTP for this reason.

Anyway, right now, what I generally recommend is to pre-provision a huge MST configuration, even if you don't use it.

Map all the vlans to the 65 instances available, even the vlans you don't use. Don't hesitate to group ranges of vlans you don't use to an instance, this instance will not run unless there is at least one vlan locally enabled. And anyway, because it's MST, there is no performance impact in having a huge MST configuration.

This way, when you need a new vlan or a new topology, you already have a pool of them in your MST configuration and you don't have to update it.

Of course, we have tried to enhance that. VTP3, which was issued around 2003 on CatOS, is able to propagate the MST configuration across a VTP domain. I think it is now supported on some IOS plaftorms. Changing the MST configuration will still have all the switch restart their MST, and is thus still disrupting. We had other enhancements to prevent that, but it's all a matter of priorities, and it seems that there has not been a lot of interest from our customers.

Regards,

Francois

[badalam_nt]

Francois, sorry to bother you, I was impressed by your answer and wanted to ask you a favor: could you help me with RIP algorithm implemented in Cisco (especially regarding hold down process, as all info is misleading).

This is the corresponding post:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&topicID=.ee71a04&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd2388f

Thanks a lot.

[Francois Tallet]

Hi!

I'm afraid you're asking the wrong Francois;-) I mainly answer quick STP questions that I don't need to investigate. I can entertain you about the reason why we don't have a hold down timer in RSTP/MST (really!). But even if I have an opinion on your question, I can't give you an authoritative answer and will abstain. Sorry about that.

Regards,

Francois

[zztopping]

To elaborate Francois,

VTPv3 is supported on the latest version of IOS for the 6500 Sup720:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vtp.html

It supports MST database propagation, read up on that if you have the said equipment.

If not, do as Francois said, pre-map all your VLANs to MST instances, and let VTP pruning keep broadcasts to a minimum.

I would stick with RPVST+ unless you have a whole lot of VLANs and trunks(and do not want to manually prune) that overcome the 6500's STP scaling problem as documented here:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_Infra2_5/DCInfra_5.html#wp1097562