Hello Dominique
Yes, tuning the max-age will indeed tune the blocking delay… so what you describe in your post is correct.
I found the following document useful to further understand the intricacies of STP timers, I hope you find it useful.
I hope this has been helpful!
Laz
Hi Rene,
The port which is in blocking state has to wait for 20 seconds , any specific region behind this ?
Hello Pradyumna
The blocking state timer (and all STP timers) are configured in such a way so that the formation of a layer 2 loop can be avoided.
In the lesson, Rene states:
When an interface is in blocking mode and the topology changes, it’s possible that an interface that is currently in blocking mode has to move to the forwarding state. When this is the case, the blocking mode will last for 20 seconds before it moves to the listening state.
As soon as a blocked port receives information that the topology is changed, via BDPUs (a blocked port will only receive and process BPDUs), and it too may need to change, it doesn’t immediately go into the listening state but waits 20 seconds. This delay is used to allow the other areas of the STP topology to stabilize before changing to the listening state, and reacting to them.
The timers (blocking 20, listening 15, learning 15) have been defined after experimentation and research, and are based on the optimum values for most network topologies. Remember, that for this lesson, Rene is speaking about the original STP implementation of IEEE 802.1D defined in 1990 (thirty years ago!!), an implementation that is great for teaching network fundamentals, but one that should not be used in modern networks.
I hope this has been helpful!
Laz
Q-1:- What i understood, kindly correct me if i am wrong .
If a root and designated port breaks then the switch will take only 30sec to make the block port as root port …
But when it take 50 sec.?
How TCN and Configuration BPDU transited between the switches ??
(SW1=>sw2=>Sw3)
Will sw1 will send the BPDU to sw3 ?, if it will send then what sw-2 will modify in that bpdu before it sends to sw3 ?..
Hello Narad
If a port is down, and it is just plugged in, then it will take 50 seconds because it goes blocked for 20, listen for 15, and learning for 15 = 50 seconds. Even if there is a topology change, such as when a root or designated port fails, any ports that were in the blocking state will remain in that state for 20 seconds before going to listening and learning. Therefore the total amount of time would still remain 50 seconds before forwarding…
Take a look at this lesson:
I hope this has been helpful!
Laz
Thanks Sir for your help…!!
Hi,
regarding case 2, which are previously received BPDUs received on port B of switch 3 from switch 2? What makes them superior BPDUs?
Hello Quirik
Switch ports in the blocking or alternate state still receive BPDUs from the connected switch. So for the following statement here is the explanation:
So before port C on SW2 went down, when STP was converged and stable, port B had received some BPDUs from SW2. These are the “previously received BPDUs.” When the topology changed, SW2 sent new BPDUs with new information, stating that it is the root bridge. SW3 does not process these yet, until the blocking timer expires.
What makes the superior? I assume you are referring to this statement:
The statement says that once the blocking timer expires, the newly received BPDUs are considered. However, they are not accepted because those received from SW1 are superior to those received from SW2. So, SW1 becomes the root once again, as it should be.
Does that make sense?
I hope this has been helpful!
Laz
Hello,
I have tried htese topology changes in a lab environment , For a designated port here is the cases and results:
For an Alternate port.
Also
I saw something like this in another resource:
In STP, regardless of their own configurations, all other switches inherit the timer configurations of the root bridge. This is because the root bridge uses Bridge Protocol Data Units (BPDUs) to disseminate its timer values throughout the network.
But When I tried this in my own lab, I change a non-root bridge ID timers, and I waited a little bit, but it didnt sync itself according to root bridge Timers, I even tried to triggered the sync by changing timers on root briddge but it didnt work,
Why is that?
Thanks
Hello Görgen
This is expected behavior. Keep in mind how a topology change is defined. When you connect a server to a designated port, the switch doesn’t see this as a topology change, hence no TCN is sent. When you shut and no shut the designated interface, the switch goes through the STP states (Listening, Learning, Forwarding) as expected. This is because the interface was manually shut down and brought back up.
Yes, PVST+ skips the learning state and goes directly to blocking.
Hmm, I’m curious to know where this information was published. STP does not typically synchronize timers across all switches in the network. In both the original STP and its subsequent versions like RSTP and MSTP, timer synchronization is not a feature.
In STP, the root bridge sends out BPDUs which contain information about the network topology, the root bridge ID, and the root path cost, along with the timer values like Hello Time, Max Age, and Forward Delay. However, these timer values are not meant to synchronize the timers of all switches in the network. Instead, they are used by each switch to understand the network topology and to time their own STP state transitions.
Each switch in the network will use the timer values from the root bridge’s BPDUs for STP calculations, but they maintain their own timers and do not automatically adjust their local timer settings to match those of the root bridge.
I hope this has been helpful!
Laz
Hi,
The broken state (The switch has detected a configuration or an operational problem on a port that can have major effects. The port discards packets as long as the problem continues to exist.) is something specific to Cisco or is included by IEEE. I have not been able to find any reference in the standard.
Hello Diego
This is an excellent question. It turns out that the BKN* state is actually a Cisco proprietary extension to the spanning tree protocol. According to the command reference linked below, it appears as an option only when you issue the show spanning-tree vlan command. Where and when it actually appears can only be confirmed in practice.
However, having said that, the BKN* status indicates an inconsistency of some sort. There are several inconsistencies that may appear on ports including:
Some references that may be helpful include:
show spanning-tree command. This includes some information about the BKN* status.I hope this has been helpful!
Laz