Spanning Tree Protocol

STP was defined by the Institute of Electrical and Electronics Engineers (IEEE) standard 802.1D. STP prevents broadcast storms by automatically and logically eliminating loops in an Ethernet network.

In the figure below, the network contains several loops, such as the loop formed by links A-B-C and links B-D-E. To eliminate loops, STP uses an algorithm described in the following paragraphs.

Figure 3. Network with Physical Loops

First, STP will select a root bridge. The root bridge is the logical center of the network. Root bridge selection is accomplished by exchanging messages called Bridge Protocol Data Units (BPDU) between the bridges, or devices, that make up the network. Each BPDU contains the originating device bridge identifier. The bridge that has the lowest bridge identifier becomes the root bridge. Once the root bridge is selected, preventing loops requires that one, and only one, bridge may forward traffic from the direction of the root onto any given link.

STP determines a designated bridge and designated port for each destination bridge. The designated bridge is the only bridge that is allowed to forward traffic from the root bridge to a particular destination bridge. The designated port is the port used to forward traffic away from the root to the destination bridge. The process of determining the designated bridge and designated port is accomplished by exchanging BPDUs. The BPDUs contain path costs, which are user configurable weighting that enable prioritization of one network path over another. The port associated with the link that has the lowest path cost becomes the designated port.

Figure 4. Designated Bridge and Port Selection

In the example above, all the physical links have a same cost of 10. Possible paths to forward traffic from device 1 to device 4 are C, A-B, and A-D-E. In this example path C would have a cost of 10, path A-B would have a cost of 20, and path A-D-E would have a cost of 30. Path C has the lowest cost, and therefore the port associated with that link will become the designated port.

Once the root bridge and designated bridges have been determined, STP breaks the loops by artificially disabling links. Disabling a link is done by putting the ports at both ends of the link into a blocking state. A port that is in a blocking state will not transmit or receive any traffic expect BPDUs. All ports, except designated ports and root ports, are put into a blocking state.

Figure 5. STP Enabled Network

The bridges along the designated links become the Spanning Tree.

Rapid Spanning Tree Protocol

Once the Spanning Tree has been established, STP monitors the network for failures and topology changes. Events that can cause the topology to change include bridge failure, link failure, new links, new bridges, or new bridge configurations. As these events occur, STP will automatically adapt the tree to the new topology.

If link D fails, as shown in the figure below, bridge 4 becomes the designated bridge for forwarding traffic to bridge 3. This topology change occurs by going through the entire Spanning Tree Protocol algorithm after the link failure. This process is called reconvergence.

Figure 6. Topology Change

STP was designed to support Enterprise networks where the recovery from a failure within several minutes is acceptable. However, Carrier Class service delivery and guarantees require reconvergence times of less than 200 milliseconds.

To improve the time necessary to reconverge, the IEEE defined a faster version of STP, 802.1w, called Rapid Spanning Tree Protocol (RSTP). The goal of RSTP was to make the reconvergence time close to one second, and possibly less.

This performance improvement was made possible by three categories of important enhancements:

• Faster detection of a topology change
• Simplified state machines. STP defines five port states, where RSTP reduces that number to a more efficient set of three states
• Simplified negotiation process between the bridges

Continue

• Part 1:
  Introduction/Broadcast Storms
• Part 2:
  Spanning Tree Protocol
• Part 3:
  LightningEdge Enhancements
• Part 4:
  Conclusion