I am fixing to run into my 64 STP instance limitation on my Fiber MAN composed of 5 fiber Gig-E rings. From what I have been reading, it says you can prevent this from happening by setting allowed lists on the trunk ports of switches that have used up their allocation of spanning-tree instances, but from my testing this does not work. Even though I block all the unused vlans on all of my trunk ports, and it only shows those STP instances I have allowed being forwarded or blocked on those trunk ports, I still can't create another spanning-tree instance. From my testing, it seems that I have to turn off STP for those vlans all together, in order for me to create another. This is fine, but just curious if there was another way, considering it seems kind of dirty and will require alot of config updating on all my 30-40 switch's.
One other question.. they make an updated IOS version for the 3508XL that supports more than the 64 instances, maybe even supports MISTP?
A network that exceeds these limits is not desirable. I would rather look into possibilities to reduce the presence of stp by making the interconnecting gig-links layer3 and make several smaller stp domains for the variuos sites. That involves a lot of reconfiguration as well but you will gain a lot of stability.
I can't do that. I do alot of TLS/802.1Q-in-Q implementations. I need alot of these STP instances to span my entire Gig-E backbone, where by all my switch's in my entire MAN recognize certain layer2 segments.
So, as you can see, I can't break them up with a Layer 3 device, unless I was doing some sort of Layer 3 MPLS to get my customer site-to-site connections to work, which I am not.
Right now, my only option is to block all my manaagment STP instances on all my trunk links, freeing up instances for my 802.1Q-in-Q customers. Once I do this, we will upgrade all of our PE switch's with switchs that support more than 64 instances of STP and support MST or MISTP.
So, back to my original question... Is there any other way to stop the STP instances on my trunk links, besides disabling unused STP instances for all those VLAN's on my switch's, because just blocking them with allow-lists doesn't work?
Do you have VTP pruning enabled on your switches. VTP pruning is enabled by default on most switches unless someone manually turned it off. VTP pruning should limit VLAN propogation to the VLANs in use on the downstream/access switches. This would curtail the STP instance to the active VLANs.
I may be wrong, but setting up the allow-list of vlans across my trunk links would essential do the same thing correct? I mean it does block the vlans across them, where by I do only see those vlans being forwarded or blocked on those trunk links? Does Pruning differ in the way allow-lists work on a switch?
I also thing I read somwhere that Pruning will not work for blocking the STP instances?? I may be wrong there as well.
Your suggestion of using allow-lists involves a serious amount of administration on a network of the size we are talking here. Your main backbone must & will be able to handle all vlans (=stp instances). There is however no need to forward each and every vlan over a link where it is not used. After all, how many different vlans do you need on a 24 or 48 port switch?
I would say Sundar is absolutely correct in suggesting the use of pruning which is more autonomous. You might gain a lot from taking a fresh look at your topology with this in mind.
Well, these are 3508XL switch's which are trunked to GPON FTTP equipment, which can support up 128 vlans. I do not have vlans coming off 24-48 port switchs.
Well, my allow-list suggestion doesn't work. It works for broadcast and other types of traffic being forwarded across the trunk links, but like I have said previously, I still connect create another vlan, without disabling those STP instances on each switch all together.
As far as VTP Pruning goes...I plan on eventually getting rid of VTP all togther, because there is to much overhead with it and I do plan on using my extended range vlans. Does VTP Pruning work without VTP?
Also, in my test lab. I enable pruning on my core switch, which does enable it on all my downstream PE switch's, but I don't see where you can prune that vlan on my PE switchs? Am I missing somthing?
Just an FYI... I have tested this in my lab and all though pruning may be great for blocking unwanted broadcasts and unicasts across a trunk link, it does not block vlan STP instances. Even with allow-lists.....if you do a "sho spanning-tree summary", it still shows 64 vlans, regardless if the only vlans that are forwarded and blocked on those trunk links, are the ones you allowed.
Issuing a "no spanning-tree vlan (vlan)" seems to be the only thing that works, which bites!
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...