number of MSTP instances needed

[Sherif Atef Ahmed Ismail]

Dears,

I have a query about MSTP instances number and would like your advise plz

If access switch [A] has 400 VLANs and it connected to two distribution switches B & C

Now we have have 2 possible STP topologies thus 2 instances are needed

My question now, what is the recommnended to configure from below & why ?

1- Configure only 1 instance so now you 2 instances ; instance 0 and instance 1

or

2- Configure 2 instances so now you have 3 instances; instance 1 & instance 2 beside instance 0

Many Thanks

BR,

Sherif Ismail

[JohnTylerPearce]

Well, you can create multiple instances obviously with MSTP, but remember it's still running RSTP inside, and if you don't change any costs, it's just going to use the same ST-ALgorithm for each instance. So you can create 2 separate instances for each 200 vlans, but it's still going to be using the same path, unless you want it to choose different paths. The advantage you will get with just the default settings, is cutting down one instance having a large amount of vlans, you will now have two instances per each 200 vlans. Sorry if that sounds confusing.

[Mohamed Sobair]

Hi Sherif,

In MSTP, Instance 0  is special instance that carry the IEEE BPDU, So switches running MSTP would exchange BPDUs using instance 0.

Now, by default (if not manually configured), all vlans will be mapped to instance 0, and I dont recommend this type of Setup, because each STP instance has its own topology overview and provide fault tolerance so that an affect of one instance doesnt impact the other, Thats why its better if you map your VLANs to instances. and If I recall correctly, you can have up to 16 instances in MSTP.

Regards,

Mohamed

[Peter Paluch]

Hello Sherif,

This depends on your network. If there are multiple redundant paths then I would personally suggest creating two separate instances, 1 and 2, and mapping the individual VLANs into them so you can utilize all your redundant connections at the same time. Mohamed's suggestion to keep the VLANs away from instance 0 is worth observing - the instance 0 has somewhat special position, and while there is nothing wrong with keeping VLANs in the MSTI0, it is a best practice to create additional instances for your own VLANs. The maximum count of MST instances has been lifted from 16 to 64 in newer IOSes - but you certainly do not need that many.

Best regards,

Peter

[JohnTylerPearce]

Hey, Peter I got a question for you, or anyone really..

Lets say you have 500 vlans in your network. Is there a certain max number of vlans per instance?

To me there are only really 3 reasons to have MSTP.

1) To break up your spanning tree instances from 500 seperate instances via STP/PVST/RPVST to a minimum number of instances.

2) If you have multiple switch vendors, which may or may not interact with RPVST/PVST very well.

3) If you have multiple redundant pathts and want traffic to use both with seperate instances and not have one blocked for all instances.

[Sherif Atef Ahmed Ismail]

Thanks all for your assistance

@ John
I dont think there is a limitation

[Peter Paluch]

Hello Sherif,

You are welcome.

John: About the maximum number of VLANs in an instance, Sherif is correct: there is no limit. In fact, the basic default MSTP configuration places all VLANs into the MSTI0 - without any issues whatsoever.

With regard when to use MSTP - personally, I am probably a bit emotional about this, but I consider the MSTP to be the STP incarnation for VLAN-aware switched networks. It is a fine protocol that is just sadly underrated and often not explained (and hence not understood) properly. If I have the option of doing it in networks I manage, I am trying to have them run MSTP. Even with just a few VLANs, it is highly improbable that each of them can have a unique spanning tree. As our networks are usually running tens or even hundreds of VLANs, running a per-VLAN kind of STP seems to be to be only about wasting switches' resources without really gaining any advantage. Quite a strong argument for MSTP is also that Cisco switches generally support only up to 128 STP instances. If more VLANs are active, the switch is unable to run additional STP instances for them, necessitating the move to MSTP. The other reasons you have named are all valid as well.

Best regards,

Peter

[JohnTylerPearce]

Well, I know you can have as many as you want up to 4094 I suppose in an MSTP instance. I guess I should have re-phrased my question. I've never used MSTP in a professional enviornment, but is there a maximum amount you would

"want" to put in a MST Instance? I guess it would depend on your switches resources etc etc. I also guess it depends on what you are using MSTP for as well.

[Peter Paluch]

Hi John,

I see your point. Well, my primary concern would be the count of MST instances in the first place. Personally, I would leave the MSTI0 mostly untouched, and I would create additional MST instances to allow for multiple spanning trees and making use of redundant links in the topology. Afterwards, I would probably just split my VLANs among these instances in an equal fashion, perhaps taking into account the amount of data carried by each VLAN so that I do not force one active topology to carry significantly higher traffic loads than the other.

As you see, there criteria actually do not deal with MSTP at all. There is no increased load or resource consumption by having "too many" VLANs mapped to a single instance. Per IEEE 802.1Q standard, each MSTP switch must maintain a table with 4096 elements that maps a particular VLAN to a particular instance. This table must always be maintained, even if there is just a single MSTI present. So there is really no added load on the switch resources just because having lots of VLANs mapped to a single instance. Increasing the number of instances understandably causes increased resources consumption, but just as I indicated before, you rarely realistically need more than a few.

I am not sure if this answered your question - please do ask further.

Best regards,

Peter

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Peter, well said ". . . I consider the MSTP to be the STP incarnation for VLAN-aware switched networks."

In a network far, far away and long ago, I remember some VLAN switches only supported one global instance of STP.  So, MSTP is a bit of déjà vu, but the incarnation is, of course, better as you can have multiple instances, likely only one per redundancy instance, assuming you're trying to utilize the link capacity of the redundant paths.

I also wanted to emphasis another part of your post ". . . running a per-VLAN kind of STP seems to be to be only about wasting switches' resources without really gaining any advantage."  Often some engineers seem to overlook the hardware forwarding capacity of modern switches probably doesn't extend to control plane functions.  Some kind of flap that keeps triggering STP computations might adversely impact your network in a needless PVSTP configuration that a MSTP configuration might be able to sustain.  In other words, in normal day-to-day operations, "wasting switches' resources" is in itself often not a problem until you don't have the capacity to waste when then it's discovered how important those resources can be.

For those who (rightly) take into consideration size of subnets, hierarchical addressing and/or summarization, number of L3 devices in an shared topology, etc., MSTP might be given similar consideration.

[Peter Paluch]

Joseph,

Amen to that. Thank you!

Best regards,

Peter

[Kishore Chennupati]

With stuff like TRILL and OTV , STP will soon be EOL

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Kishore Chennupati wrote:
With stuff like TRILL and OTV , STP will soon be EOL 

Sure, just like RIP.

[Peter Paluch]

Joseph,

Sure, just like RIP. 

ROFL

Best regards,

Peter

[JohnTylerPearce]

Well played Joe. Funny thing, I know of a state agency, that ran OSPF, and then decided to scrap that and run RIP and BGP

between RIP domains. I heard they kept complaining that OSPF wants everything in one area.. I'm sure you know what the problem was.....