Cisco 2950 PVST Vlan Spanning Tree instances problem

I have some 2950's in production that I noticed did not have spanning-tree instances for every VLAN our network has(We are running PVST+). So I did some research and found that 2950's only support 64 Spanning tree instances, and at the time our network had about 80 VLANs.

After a few weeks of retiring old VLANs and consolidation, I got the number down to 64. However when I look on some of our 2950s, several of our VLANs still don't have spanning-tree instances. Do I have to reboot the switches or something to get these instances to start or should it happen automatically?

Right now our VTP domain is sitting right at 64 VLANs. In the new few days I expect to have that number down to 55.

Perhaps this is because it is reserving room for the built-in VLANs like 1002-1005 or something?

Any opinions/experience are welcome.
Who is Participating?
Don JohnstonConnect With a Mentor InstructorCommented:
Do I have to reboot the switches or something to get these instances to start or should it happen automatically?

You will have to reboot. Spanning Tree instances get assigned on a first come, first serve basis. So the first 63 VLANs (VLAN 1 already has an instance) that you create will exhaust all the instances. All the VLANs created after that will be without STP. Deleting the older instances will not reassign the now unused instances.
AkinsdNetwork AdministratorCommented:
I will say try a reload (reboot) first. vlan information stays iin RAM if it was saved in startup even after deleting it.
The defined vlans exist in the vlan database on a switch of that age. There is a good chance you will need to remove unneeded vlans from the database to get them gone for good.

sw01#vlan database
VLAN database editing buffer manipulation commands:
  abort  Exit mode without applying the changes
  apply  Apply current changes and bump revision number
  exit   Apply changes, bump revision number, and exit mode
  no     Negate a command or set its defaults
  reset  Abandon current changes and reread current database
  show   Show database information
  vlan   Add, delete, or modify values associated with a single VLAN
  vtp    Perform VTP administrative functions.
We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

ThePorthosAuthor Commented:
Thanks for the fast responses guys. I can't reboot them because they are in an active work environment, so I will have to wait for a downtime to test it on one or two switches to see if that is the problem.

As far as the old VLAN database removal method, are you talking about the old 1002-1005 VLANs? Didn't think those could be removed. The device providing VTP is a 65506 and that's where I manage all our VLANs.
rauenpcConnect With a Mentor Commented:
You won't ever be able to remove the 1002-1005 vlans, but if any are stuck and not being removed by VTP, you can check their existence in the database and maybe remove them manually.

Potentially in lieu of a reboot or manual removal, you could change vtp modes from client to transparent and back to client. This could give VTP a little kick in the pants to synchronize and remove non-existent vlans. This isn't supposed to cause any outage, but you may want to do this during a time that the users could handle a blip on the radar. I suppose you could also play the devil's advocate and argue that any change could cause a crash and reboot...

Does the switch have active ports in the vlans or have the vlans allowed on a trunk port?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.