03-26-2026 10:08 AM
spanning-tree mode rapid-pvst
spanning-tree extend system-id
no spanning-tree vlan 1-4094
spanning-tree vlan 1-3,10,300,305,310,315,320,325,330,335,340 priority 16384
spanning-tree vlan 345,397-398,400,410,425,499,700,899,999,2002 priority 16384
spanning-tree vlan 895 priority 28672
spanning-tree vlan 902,992 priority 8192
what will be the result, whether spanning tree is disabled for all VLANs or spanning-tree is enabled only for explicitly enabled VLANs ?
03-26-2026 10:49 AM
The no spanning-tree vlan 1-4094 will disable it on all VLANs, the priority is just to influence the Root Bridge election, in this case will have no affect since the STP will be disabled.
03-26-2026 11:39 AM
Assuming you have no L2 loops, disabling STP shouldn't have an impact.
If you don have an L2 loops, results of disabling STP might be noticeable!
Of course, disabling or enabling STP, applies to just this one switch, but disabling it will also break BPDUs being passed across this switch, and might impact what other STP switches believe the L2 topology is, which, also, might be noticeable.
In many networks, using L3, STP is generally only running to preclude or handle accidental L2 loops.
In network with intentional L2 loops, you need something like STP, doesn't necessarily need to be STP, to prevent looping frames.
03-26-2026 11:56 AM
STP does not run on any VLAN:
No loop protection → high risk of broadcast storms. Any Layer 2 loop can bring down the network.
STP enabled only on configured/enabled VLANs:
This should protect your network from broadcast storms, layer 2 loop on those particular VLANs.
In short, the config is fine as long as you make sure to add the VLAN in spanning tree whenever you create a new vlan. However, the recommended config would be to keep STP enabled for all VLANs irrespective of VLAN being configured or not to avoid any misconfiguration.
03-26-2026 01:21 PM
@Atul_Choudhary wrote:
STP does not run on any VLAN:
No loop protection → high risk of broadcast storms. Any Layer 2 loop can bring down the network.
STP has noting to do with broadcast storms.
Concerning a L2 loop bringing down a network, it certainly will mess up the L2 domain it's within, but how much that impacts the devices touching that domain, can vary.
Understand, a true broadcast storm is a real killer because every device needs to open every packet/frame and determine whether it's relevant to that host.
A L2 loop of unicast traffic, or multicast traffic, would be ignored by hosts without matching unicast or multicast IPs. Switches, though, would just forward them, like they would any other such traffic. So, the links, within that domain, do get flooded with traffic, which is very, very impactful to communication within that L2 domain, but not necessarily to the hosts or switches.
That understood, L2 loops are bad, which is why STP, or something similar, is recommended as a safety net.
In this case though, the question is whether working without the, in theory, unnecessary safety net of STP vs. whether STP, if, somehow, STP is a contributor to the L3 switch freezes, is a possible the decision.
Hard to say which is a better choice, i.e. STP or now STP, although part of the decision would depend on the L2 vs. L3 topology design of the network.
I don't know whether, without research, any other L2 loop protocols are available on the C1300s, like something like REP or MST. (MST, of course, is a variant of STP, but likely you're not running multiple L2 topologies.)
03-26-2026 02:11 PM
Totally!! STP itself has nothing to do with broadcast storm, it just prevents the loop which can cause broadcast storms. Have seen numerous issues when worked in Cisco TAC where these storms choked out the network links, brought the CPU utilization high and made it very difficult to even get the access of switches to troubleshoot.
From a quick check, it seems like REP is not supported but MST is.
My personal preference is always to use RSTP than MST unless we have a huge number of VLANs.
03-26-2026 02:56 PM
@Atul_Choudhary wrote:
Totally!! STP itself has nothing to do with broadcast storm, it just prevents the loop which can cause broadcast storms.
You don't need a L2 loop to have a broadcast storm, nor does a L2 loop, and its adverse impact, need any broadcast packets.
That said, certainly a L2 loop can contain broadcast packets/frames, and such would make a L2 loop even more impactful.
Again, what a L2 loop does is flood the loop's links with traffic, the same traffic looping round and round, forever, as L2 doesn't have the equivalent of a TTL. (Actually, if any host is still injecting traffic, some traffic will be dropped as switch buffers overflow. But that will not break the loop or reduce the overall volume of traffic.)
Again, what a broadcast packet/frame causes, every host must open it to determine it's of interest. Switches, that aren't visible (no IP nor MAC) as hosts within a L2 domain, would just not open such packets/frames, to them, it's just hardware forwarded.
The combination, though is particularly bad!
@Atul_Choudhary wrote:
Have seen numerous issues when worked in Cisco TAC where these storms choked out the network links, brought the CPU utilization high and made it very difficult to even get the access of switches to troubleshoot.
I don't doubt that at all! But a switch's CPU shouldn't be impacted by a L2 loop, even if 100% broadcasts, unless the switch has an IP or MAC on the L2 loop. Otherwise, to the switch, it's just a 100% busy port.
The impact of broadcast, and some multicast, traffic to a switch, as a host, is also why so many switches have "storm control settings" and/or CoPP, which have nothing to do with L2 loops, just dealing with floods of certain kinds of traffic.
(I am assuming, switch's CPU isn't used for forwarding/switching "normal" packets. If it were, CPU can be easily overloaded by a high volume of any kind of traffic, as many software based routers are.)
@Atul_Choudhary wrote:
My personal preference is always to use RSTP than MST unless we have a huge number of VLANs.
I've yet to use MST, but I do use rapid-PVST if it's not the default. This because I moved away from L2 topologies, decades ago, when small L3 switches came along. As a general rule, I never, for new or upgrade designs, span VLAN access ports across switches.
Lastly:
Just noticed, this reply and my prior reply was also made in the context of another thread dealing with C1300 lock ups, where STP was thought it might be a possible cause of the issue.
Hence my suggestion to disable STP for a C1300 in my prior reply.
Technically, this is known an oops!
So, my suggestion was specific to a different specific case, vs. this OP.
I do recommended running STP as a safety net.
I also standby what I've written about STP is for dealing with L2 loops, not broadcast storms, but the two can, be combined. Either can be, and often is, very bad! The combination might not be that much worse only because either, alone, can be so bad, it cannot get worse.
03-26-2026 12:26 PM
Thanks all for your responses
One more thing
If we give "show span", it says like below. But we configured so many trunk (with allowing VLANs) and few access ports with VLAN 3
No spanning tree instance exists.
What might go wrong here ?
04-02-2026 01:32 PM - edited 04-02-2026 01:33 PM
Hello @vivekbabu-s ,
you have to enable again STP for all the VLANs of interest as suggested by @Atul_Choudhary
This is the reason why you don't see any STP instance running on your switches.
It is highly recommended to re enable STP for all existing VLANs
Hope to help
Giuseppe
03-26-2026 12:47 PM - edited 03-26-2026 01:08 PM
try command
04-01-2026 07:03 AM
@vivekbabu-s Just following up to see if it fixed your issue.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide