Implementing RSTP 3.2.7 Identifying the RSTP Proposal and Agreement Process In 802.1D, when a port has been selected by spanning tree to become a designated port, it must wait two times the forward delay before transitioning the port to a forwarding state. RSTP significantly speeds up the recalculation process after a topology change in the network, because it converges on a link-by-link basis and does not rely on timers expiring before ports can transition. Rapid transition to the forwarding state can only be achieved on edge ports and point-to-point links. In RSTP, this condition corresponds to a port with a designated role that is in a blocking state. Figure illustrates how rapid transition is achieved, as follows:
  1. Switch A has a path to the root via switch B and switch C. A new link is then created between the root and switch A, and both ports are in designated blocking state until they receive a BPDU from their counterpart. When a designated port is in a discarding or learning state (and only in this case), it sets the proposal bit on the BPDUs it sends out. This is what happens for port P0 of the root bridge.
  2. Switch A sees that the proposal BPDU has a superior path cost. It blocks all non-edge designated ports other than the one over which the proposal-agreement process are occurring. This operation is called sync and prevents switches below A from causing a loop during the proposal-agreement process. Edge ports do not have to be blocked and remain unchanged during sync.
  3. Bridge A sends an agreement that allows the root bridge to put root port P0 in forwarding state. Port P1 becomes the root port for A.
After switch A and the root bridge are synchronized, the proposal or agreement process continues on switch A out of all of its downstream-designated non-edge ports, as shown in Figure :
  1. Switch B on P5 will see that switch A is discarding and will also transition to the designated discarding state. Switch A then sends its proposal BPDU down to B with the root ID of the root bridge.
  2. Switch B sees a proposal with the superior BPDU from A and blocks all non-edge, designated ports other than the one over which the proposal-agreement process is occurring.
  3. Switch B sends a BPDU with the agreement bit set, and switch A P3 transitions to forwarding state. The synchronization process continues with switches downstream from B.
Content 3.2 Implementing RSTP 3.2.8 Identifying the RSTP Topology Change In 802.1D, any port state change generates a TCN. When an 802.1D bridge detects a topology change (TC), it sends TCNs toward the root bridge. The root bridge sets the TC flag on the outbound BPDUs that are relayed to switches down from the root. When a bridge receives a BPDU with the TC flag bit set, the bridge reduces its bridge-table aging time to forward delay seconds. This ensures a relatively quick flushing of the MAC address table. In RSTP, only non-edge ports moving to the forwarding state cause a topology change. Loss of connectivity is not considered a topology change, and a port moving to the blocking state does not generate a TC BPDU under those conditions. When an RSTP bridge detects a TC, it performs the actions outlined in Figure . The TCN is flooded across the entire network, one switch at a time, from the switch that is the source of the change rather than from the root bridge. The topology change propagation is now a one-step process. There is no need for each switch port to wait for the root bridge to be notified and then maintain the TC state for the value of the max age plus forward delay seconds. If the port consistently keeps receiving BPDUs that do not correspond to the current operating mode for two periods of hello time, the port switches to the mode indicated by the BPDUs.
Content 3.2 Implementing RSTP 3.2.9 Describing Rapid PVST+ Implementation Figure shows the most common Rapid PVST+ commands. Figure describes the commands.
Content 3.2 Implementing RSTP 3.2.10 Implementing Rapid PVST+ Commands Figures and describe how to configure PVRST. A variety of show commands can be used to display configuration and operation information about spanning tree. The show spanning-tree command displays information about the STP configuration. Without any arguments, it displays general information about all STP configurations. The complete syntax is as follows: Switch#show spanning-tree [bridge-group | active | backbonefast | {bridge [id]}| detail | inconsistentports | {interface interface interface-number} | root | summary [total] | uplinkfast | {vlan vlan-id} | {port-channel number} | pathcost-method] Refer to your software documentation for a complete explanation of each parameter.
Content 3.3 Configuring PortFast 3.3.1 Explaining MSTP The main purpose of MSTP is to reduce the total number of spanning tree instances to match the physical topology of the network and thus reduce the CPU loading of a switch. The instances of spanning tree are reduced to the number of links (that is, active paths) that are available. If the example in Figure was implemented via PVST+, there could potentially be 4094 instances of spanning tree, each with its own BPDU conversations, root bridge election, and path selections. In this example, the goal is to achieve load distribution with VLANs 1 through 500 using one path, and with VLANs 501 through 1000 using the other path, with only two instances of spanning tree. The two ranges of VLANs are mapped to two MSTP instances. Rather than maintaining 1000 spanning trees, each switch needs to maintain only two. Implemented in this fashion, MSTP converges faster than PVST+ and is backward compatible with 802.1D STP, 802.1w RSTP, and the Cisco PVST+ architecture. MSTP is not required if the Enterprise Composite Network Model is employed, because the number of active VLAN instances, and hence the STP instances, would be small and very stable. MSTP allows you to build multiple spanning trees over trunks by grouping VLANs and associating them with spanning tree instances. Each instance can have a topology independent of other spanning tree instances. This architecture provides multiple active forwarding paths for data traffic and enables load balancing. Network fault tolerance is improved over Common Spanning Tree (CST) because a failure in one instance (forwarding path) does not necessarily affect other instances. This VLAN-to-MSTP grouping must be consistent across all bridges within an MSTP region. In large networks, you can administer the network more easily and use redundant paths by locating different VLAN and spanning tree assignments in different parts of the network. A spanning tree instance can exist only on bridges that have compatible VLAN instance assignments. You must configure a set of bridges with the same MSTP configuration information, which allows them to participate in a specific set of spanning tree instances. Interconnected bridges that have the same MSTP configuration form what is called an MSTP region. Bridges with different MSTP configurations or legacy bridges running 802.1D form separate MSTP regions. In a Cisco PVST+ environment, the spanning tree parameters are tuned so that half of the VLANs are forwarding on each uplink trunk. This is easily achieved by electing bridge D1 to be the root for VLAN1-500, and bridge D2 to be the root for VLAN501-1000. In this configuration, the following is true: Note: The MST implementation in Cisco IOS Release 12.2(25)SEC is based on the IEEE 802.1s standard. The MST implementations in earlier Cisco