Spanning Tree – RSTP (802.1w)

802.1d has some downsides to it.  Namely, it was slow to converge to a new topology taking anywhere from 30 to 50 seconds to do so.  The main aim of RSTP is to make that convergence happen at a much faster rate.  In addition, RSTP standardizes some of the Cisco proprietary features of 802.1d such as portfast, uplinkfast, and backbonefast. 

To do this, RSTP defines/changes some of the port states that normal 802.1d used.  The 802.1w states are…

Root port – Same as 802.1d.  Best path cost to the root bridge

Alternate port – A backup root port.

Designated port – Same as 802.1d.  Best path cost for each network segment.  In 802.1w these ports are also referred to as point-to-point links.

Backup port – A backup designated port for a network segment. 

Edge Port – Connects to an end device.

RSTP also redefines the disabled and blocking port states into one state called ‘discarding’.  Discarding means that the port does not forward data frames and does not learn MACs.

RSTP uses a handshake process to create a loop free topology.  Much like the Cisco backbonefast feature used RLQs to talk to the neighbors and determine the STP topology the RSTP process works off of proposals and agreements.  A switch will generate these proposal and agreement messages to a directly connected switch when an interface initially comes up.  The sync process is easier understood with a quick diagram…

Let’s consider a simple topology with two switches…

The instant the two switches connect, each switch change their port states to be the designated port.  Directly after that, each switch sends the other switch a proposal.  We can see the port state of each switch in the switch debug…

Root Bridge
*Mar  1 01:12:24.023: setting bridge id (which=3) prio 24577 prio cfg 24576 sysid 1 (on) id 6001.000f.9065.4680
*Mar  1 01:12:24.032: RSTP(1): initializing port Fa1/0/2
*Mar  1 01:12:24.032: RSTP(1): Fa1/0/2 is now designated
*Mar  1 01:12:24.040: RSTP(1): transmitting a proposal on Fa1/0/2

Second Bridge
*Mar  1 01:12:24.308: setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.000d.2818.af00
*Mar  1 01:12:24.317: RSTP(1): initializing port Fa1/0/2
*Mar  1 01:12:24.317: RSTP(1): Fa1/0/2 is now designated
*Mar  1 01:12:24.325: RSTP(1): transmitting a proposal on Fa1/0/2

A packet capture on the link shows the proposals being transmitted…

Root Bridge

Second Bridge
 

Note how each bridge thinks that it is the root listing their own bridge ID as that of the root. 

 

The second bridge examines the BPDU it received and knows that it’s a better bridge ID.  It updates the port it heard the better BPDU on to it’s root port, generates a topology change notification, and sends an agreement to the root bridge…

*Mar  1 01:12:24.359: RSTP(1): updt roles, received superior bpdu on Fa1/0/2
*Mar  1 01:12:24.359: RSTP(1): Fa1/0/2 is now root port
*Mar  1 01:12:24.359: RSTP(1): synced Fa1/0/2
*Mar  1 01:12:24.359: STP[1]: Generating TC trap for port FastEthernet1/0/2
*Mar  1 01:12:24.367: RSTP(1): transmitting an agreement on Fa1/0/2 as a response to a proposal

The root bridge receives the agreement…

*Mar  1 01:12:24.048: RSTP(1): received an agreement on Fa1/0/2

At this point, the ports on both end can move into the forwarding state since the topology is in sync.  Now let’s look at what happens when we add two more switches to the topology…

Just like last time, the switches mark their new ports as designated ports, and exchange proposals.  The proposal that the second bridge transmits has the root bridge’s bridge ID in it which is superior to the third bridge’s bridge ID…

Again, the same thing occurs.  The third bridge updates it’s port to be the root port and sends an agreement back to second bridge.  The second bridge generates a topology change notification and then both the second and third bridge become in sync.  The same process will occur when we add the fourth bridge to the picture…

When we connect the third and the fourth bridge, let’s see what RSTP does…

The same type of process occurs.  Bridge 3 and bridge 4 set their connecting ports to be designated and exchange proposals. 

Bridge 4 receives a superior BPDU from bridge 3 and instantly puts it’s port into a an ‘alternate’ designated port state.  Recall that the alternate port state is really in discarding mode.

Since the port on the third bridge is in ALT (discarding) mode, the proposals sent by the fourth bridge go unanswered…

*Mar  1 01:41:29.491: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:30.791: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:31.479: %LINK-3-UPDOWN: Interface FastEthernet1/0/6, changed state to up
*Mar  1 01:41:32.486: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/6, changed state to up
*Mar  1 01:41:32.805: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:34.818: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:36.831: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:38.844: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:40.858: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:42.871: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:44.490: RSTP(1): Fa1/0/6 fdwhile Expired
*Mar  1 01:41:44.884: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:46.898: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:48.911: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:50.924: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:52.937: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:54.951: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:56.964: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:58.977: RSTP(1): transmitting a proposal on Fa1/0/6
*Mar  1 01:41:59.497: RSTP(1): Fa1/0/6 fdwhile Expired

When that happens, the fourth bridge just assumes the role of designated port for that segment. 

The other thing that changes with RSTP is the topology change notifications.  Any switch can act on a TC notification when it hears one from any other switch.  Recall in 802.1d that the switch had to notify the root, which then had the responsibility of notifying the other switches.  Upon receipt of a TC in RSTP a switch will flush it’s CAM table of al entries except for the port that it received the TC on. 

The other thing to note here is that Cisco’s implementation of RSPT is Per VLAN–RPST(+).  It’s also referred to a RPVST(+).