Fast Convergence for Designated Ports

RSTP protocol’s fast convergence depends on the use of point-to-point links connecting switches. In order to quickly transition a designated port into non-discarding state, the upstream switch needs to make sure that the downstream neighbor agrees with that idea. This constitutes the process known as handshake (or proposal/agreement):

  1. Upstream bridge sends a proposal out of a designated port. As a matter of fact, it just sets the proposal bit in outgoing configuration BPDUs.
  2. Downstream bridge receives the proposal, and if it agrees with the upstream port role, it starts the process known as synchronization.
  3. Synchronization implies the downstream bridge blocking all non-edge designated ports, prior to sending an agreement to the upstream bridge.
  4. Synchronization is needed to make sure there are no loops in the topology, after the upstream bridge unblocks its designated port.
  5. If the downstream bridge does not agree with the proposal, it will continues sending it’s own configuration BPDUs with the proposal bit set. Eventually one of the bridges will accept the superior information and send an agreement.

Fast Convergence for Other Port Types

See more detailed overview at:

The above procedure outlines the fast transition procedure for designated ports. As for root ports, they can always transition to forwarding state upon receiving a superior BPDU and synchronizing the local designated ports. Alternate ports may quickly transition to forwarding state if the current root port is lost, thanks to the feature known as UplinkFast in the classic STP implementations. Inferior BPDU handling is similar to BackboneFast feature, where a designated port receiving an inferior BPDU will quickly send a new proposal to synchronize the downstream peer.

Why P2P links are So Important?

And now, an interesting question: Why RSTP needs point-to-point links for fast convergence? The answer lies in the handshake protocol. If we would have multiple devices on the segment, performing synchronization would become really cumbersome. The upstream bridge will have to detect all downstreams, and wait for every one of them to synchronize with its proposal. Implementing such complicated protocols is not worth the benefits, as most of the time switches are connected using full-duplex links.

Treating Shared Links as P2P

Yes, this is possible. Even though you may think this is purely a theoretical concern, it’s possible to encounter this in real-life scenarios. Recall that RSTP detects P2P links by looking at the link duplex. What if we have switches A,B and C (customer switches) plugged into switch D (provider switch) and switch D performing Layer-2 Protocol Tunneling? In this case, all customer switches would consider their connection as being P2P. However, switch D will tunnel all BPDUs, effectively connecting the switches via a share cloud. In this situation, RSTP would behave according to the P2P link rules, sending a proposal and unblocking the designated port upon receiving the first agreement. This may potentially introduce temporary Layer 2 loops, as one of the switches may not yet be synchronized. You may easily lab up this scenario and observer “fast convergence” over a shared link.

Another situation is possible with Cisco’s R-PVST, which is a hybrid of RSTP and Cisco’s proprietary PVST+. The encapsulation rules for RPVST follow the same used for PVST+ in order to allow for tunneling of Cisco PVST instances over an IEEE CST cloud (You may read about PVST+ encapsulation rules in the blog post named PVST+ Explained). The problem with RPVST is the same – there could be multiple Cisco switches connected to the IEEE CST cloud, every switch treating this cloud as a P2P link, as the links are full-duplex. The net effect is the same as described above.

So how long does it take for RSTP to converge?

Contrary to many beliefs of RSTP’s fast convergence (order of milliseconds), it may exhibit convergence times in order of seconds even for small topologies. The main problems is the distance-vector or gradient nature of STP protocol, which converges based on the best information received from peers. Under some some cases (e.g. root bridge crash), this may result in old information circulating inside the topology until the hop count exceeds the limit. This is known as count to infinity and is very similar to the problem found in RIP or any other distance-vector protocol. With the critical nodes failing, RSTP may take seconds to recover from the information loss.

Further Reading on Ethernet and RSTP

If you are curious about details, you may want to read the following relatively small article Scaling Etherenet to a Million of Nodes which discusses the RSTP convergence problem and proposes a solution for “broadcast-less” Ethernet, which does not require STP. Pay special attention to the figures, especially the one showing the convergence times in ring topologies. To anyone further interested in «scalable ethernet» I would highly recommend reading another, more recent article: Floodless in SEATTLE. Special thanks to Daniel Ginsburg for referring me to this little gem!

Have fun with RSTP! :)

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

14 Responses to “RSTP and Fast Convergence”

  1. John Spaulding says:

    Great write up!!

  2. Terry Vinson says:

    Petr you must love switching technologies, as always a great read. Thanks!

  3. Rui Menas says:

    Fisrt of all, let me say that your article is very good and interesting. However, i have a doubt related with “Fast Convergence for Designated Ports” when downstream bridge doesn’t agree with the proposal. Here, you refer that “Eventually one of the bridges will accept the superior information and send an agreement.”. When you mencioned that “one of the bridges will accept the superior information” are you refering to another downstream bridge? Are you considering that the bridge that doesn’t agree the proposal is a legacy bridge?

  4. Andy Horn says:

    Hi Petr,

    You`re writing that under rare circumstances a `count to infinity` event happens. It seems we`ve just hit such thing recently: our c6513 which was the RB in RPVST mode for most of our vlans. Is there a way to check or verify or reproduce such thing?

    Is there a way to measure the amount of CPU a switch needs to converge hundreds of vlan instances? (we`ve seen a limitation of 128 vlans in for 3750 series stacks, but not sure about bigger platforms, etc.)

    Any private msg. is much appreciated, and congrats on the site so far guys! :)


  5. [...] time passed, STP evolved into RSTP and Cisco answered with Rapid-PVST+: the fast STP, but with the same per-VLAN instance concept. The single spanning-tree instance used [...]

  6. Mesh says:

    I have a doubt. If we compare, RPVST+/RSTP with some routing protocols(e.g EIGRP and OSPF), which converges faster? Could someone explain whether we could compare a layer 2 and layer 3 convergence or we should take them as a separate thing?

    • @Mesh

      You can only use RSTP in small environment, limited to a switch block or maximum two switch blocks. RSTP generally convergest fast, but the convergence is unpredictable and under some conditions may take siginificant time. It’s “unfair” comparing IGPs vs RSTP, as any popular IGP (OSPF, ISIS, EIGRP) could be tuned to converge in sub-second interval and scale way much more than RSTP.

  7. [...] RSTP and Fast Convergence [...]

    • Dejunl says:

      1. Uner STP environment, if a bridge makes it’s alternate port the new root port, and makes it’s old root port the new designated port, what’s the state of the new designated port?

      2. Under RSTP environment, if a bridge which only has a root port and a designated port receives inferior BPDU from it’s root port, what will it do?

      3. Before P/A, I think there are some ordinary BPDUs exchanged between the adjacent two bridges, only in this way they can assign appropriate roles to ports connected directly. And in a pure RSTP environment, absolutely there will be an agreement message.

      Expecting your repaly.


  8. Elvin Arias says:

    Awesome post. :)


  9. Sreeju Sreedhar says:

    Hi Petr,

    Thanking you for all the technical write-up’s. It helped me a lot in my CCIE sec prep. I love them all.
    In this article you have mentioned, when the downstream switch does not respond with a Agreement bit set BPDU, the top bridge will continuously send proposals and finally one of the downstream switch will respond with an Agreement. I feel in such a case, the downstream switch will not send any Agreement back, but the STP timers will kick-in for the upstream switch and after 15*2 sec, it will bring the port into forwarding.

    Sreeju Sreedhar (#29874)

  10. Marc Edwards says:

    This was very insightful. Much appreciated.


Leave a Reply


CCIE Bloggers