Rapid STP

Protocols of the STP family are usually slightly disturbing the minds of engineers. And for the most part on the Internet, most often you come across the details of the maximum protocol STP. But time does not stand still and the classic STP is less and less common in work and in various vendor materials. The idea came up to do a short review of the key points of RSTP in the form of a FAQ. Anyone who is interested in this question, I ask for a cat.

What to configure STP, RSTP or MST?

In modern standards, the STP protocol does not appear anywhere. Known to everyone in the latest version of 802.1d ( 802.1d-2004 ) describes the RSTP protocol. At the same time, MST migrated to 802.1q ( 802.1q-2014) As we recall, earlier RSTP was described by the standard 802.1w, and MST - 802.1s.

RSTP and MST have significantly shorter convergence times. They rebuild the network topology much faster in the event of equipment or communication channel failure. The convergence time for a series of failures of these protocols is less than 1 second versus 30+ seconds in the case of STP. Therefore, the classic STP is recommended to be used only where old equipment is used that does not support more modern protocols.

MST uses RSTP algorithms in its work. But unlike RSTP, MST allows you to create a separate STP topology (instance) for a group of VLANs. In the case of the usual RSTP, we have one common topology for all VLANs. This is not very convenient, since it does not even allow manual balancing of traffic on different channels. This means that we lose at least half the bandwidth in the case of redundant paths.

Some vendors (in particular Cisco) offer another kind of fast STP protocol - Rapid Per-VLAN Spanning Tree (PVRST +). In this case, for each virtual network its own topology is built, which allows more efficient utilization of channels. The main disadvantage of this approach is the restriction on the maximum number of such topologies. To ensure the operation of each topology, the device spends hardware resources. But they are not unlimited. For example, a maximum of 128 STP instances are supported on Cisco 2960 switches.

Thus, MST is a good alternative between standard RSTP and proprietary PVRST +. Especially if our network is built on the basis of switches from different manufacturers. It is worth noting that all three variations of fast STP are compatible with each other.

In the future, mentioning RSTP, we will mean, among other things, its extensions MST / PVRST +.

What technologies provide quick response in RSTP?

RSTP primarily relies on the work of mechanisms that are not tied to standard timers. That is why it allows you to get significantly less network convergence time. The following improvements in the performance of RSTP compared to the classic STP can be distinguished:

1. Generate BPDU messages by each device, regardless of the root switch.
   
   In the classic version, BPDU "generates" only the root switch on the network. All other devices only relay it. Thus, the absence of a BPDU from the upstream device means that the problem can be anywhere between this device and the root switch. Therefore, I had to wait long enough (MaxAge = 20 seconds) before, to come to terms with the fact that something went wrong and you need to rebuild the topology.
   
   In the case of RSTP, BPDUs began to act as Hello packets. Now the loss of three such packages (and this is 2 * 3 = 6 seconds) means that it is time to think about changes in the topology.
   
   
2. The Proposal / Agreement mechanism when a point-to-point connection is activated on non-Edge ports for a quick transition to the Forwarding state.
   
   
   Note

   RSTP provides two types of connection:
   

   • point to point ( point-to-point ) - the only one RSTP switch is connected to a port;
     
   • general ( shared ) - several RSTP switches are connected to such a port (via a hub, which in our time is a big exotic).
     

   
   Typically, switches determine the type of connection automatically, based on the transmission mode full-duplex (point-to-point) or half-duplex (general). In the case of a shared connection, the "chips" of RSTP stop working.
   
   
   In the classic STP, the port, which should become the root, goes through all the stages of transition to the transfer mode (Listening → Learning → Forwarding), which takes more than 30 seconds.
   
   Before touch Proposal / Agreement mechanism, it should be noted the two different types of ports in RSTP: Edge port ( Edge port ) and the border ( non-Edge port ). In the Edge port, terminal devices (PCs, servers, in some cases routers, etc.) are connected. Other switches participating in the STP topology are connected to the non-Edge port.
   
   
   Note

   Edge port type is set manually. The switch cannot quickly determine who is connected to it: a regular host or switch. Of course, he could focus on the presence of BPDUs on this port. But according to the standard, the switch must always wait at least 15 seconds (Forward delay) before deciding that no message has arrived on its port. And this is too long. Therefore, the right to determine what is connected to the port was entrusted to a person.
   
   On Cisco switches, the edge port type is specified by the spanning-tree portfast command .
   
   
   RSTP uses the Proposal / Agreement mechanism to quickly switch ports from the Discarding state to the Forwarding state. This mechanism starts when the switch changes the Root Port (at least when connected to the network). In this case, it turns off all ports that are not Edge ports. This is notified by a higher-level switch (where Root port is just looking), after which it switches on only Root port to Forwarding mode. The remaining ports (not Edge) are in a blocked state until one of two things happens:
   
   
   • the switch exchanges Proposal / Agreement messages with the downstream switch,
   • Discarding to Learning (15 sec) and Learning to Forwarding (15 sec) timers will expire if the connected equipment does not support RSTP.
     
   
   A Proposal message is sent by a port that wants to become Designated for this network segment. And it actually launches the Proposal / Agreement mechanism. An Agreement message is sent by the port that becomes the root (Root). It is necessary to notify the superior device about the ability to immediately put the port in the Forwarding state.
   
   
   
   
3. Alternate port mechanism in case of loss of communication through the root port.
   
   RSTP differs from STP in that the state of the port is untied from its role. This made it possible to describe the role of the port in the network topology without regard to its state. So, to have the best vision of the network topology and the ability to quickly respond to changes in it. So there were alternative (alternative) and reserve (backup) ports. An alternative port is to replace the root. A root switch can be reached through it, but at the same time, this port does not have a root role (i.e., receives BPDUs with the worst metric) and is not assigned (i.e., it is not the best in this network segment for reachability of the root device).
   
   In RSTP, the alternate port enters the transfer state immediately after the root port fails. The same behavior can be achieved in the classic STP, using proprietary improvements. For example, Cisco offers UplinkFast technology for these purposes.
   
   
   
   
   
4. The mechanism of immediate reaction to receiving BPDUs with information about the “worst” root switch from a neighbor having a designated port for a given network segment.
   
   In this situation, if the device has a different route to the root switch, in the classic STP port, which was previously blocked, it will go through all the stages and switch to transfer mode after only 50 seconds (MaxAge + 2x Forward Delay).
   
   In the case of RSTP, the switch will immediately evaluate the received BPDU (there is no MaxAge timer in RSTP) and will start transmitting its own by setting the Proposal flag. Having received such a BPDU, the switch that has lost contact with the root will take part in the Proposal / Agreement mechanism, since its root port has changed. And then, rather quickly enough, the ports on both switches will go into a transfer state.
   
   
   
   
5. Improved TCN BPDU message distribution and processing scheme for network changes.
   
   Classic STP believes that the topology has changed if the port has transitioned from a locked state to a transfer state or vice versa. Since changing the topology can cause MAC addresses to be accessible through other ports (which means that the switch will send packets to the wrong place), the procedure starts for notifying all devices about such an event. For this, a Topology Change Notification (TCN) message is sent. Upon receiving which, the switch changes the aging time of MAC addresses from the default value (300 sec) to 15 sec (Forward Delay). The TCN message is sent in two stages. First, the switch that detects changes in the topology sends it to the root switch. Next, the root switch, having received such a message, finds out about the change in the network and sends a TCN message (BPDU with the corresponding flag) to everyone else.
   
   In the case of RSTP, a change in the topology is considered to be only a port transition to transmission mode. Moreover, ports that are not borderline (non-edge port) are taken into account. This is logical, since the port goes into a blocked state automatically makes the MAC addresses behind it no longer available. As soon as a topology change is detected, the switch sends out all the ports (root and designated) BPDUs with the TC flag. Such a message quickly spreads across the network. Upon receiving it, the switches remove from the table all MAC addresses accessible through non-edge ports, except where BPDU with the TC flag was received.
   
   The edge port never causes changes in the topology, and MAC addresses are not reset for such a port if a BPDU with the TC flag is received.
   

Why does RSTP sometimes “slow down” and put the port into traffic transfer mode only after a few tens of seconds?

RSTP uses normal timers in its work in the following cases:

• A device that supports only the classic STP is connected to the port. In this case, the switch port switches from RSTP mode to STP mode. So it goes through all the standard stages for STP: Blocking, Listening, Learning, Forwarding (depending on what values ​​of the root switch and cost BPDU will be received).
  
  
• The switch defined the connection as shared. In this case, standard RSTP timers are used. Since two or more switches are connected to such a port, it is impossible to use the Proposal / Agreement mechanism.
  
  
• A device that is not involved in STP is connected, and the edge type is not set on the port. In this case, the port will go through the following stages of RSTP: Discarding (15 seconds), Learning (15 seconds), Forwarding. Thus, it will only go into transfer mode after 30 seconds.

Why is setting the type of Edge port more important for RSTP than for STP?

The division into ports of Edge and non-Edge is characteristic not only for RSTP, but also for STP. But in the case of STP, this is a vendor refinement of the protocol, rather than the requirements of the standard.

The main “FOR” inclusion on the Edge mode port (for Cisco equipment it is portfast) in the case of using the STP protocol:

• Fast port switching to transfer mode (Forwarding). The port in this case does not go through the standard stages based on timers. This is important if regular equipment is connected to such a port. For example, a server or PC.
• There is no reduction in the aging time of the MAC addresses at that port when a TCN message is received. This means that packets are less likely to be dropped for hosts that listen more than they send something.

For RSTP, in addition to the points mentioned above, there is one more characteristic of this protocol only:

• When the Proposal / Agreement mechanism is triggered, all non-Edge ports are blocked. This means that if we do not configure the regular port where the terminal equipment is connected to Edge mode, the switch will turn it off for 30 seconds (RSTP timer work) each time the root port changes. In simple networks, this does not happen often. But relatively large is easy. This is just the case when it seems that the rebuilding will happen on the network quickly enough, and no one will even notice it. And in fact, the devices "fall off" from the network for half a minute.

Thus, we can conclude: for RSTP, the lack of Edge-port configuration is more critical than for the classic STP.


If the network is multi-vendor, and part of the equipment does not support STP at all in any way, will everything be bad?

This question is not entirely related to the work of RSTP, but still I decided to include it. Oddly enough, similar questions periodically arise at our customers. Therefore, it makes sense to dwell on it.

If the switch does not support STP in any form, what will it do with BPDU packets? The answer is simple - transmit such packets through all ports. As the destination MAC address, the BPDUs of the STP and RSTP packets set the address 0180.C200.0000, which is a multicast address. Such a BPDU packet is transmitted within VLAN 1.


Another interesting point is that even if we exclude VLAN 1 from the trunk between the switches, BPDUs for the first VLAN will still be transmitted.

As a result, if in our topology there is a switch that does not support STP, it will look like a regular communication channel for the STP topology.


And what happens if you connect two ports together on switch SW1 (i.e. make a ring). Will our network die? There is a big chance that not. In this case, Root SW will receive its own BPDU on the same port from which it was sent. After that, he will immediately block it. And the loop will remain “live” only within the switch SW1. But a positive outcome is possible only if the Root SW does not “choke” ahead of time from the broadcast storm that appeared due to the loop on SW1. Therefore, it is better not to use switches that do not support STP on the network.

Does STP / RSTP / MST / ... need a network if there are no loops?

Of course. If there is no loop now, it is not a fact that it will not appear in the future. For example, due to a simple human error when one access port of a switch is connected to another access port of the same device.

This FAQ is not intended to be exhaustive. It is more of a fact-finding character and sets a vector for further research on a particular issue related to the work of modern protocols of the STP family.