Thank you so much Laz!
1 Like
Hello Pradyumna
The first BPDU that SW1 sends to SW2 will contain the proposal bit set. This is the proposal message. Once this is sent, then the sync mechanism will begin to operate between the two devices. Remember that a blocking state (in all STP versions) will still listen to and respond to BPDUs.
I hope this has been helpful!
Laz
Hi
I just want to clarify how the negotiation mechanism works to confirm I understand it correctly.
In your example:
When SW1 and SW2 are connected, they both start in a discarding state. However, a discarding state in RSTP still sends and receive BPDUs, and the proposal bit will be set for both as they send BPDUs to one another. So far correct?
SW1 then inspects SW2’s BPDU and see’s it is inferior, so ignores it.
SW2 does the same and inspects SW1’s BPDU, but in this case sees it is superior, and block’s its non-edge ports, then sends the BPDU with the agreement flag set back to SW1. SW1 then starts forwarding traffic to SW2.
Now all SW2’s ports are blocked the above sequence begins again it’s neighbours.
Still correct so far?
However, what would happen if, for example, SW3 already had a connection directly to SW1?
In this situation, even though SW2 has put its ports into a blocking state it will still be receiving BPDUs from SW3 with information about it’s own connection to SW1, correct?
And SW2 will see SW3 has a connection with a cost equal to it’s own cost to the root bridge (which SW3 will prefer once local port cost is added). In which case, what happens next?
Does SW2 still send a BPDU with a proposal bit set - and if so, how does SW3 respond?
Or does SW2 understand that it’s neighbour has a preferred connection and simply sends BPDUs without the proposal bit set, at which point, the designated port for the segment is selected using the same rules as classic spanning tree. i.e. in this case, lowest bridge ID.
Basically, I am trying to understand what happens when a switch tries to negotiate with another switch that already has its own preferred path to the root bridge.
Thanks,
Sam
Hello Samir
Your description of the process is correct.
Correct.
Cisco states it this way:
When a designated port is in a discarding or learning state (and only in this case), it sets the proposal bit on the BPDUs it sends out.
This means that regardless of what it has received from the switch on the other end, the proposal bit on the BPDU is set to only in the cases mentioned. So in the scenario, you described, SW2’s port is indeed blocked initially, so it does send a proposal bit. SW3 will see this, but will also see that this is inferior to the one it received from SW1, so it keeps the root port as the one connected to SW1. SW3 informs SW2 with its BPDU and SW2 sees that its connection to SW1 is also the superior BPDU, so it keeps that as the root port.
So in essence, both SW2 and SW3 will still send out a BPDU with a proposal bit, and do the synchronization as normal, even if SW3 is already connected to SW1. The result will be that both switches will simply realize that the BPDUs they’ve received from SW1 are superior and they will keep those ports as the root ports.
I hope this has been helpful!
Laz
Hi, guys!
What exactly is a While Timer, and why does it have 2x the hello timer?
What a bridge will do if the While Timer expires?
Hello Marcus
The while timer in RSTP is used to quickly send BPDUs with the Topology Change bit set. Here is the process in detail.
- When a topology change occurs, the bridge that detects it will send out a BPDU with the TC bit set.
- When a bridge receives a BPDU with the TC bit set, it will start a TC while timer internally which is equal to 2x the hello timer. As long as the while timer has not expired, all of the BPDUs sent out from this bridge for that time period will have the TC bit set.
- Once the while timer expires, all subsequent BPDUs sent by the local bridge will not have the TC bit set.
- Every time a BPDU is received with the TC bit set, the while timer is started again, and the process continues.
The reasoning behind this is that as long as a bridge is receiving BPDUs with the TC bit set, it too will send out BPDUs with the TC bit set. If the while timer expires without receiving another BPDU with the TC bit set, that means that the topology has stabilized, and thus, it too will stop sending BPDUs with the TC bit set.
Why is it set to 2x the hello timer? Well, that’s because BPDUs are sent every hello time. Using a value of 2x the hello timer will ensure that at least one BPDU will be sent out by the local bridge with the TC bit set.
You can find more info about this process at this documentation:
I hope this has been helpful!
Laz
What’s the differnce between RSTP EdgePort to STP Portfast?
How to configure EdgePort?
Hello Haim
Simply put, EdgePorts for RSTP are essentially the same concept as a portfast port in STP. According to this Cisco documentation:
The edge port concept is already well known to Cisco spanning tree users, as it basically corresponds to the PortFast feature. All ports directly connected to end stations cannot create bridging loops in the network. Therefore, the edge port directly transitions to the forwarding state, and skips the listening and learning stages. Neither edge ports or PortFast enabled ports generate topology changes when the link toggles. An edge port that receives a BPDU immediately loses edge port status and becomes a normal spanning tree port. At this point, there is a user-configured value and an operational value for the edge port state. The Cisco implementation maintains that the PortFast keyword be used for edge port configuration. This makes the transition to RSTP simpler.
Both portfast and edge ports are configured using the portfast keyword. This was done in order to simplify transitioning from STP to RSTP.
I hope this has been helpful!
Laz
Is there a reason you would have RSTP and Classic Spanning tree both running in the same network? Im just assuming that was an example to show what would happen and not something you would want to do if you could avoid it.
Hello Paul
You are correct, this is simply an example of what would happen if you deployed STP with RSTP. In production networks, it is best practice to avoid the use of plain old 802.1D STP. The only situation in which you would have to use such an arragement is if you are using an old switch that doesn’t support any other version of STP. Even if this was the case, it would be best to replace such old hardware anyway.
I hope this has been helpful!
Laz
1 Like
I am from Germany. I have a question.
How does RSTP deal with link failure in compare with solution of STC (portfast, uplinkfast and Backbonefast) ?
Thanks
Khanh
Hello Khanh
WHen a link failure occurs in an STP or an RSTP topology, the mechanism that is used to reconverge and stabilize the topology is the Topology Change. STP and RSTP topology changes take place in different manners.
This topology change is described in detail in this lesson:
Specifically, you will find this explanation at the very end of the lesson. I’m not sure if I have responded to your question fully, so if there is any additional information you require, please feel free to clarify your question.
I hope this has been helpful!
Laz
Hello Laz
Thank you for your explanation. That is very helpful!
I have also found the answers in this article.
Thanks a lot
Khanh
1 Like
[BPDUs are now sent every hello time. Only the root bridge generated BPDUs in the classic spanning-tree]
Q1. Does only the root bridge generate BPDUs in classic spanning tree?
Q2. Classic Spanning Tree and RSTP both have a hello timer of 2 seconds. What’s different?
Q3. RSTP all bridges generate a BPDU every 2 seconds. What switches generate BPDUs under what circumstances in Classic STP?
Hello Yong Hun
Yes, that is correct.
Yes, both have a hello timer of 2 seconds. This does not change. (In the lesson, Rene states “BPDUs are now sent every hello time” but this wording can be misleading. I will ask him to change the wording to avoid confusion.)
In classic STP only the root bridge sends BDPUs, and they are relayed by non-root bridges. In RSTP, all bridges send BPDUs every hello time.
I hope this has been helpful!
Laz
at which situation we can see the port state > discard when we type
sh spann vl 10
because i didn’t see it before
if the switch in the listening state and receive bpdu can we see the word discard ?
Hello Hosam
The reason why you never see the discarding state is that the discarding state is there only momentarily. It’s not there for any extended period of time, so in order for you to issue the show command right at the moment when the discarding state is, it is very rare. This is one of the features that make RSTP rapid in comparison to STP, which maintained the listening state for 15 seconds before going to the learning state.
So it’s unlikely you will be able to observe that particular state, simply because it is in the discarding state for such a short period of time.
I hope this has been helpful!
Laz
Today, ive been reviewing this topic and i have a doubt about RSTP link failure.
I’ll extract two different excerpts of this lesson :
“With the classic spanning tree a link failure would trigger a topology change. Using rapid spanning tree a link failure is not considered as a topology change. Only non-edge interfaces (leading to other switches) that move to the forwarding state are considered as a topology change”
“Rapid spanning-tree works differently! BPDUs are now used as a keepalive mechanism similar to what routing protocols like OSPF or EIGRP use. If a switch misses three BPDUs from a neighbor switch it will assume connectivity to this switch has been lost and it will remove all MAC addresses immediately.”
My doubt is, whenever a non-edge stop receiving 3xhello bpdu (keep alive mechanism) it only does a mac add flush (all cam tbl) but not generate any BPDU TCN ?
Hello Juan
Yes, that’s exactly correct. If a port misses three hellos, the link is considered down. When a link goes down, either due to missed BPDUs or even if a cable is unplugged, no TCN is sent. Only when the BPDUs begin flowing again and the port is considered up again will a TCP be sent.
I hope this has been helpful!
Laz
1 Like
I have another 2 questions :
So in RSTP when a switch misses 3x bpdu from a neigh switch, the switch that stop receiving these bpdu do a complete flush of its cam table or only flush mac add previous learned from the port that misses these bpdu ?
and the other question is about the TCN mechanisn in RSTP :
from the lessson in understand the following :
a TC in RSTP is only when a non-edge port change to forwarding state, therefore the switch that has been detected this TC will generate a while timer ( 2x hello timer = 4 secs) , what is the purpose of that ? i mean when a port changes to forwarding and then the switch generates a BPDU with a timer set in 4 secs , in which bpdu field ? and this bpdu is sent out of all non-dsg ports to the others switches, except the port that changed to forwarding state ?
thanks in advance.