When using RSTP, the transition of the port from Alternate to forwarding will go much faster. That’s why this protocol is called Rapid STP.

There are many differences between the classic STP and the RSTP. However, in the case where in the same network you are using in some MikroTik Switch the STP protocol and in some others you are using the RSTP, then the STP will be the one used on all the Switches.

If we compare STP and RSTP, you will see many differences as following:

You see that on the RSTP, the Blocking and Listening become Discarding on the RSTP.

Another difference is that there is no more timer for the port to move from the blocking state to the forwarding as we have seen on the STP. There is another mechanism called the negotiation process (which is out of the scope of this course) in which it makes the transition to go much faster. 

Another difference between STP and RSTP is that in the RSTP the BPDU’s are sent every 2 seconds as keep-alive, and in case he doesn’t hear from the neighbors after 6 seconds then he will believe that the neighbor is down and will remove from its MAC address table all MAC addresses learned from the neighbor.

Now we have a basic idea about RSTP, let’s apply it on a LAB to see what is going to happen with the failover.

[mepr-show rules=”319″ unauth=”message”] 

LAB: Rapid STP

I am still using the same LAB scenario that I have used on the STP LAB. Now everything is back to what it was before, and SW1 is the root bridge.

We need to change the protocol from STP to RSTP on all 3 Switches (by default, RSTP is enabled on the MikroTik CRS switches).

Now RSTP has been enabled on all switches.

Let’s see SW1 if it is the root bridge and the state of its interfaces.

Then SW1 is the root bridge and all its interfaces are designated ports. Let’s see the states of the interfaces on SW2:

Very good, as I was expected. Last one, we check SW3 interfaces states to see if Ether3 is on Alternate state.

Indeed, Ether3 is on Alternate state.

Now, with RSTP we can use Edge Port. The Edge port should be enabled only on ports that are connected to end devices and not to other switches. What the Edge port will do, it will make the port go to the forwarding once you connect the end device to it. In our scenario, we have to do it on Ether23 on SW2 where PC2 is connected and on Ether5 of SW3 where PC1 is connected.

I will start with SW2.

I will also do it on Ether5 of SW3.

While enabling the Edge port, you may have noticed Point to Point. This has a function for the ports which are connected from a switch to another switch. When you enable the Point to Point on a Switch, then you say to the switch that you are connected to another switch port that is working on a full-duplex mode. By default, it is on auto and most likely it is enabled, but it is a good practice to enable it to ports that are connected to other switches.

The last thing that I want to do is enable BPDU Guard on Edge ports. As the edge ports are ports connected to end devices, then I should not receive BPDU’s from them, correct? So once I enable BPDU guard, in case on that interface I receive a BPDU then the interface will go directly down. A lot of hackers use some emulation software on their PCs and start sending BPDU’s with a low priority to become the root bridge, then all traffic of the network will pass via their PC, and they can intercept everything happening in the network. That’s something we need to avoid. So let me enable BPDU guard on Ether23 of SW2 and Ether5 of SW3

Excellent!!!!

Now I am ready for the test. I will issue again an extended ping from PC1 to PC2, then I will disable the port Ether2 on SW3 and will see how long it takes for the network to be operational again.

Let’s open the ping now:

Now I will disable Ether2 interface on SW3

If I look to the ping, I don’t even have a single request timed out.

Wow!!!! That’s amazing how RSTP works and solves our issue with a late transition when using the classic STP. That’s the reason why MikroTik uses RSTP as the default one on their Switches.

[/mepr-show]