The Spanning Tree Protocol (STP) prevents loops from forming in a switched network, but it does this task inefficiently by comparison with the processing capabilities of modern equipment. This article takes a look at the Rapid Spanning Tree Protocol (RSTP), which was designed to take over the duties of STP. RSTP was standardized in IEEE 802.1w (now integrated into IEEE 802.1D). It tweaks the way that STP works, in an effort to minimize converge times on switches, both on startup and on link failure. We’ll examine how RSTP improves on STP and how to configure it on a Cisco switched (IOS) device.
Rapid Spanning Tree Protocol Operation
Let’s take a look at the mechanics of how RSTP works. To make this a bit easier to follow, we’ll start with an analogy. Think of (R)STP as a control mechanism for stoplights in a city. Occasionally, it might be necessary for the city’s traffic department to reroute traffic from one street to another in an effort to decrease congestion. But what happens if one intersection’s controller isn’t connected with another intersection’s controller?
Take a look at the traffic pattern in Figure 1. It quickly becomes obvious that traffic in this scenario could potentially run in a continuous loop around the same city block. If enough cars were routed into this loop, traffic would eventually stop (quickly, in city traffic).
The initial duty of (R)STP is to form a relationship to the switched network on which it exists. If this is the only switch in the network, by default it would become a root bridge (or switch). This root bridge is elected initially within the STP network, and the rest of the network is built on that switch being the center of the switching universe. This also means that you don’t want the switch that gains this title to be on an edge switch, or on a switch that exists on a remote site.
Typically the election is fixed to make one of the central switches in a network the root bridge. When the election isn’t fixed, the root bridge is selected based on the priority of the switch. However, by default the priority of a switch is the same across all switches, so the second selection is made based on the bridge ID. The bridge ID is typically a hardware-encoded MAC address assigned to the switch by the manufacturer.
These priorities and bridge IDs are relayed through the exchange of Bridge Protocol Data Units (BPDUs), which are sent by RSTP every “hello” interval—by default, every two seconds. The bridge that has the superior priority or bridge ID is elected the root bridge.
A big difference between the original STP and RSTP is in how they converge. With the original STP, all of the switches must wait as the interfaces go through listening and learning port states (15 seconds each) before deciding which switch will become the root bridge and which interfaces will become root interfaces. With RSTP, a proposal and agreement (P/A) process is put in place, which is automatically used as soon as an interface comes up. This P/A process drastically shortens the time needed for an interface to move into a forwarding state. However, this process only happens on what RSTP calls point-to-point (p2p) links.
Cisco switches use the duplex setting of an interface to determine the link type. Interfaces with a full-duplex setting follow the P/A process; interfaces with a half-duplex setting go through the slower STP convergence process (30 seconds total) before converging. An exception to this rule is root ports, which are automatically pushed into a forwarding state when a switch is brought up. In RSTP, these half-duplex links are referred to as shared(Shr) links. RSTP also defines a third type of link, edge links; these ports operate like older Cisco PortFast ports and are automatically put into a forwarding state.
The port states are also referenced differently in RSTP. STP has five port states: disabled, blocking, listening, learning, and forwarding. RSTP combines those states into a total of three: discarding (disabled, blocking, listening), learning, and forwarding.