MSTP and RSTP converge equally fast, MSTP is the current protocol version. Given the topology in your diagram (ugh!) and its tree depth, no STP variant will converge quickly (if at all).
xSTP default parameters are designed for a maximum tree depth or chain length of 20 hops. Building longer/deeper constructs requires parameter tuning or your network will ...
All the switches in network intially sends and receives BPDU messages when connected in network and election process starts . Switch Ports enters blocking state during the time of election process, when a switch receives a BPDU on a port that indicates a better path to the Root Switch Root Bridge and if a port is not a Root Port or a Designated Port.
You have a fundamental problem with your configuration, which is that the configuration digests on core and access switches don't match.
[Core-sw]dis stp region-configuration
Format selector : 0
Region name : ***edited***
Revision level : 0
Configuration digest : 0x950fe4b63ba3d47dc4a539d00f613bb9
Generally, a ring is a bad design for Ethernet switches. STP blocks one of the ring links, forming a chain. Traffic between switches on opposite sides need to cross the whole chain, potentially causing link congestion. In your diagram with A being the root switch, C-to-D traffic would require four L2 hops.
With 802.1D-compliant switches/bridges, STP BPDUs ...
If you can use Cisco Metro Ethernet switches, you might consider Resilient Ethernet Protocol, which is designed for ring topologies.
REP is a protocol used in order to replace the Spanning Tree Protocol
(STP) in some specific Layer 2 network designs. ... Benefits Here are
some of the benefits of REP:
REP offers these convergence times:
MST (IEEE 802.1s) exchanges BPDUs only on instance 0. Don't expect BPDUs on the other instances.
VLAN-to-instance mapping must be identical on all MST switches (ref: richardb's answer) for the topology to converge.
With MST (802.1s), only instance 0 is meant to exchange BPDUs. One of the best writeups about MST I could find is ...
Actually a STP/RSTP blocked port requires BPDUs to be received, otherwise it will become unblocked. Here's the output of a show command on one of my production switches, which is a blocked port for this vlan. I typed these two commands a couple of minutes apart, and you can that the received BPDUs incremented by 70 or so:
SW1# sh spann int f0/24 det | sec ...
We're talking about two different versions of spanning-tree, IEEE 802.1D STP standard and IEEE 802.1W RSTP, they cannot work together because 802.1D does not understand RSTP BPDUs, but when a RSTP Switch receives an 802.1D BPDU, it responds with 802.1D BPDU and
eventually the two switches runs 802.1D to communicate.
The best practice is to configure RSTP on ...
You need to make sure whether those devices
really don't send any xSTP BPDUs on their own (verify by packet capturing) - you cannot trust the documentation at all times
possibly pass through xSTP BPDUs - 802.1D-compliant bridges need to drop these BPDUs but there are many switches around (especially small ones) that do forward BPDUs.
If they really do not ...
The timer fields are not encoded as integer seconds but as a fixed-point number - the first octet means full seconds (more significant), the seconds stands for 1/256 seconds (less significant). 14 00 means 20.000, 14 80 would be 20.500.
This is pretty well hidden in IEEE 802.1Q - where RSTP/MSTP were moved after 802.1D-2004:
14.2.8 Encoding of Timer Values
RSTP is an IEEE STP that works on the port level only and is unaware of VLANs. For VLANs to form different spanning trees you require MSTP and an appropriate configuration using multiple instances (MSTI). Each of these instances forms its own spanning tree and you use those instances to group your VLANs and distribute their over your redundant links.
Running spanning tree in such a large, unreliable network is just asking for trouble. You will always have links flapping which will cause spanning tree to continually reconverge.
You need to redesign your network. That means adding routers or layer-3 switches to break up the network into more manageable L2 domains. The goal is to eliminate L2 loops by ...
For question 1, I think it is normal behavior that you will type the command on interface level and it will be global config mode command
for your second question there is no option for disabling STP on the port level you can disable the STP on VLAN level only
BPDU filter and portfast will provide the expected behavior for disabling the STP on port level
BPDUs are not forwarded, generally.
BPDUs are generated and sent on all links, including blocked ones.
Topology information contained in the BPDUs can be considered to be forwarded, but the BPDUs themselves aren't.
"Dumb" (unmanaged) switches often forward BPDUs even though they're not suppposed to - see IEEE 802.1Q 8.6.3:
The [...] group address ...
bpdu-guard disables a port when it receives (unwanted) BPDUs. That is its design. You cannot use bpdu-guard with devices that you expect to emit BPDUs in general. The only way to keep bpdu-guard enabled productively is to make those device stop sending BPDUs.
If you want to ignore BPDUs from a port you should instead use bpdu-filter (ignoring BPDUs generally,...
Realistically, it depends on the size of the current spanning tree and how it is disrupted.
In an RSTP or MSTP environment, if an interface goes hard down (eg: it's disconnected or otherwise shut down), then the topology change will trigger immediately - between only two switches, a new tree should establish in less than a second and forwarding will ...
I think you could do this using a SPAN port.
Since your switches are redundantly connected, determine which of the two links is the Alternate.
Set up a SPAN session using the Alternate port as a source and the option "encapsulation replicate"
Connect the SPAN destination to your laptop running Wireshark and start a capture
Disconnect the active link causing ...
15 minute convergence? Ouch! ;) But yes, I agree with your suspicion - multiple 802.1D bridges scattered around the network could easily blow out convergence, as they block all ports other than root while in their Listening state - multiply this by a few boxes and you'll have quite a few topology state changes as the radius increases.
Firstly, if you're ...
It could be a spanning tree mode related problem.
Among RSTP, MSTP and PVST, each mode has some STP compatibility, with a fallback mechanism to STP for ports that receive STP BPDUs.
If a MSTP mode port receives STP BPDUs, it automatically transits to STP mode, but doesn't transit to RSTP mode when receiving RSTP BPDUs.
This may explain why your ...
Spanning tree is to prevent layer-2 forwarding loops. It only works if you have multiple bridges (switches are bridges) connected. It works by forwarding frames toward the root bridge, thus preventing loops.
If you connect each switch (bridge) to a separate layer-3 interface on your firewall/router, then you have no need for STP, but if you connect your ...
Let me break down as the following:
STP is used when you have redundant paths in order to avoid an endless loop which can harm your network. Based on your topology A<->B<->C this is a straight topology tree hence the STP might not be entirely necessary.
There are two types of BPDU's: Configuration and Topology Change Notification. Do not confuse both....
If the devices are bridging, and they, themselves, do not support RSTP, then you will not be using RSTP. The STP version used will be the common version supported by all devices. To be able to use RSTP, all the bridges must support RSTP.
Even with RSTP, you will not get recovery times of <1s.
Specifically, I have one Ethernet switch. Connected to that ...
After running some tests these logs are actually generated by activating debug spanning-tree synchronization.
I noticed they are actually sent whenever a switch did not received/triggered synchronization proposal (RSTP proposal/agrement handshake) during 2 minutes.
They can be considered as a RSTP synchronization "watchdog" if the proper debugging is on.
After days of trials and researches, I managed to get a clear answer that I want to share here also.
VTP pruning does NOT reduce the number of STP instances running on each switch; it just removes replication of broadcast, multicast, unknown unicast frames for the pruned Vlan but STP/RSTP BPDU traffic is not impacted by VTP Pruning.
Your max diameter is currently 19. That's what happens if Field Switch 1 or 2 goes down, which they sometimes will for maintenance. Even during normal operation, your diameter is 11. That's alright -- RSTP default max age is 20 -- but I would make these rings a little smaller.
If I inherited that network, my priorities would be:
Remove all xSTP ...
If all your switches use STP a loop isn't that bad (it's definitely suboptimal, but there are times when you can't get around it), but then you'll need switches with STP support, and with it enabled and properly configured on each switch.
In your case, the switch connecting to the ring to the outside would have to have it's priority set so that it's most ...
You're trying to detect a link failure by missing BPDUs but that takes at least two hello intervals.
The best option is to make the bridges drop their Ethernet link as soon as they detect carrier loss on the wireless side. Then, use RSTP on the router (apparently, there's a bridge group). RSTP can fail over in less than 1 ms on link failure, it all depends ...