Intro

It is well known that RSTP uses synchronization to speed up convergence in
switched networks. Not many articles or books give the full picture how this
process really works. The synchronization process is often oversimplified
and readers are left with the IEEE standard if they want to understand all
of the details. This post will give you a better understanding of how the
RSTP synchronization really works.

Initial synchronization

In regular 802.1D when switches first boot up ports are brought online
the switch claims to be root because it has not yet heard any better BPDUs.
This is no different in RSTP or RPVST+ which is Ciscos implementation.
Take a look at the following topology.

RSTP-synch-1

The goal here is to make SW1 the root bridge. But until better BPDUs have
been heard all switches will claim root. That is how STP works, it stores
the best BPDU received in on a port. To emulate a network coming online
to begin we will have all ports shutdown and then try to bring them up
at the same time. Debugs and captures will be run to show how the synchronization
process works. The following debugs have been enabled.

SW1#sh debug
Spanning Tree:
  Spanning Tree event debugging is on
  Spanning Tree state sync support debugging is on

So we start at looking at the debugs from each switch in order.

SW1

setting bridge id (which=3) prio 16385 prio cfg 16384 sysid 1 (on) id 4001.aabb.cc00.0100
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): received an agreement on Et0/0
STP[1]: Generating TC trap for port Ethernet0/0

SW1 assumes its port is designated and sends out a proposal. SW2 will agree to this
proposal.

SW2

%LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
%LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0200
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/1
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1
STP[1]: Generating TC trap for port Ethernet0/1
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): Et0/0 is now root port
RSTP(1): syncing port Et0/1
RSTP(1): synced Et0/0
STP[1]: Generating TC trap for port Ethernet0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1

SW2 initializes all ports as designated and starts sending out proposals. It
then receives a better BPDU from SW1 so it has to sync its downstream ports (Et0/1).

SW3

%LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
%LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0300
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): Et0/0 is now root port
RSTP(1): syncing port Et0/1
RSTP(1): synced Et0/0
STP[1]: Generating TC trap for port Ethernet0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1
STP[1]: Generating TC trap for port Ethernet0/1
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): syncing port Et0/1
RSTP(1): synced Et0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1

SW3 goes through the same process. Claims root at first, then hears a better BPDU
and must sync its downstream port.

SW4

%LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0400
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): Et0/0 is now root port
RSTP(1): synced Et0/0
STP[1]: Generating TC trap for port Ethernet0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): synced Et0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal

SW4 also claims root, hears a better BPDU. It has not downstream ports to
synchronize so the process ends there.

To visualize the process this is what happens at time 0.

RSTP-synch-2

This can be seen in the BPDUs as well. This is the BPDU that SW1 sends out.

BPDU-SW1-1

The BPDU is a proposal and the designated bit is set. It’s not yet trying to learn or
forward on the port.

SW2 sends out the following BPDU.

BPDU-SW2-1

When SW1 has received agreement BPDU it can start forwarding on its designated port.
SW2 can forward on its root port as soon as it decides that it is root. When SW2
has learned better root information it must synchronize downstream ports so the port
to SW3 is still blocking.

RSTP-synch-3

This is the agreement BPDU that SW2 sends to SW1.

BPDU-SW2-2

The learning and forwarding bits are set and the role is root. The agreement
bit is also set as well as TC so that MAC address tables can be updated. The
TC bit is set for 2x the hello time and is called TcWhile.

The next segment to be synchronized is the one between SW2 and SW3.
At first SW3 claims to be root.

BPDU-SW3-1

Then SW2 sends out a better BPDU.

BPDU-SW2-3

SW2 sends a BPDU with TC set because for a brief period of time SW2 was believed to
be root before SW2 heard a better BPDU from SW1. Then SW3 sends agreement BPDU.

BPDU-SW3-2

After SW2 has received the agreement BPDU it can bring its downstream port (Et0/1)
to forwarding making the topology look like this.

RSTP-synch-4

Finally the segment between SW3 and SW4 is synchronized. SW3 sends out the BPDU
and then SW4 agrees to it. TC is set because for a brief period SW3 as believed
to be root.

BPDU-SW3-3

BPDU-SW4-1

The final topology is then that all links are forwarding because we have no physical
loop in this topology.

RSTP-synch-5

Receiving better root information

So far we had no physical loop in the topology. This is not a very realistic
scenario and to see how RSTP works when receiving better root information we
will add a link between SW1 and SW4 meaning that SW4 has a direct path to the
root like this.

RSTP-synch-6

Before we look at what happens when bringing up the port between SW1 and SW4
let us assign port roles to all the ports on the drawing. This is good practice
to understand how STP works and you should be able to do this manually if you
fully understand STP. We are expecting the topology to converge like this.

RSTP-synch-7

After SW4 receives better root information, which ports do we need to synchronize
to converge the topology? SW1 does not receive better information, it is the root.
SW4 has a designated port towards SW3 so it needs to synchronize that segment.
SW3 has no designated ports so we except the synchronization process to stop
there. Lets look at debugs and I’ll do a play by play with the drawings.

SW1

%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1
STP[1]: Generating TC trap for port Ethernet0/1

SW1 initializes the port and waits for agreement BPDU from SW4 before it can
bring the port into forwarding.

SW4

%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): updt roles, received superior bpdu on Et0/1 
RSTP(1): Et0/1 is now root port
RSTP(1): Et0/0 blocked by re-root
RSTP(1): synced Et0/1
RSTP(1): Et0/0 is now designated
STP[1]: Generating TC trap for port Ethernet0/1
RSTP(1): transmitting an agreement on Et0/1 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): received an agreement on Et0/0
STP[1]: Generating TC trap for port Ethernet0/0

SW4 initializes the port but then receives a better BPDU. Et0/0 is then blocked by
reroot because Et0/1 is now the root port. Et0/0 must be synchronized because it
is now a designated (downstream) port. SW3 then sends an agreement. So looking at
the topology this is what has happened so far.

RSTP-synch-8

Then SW3 sends agreement so that SW4 can bring Et0/0 into forwarding.

RSTP-synch-9

So now the question is, what happens at SW3?

RSTP(1): updt roles, received superior bpdu on Et0/1
RSTP(1): Et0/1 is now alternate

SW3 did not receive any better root information and it has no designated ports.
This means that the synchronization process can stop. Making the final topology
look like this.

RSTP-synch-10

What happens when synchronization fails?

RSTP synchronization is dependant on that all links in the topology are
point to point. This is decided by if the link is running in full duplex or not.
It is possible to force a link to point to point but if you are running your
interfaces in half duplex STP is not your biggest problem!

In the case that the proposal and agreement process fails RSTP has to fall
back on relying on the old timers used in regular STP. There is a timer called
FdWhile which is the same as the forward delay, defaulting to 15s. After trying to
send proposals for 15s it will start to bring the port through discarding, learning
and then to forwarding. I simulated this scenario below by blocking BPDUs between
SW3 and SW4.

20:02:23.338: RSTP(1): Et0/1 is now root port
20:02:23.338: RSTP(1): Et0/0 blocked by re-root
20:02:23.338: RSTP(1): Et0/0 is now designated
20:02:23.338: STP[1]: Generating TC trap for port Ethernet0/1
20:02:23.339: RSTP(1): transmitting a proposal on Et0/0
20:02:23.509: RSTP(1): transmitting a proposal on Et0/0
20:02:25.509: RSTP(1): transmitting a proposal on Et0/0
20:02:27.509: RSTP(1): transmitting a proposal on Et0/0
20:02:29.517: RSTP(1): transmitting a proposal on Et0/0
20:02:31.517: RSTP(1): transmitting a proposal on Et0/0
20:02:33.517: RSTP(1): transmitting a proposal on Et0/0
20:02:35.517: RSTP(1): transmitting a proposal on Et0/0
20:02:37.521: RSTP(1): transmitting a proposal on Et0/0
20:02:38.338: RSTP(1): Et0/0 fdwhile Expired

Every 2 seconds it tries to send a proposal but gets no agreement back.
After 15 seconds the timer expires and RSTP has to go through the regular
phases instead of immediately bringing the port online.

Conclusion

RSTP is a rapid protocol that works by synchronizing the topology. This process
is often overlooked in books on switching and spanning tree. This post describes
in detail how the synchronization process actually works. RSTP is a distance vector
protocol since the cost is learned by listening to BPDUs from other switches. In
some cases this can lead to issues like counting to infinity. For detail on this
refer to INE STP convergence PDF by Petr Lapukhov.
RSTP converges fast as long as the synchronization process works. This process relies
on all links running in full duplex and all switches are running in the same STP mode.

RSTP synchronization – behind the scenes
Tagged on:                 

26 thoughts on “RSTP synchronization – behind the scenes

  • August 9, 2013 at 9:23 am
    Permalink

    Nice write up as usual!

    Reply
  • August 9, 2013 at 5:29 pm
    Permalink

    Quality post. Thanks Daniel!

    Reply
    • August 9, 2013 at 7:39 pm
      Permalink

      Thanks Chris!

      Looks like you passed just a couple of weeks before me looking at your number 🙂

      Reply
  • Pingback:Switching – RSTP | FrÃ¥n CCNA till certifierad CCIE

  • September 16, 2013 at 1:14 am
    Permalink

    Excellent explanation, best i read so far!

    Reply
    • September 16, 2013 at 7:55 am
      Permalink

      Thanks!

      I thought this was one area where there weren’t many good articles. Petr from INE did a great one on STP/RSTP convergence but it did not cover the synchronization process in detail.

      Reply
  • March 24, 2014 at 1:17 pm
    Permalink

    I guess here sw4 (E 0/1) wil have Alternate port instead of Sw3 because, the bridge ID of Sw4 is more when compared to Sw3. so Sw3 (E0/1 ) will be designated and Sw4 (E0/1) will be alternate discarding. Please correct me if I am wrong

    Reply
    • March 29, 2014 at 7:52 am
      Permalink

      Hi Vijay,

      SW4 has a lower cost to the root than SW3 so that is why SW4 will be designated. If there was a tie in the root path cost and SW4 had a higher BID then SW3 would become designated on the segment.

      Reply
  • July 21, 2014 at 9:03 pm
    Permalink

    You made RSTP communication simple and clear. Thank you for your very detailed explanation.

    Reply
  • September 23, 2014 at 5:10 pm
    Permalink

    very good explanation on rstp.I have a doubt.
    whether the root bridge election(proposal and agreement) happens in parallel between every switch,as you explained in sequence its bit confusing.for example between sw1—sw2 and sw3–sw4 both happen parallel?

    whether this proposal and agreement happens only after root bridge election or after topology change?

    Reply
    • October 4, 2014 at 7:40 am
      Permalink

      I explained it in sequence because it would be very messy to try to explain from all switches PoV at once.

      Actually the process is kind of sequential though because switches block their downstream port(s) when doing the synchronization process. This is to prevent any temporary bridging loops from forming. After one switch is done, it moves to the next and so on. This is often explained as an expanding wave. If two switches are connected to the same upstream switch the process could be happening at the same time though.

      This synchronization process takes place when superior BPDU is received, not on every topology change. Topoloy change only happens when port moves to forwarding in RSTP as well.

      Reply
  • October 1, 2014 at 1:49 pm
    Permalink

    I am very impressed with this explanation. Thank you.

    Reply
  • October 8, 2014 at 2:25 pm
    Permalink

    I’m still not completely clear on the process. Consider the first example, with four linear switches. Suppose the switch priorities are: SW1 – 1, SW2 – 4, SW3 – 3, SW4 – 2. (Priority numbers incrementing by 1 to keep things simple.) So SW1 and SW2 agree SW1 should be the root and start the convergence process as described. But what happens with SW4? It sees an inferior BPDU from SW3 and thinks it’s the root. SW3 sees an inferior BPDU from SW2 and a superior from SW4, so it agrees SW4 is the root. Do SW4 and SW3 also start the convergence process with SW4 as the root? If not, why not? How does SW4 know that SW1 even exists at this point if BPDUs are not forwarded?

    Reply
    • October 26, 2014 at 8:18 am
      Permalink

      The post written to simplify the concepts. In reality, multiple synchronization events could be occuring at the same time. The order would depend on which switch is booted first and which switch that is sending out BPDUs first.

      So let’s say that SW3 sends a BPDU to SW4 before the one from SW1 has propagated. They would then negotiate on the roles locally, because SW4 sees an inferior BPDU it will send out its own BPDU, claiming its the root. During the synchronization process, downstream ports are blocked, SW4 does not have any but SW3 would consider SW2 to be downstream if SW4 is the root so that port would be blocked.

      Maybe then SW3 gets a better BPDU via SW2, SW3 would then synchronize with SW2 while blocking its downstream port to SW4 and when that it’s done it would then synchronize with SW4.

      So there could be some going back and forth and the synchronization may not start from the root but the concepts are the same.

      Reply
  • October 14, 2014 at 1:14 pm
    Permalink

    A great write-up. Thanks. On a downstream segment, is the process of synchronization complete when an agreement frame has been received? In you first batch of debug, we can see “syncing port Et0/1”, but the debug never reports port Et0/1 as synced. I presume it is synced since an agreement was received.

    Reply
    • October 26, 2014 at 8:22 am
      Permalink

      Thank you!

      Yes, seems the debug does not show it but it would be synchronized after receiving the agreement.

      Reply
  • Pingback:STP Notes for CCDE | Daniels networking blog

  • March 13, 2015 at 5:09 pm
    Permalink

    Agree with the rest of the commenters. Great write up! The sync process was something I overlooked for sure.

    Reply
  • August 16, 2015 at 7:14 pm
    Permalink

    I got confused,according stp rules,SW2 and SW3 link should be blocked,

    Reply
  • March 17, 2016 at 3:29 am
    Permalink

    This is the best blog I have ever studied. Thank you so much !!

    Reply
  • December 27, 2016 at 8:23 pm
    Permalink

    I test it on GNS3 and Packet Tracer and i saw a different result

    Did anyone test this on GNS3 ?!

    I think there is a bug on GNS3 for RSTP and its block a port with CST rule instead of RSTP

    Reply
    • December 27, 2016 at 10:11 pm
      Permalink

      Sorry replying
      I switched the Switch 2 priority with Switch 4 priority and I saw E0/0 of Switch 3 got blocked

      Why this happened ?!

      Reply
  • January 27, 2018 at 9:30 am
    Permalink

    Hi Daniel,
    I have to say, great great work, thanks so much!
    I’m stucking on the RSTP sync process recently, and like you said, most books just overlooked this part, and that confused me for some while, until I saw this article.
    It really helped me out, thank you again!

    Reply
  • April 10, 2018 at 4:45 pm
    Permalink

    Great read indeed.
    Thanks.

    Reply
  • October 7, 2023 at 11:01 am
    Permalink

    How RSTP handles if there’s an Link failure or a new Link/ Bridge gets added to the Active Topology ?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *