Rapid STP

Protocols of the STP family usually slightly excite the minds of engineers. And for the most part on the Internet, you most often come across the details of how STP works. But time does not stand still and classic STP is less and less common in work and in various vendor materials. The idea was to make a small overview of the key points of RSTP in the form of a FAQ. Anyone who is interested in this question, please under the cat.

What to configure STP, RSTP or MST?

In modern standards, the STP protocol does not appear anywhere else. Known to all 802.1d in the latest edition ( 802.1d-2004 ) describes the RSTP protocol. At the same time MST migrated to 802.1q ( 802.1q-2014 ). As we remember, earlier RSTP was described by the standard 802.1w, and MST - 802.1s.
')
RSTP and MST have significantly less convergence time. They are much faster rebuild the network topology in case of failure of equipment or communication channels. 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, classic STP is recommended to be used only where old equipment is used, which does not support more modern protocols.

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

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

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 also include its MST / PVRST + extensions.

What technologies provide quick response in RSTP?

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

1. BPDU generation of messages by each device regardless of the root switch.
   
   In the classic version of BPDU, only the root switch is “generated” on the network. All other devices only relay it. Thus, the absence of a BPDU from the upstream device means that there may be a problem anywhere between this device and the root switch. Therefore, we had to wait long enough (MaxAge = 20 seconds) before accepting the fact that something went wrong and you need to rebuild the topology.
   
   In the case of RSTP, BPDU messages have become the role of Hello packets. Now the loss of three such packages (which is 2 * 3 = 6 seconds) means that it is time to think about changes in the topology.
   
   
2. Proposal / Agreement mechanism when a point-to-point connection is activated on non-edge ports for fast transition to the forwarding state.
   
   
   Note

   RSTP provides two types of connections:
   

   • point-to-point — only one RSTP switch is connected to this port;
     
   • shared ( shared ) - several RSTP switches are connected to such a port (through a hub, which is a big exotic nowadays).
     

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

   Edge port type is set manually. The switch can not quickly determine who is connected to it: a normal host or switch. Of course, he could focus on having a BPDU on this port. But according to the standard, the switch must wait at least 15 seconds (Forward delay) before deciding that no message has come to its port. And this is too long. Therefore, the right to determine what is connected to the port is entrusted to the person.
   
   On Cisco switches, the Edge port type is specified by the spanning-tree portfast command .
   
   
   RSTP uses the Proposal / Agreement mechanism to quickly move ports from the state of Discarding to the state of Forwarding. This mechanism starts when the Root Port of the switch changes (at least when it is switched on in the network). In this case, it turns off all ports that are not edge ports. This is indicated by the upstream switch (where the Root port is looking at), after which only the Root port is included in the Forwarding mode. The remaining ports (not Edge) are in a locked state until one of two things happen:
   
   
   • the switch exchanges the Proposal / Agreement with the downstream switch,
   • transition timers will expire from Discarding to Learning (15 seconds) and from Learning to Forwarding (15 seconds) if the connected equipment does not support RSTP.
     
   
   The Proposal message is sent by the port that wants to become Designated for this network segment. And it actually starts the Proposal / Agreement mechanism. Agreement message is sent by the port, which becomes the root (Root). It is necessary to notify the upstream device about the possibility of immediately transferring the port to the Forwarding state.
   
   
   
   
3. The mechanism of the alternative port in case of loss of connection through the root port.
   
   RSTP differs from STP in that the port state is untied from its role. This allowed us 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. Alternative port - replace the root. Through it, the root switch can be reached, but this port does not have the role of the root (i.e., receives BPDUs with the worst metric) and is not designated (i.e., it is not the best in this network segment to reach the root device).
   
   In the RSTP protocol, the alternative port enters the transfer state immediately after the root has failed. The same behavior can be achieved in classic STP using proprietary improvements. For example, Cisco offers UplinkFast technology for this purpose.
   
   
   
   
   
4. The mechanism of an immediate response to receiving BPDUs with information about the “worst” root switch from a neighbor with a designated (designated) port for this network segment.
   
   In such a situation, if the device has another route to the root switch, in the classic STP port, which was previously blocked, will go through all the stages and switch to the transfer mode only after 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 begin to transmit 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, the ports on both switches will go into the transfer state.
   
   
   
   
5. Improved distribution and processing of TCN BPDU messages about changes in the network.
   
   Classic STP believes that the topology has changed if the port has moved from the state blocked to the transmission state or vice versa. Since a topology change may result in MAC addresses becoming available through other ports (which means the switch will send packets not there), the procedure for notifying all devices about such an event is launched. For this, a Topology Change Notification (TCN) message is sent. Having received that, the switch changes the aging time of MAC addresses from the default (300 sec.) To 15 sec. (Forward Delay). A TCN message is sent in two stages. First, the switch that detects changes in the topology sends it to the root switch. Further, the root switch, having received such a message, learns about the change in the network and sends the TCN message (BPDU with the corresponding flag) to everyone else. A two-tier scheme is necessary, since the BPDU in the classic version is sent only by the root switch.
   
   In the case of RSTP, the change in the topology is considered only the transition of the port to the transfer mode. Moreover, the ports that are not border (non-edge port) are taken into account. This is logical, since the transition of the port to the locked state automatically makes the MAC addresses behind it no longer available. As soon as a topology change is detected, the switch sends out all ports (root and assigned) BPDUs with the TC flag. This message quickly spreads over the network. Having received it, the switches remove from the table all MAC addresses accessible through non-edge ports, except where the BPDU was received with the TC flag.
   
   Edge port never causes changes in the topology, and for such a port, MAC addresses are not reset in case of receiving a BPDU with the TC flag.
   

Why does RSTP sometimes “slow down” and switch the port to the traffic transfer mode only after several tens of seconds?

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

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

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

The division into ports Edge and non-Edge is typical 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” switches on the Edge mode port (for Cisco equipment is portfast) in the case of using the STP protocol:

• Fast port switching to transfer mode (Forwarding). The port in this case does not pass the standard stages on the basis of timers. This is important if conventional equipment is connected to such a port. For example, server or PC.
• There is no decrease in the aging time of the MAC addresses behind such a port when receiving a TCN message. So, there is less likelihood of packet flushing for hosts that listen more than they send something.

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

• When the Proposal / Agreement mechanism is triggered, all non-edge ports are blocked. This means that if we do not configure the normal port where the terminal equipment is connected to in Edge mode, the switch will turn it off for 30 seconds (RSTP timer operation) every time the root port changes. In simple networks this does not happen often. But in relatively large. This is exactly the case when it seems that the rebuilds will occur on the network quickly enough, and no one will even notice. And in fact, the device "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 classic STP.


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

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

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


Another interesting moment is connected with the fact that even if we exclude VLAN 1 from the trunk between the switches, the BPDU 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 for the STP topology as a normal communication channel.


And what happens if you connect the two ports to each other 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 SW1 switch. But a positive outcome is possible only if Root SW does not “choke” ahead of time from a broadcasting storm caused by a loop on SW1. Therefore, it is better not to use switches that do not support STP in the network.

Do I need STP / RSTP / MST / ... on the network if there are no loops?

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

This FAQ does not claim to be complete. It is more of an introductory nature and sets a certain vector of further research on a particular issue related to the work of modern protocols of the STP family.