RSTP

    Hi everybody,

       I am currently studying for my BCMSN exam, and i have one question.

       In RSTP , is every switch transmiting BPDU to every other switch or is it only transmiting to the root and neighbours?

    Thank you in advance.

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

    BPDU's are like hello's sent every hello time (default 2 sec.). Even though ports are in blocking state BPDU's are exchanged

     

    For more information please refer following white paper:

     

    Understanding Rapid Spanning Tree Protocol (802.1w)

     

    http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml

     

     

    Regards,

    Deepak


    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    tks

     

    Bucharest, I am as well currently studying for the same exam. I have to look this up to confirm, but to answer your question on the quick, I believe the BPDUs are sent to every switch in the STP instance. This is not like an OSPF DR situation where all devices talk to the DR and then the DR sends information back to the other devices.

     

    Ken.


    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

     

    Bucharest,

    From the link Deepak posted, it's mentioned that every RSTP bridge will send a BPDU, whether it receives a BPDU on its root port or not.

    quote: "A bridge now sends a BPDU with its current       information every <hello-time> seconds (2 by default), even if it does       not receive any from the root bridge."


    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Hi!

     

    Here is a link to a nice presentation on RSTP.  It should answer most if not all of your questions.

     

    Erick

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

    https://learningnetwork.cisco.com/docs/DOC-1754

     

    HI everyone,

     

    I wanted to take a moment to comment on this because BPDU generation in RSTP is a topic that confuses a lot of people.  So...here you go:

     

    1. In 802.1d Spanning-Tree, only the Root Bridge was responsible creating/generating fresh BPDUs every Hello-Time (2-seconds by default).  The Root Bridge would then transmit those new BPDUs on all of its Designated Ports.  A downstream bridge that was directly-connected to the Root Bridge would receive those BPDUs on a port that might be either a Root Port or Blocking Port (if that downstream switch had an alternative path to the Root with a lower cumulative Cost).

    ----a. If a downstream bridge received those BPDUs on a Blocked Port, it would process the BPDU and then drop it.  It could NOT forward that BPDU any further.

    ----b. If a downstream bridge received those BPDUs on a Root Port, it would process that BPDU, change the Sending Bridge-ID to it's own ID, update the "Root Cost" field, and then forward that BPDU out any Designated Ports it had.

     

    2. In 802.1d, if the Root Bridge temporarily stopped sending BPDUs for a few seconds (maybe because it's CPU was spiked at 100%, or it was having memory shortage issues, yada, yada, yada) then you would notice that there were NO BPDUs anywhere in the switched topology for that duration of time. In other words, if you (as a non-Root bridge) didn't receive a BPDU, you had nothing to send to anyone else.

     

    Point number 2 above changed when RSTP was developed.

     

    In RSTP, while everyone knows who the Root Bridge is, EVERY bridge containing at least one Designated Port is responsible for generating its own BPDUs and transmitting them on that Designated Port...even if it hasn't received a BPDU from its upstream neighbor.

     

    Example:

     

    Root Bridge (dp)-------(rp) Bridge-A (dp)------(rp)Bridge-X

     

    802.1d

    1. Bridge-A is expecting BPDUs to be received on it's Root Port (rp) every 2-seconds.  Every time a BPDU arrives on its Root Port it will process and then forward that BPDU out of it's downstream Designated Port (dp) to Bridge-X

    2. If the Root Bridge fails to send BPDUs for 6-seconds (as an example) there will be no BPDUs flowing between Bridge-A and Bridge-X for those same 6-seconds.

    3. If ANY switch that is receiving BPDUs on either a Root Port (such as Bridge-X above) or a Blocked Port does not receive a BPDU within the Max-Age timers (which is 20-seconds by default) that bridge will declare its upstream neighbor "Dead" and recalculate its Spanning-Tree topology as necessary

     

    RSTP:

    1. Bridge-A is expecting BPDUs to be received on it's Root Port (rp) every 2-seconds.  But regardless of whether it receives a BPDU from the Root Bridge or not, Bridge-A is still responsible for sending a BPDU to Bridge-X every 2-seconds.

    2. If ANY switch that is receiving BPDUs on either a Root Port (such as Bridge-X above) or a Blocked Port does not receive a BPDU within 3-times the Hello Interval (or 6-seconds) that bridge will declare its upstream neighbor "Dead" and recalculate its Spanning-Tree topology as necessary.Max-Age is no longer necessary to detect a "dead" upstream neighbor.

     

    In either event (802.1d or RSTP) BPDUs are NEVER transmitted out of Blocked ports or Root Ports.  BPDUs are ONLY transmitted out of Designated Ports.

     

    Hope that helps!

    Keith

     


    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    all seems to be right w/ the last post except the part about the root port not transmitting bpdu's in RSTP

     

    from the cisco book CCNP BCMSN pg 265:

     

    BPDUs are sent out every switch port at Hello Time intervals, regardless of whether BPDUs are

    received from the root. In this way, any switch anywhere in the network can play an active role in

    maintaining the topology. Switches also can expect to receive regular BPDUs from their

    neighbors.

     

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Well, if there's one thing I've learned is that when it comes down to trusting what's in a book...or trusting an RFC or IEEE specification...I'll trust the specification any day over a book.

     

    Taken from the IEEE 802.1w Specification

    Page-35

    Section:

    17.7 Communicating Spanning Tree Information

     

    Designated Ports transmit Configuration Messages at regular intervals to guard against loss and

    to assist in the detection of failed components (LANs, Bridges, or Bridge Ports). In both cases, message

    transmission is subject to a maximum transmission rate (see Transmission Limit in 17.28.2).

    Each Bridge Port receives information from the Designated Bridge on the LAN it is connected to, recording

    the message priority vector in the port priority vector (17.4.2.2), and replacing information recorded from

    any previous Designated Bridge if the received vector is better. The Port itself updates the port priority

    vector and becomes the Designated Port for the LAN initially when no information has yet been received

    from any other Bridge, and at any time that its designated priority vector is better than the port priority

    vector recorded from received BPDUs.

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Hey there keith.

     

    Im not trying to argue.. just want to understand it fully..

     

    In RSTP if no root ports send bpdus at hello intervals, then the root bridge would never receive any bpdu's.  The root bridge would have no way of telling if its neighbor bridge went silent by a lack of bpdus.

     

    You see where Im coming from?

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    No problem...I see where you're coming from.

     

    However you're making an assumption that the Root Bridge even cares about knowing about its downstream neighbors.  In reality...it doesn't.  The Root Bridge will never receive BPDUs from anyone.

     

    Your concern was that, "The root bridge would have no way of telling if its neighbor bridge went silent by a lack of bpdus".  The next question I'd have to ask you (and anyone else reading this) would then be, "why would it care if its neighbor went silent?"  Under what circumstances can you imagine that it would be important for the Root Bridge to know this information?

     

    Or more specifically:

    1. If Bridge-X only has a Root Port and Blocking Ports (but no Designated Ports) and...

    2. Bridge-X is not sending BPDUs to any of its neighbors

    3. Under what circumstances can you imagine that those neighbors would NEED to know about Bridge-X in order to detect/prevent loops?

     

    Kind regards,

    Keith

     

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

     

      Thank you Keith.  By the way...the videos from CCNP TV are verry good. Cleared a lot of my problems.

     

    I'm confused, but is there any circumstances????

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Hi Deepak,

     

    If you're asking, "Are there ever any circumstances where BPDUs are transmitted out of Root Ports or Blocking Ports?" the answer would be "no".

     

    Kind regards,

    Keith

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    thanks a lot keith...

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Hi Keith,

     

    Just wanted to say, your post was very informative. Thanks.

     

     

    cheers,

    Saurabh

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Sorry to dig up this post from the past but I need some help to try and understand a few things regarding RSTP (RPVST+). Seen many docs and posts that state that RSTP(RPVST+) can converge in 1 second. However reading through posts over here by Keith he says that the change will be detected only if the BPDUs are missed 3 x hello time (2sec) which is approx 6 seconds. Hence in reality it would take atleast 6 seconds for a bridge to detect that its root port is down before putting an alternate port into fwd. Is that understanding correct?

     

    Also stated in many documents is that only a port that goes into forwarding generates a topology change. What actually causes that port to go into forwarding in the first place. I read the docs on cisco.com and maybe missing it completely but cannot see it. In a scenario where you have following now suppose if link between Bridge-C and Bridge-D fails who generates the TCN since no ports have actually gone into forwarding. Thanks

     

    Root Bridge (dp)-------(rp) Bridge-A (dp)------(rp)Bridge-B

    (dp)                                                           (dp)

    |                                                                  |

    |                                                                  |

    (rp)                                                            (Blk)

    Bridge C(dp)--------------(rp)Bridge-D (dp)------(rp)Bridge-E

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Ned,

     

    The use of BPDUs for failed link detection (3xHello time) is the most "unlucky" case. In general, fast failure detection is facilitated by loss of signal detection, which could be as fast as order of milliseconds (look for information on the "carrier-delay" interface command to introduce a delay in event detection and prevent flapping). Failure detection by means of hello timer could be possible on shared links or on links that do not properly detect loss of connectivity (e.g. some fiber/twisted-pair converters)

     

    However, when failure is reported to RSTP, the synchronization process may take considerable time, way over one second in some topologies (e.g. full-mesh or large rings). The problem is that RSTP is "gradient" algorithm, which you could think of as similar to RIP. Even though the change is propagated quickly through the topology, old information may circle in loops, until it gets expired by the virtue of MaxAge timer. This process is known as "counting to infinity", and could be very noticable under special conditions, e.g. root bridge failure.

     

    To be safe and predictable with RSTP you need to work with simple 3-4 nodes topologies, e.g. triangle or "U" topologies. RSTP convergence time is proportional to the number of nodes and could be kept to the order of milliseconds in small topologies of 3 switches (e.g. distribution-access block).

     

    As for your topology of the 4-node ring. There is always one port blocking in this topology. When a link fails, the blocked port becomes unblocked (unless the failed link was connected to this port) and transitions to forwarding state. This will start TCWhile timer on the switch that unblocked the port and initiate TC-bit flooding procedure.

     

    HTH,

     

    Petr

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Hello Petr, thanks for helping.

     

    Could you elaborate on what actually (signalling?) causes the port to move from blocking to forwarding in case of a failure in RSTP in the previous example? how would it be different if link was a direct link failure or indirect link failure and how does a indirect switch realize there is a topology change since the port that went down does not cause a TC to be generated in RPVST+ standard.

     

    In small ring topologies when you mention that timer is propotionate does that mean that convergence will happen in 4seconds if there are 4 switches.

     

     

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

     

    Sorry, didn't notice you have 6 switches in the ring topology. However, that does not change anything from the logical perspective. If there is a link failure, the switches connected to the link will detect the event and start RSTP synchronization process according to the new information.

     

    For example, assume the link between "Bridge A" and the "Root Bridge "fails.

     

    Root Bridge (dp)-------(rp) Bridge-A (dp)------(rp)Bridge-B

    (dp)                                                                       (dp)

    |                                                                               |

    |                                                                               |

    (rp)                                                                        (Blk)

    Bridge C(dp)--------------(rp)Bridge-D (dp)------(rp)Bridge-E

     

    1) Root bridge detects the link down event, but since this does not invalidate any RSTP information it does nothing about it.

    2) Bridge A detects loss of root bridge information as it's root port is down and declare itself (A) as the new root. It will send proposal to B, declaring its downstream port connected to B as "designated" and claiming itself a new root.

    3) B notices the loss of root bridge information and tries to adapt to the new announcement. Let's assume A's priority is better than B's. Then B accepts A as the root bridge and attempt to synchronize its downstream port to E with the new root.

    4) B sends proposal to E, declaring A as the root and B's downstream port as designated. However, E knows a better root, and thus declares the new information as "inferior".

    5) E would  normally ignore the proposal on the blocked port, but since the information is inferior (worse root), it immediately responds back with a better root bridge information.

    6) B adapts to the new information and agrees with E, marking its connection to E as a "root port". Also, E declares its blocked port as designated and unblocks it. Since a blocked link went to forwarding state, E independently starts topology change notification process, by sending BPDUs out of its root port and new designated port with the TC bit set.

    7) B proposes new root information to A, and A agrees. The port connecting A to B is now A's new root port. The topology is now sychronized.

    8) Meanwhile, E continues to propagate TC information so eventually reaches all bridges in the topology, invalidating their MAC address tables. The flooding process continues for TCWhile time, to ensure all bridges have learned about the change and invalidated their MAC address table information. All switches are involved in the process, but the TC bit flooding is started by E.


    Now for the convergence times. When I say "it's proportional to the number of switches" it does not mean this time is "N seconds" where N is the number of switches. It means "as the number of switches in the topology grow, so does the convergence time". It is important to point that there is no deterministic upper bound for RSTP convergence time - this time depends on the topology and the type of failure (link/node, link position with respect to the root node). If you seek deterministric behavior, stick with simple topologies like I mentioned before - they guarantee subsecond convergence under any failure.

     

    HTH,

     

    Petr

     

     

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     

    That helped a lot. It was very easy to understand and grasp. Thanks

     

    can u help answer these additional questions

     

    some whitepapers and books say that RSTP can converge in less than msec and can that occur in topology i had below where failure on link between Root Bridge and A or A and B converge quickly.

     

    Root Bridge (dp)-------(rp) Bridge-A (dp)------(rp)Bridge-B

    (dp)                                                                       (dp)

    |                                                                               |

    |                                                                               |

    (rp)                                                                        (Blk)

    Bridge C(dp)--------------(rp)Bridge-D (dp)------(rp)Bridge-E

     

     

    how can sub-second convergence happen as minimum time for BPDU generation is 2 second and so entire topology won't be stable until atleast 1 x BPDU has been sent.

     

    When E receives inferior BPDU does it wait any time to put the blk port in forwarding or because of inferior bpdu it does that immediately.

     

    how long does TCwhile timer run and how does it stop

     

    "this time depends on the topology and the type of failure (link/node, link position with respect to the root node)."

     

    does above mean that if the failure was not directly on link to the root bridge or if the root bridge itself didn't fail than convergence would be slower.

     

    This document was generated from the following thread: RSTP