STP: Rapid PVST+ configuration

The iEEE 802.1w standard was developed using the main concepts of 802.1d (Common Spanning-Tree) but with a faster convergence time. It can be applied to single or multiple instances per vlans, but to apply it to multiple instances RSTP is used with Cisco’s proprietary PVST+ mechanism, the result is called Rapid PVST+ (RPVST+).

The calculation of the topology starts with the election of the root bridge in the same way as 802.1D, once assigned the roles of the ports can be:

  • Root: port of the switch with the lowest total cost to the root bridge of the topology.
  • Designated: Port of the network segment or link (collision domain) with the lowest total cost to the root bridge of the topology.
  • Alternate: A port that has an alternate path to the root bridge. This path is less desirable than the root port.
  • Backup: A port that provides a redundant (but less desirable) connection on a segment where another switch port is already connected and operating. For example, when we have two links between the same switches, one of them is the backup of the other.

Each of the port roles can go through the following states:

  • Discarding: MAC addresses are not known and frames are discarded. (This state combines the 802.1D Disabled, Blocking and Listening states. The Listening state is not necessary because RSTP can quickly negotiate a state change without first listening for BPDUs).
  • Learning: incoming frames are dropped, but MAC addresses are learned.
  • Forwarding: incoming frames are forwarded according to the MAC addresses that have been (and are being) learned.

RSTP uses the 802.1D format of BPDUs for backward compatibility but with modifications to some fields. However, some previously unused bits are used in the Type field of the message. In the BPDU version field a value of 2 is assigned to differentiate them from 802.1D BPDUs (Version 0 is to identify Common Spanning-Tre 802.1D).

Unlike 802.1D where only the root bridge can generate BPDUs, with 802.1w each of the switches in the topology sends its own BPDUs with its current information every hello timer (2 seconds is the default), even if it does not receive any from the root bridge.

With RSTP if a switch does not receive three consecutive BPDUs (6 seconds) it considers the neighbor as inactive, this fast aging of information allows fast fault detection. In normal STP you had to wait for the MAX AGE timer (20 seconds) to consider it inactive.

RSTP takes a different approach based on the STP topology, to achieve fast convergence on a port, the protocol relies on two new variables: edge ports and link type. When RSTP detects a failure in the existing topology, RSTP bases its forwarding decisions on port type. The two new features are:

Edge Port: The edge port concept basically corresponds to the PortFast function. All ports directly connected to end stations cannot create bridging loops in the network. Therefore, the edge port transitions directly to the forwarding state bypassing other states. Neither edge ports nor PortFast-enabled ports generate topology changes when the link is toggled. An edge port receiving a BPDU immediately loses the edge port state and becomes a normal spanning tree port.

The link type is defined by the duplex operation of the port:

Point-to-point: any port that connects switch and becomes a designated port. A quick acknowledgement with the neighboring switch defines the port state instead of typical timers. BPDUs are exchanged in the form of a proposal and an agreement. One switch proposes that its port become a designated port; if the other switch agrees, it responds with an agreement message. Point-to-point ports are automatically determined by the duplex mode in use. Full duplex ports are considered point-to-point, so that STP convergence can occur quickly through RSTP hello messages.

On the other hand, half duplex ports are considered to be on a shared medium and cannot be point-to-point. STP convergence on a half-duplex port must occur between several directly connected switches. Therefore, traditional 802.1D-style convergence must be used. This results in a slower response because the shared media ports must go through fixed Listen and Learn state time periods (30 seconds total).

RSTP handles the full STP convergence of the network as a propagation of the handshake over the point-to-point links. When a switch needs to make an STP decision, a handshake is performed with the nearest neighbor. When that is successful, the handshake sequence moves to the next switch and so on, like an ever-expanding wave moving out to the edges of the network.

During each handshake sequence, a switch must take steps to fully guarantee that it will not introduce a loop before moving the handshake out. This is done through a synchronization process.

To achieve proper convergence RSTP uses flags for port state negotiation based on the port type of the link. As mentioned before we will talk about the proposal and agreement flags.

RSTP works differently on full duplex (point-to-point) and half duplex (shared) interfaces. A point-to-point interface uses the proposal and agreement flags. On the other hand, shared interfaces do not use the above flags and their port state negation is carried out like the normal spanning-tree, 802.1D, i.e. we lose the RSTP features.

 

Agreement and proposal:

  • Proposal: This is a flag that is sent on (1) when the switch is started and is considered as a root bridge.
  • Agreement: This is another flag that is turned on in the BPDU, because it has been detected that there is a neighboring switch with lower priority and for this reason the neighboring switch is the root bridge or knows a new root bridge without the need to be directly connected to it.

The combination of these flags in the sending of BPDUs between two switches speeds up the convergence of the network, because when exchanging BPDUs of a switch with the proposal flag activated and the BPDU of the other switch with the agreeement flag activated, the interface is immediately forwarded, thus avoiding the learning state.

 

Synchronization process of a new Root Bridge

  • If the BPDU sent with the proposal has a better Bridge ID than the root, the switch realizes that it is connected to a root bridge and its port must be root.
  • All non-edge ports are moved to discarding state (i.e. where other switches are connected).
  • A BPDU with the agreement bit is sent to the new root bridge and the port goes to forwarding state.
  • For each of the non-edge ports that are in the discarding state, a BPDU with the proposal bit set is sent, saying that it has found the new root bridge and replicates it to all neighboring switches.
  • The process is repeated until all switches in the topology are synchronized.

Topology changes

  • RSTP detects a topology change when a non-edge port changes its status to forwarding.
  • The switch that detects the change sends a BPDU with the TC flag on all non-edge ports. The switches that receive the BPDU with the TC flag also send a BPDU with the TC flag. This is done for 4 seconds on each switch.
  • All MAC addresses associated with the ports where the BPDU with the TC flag is sent remove the MAC addresses associated with those ports.

By default cisco switches work with pvst+ which corresponds to 802.1D, to enable RSTP (Raid PVST+) it is necessary to configure the following command:

Switch(config)# spanning-tree mode rapid-pvst

Ports connected between two switches are usually set to full duplex but may operate in half duplex. To force the port to act as a point-to-point link use the following command:

Switch(config-if)# spanning-tree link-type point-to-point

To configure an Edge RSTP port, it is only necessary to specify the portfast command:

Switch(config-if)# spanning-tree portfast

 

For more information:

https://www.cisco.com/c/es_mx/support/docs/lan-switching/spanning-tree-protocol/24062-146.html

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-2_2_e/layer2/configuration_guide/b_layer2_1522e_2960x_cg/b_layer2_1522e_2960x_cg_chapter_01.html#d25e232a1635

Leave a Comment

Your email address will not be published. Required fields are marked *

en_US