Spanning-tree Forwarding State - Loop Guard

[Steph1963]

Hi,

1) Spanning-Tree

I would like  to know if the Spanning Tree forwarding state is applicable to the designated  and root port. I read at many places that Spanning-tree supported the following states and roles

Spanning-Tree States                    Port Roles

Blocking                                        Root

Listening                                        Designated

Learning                                        Block

Forwarding

Disable

Trying to answer the following question made me realize that I did not really understand the concept of forwarding

Which two statemets about STP state changes are true

a) If a forwarding port receives an inferior BPDU, it will transition to listening

b) Upon bootup, a port transitions from blocking to listening beacuse it assumes itself as a root.

c) If a blocked port receives no BPDU by the max_age time limit, it will transition to listening

d) Upon boot up, a port transitions from listening to forwarding because it assumes itself as a root

e) If a forwarding port receives no BPDUs by the max_age time limit, it will transition to listening.

f) Upon bootup, a port transitions from blocking to forwarding because it assumes itself  as root.

The answers are b & c. This assumes e) is false because because a forwarding port is a designated port and it cannot receive a BPDU or is because that a ROOT port that stop receiving BPDU does not goes to into a listening state (which I think is really the case)

Can somebody confirm me that a forwarding port only applies to a designted port or if the root port really transition to listening when it does not receive any BPDU.

Root-Guard

Can somebody explain me if configuring the following network with the loopguard features prevent the switches B & C from becoming the root in case of Switch A failure. In other words,  does using loopguard prevent any other switches in a network of becoming the root.

Thanks for all your help

Stephane

[Peter Paluch · Accepted solution]

Hello Stephane,

I am right now wondering if I answered all your questions in your last question about PIM and multicasts. If not please let me know!

Regarding your questions here:

Even though we are obviously talking about legacy STP here, it is always very helpful to think about port roles and states independently. As you have correctly pointed out, there are formally five port states in STP: Disabled, Blocking, Listening, Learning, Forwarding. With respect to the port function in a stable topology, there is a Root port, Designated port and a Non-Designated port.

Now, in a stable topology, both the Root port and Designated port are in Forwarding state. Hence, saying that the port is Forwarding does not exactly tell us what is the function of the port - it can well be either Designated or a Root port. The Non-Designated port will always be in the Blocking state.

The Listening and Learning states are transitory states, and Designated/Root ports go over these, but they will never remain in these states.

Regarding the statements: b) and c) are fine. The a), d) and f) are obviously wrong. The e) answer is speculative. As the port is in the Forwarding state, it can be either Designated or Root. A Designated port may receive inferior BPDUs although that would not happen in a correct STP implementation - but even if it did, the Designated port would not care at all because its BPDUs are superior to those received. But it does not matter if a Designated port really receives BPDUs or not, as long as its own BPDUs are superior to all received. Therefore, for Designated ports, the e) is incorrect.

However, if the port is a Root port, and the BPDUs haven't been heard for max_age seconds, it's a different story. This would mean that the original root switch is unreachable. As a result, the entire switch would start considering itself as a new root, and because of this fundamental change, all ports would be reset to the Listening state which is actually the starting port state in STP - it is as if you unplugged the switch from mains, and plugged it back after a while. Here, the e) answer would be actually correct.

Regarding the LoopGuard: the LoopGuard would not be able to prevent another switch from becoming root. The point of the LoopGuard protection is that if BDPUs were received on a port and suddenly they stop being received, then it is an indication of a uni-directional link. However, if another bridge were to rightfully become the root, it would either be placed topologically "above" the protected port, in which case the port will still receive BPDUs, or it will be placed topologically "under" the protected port, in which case the port may freely change its role from Alternate or Root to Designated because it will be cause by a re-root event, not by a lack of BPDUs.

Hopefully this all is understandable but please feel welcome to ask further!

Best regards,

Peter

[Steph1963]

Hi Peter,

I think I finally understand your answer and it makes a lot of sense.

If the forwarding port is a designated port, does not really matters if it receive or not BPDUs as long as the BPDU is inferior.

If the forwarding port is a root port, then it will start to listen for other BPDUs if no BPDU has been receive during max age timer.

This made me realize that I am not completely understand STP.

A port moves from blocking to listening if the port is on its way to the forwarding state

A root port will wait max age timer before considering itself as the root port and force each ports of the switch in the listening state.

I would like to know what happen to a Designated Port that receive a superior BPDU like switches C & D in the following examples.

Does switch C immediately change the DP into RP without waiting for any timer as soon a superior BPDU is received.

Does switch D immediately change the DP into a block port without any timer as soon a superior BPDU is received.

In the following network:

If the failure does not affect switches 5 & 6, is it possible that communication between Host A and Host B is affected because of the reception of the TC BPDU that will reduce the MAC aging time to 15 seconds of the MAC table? In other words, can we loose packets between Host A & B because of a failure that does not directly affect these host.

Can I say that a switch that receive a BPDU Message Age of 2 will display a timer message age that vary between 0 and 18 when I am using the command show spanning-tree for the interface receiving the BPDU.

Thanks for all your help

Stephane

[Peter Paluch]

Hi Stephane,

If the forwarding port is a designated port, does not really matters if it receive or not BPDUs as long as the BPDU is inferior.

Yes. Note please that even a Designated Forwarding port still listens to BDPUs in addition to sending them, because at any time, a superior BPDU could arrive.

If the forwarding port is a root port, then it will start to listen for  other BPDUs if no BPDU has been receive during max age timer.

This is not correct. A Root Forwarding ports listens to BPDUs all the time but usually does not send BPDUs itself. An exception to this rule is the propagation of a topology change (the TCN BPDUs).

In essence, every port in every role and every state listens to BPDUs all the time. Whether it processes the received BPDUs depends on whether the BPDU is superior or inferior to the port's own BPDU. But it is the process of listening to BPDUs that actually makes each port to stay in its role and state.

A port moves from blocking to listening if the port is on its way to the forwarding state

Yes, that is true.

A root port will wait max age timer before considering itself as the  root port and force each ports of the switch in the listening state.

Not correct. You are confusing the root port and the root bridge here. Correctly, it should state: If a root port does not receive superior BPDUs for max_age seconds, the entire switch will start considering itself as a new root. As a result of this event, all ports on the switch will be put into Listening state.

Does switch C immediately change the DP into RP without waiting for any timer as soon a superior BPDU is received.

Yes, it does. However, even though it is clear that the port will be the root port after receiving the first BPDU (which will obviously be the best among all BPDUs received), it will fall back from Forwarding to Listening state and will have to go over the Listening->Learning->Forwarding sequence. So - the role would be changed immediately but the state will not remaing Forwarding, rather, it will go the beginning state of Listening (note, the Blocking state is not the starting state in STP - the Listening is).

Does switch D immediately change the DP into a block port without any timer as soon a superior BPDU is received.

Yes, it does. The port will not become the new root port on switch D, and when comparing to switch C, its own BPDUs are inferior. Such a port is superfluous in a spanning-tree topology, and will be blocked immediately.

If the failure does not affect switches 5 & 6, is it possible that  communication between Host A and Host B is affected because of the  reception of the TC BPDU that will reduce the MAC aging time to 15  seconds of the MAC table? In other words, can we loose packets between  Host A & B because of a failure that does not directly affect these  host.

No, we will not loose any frames. Even if the MAC address table was completely erased (which is something that RSTP does, in a judicious manner), the frames would be flooded through all ports except the incoming port, and would still be delivered to the intended recipients. Shortening the aging time helps us to remove the outdated and incorrect entries while maintaining the reachability of all other stations thanks to the nature of Ethernet switches (flood all frames with unknown/multicast/broadcast destination MAC to the entire network). Hosts A and B would at most see more frames delivered than usual, because of the flooding.

Can I say that a switch that receive a BPDU Message Age of 2 will  display a timer message age that vary between 0 and 18 when I am using  the command show spanning-tree for the interface receiving the BPDU.

This information is not reported as far as I know. What you see is a message age, and the BPDU on that port would expire in (max_age - message age) seconds, but this expiration time is not displayed. See the following output, for example:

 Port 24 (GigabitEthernet0/24) of VLAN0001 is root forwarding 
   Port path cost 4, Port priority 128, Port Identifier 128.24.
   Designated root has priority 32769, address 0009.e8ee.02c0
   Designated bridge has priority 32769, address 001b.8f8f.de00
   Designated port id is 128.45, designated path cost 4
   Timers: message age 2, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 8, received 3110863

Best regards,

Peter

[lgijssel]

Can somebody confirm me that a forwarding port only applies to a designted port or if the root port really transition to listening when it does not receive any BPDU:

No, all ports of a switch running STP are normally in forwarding mode as long as there is no loop.

Ports connected to hosts will not receive BPDU's, this causes them to move to forwarding.

Only ports which are receiving BPDU's can move to a different state.

The designated port is the port which is sending BPDU's onto a segment and hence it is always forwarding. When the topology contains a loop, another port than the designated port will be blocking. The designated port may change when a different root is elected.

Loopguard:  In case of a unidirectional failure, a blocking port may move to forwarding and create a loop.

The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop.

This does not interfere with the root election process.

regards,

Leo