STP instances

Unanswered Question
Oct 9th, 2007

I have more than 64 VLANs in my network and when I use STP I see the following log message:

"%SPANTREE_VLAN_SW-2-MAX_INSTANCE: Platform limit of 64 STP instances exceeded. No instance created for VLAN108 (port Fa0/1)."

What are the problems that I will have with this and what can I do to resolve them?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Francois Tallet Tue, 10/09/2007 - 14:06

The problem is that the additional vlan configured will not have an instance of stp to protect against loop. It's not as dramatic as it looks, as long as the neighboring switches are able to run STP on this vlan, but you should be careful about redundancy in that case. A simple solution is to move to MST mode.



Kevin Dorrell Tue, 10/09/2007 - 23:15

(Francois, please correct me if I am wrong here, because you know switches better than anyone.)

This sounds like it is a 2950 switch or something similar, and therefore probably has not so many ports, and is probably an access switch. In such a situation, it might not need all those VLANs.

One solution is to make it VTP transparent, and then remove the VLANs it does not need. However, that means you don't have the convenience of VTP updating the VLAN database.

Try allowing on the trunks only those VLANs you actually need in the switch. Once a VLAN does not have any ports left, it does not have a Spanning-Tree instance in this switch, and so does not count towards the 64-VLAN limit.

Personally, I would be cautious about MST because of the complications of maintaining consistency across all the switches.

Kevin Dorrell


paul.matthews Wed, 10/10/2007 - 00:22

I am also apprehensive about MST so far. I would go for similar to Kevin, but I would leave the access switch as a VTP client, and manually prune the VLANs on trunks.

If he has 64 or more VLANs, there is a fair chance that there are quite a few switches around, and thus the chance of a complex spanning tree. Pruning so VLANs only go where needed simplifies the spanning trees and thus makes problems less likely, constrains any problems better, and makes them easier to troubleshoot.

Konstantin Dunaev Wed, 10/10/2007 - 00:58

I'm also agree that most of the time it's possible to reduce the number of VLAN on every particular switch and thus avoid the reaching of the limit in 64 STP instances.

But in some cases, e.g. in VMware, it's necessary to have all VLANs on each access switch because of possible VM instance migration between different VMware host.

VTP prunning doesn't work correctly in case as well.

paul.matthews Wed, 10/10/2007 - 01:07

Having instances move around like that can't be that great an idea - I presume the hosts talk dot1q to the switch.

I would class it as pretty poor design if you had over 50 VLANs moving around that far!


Kevin Dorrell Wed, 10/10/2007 - 01:46

Yes, VMware does talk dot1q to the switch. That can be an issue, but generally if you are running VMware then the switch is in a Data Centre environment. To have more than 64 VLANs in your Data Center sounds suicidal, except perhaps if you are a service hosting company. But in that case, I think you would be unlikely to be using 2950 switches in your Data Centre.

I don't know, I could be wrong on that last point. I know that 2960s make quite a good top-of-rack switch, especially if you essentially have a layer-2 architecture in your Data Centre. (Discuss) Do the 2960s also have the limitation of 64 Spanning Tree instances?

Kevin Dorrell


Konstantin Dunaev Wed, 10/10/2007 - 03:46

The cisco switches (IGESM) which are internal in IBM or HP bladecenters have such a restriction - 64 STP instances.

Exactly in case of service hosting company it can have more then 64 VLANs and if you have 30-40 bladecenters you can't predict where the new instances will be installed or where to the existing instance wll be moved in case of maintaince or whatever.

MST in this case can be very helpfull and solve most of the problems.

Kevin Dorrell Wed, 10/10/2007 - 04:20


Thank you very much for that view. That is waht I like about NetPro: it is a great place to get perspectives that each of us individually cannot get from our own individual direct experience.

Kevin Dorrell


glen.grant Wed, 10/10/2007 - 05:05

The IGESM's are basically a 2950 on a card so it would have the same restrictions as a 2950 as far as STP goes . Also if you are trunking to these IGESM's then to get rid of the messages you have to "manually" prune off the vlans you do not need on each side of the link to the IGESM's , this reduces the stp instances on the switch itself to those that are specifically allowed across that trunk. We ran into this on some 2950's in a big client/server environment and manually pruning any unneeded vlans from the trunks fixes this .

paul.matthews Wed, 10/10/2007 - 04:29

I would be tempted in a situation like that to look at having the bladecenters as small STP domains, using L3 to get away from the bladecenters.


Kevin Dorrell Wed, 10/10/2007 - 04:40


That's fine, so long as they are not using layer-2 to failover to a backup site (or a backup rack) via dark fibre. (The backup site being on the same VTP domain.)

But I do agree that in the non-redundant case, or in the case of layer-3 failover (multiple DNS entries), or in the case of layer-4 failover (e.g. content blades), that would be the solution.

Kevin Dorrell


Konstantin Dunaev Wed, 10/10/2007 - 05:06

Hi, Paul,

could you please explain a bit more what exactly you mean? I didn't fully get how is it possible to reduce the STP domain size. may be it would be appropriate for our situation.

do you mean to use the indepanded set of VLANs on all bladecenters?


paul.matthews Wed, 10/10/2007 - 05:43

Basically keep the sise of that switched network to an absolute minimum. IME the switches that form part of a blade center type system temd to be "managed" by the ppeople that look at the servers rather than the network people.

As Kevin says, it does depend upon what else is in place - it gets more involved if doing L2 failover to another site.

Basically you have the bladecenters with their inbuilt switches connected to a minimum of access switches. From there instead of VLAN trunks use L3 interfaces. This may mean something like using 3750s as access switches and handling all the local inter vlan routing there, and then simply configuring the links from the access switches to the core switches as L3.

ankbhasi Wed, 10/10/2007 - 07:55

Hi Paul,

I do not think pruning the vlans from the trunk can avoid flow of STP information. Pruning may restrict flooding of broadcast, multicast and unknown unicast traffic across the trunk but will not restrict STP BPDUs and stp information will sill flow.

We need to manually remove/clear the vlans from the trunk to restrict BPDU to flow across the trunk ports.



Kevin Dorrell Wed, 10/10/2007 - 08:03

I think Paul meant switchport trunk allowed vlan remove rather than VTP pruning. So actually, you both agree, I think. Isn't that right Paul?

Very often we use the terms "pruning" and "removing" interchangeably, but actually they are not the same thing at all.

Kevin Dorrell


glen.grant Wed, 10/10/2007 - 08:06

Kevin is correct if you use the switchport trunk allowed vlan remove " command to prune off the vlans this should get rid of the messages .

paul.matthews Wed, 10/10/2007 - 23:42

Sorry if I was unclear - I mean exactly that - manual pruning of VLANs byt blocking them on trunks.



This Discussion