Spanning Tree Port States

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

1 Like

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…!!

1 Like

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

1 Like

Hello,

I have tried htese topology changes in a lab environment , For a designated port here is the cases and results:

  1. When I connected a server to a designated port, it goes directly to Forwarding , I didnt see any TCN notification from debug. Why is that? (There is no portfast conf.)
  2. When I shut and no shut the designated interface , It acted accordingly, it goes 15 sec listening, 15 sec learning and then forwarding, this is ok,

For an Alternate port.

  1. When I shut and no shut the interface, It first go listening but after 2 sec it went directly to Blocking, Does it because it uses pvst and not classic 802.1d?

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