Spanning tree root bridge election and ports status

[Benoit Desbiolles]

Hi, regarding my studies I would like to confirm the three statements below about spanning tree.

1. When a switch boot or spanning tree is enabled on a switch, the switch ports pass into blocking state 20 seconds before going into listening state (I read it on Internet but not the case after testing it on Cisco packet tracer)
2. The root bridge election and the root designated port are chosen during the listening state
3. We could consider that the root bridge election and the root designated port selection is done after the listening state (15 seconds default).

Thanks !

[Peter Paluch · Accepted solution]

Hi Benoit,

1.) When a switch boots or the STP is enabled, a port is immediately put into the Listening state. A port never starts in the Blocking state. The Blocking state is only used for ports that have been reliably identified as non-designated ports (that is, a port that is neither Root Port nor Designated Port). Hence, a port requires 30 seconds after coming up to become Forwarding (Listening - 15s - Learning - 15s - Forwarding).

2.) Root bridge election and root port selection is a neverending process, and is repeated whenever a new BPDU is received. However, in a stable network, the elections always produce the same result, giving off the impression that the election stage has ended. However, the topology can change at any time, and so the switches need to be prepared to reelect the root bridge and root port at any time instant.

3.) Root bridge, root port, and designated port elections are performed as soon as the port comes up, as they are all based on comparing the received and sent BPDUs. There is no waiting before performing these elections and they can be safely performed even during the Listening state - after all, that is what the name "Listening" refers to. Once again, the elections are performed with each received BPDU, but after a network has stabilized and no further changes have taken place, the BPDU contents do not change, and so processing them produces always the same result.

Feel welcome to ask further!

Best regards,
Peter

[Benoit Desbiolles]

Thanks Peter! Your response is very clear! 

[Benoit Desbiolles]

Hi Peter,

Just an additional point,

So, do the following assumptions are true:

Port passing UP:
    - Listening immediately
    - Ports roles and states determination with received BPDUs
    - Root port and Designated port, will pass into Learning and Forwarding step
    - ND port will pass immediately in blocking state (without waiting the end of the 15s Listening state)

Port passing from Blocking to Listening :
    - When the topology change
    - If ND port get the root port or designated port role

Port passing from Forwarding to Blocking:
    - When the topology change
    - If root port or designated port get the ND port role

Thanks!

[hikandpal]

Hello Peter,

I would prefer to disagree with you first statement, that a "switch never starts with blocking state".

I was going through this Cisco doc regarding STP and it has clearly mentioned that switch starts with Blocking state when we power it on .

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_53_se/configuration/guide/2960scg/swstp.html#pgfId-1020084

"When you power up the switch, spanning tree is enabled by default, and every interface in the switch, VLAN, or network goes through the blocking state and the transitory states of listening and learning. Spanning tree stabilizes each interface at the forwarding or blocking state."

Thanks 

[Peter Paluch]

Hello,

Thank you for joining!

Let's first check what a real switch does. Using debug spanning-tree events, you can easily see that a port jumps into Listening state after coming up, then to Learning state, and finally to Forwarding:

Cat3560(config)# int gi0/19
Cat3560(config-if)# do term mon
Cat3560(config-if)# do debug spanning-tree events
Cat3560(config-if)# no shut
Cat3560(config-if)#
*Feb 12 16:43:14: %LINK-3-UPDOWN: Interface GigabitEthernet0/19, changed state to down
*Feb 12 16:43:15: set portid: VLAN0001 Gi0/19: new port id 8013
*Feb 12 16:43:15: STP: VLAN0001 Gi0/19 -> listening
*Feb 12 16:43:17: %LINK-3-UPDOWN: Interface GigabitEthernet0/19, changed state to up
*Feb 12 16:43:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/19, changed state to up
*Feb 12 16:43:30: STP: VLAN0001 Gi0/19 -> learning
*Feb 12 16:43:45: STP[1]: Generating TC trap for port GigabitEthernet0/19
*Feb 12 16:43:45: STP: VLAN0001 Gi0/19 -> forwarding

Please ignore the timestamps, I just grabbed a lab device that has its time totally off ;)

The gi0/19 interface was first administratively down (it was shutdown). After the no shutdown command was executed, the interface first became down, waiting for the Ethernet autonegotiation to complete, and when it did, STP sprang to action, immediately putting the interface into the Listening state directly. Also note how it took exactly 30 seconds (2x15 seconds, Listening->Learning and Learning->Forwarding) for the port to become Forwarding since it came up.

So what is really happening? Truth is, we need to dig deep into 802.1D-1998 standard (see the attachment) to understand the steps taken when a port is enabled. After enabling the port, STP executes the Enable Port procedure described in Section 8.8.2. I am not going to quote it here in its entirety, but note what it does:

1. It declares the enabled port as Designated Port
2. It puts the port into Blocking state
3. It stops a set of timers if they were running for the port, and resets internal flags
4. Finally, it calls the Port State Selection procedure described in Section 8.6.11

Indeed, the port is put into the Blocking state. However, the Port State Selection procedure finds that the port is declared as Designated Port (in the Blocking state), and immediately invokes the Make Forwarding procedure in Section 8.6.12 - and the Make Forwarding procedure, upon finding that the port is in the Blocking state, immediately moves it to the the Listening state and starts the Forward Delay timer.

So - indeed, after a port is enabled, it formally undergoes the Blocking state. However, this particular instance of the Blocking state is not driven by timers, and is left immediately as the initialization procedures in STP complete, and once again, the formal IEEE 802.1D-1998 specification executes the Enable Port, then Port State Selection, then Make Forwarding procedures in immediate succession, without any timer-driven delays between them. Cisco IOS does not log this initial transition through the Blocking state since the newly enabled port leaves the Blocking state very quickly.

Truly, a newly enabled port becomes initially Blocking, but it does not stay in that state for 20 seconds - instead, it immediately moves into the Listening state since the initial role of the port is Designated. That makes this particular Blocking state different since its duration is not driven by the max_age timer.

Thank you for pointing this out!

Best regards,
Peter

[ISRAFILANSARIMD]

When a switch boots or the STP is enabled, a port is immediately put into the Listening state.then how bpdu send by switches,as far as i know ,switch port in listening state only receive bpdu,

[Peter Paluch]

Hello,

True, a port in the Listening state does not send configuration BPDUs - it only receives them.

But a port can stay in the Listening state only for forward_delay seconds at most (15 seconds by default). Depending on the received BPDUs, the port knows that it either needs to be Blocking (because it is neither Root nor Designated), or that it needs to become Forwarding (because it is either Root or Designated) - and so when it moves into the Learning state and is supposed to be Designated, it will also start sending BPDUs. Root ports do not send out BPDUs, of course.

Feel welcome to ask further!

Best regards,
Peter