I got bored with reading stuff that doesn’t go into enough detail about the RSTP synchronization process on the web, so I’m making my own guide and notes about it. I’m going to start by identifying the port states and roles, then go through the RSTP synchronization process and explain how they are used.

RSTP port states and roles

Port Roles

Root port
Designated port
Edge port
Alternate port
Backup port
Port States

Discarding
Learning
Forwarding

RSTP Synchronization Process

I’m going use the topology below to go through the synchronization process.

RSTP

If we start with all links being in the shutdown state. So say fa0/0 was brought up on Sw1 and Sw2. Both ports immediately go into the designated port role and discarding port state (this is the very first role and state for a non-edge port). Both switches will transmit a BPDU with the proposal bit set. In this topology, what this actually means is that they need to agree on which switch will ultimately transition their port to the designated role and forwarding state, and which switch will make their port become a root port in the forwarding state. This is decided by the information contained in the the BPDU that has the proposal bit set. Let’s look whats typically inside this BPDU.

RSTP pcap

The key pieces of information are the Root Identifier, Bridge Identifier, and that the Proposal flag is set. Each bridge initially assumes it’s the root bridge upon startup. The reason for this is because they have not yet received a configuration BPDU from an upstream neighbor to tell them any different, so therefore have no knowledge of the existing topology. That is why the Root Identifier and Bridge identifier fields in the BPDU list the same MAC address. The proposal flag just identifies that nobody has agreed to the information that the switch has sent i.e. no switch has explicitly said, I agree, you are the root bridge.

In this topology, when Sw1 receives the configuration BPDU with the proposal bit set, sent from Sw2, it actually disagrees with the information that Sw2 sent. Sw2 has a worse bridge-id and therefore Sw2 cannot possibly be the root bridge. So Sw1 would a submit proposal stating, that he is the root bridge (basically just ignoring the proposal from Sw2). Sw2 on the other hand, agrees with the BPDU it received from Sw1. Sw2 compared the bridge-id of who he believes is currently the root (himself at this point) against the bridge-id Sw2 believes is the root (which actually is Sw2 himself) and saw that Sw1 is listing a lower bridge-id in the Root Identifier field.

When a switch agrees with a proposal, Sw2 in this case, it puts all other non-edge designated ports in discarding state (if they existed in our topology – which they don’t at the moment because fa0/1 is shutdown). Note here, that if Sw2 already had a root port elsewhere, the root port role would instantly be removed and placed onto the port that received the best BPDU information, and the old root port would become designated discarding. Only when all non-edge designated ports are in the discarding state except the link to Sw1 will the switch consider that the ports are in sync. Remember, alternate ports and backup ports are already in the discarding state, so in essence, all ports except the port in the synchronization process would be in a discarding state. At which point Sw2 can then move the port into forwarding state and send the BPDU with the agreement flag set. The learning and forwarding flags are also set because the port is moving quickly from the discarding to the forwarding state. The key point here is that all ports except the port that needs to send an agreement must be in discarding state before the switch can send it.

At this point, both Sw1 and Sw2 have decided who is closer to the root. As it turns out Sw1 is the root (as identified by the BPDU he sent that listed his “Root Identifier” as having the same MAC as the “Bridge Identifier”). So Sw2 transitions his fa0/0 port into the root role with the forwarding state. At the same time Sw1 moved his port into the designated role in the forwarding state. This is pretty much completes the RSTP synchronization process that happens between Sw1 and Sw2.

There is just one more thing the switches need to do though. In RSTP, when a port transitions into the forwarding state, it means there has been a topology change. Note that in 802.1w (RSTP) this is the only thing that triggers the topology change process now. In the old 802.1D spanning-tree, a TCN was generated when either a port went into forwarding mode or moved from learning or forwarding mode into blocking mode. However in RSTP, the topology change process is generated only when a port moves into forwarding mode. Also, the TCN BPDU is no longer used if the network is only running 802.1w. RSTP now uses only one type of BPDU, the configuration BPDU, for everything. So in the topology change, it just sends a configuration BPDU with the TC bit set in order to alert to other switches that a port has moved into the forwarding state in the topology. If another switch was to be running legacy PVST+ then a TCN BPDU would also be generated alongside this BPDU.

Back to my topology then. Because Sw1 fa0/0 moved into forwarding state, a BPDU with the TC bit was set and sent out towards Sw2. This causes Sw2 to wipe its learned MAC addresses in the CAM table for all ports upon which the BPDU was not received (in our topology, this doesn’t really do anything because fa0/1 was never brought to the admin up status, so there was no MAC addresses to wipe. If fa0/1 was however, operational, then this means the CAM table would be wiped for any MAC addresses learned out fa0/1). Anyhow, Sw1 would continue to send BPDUs with the TC bit set for a period of 2x the hello timer (so 4 seconds in total, by default). Note that if Sw1 had links to other switches here, it would have also sent this BPDU out all non-edge designated ports (and root port if it had a root port) except the port the BPDU was received on. At a similar time, Sw2 would also generate its own BPDU with the TC bit set because he moved his fa0/0 port into the forwarding state. It would advertise these BPDUs in the same way Sw1 did.

And that’s it! Sw1 and Sw2 are synchronized, and have also alerted everyone of the ports that moved into the forwarding state. The same process happens from Sw2 down toward Sw3, and then they will converge. Once all non-edge designated links have been through this process, the network is considered synchronized.