Rapid Spanning-Tree (RSTP)

Hi Rene,

What is the convergence time for RSTP compare to STP?

Regards,
Ajay

Hello Ajay.

In order to compare the convergence times of STP and RSTP, we must see what happens when a change occurs on a link. Here is how they differ. We always assume default values for timers:

STP
When a link goes down, STP waits for the Max Age time in order to consider a link down. The Max age is 10 times the hello timer and the time between hellos is 2 seconds. So it will take 20 seconds to consider a link down. At this point, the root bridge is reevaluated. If the original root bridge still has a connection to the network, it will receive Hello BPDUs and nothing will change. Otherwise a new root is elected. This can take several seconds.

Once this is done, the ports must be reevaluated as well. Root ports and designated ports are then chosen.

After the port roles are chosen, the root port will transition from Blocking to Forwarding. In order for this to happen, there are two stages in between (Listening and Learning). Listening has a duration of 15 seconds. During this time, no data packets are sent or received. Once this is done, the port transitions to the Learning (another 15 seconds) and then the Forwarding state. Assuming a new root and new root ports are selected, a single port may be inaccessible for at least 20+15+15 = 50 seconds during STP convergence.

RSTP
RSTP is faster. Thus the term Rapid STP. RSTP waits for 3 times the the Hello timer for a total of 6 seconds before a link is considered down. When a root port fails on a switch and a new root bridge has to be elected, RSTP momentarily blocks all its ports eliminating loops and thus eliminating the need for the Listening state, so we save another 15 seconds there. And the Learning stage is quick because the switch sends an RSTP proposal message immediately and receives one right away. So the port can go into forwarding state immediately. So under similar circumstances, RSTP can shorten the convergence time from 50 seconds to about 6-10 seconds.

Keep in mind that different topologies will have different results depending on which links go down. The above description should be used as a guideline, but it gives us very good insight into the differences one can expect with the use of the STP and RSTP.

I hope this has been helpful!

Laz

1 Like

Hi Rene,

I have a query. RSTP basically runs on port-fast or point to point links. In the above example , it was mentioned that all the interfaces in a switch is point to pint. In the above example interfaces of switch B connected to C and D should also be point to point links. But is is considered as non-edge port. Can you pls explain here?

Also can you pls let me know jthe diff between a designated and root port?

Regards,
Ananth

Ananth,
You are correct that RSTP requires P2P links for it to function. However, RSTP shouldn’t run on a portfast link, since the a portfast link should be turned only only on end-point devices and therefore shouldn’t have BPDUs on the link.

A switchport being classified as point-to-point vs shared is independent of its being classified as edge vs non-edge. Here’s a quick definition of each, since this might be useful:

Point-to-Point: A port that is operating in full duplex mode
Shared: A port that is operating in half duplex mode

Edge: A port that does not connect to any other “infrastructure” device, such as a switch. BPDUs should not be received on an Edge port.
Non-Edge: A port that connects to other switches or devices that send BPDUs.

Given the definitions above, in a properly functioning RSTP environment should have inter-switch connections classified as Point-to-Point Non-Edge ports.

The difference between a designated port (DP) and a root port (RP) has to do with which port is considered “closer” to the root bridge. A switch uses its root port as the path towards the root bridge, whereas the other side of the root port is the neighbor switch’s designated port. Almost always RPs and DPs are on different sides of the same link. Ports on the root bridge are always marked as Designated Ports

What is the RSTP convergence time in case of direct link failure and indirect link failure?

Nitesh,
There are too many variables involved to give a definite answer. Typically, you will see convergence from sub-second all the way up to 6 seconds (which is the default of 3 missed Hellos x 2 seconds per Hello). The reason it can be less is the active proposal mechanism that RSTP uses. The best generalized answer you will get will be: Indirect Link failure: about 6 seconds, Direct Link Failure: Less than 6 seconds.

You might want to check out the “So How Long Does it Take for RSTP to Converge” in the following article:
http://blog.ine.com/2009/09/07/rstp-and-fast-convergence/

I have a query.

In the above figure, Sw-A connected to Sw-B and SW-B is connected to Sw-C and Sw-D.
Step: When SW-B receive proposal packet from SW-A, SW-B starts Sync process on non-edge ports ( moves non-edge ports to designated /discarding).

Now my question is : with respective to above step, SW-B sending proposal flag in BBDU and send it to SW-C and SW-D and receive agreement flag set in BPDU from Sw-C and Sw-D and then send an agreement to SW-A, ( or ) first SW-B send the agreement to the SW-A and then send proposal to Sw-C and Sw-D.

Which will happen first ?

Hello Azeem

To answer your question, let’s go throug the steps:

  1. SW-B recognizes SW-A as the root bridge
  2. sync mechanism begins between SW-A and SW-B
  3. SW-A sends a BPDU with a proposal bit in the flag field
  4. SW-B blocks all non edge ports
  5. sync mechanism begins between SW-B and switches C and D
  6. once this sync mechanism begins (between SW-B and switches C and D), SW-B will send an agreement to SW-A and the interfaces between the two switches go to forwarding mode
  7. SW-B sends BPDUs with a proposal bit in the flag field to switches C and D
  8. Switches C and D send a response to the proposal with agreement BPDUs to C and D and all ports go to forwarding state.

So, SW B will first send the agreement to SW-A before sending the proposal to switches C and D.

I hope this has been helpful!

Laz

Can You Please clarify mine below Questions?
Question: 1:
------------
“The switch with the best bridge ID (priority + MACaddress) becomes the root bridge. The other switches (non-root) have to find the shortest cost path to the root bridge. This is the root port. There’s nothing new here, this works exactly the same for rapid spanning-tree.”

With this Statement, we understood that In RSTP, selection of Root Bridge is similar to STP.
1.In RSTP, I powered on 3 Switches, now all the 3 switches trying to select the Root bridge,In this process will they send proposal bit set in their BPDUs or not?
2. In RSTP, After Root bridge is elected, next in Root port selection, will they use (proposal/Agreement) negotiations or not?

Question: 2:
------------
In the above figure, the link between SW-A and SW-C is failed, now SW-C has two alternate ports Fa 0/16 and Fa 0/17.which port will choose as Root port ?
Ans: I am thinking lowest port no will chose as Root Port.( Fa 0/16). Please correct me.

Question: 3:
-----------

BPDUs are now sent every hello time. Only the root bridge generated BPDUs in the classic spanning-tree and those were relayed by the non-root switches if they received it on their root port. Rapid spanning-tree works differently
all switches generate BPDUs every two seconds (hello time). This is the default hello time but you can change it.
In my RSTP topology, I have three Switches up and running. SW_A->SW_B->SW_c->SW_A (triangle shape). SW_A is Root Bridge.
1.SW_A (Root Bridge) send BPDUs for every 2 sec. SW-B will receive BPDUs from SW_A. Now SW_B will forward this BPDUs to SW_C or not ?
2.If All Switches generate BPDUs every two seconds (hello time) ,SW_C have one Root port and one Altrnate Port, will SW_C send out BPDUs from (Altrnate port and Root Port) for every two seconds?

Question: 4:
-----------
TO clarify my understanding on (POrtFast / EdgePort). when RSTP is configured, by default EdgePort is enabled.

When a Host is connected to (RSTP configured Switch), the port will jump from blocking to forwarding and send 10 BPDUs to confirm the no BPDUs are receiving.
When a Host is connected to (RSTP configured Switch) and PortFast command is configured, the port will jump from blocking to forwarding. No BPDUs are sent out.

Question: 5:
-----------
If Switch receives BPDUs with TC bit set, It clears the MAC addresses learned on all its ports, except the one that receives the topology change.why it will not clear the MAC address entries on the received port ?

Please clarify my above questions.

Thanks,
Azeem

Hello Azeem! I will attempt to answer your questions one by one:

Question 1.1: In RSTP, I powered on 3 Switches, now all the 3 switches trying to select the Root bridge,In this process will they send proposal bit set in their BPDUs or not?

Selection of the root bridge in RSTP IS similar to STP. RSTP still uses the best bridge ID (Priority + MAC address) to determine the root bridge. And yes, the proposal bit will be set in their BPDUs. The purpose of the proposal bit however, is not to find the root bridge, but to allow for the sync process, that is, to verify that all ports of the switch are in sync with the fact that the root bridge has been determined.

Question 1.2. In RSTP, After Root bridge is elected, next in Root port selection, will they use (proposal/Agreement) negotiations or not?

Yes, proposal/agreement negotiations will occur after the root bridge is elected. Notice, that once the root port is selected, it remains in a blocked state until the rest of the ports go through the sync process. Once those ports complete the sync process, then the root port can be unblocked and a BPDU with the agreement bit set can be sent. (A port is considered in sync if it is either in the blocking state or if it is an edge port.) For more info on the sync process, check this link out: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html#agree

Question 2: In the above figure, the link between SW-A and SW-C is failed, now SW-C has two alternate ports Fa 0/16 and Fa 0/17.which port will choose as Root port? Ans: I am thinking lowest port no will chose as Root Port.( Fa 0/16). Please correct me.

First of all, I assume you are referring to the diagram in Rene’s lesson with the HUB connected in between switches B and C. If two or more ports on a switch may become root ports, such as in the scenario you describe in your question, they go through the following process to determine which will be the root port:

  1. The total cost to the root bridge. In the example you are describing, this is the same.
  2. Which port receives the lowest bridge ID from the neighbour it is connected to. In this case, both ports are connected to Switch B so both receive the same bridge ID.
  3. Finally, the RECEIVED port priority is used, that is the port priority that is being received in the ports on switch B. Just to clarify, this is not the port priority of the local ports, but of the ports to which each port is connected.

Having said that, if the network topology didn’t have the hub, and the Fa0/16 port of switch C was directly connected to the Fa0/16 port of Switch B and the same was true for the Fa0/17 ports, then, yes, the Fa0/16 would be chosen due to a default received port priority of 128.16. So, the answer to your question would be YES.

n my RSTP topology, I have three Switches up and running. SW_A->SW_B->SW_c->SW_A (triangle shape). SW_A is Root Bridge.
Question 3.1 SW_A (Root Bridge) send BPDUs for every 2 sec. SW-B will receive BPDUs from SW_A. Now SW_B will forward this BPDUs to SW_C or not ?

No, BPDUs from the root bridge are not relayed by the other bridges. This is why there is the proposal/agreement mechanism. In essence, when switch B for example is connected to switch A, they exchange BPDUs and determine that switch A is the root bridge. The sync process occurs on the rest of the ports on switch B and any switches connected to these ports will go through the same process. This creates a cascading effect away from the root bridge where each designated bridge proposes to its neighbours to determine if it can make a rapid transition. However, if a legacy STP BPDU is detected, RSTP will revert to legacy STP on that interface.

Question 3.2.If All Switches generate BPDUs every two seconds (hello time) ,SW_C have one Root port and one Altrnate Port, will SW_C send out BPDUs from (Altrnate port and Root Port) for every two seconds?

In RTP, Alternate ports are in a discarding state and root ports are in a forwarding state. Discarding state in RTP will not send BPDUs but it listens for BPDUs, while a port in forwarding state will transmit and receive BPDUs.

Question 4 TO clarify my understanding on (POrtFast / EdgePort). when RSTP is configured, by default EdgePort is enabled.
When a Host is connected to (RSTP configured Switch), the port will jump from blocking to forwarding and send 10 BPDUs to confirm the no BPDUs are receiving.
When a Host is connected to (RSTP configured Switch) and PortFast command is configured, the port will jump from blocking to forwarding. No BPDUs are sent out.

Almost! A port on a switch will be considered an edge port by RSTP under the following conditions:

  1. When portfast is enabled. If you enable portfast on a port, it is automatically an edge port.
  2. If the connection is full duplex, the switch will automatically assume it is an edge port.

The port will no longer be an edge port if one of the following occurs:

  1. If portfast is not configured and the port receives a BPDU. Under these circumstances, the port will no longer be considered an edge port
  2. If portfast is not configured and the link type is half duplex.

Question 5: If Switch receives BPDUs with TC bit set, It clears the MAC addresses learned on all its ports, except the one that receives the topology change.why it will not clear the MAC address entries on the received port ?

If a topology change is detected, a switch will relearn all of the MAC addresses from scratch in order to regain a fresh understanding of which MAC addresses can be found where. It does not however remove the MAC address of the device that sent the BPDU with the TC bit set to 1. This is because, since this BPDU was successfully received, the MAC address is still valid and can be kept.

I hope this has been helpful for you!!!

Laz

2 Likes

Thanks, Laz. Good information to learn and to get clarify the questions.

Hello Azeem.

Glad I could be of help!

Laz

19 posts were merged into an existing topic: Rapid Spanning-Tree (RSTP)

I have a doubt. You reported that when the switch is in rapid-stp (802.1) there is no need to configure UplinkFast and BackboneFast features, because it comes enabled by default.

However, to test I have a 2960 switch I changed the Spanning-Tree mode for Rapid Spanning-Tree, but the features BackboneFast, UplinkFast and remained disabled. Did I misunderstand? Could you explain that? I thank you in advance.

Segue a imagem em anexo para evidĂȘncias:

Hello Stafanio

UplinkFast and BackboneFast do not actually need to be configured because they are mechanisms that are included and enabled natively in the RSTP functionality. Whether or not they are enabled in the spanning-tree summary will not change the behaviour of RSTP.

I will ask @ReneMolenaar to clarify that in his lesson.

Thanks very much and I hope this has been helpful!

Laz

Consider this scenario: a non-edge port changed its status from blocking to forwarding. So that switch will start the topology change while timer, flush MAC table except the MAC address learned from the newly forwarding interface and forward BPDUs on all interface (Root port and Designated port).

The receiving switches will also follow the same mechanism and forward the TC BPDUs. Gradually TC BPDUs will reach the Root Bridge and the entire network (the RSTP NW).

My question is what will happen next? Will there be another election to select the Root Bridge? How the data transfer will happen again?

Hello rosna

The way you describe the scenario is correct. Now what happens next? The STP configuration is considered “Converged”. In other words, it has reached a stable state. The Root bridge will not be re-elected, it will stay the same. BPDUs will be exchanged at the normal intervals and all switches will perceive that the network is stable and does not change.

The only case in which a Root bridge will be elected is if the current Root bridge goes down and no more of its BPDUs are received by the other switches. Only then will a re-election take place.

I hope this has been helpful!

Laz

Hi guys,

I am a bit confused after reading all about STP and RSTP.
Can you please answer the following questions:

  1. Is the root election process for STP and RSTP the same? All switches send on all ports BPDUs in order to elect the root bridge? And all switches forward the received BPDUs to their neighbours?

  2. What ports do send and receive BDPUs after the root election process is done? I know for STP, only the root bridge generates BPDUs which are forwarded to the connected root ports and then the other switches(non-root) forward those BPDUs out of all ports(DP, Blocked)???

And how is it for RSTP once the root election process is completed? I know all switches send BPDUs. Out of all ports?

Thanks for your help!
Flo

How the port goes into blocking mode in RSTP. Is same as classic spanning tree based on cost.

Hello florian

Sorry for responding late to this question.

Yes, the election process does not change.

Yes this is also correct. This is done so that switches can compare their Bridge IDs and their priorities to decide who is the root bridge.

During the election process yes, unless you have configured specific ports not to participate in STP (by enabling BPDU Filtering for example).

For STP, once there is a converged spanning tree, only the Root bridge sends BPDUs and other bridges just relay these BPDUs. In RSTP, all bridges send a BPDU every hello time (default 2 seconds). These BPDUs are sent out all ports except those configured as portfast and those configured with BPDU filtering.

More information can be found at this Cisco documentation which includes additional differences such as the new Port States, port roles, BPDU format and the new topology change mechanisms.

I hope this has been helpful!

Laz