Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

RSTP convergence few questions

Hello all

I study RSTP and I'm really confused

What are the steps of convergence in RSTP , For example in case of implementing another switch into running topology.

So let the look on my understanding of RSTP convergence ..
Few questions ...


1. I put a switch somewhere into center of topology far far away from root sw
    He Boots up and , now starts elect a root ports , designated ports as in 802.1D ? or he puts all non edge ports into "designated discarding" state and   starts sync process ?

2. Only switches directly connected to the new switch start sync process ? or it runs chain reaction in whole topology , all switches start proposal process ?

3. With what port it starts proposal process , with port that has best root path ? and the other ports are still listening ? and generating BPDUS ?

Perhaps a dump questions , then in advance sorry for that

16 REPLIES
Cisco Employee

Re: RSTP convergence few questions

Hi Roman,

1. I put a switch somewhere into center of topology far far away from root sw

     He Boots up and , now starts elect a root ports , designated ports as  in 802.1D ? or he puts all non edge ports into "designated discarding"  state and   starts sync process ?

It boots up and starts considering itself as the root switch. It will, by default, put its non-edge ports into Designated Discarding role/state and start sending Proposals. However, if its priority is higher than the current root switch priority, it will not become a new root switch, and these Proposals will mostly go unanswered. Other switches will, in a similar fashion, send their own BPDUs to the new switch, making it understand who the real root switch is and allowing it to choose its new root port.

2. Only switches directly connected to the new switch start sync process  ? or it runs chain reaction in whole topology , all switches start  proposal process ? 

It has to be stressed that the Proposal/Agreement mechanism serves to rapidly put a new root link into forwarding state. A new link that does not have a root port on one of its ends is a redundant link that must remain blocked, and on this link, Agreements will never be sent. The entire Proposal/Agreement process therefore starts at the point of the topology change and propagates as far as there is a root link to be put into forwarding state rapidly. This wave of Proposals/Agreements will ultimately be terminated at links which are redundant.

By definition, every non-edge Designated port in the Discard or Learning state sends Proposals. If a newly connected port is non-edge Designated/Discarding, non-edge Designated/Learning, or has become Designated/Discarding as the result of the sync (reaction to an accepted Proposal) or re-root operation (change of the root port), it sends Proposals down the link. Agreement to such a Proposal is sent if the sending port of the Agreement is the root port, otherwise, Proposals are ignored and the wave of Proposal/Agreement is terminated here.

Therefore, in general, it is difficult to say how far will the Proposal/Agreement wave go.

3. With what port it starts proposal process , with port that has best  root path ? and the other ports are still listening ? and generating  BPDUS ? 

No. The Proposal is always sent from a non-edge Designated/Discarding or Designated/Learning port. A port may become Designated/Discarding

  • after being connected
  • after re-root operation (the root port on the current switch has changed, or the root switch itself has changed)
  • after sync operation (receiving a Proposal on a new root port and putting all non-edge Designated ports in Discarding state before sending an Agreement through this new root port)

Also, changes in the mode of operation (trunk, access, changing the access VLAN, adding a new alloved VLAN on a trunk port, etc.) result in topology change being registered on that port - but let's leave those details out for a moment.

RSTP is quite a nut to crack, isn't it? I am aware that these topics are difficult, and I encourage you to ask further. You are welcome.

Best regards,

Peter

Re: RSTP convergence few questions

I always thought if you just throw up a new switch in the middle of your network, and lets say it has 2 links, each one to a different path, so it has 1 redundant path. As soon as you boot that bad boy up, and it's enabled with RSTP, it will immediately blocks its non-edge designated ports as long as their p2p(full duplex). Then in my scenario boths ports on this switch that was just setup in the middle of the network will be blocks (as well as others that are in Full Duplex and not configured with portfast). Then this switch will send out BPDUs with the Proposal bit set. The Proposal BPDU will include cost information and BID. Through your typical RP/DP/BLK election process the other two switches will send na Agreement back, which will then provide the switch that send the proposal with the information needed to make decisions about port assignments. After this part, the two switches connected to the switch that was just thrown up, will then block all their p2p links and start the process over again.

Is this correct or am I missing something?

Cisco Employee

Re: RSTP convergence few questions

Hello John,

Let's go over the individual statements.

it will immediately blocks its non-edge designated ports as long as their p2p(full duplex).

It  will indeed block its non-edge ports but not because of point-to-point  link nature but merely because the Designated Discarding role/state is  the default, initial role/state for a new port on which RSTP has just been  enabled. The same would be also valid for Shared link types.

Then this switch will send out BPDUs with the Proposal bit set. The Proposal BPDU will include cost information and BID.

Correct. Note that the Proposal is just a BPDU with a particular bit set in the Flags field but otherwise it's just an ordinary BPDU. The Proposal will be sent because the port is in Designated Discarding state, and the Proposal is sent on Designated Discarding and Designated Learning ports - however, they must be on p2p type links. Proposals are not sent on shared link types.

Through your typical RP/DP/BLK election process the other two switches will send na Agreement back

No, this is generally an incorrect assumption. A Proposal absolutely does not need to be be replied to by an Agreement - it may very well go unnoticed. If a switch sends an Agreement from one its ports then it declares that this port is its new root port, that the link may immediately become forwarding, and that all its other non-edge Designated ports have been moved to Discarding state (the Sync operation). But you have just plugged a switch in the middle of a network, and generally, it is not clear at all if this switch provides a better path towards the root than what the remaining switches already have.

To be perfectly correct, while your new switch indeed starts sending Proposals, the surrounding switches will see that these Proposals are inferior to BPDUs they originate themselves, because this new switch is not a root switch (although by default, it declares itself as a root switch). They will therefore not be influenced by the first BPDUs produced by this new switch, and they will simply send it their own BPDUs - with Proposal bit set, as the connection of the new switch has caused their previously deactivated ports become active, and hence Designated/Discarding (and therefore eligible to send Proposals).

The new switch will, upon receiving these BPDUs, note who the real root switch is, and eventually elect its own root port. Upon receiving one of the Proposals on this root port, it will put all its non-edge Designated ports into Discarding state (they are there already, as this all happens in a few seconds at most) and confirm to the upstream switch that this link is ready to be put into forwarding state by sending an Agreement. Both switches will then put the port into Forwarding state - the upstream switch will keep the port role as Designated, this new switch will declare it as the Root port.

Subsequently, all following BPDUs produced by this new switch will carry the new correct root switch ID and the appropriate root path cost. The remaining Designated Discarding ports will continue sending Proposals containing these new data. If the surrounding switches decide that this new switch provides a better path towards the root than they already have, they will Sync their non-edge ports and send an Agreement to make the link immediately forwarding.

Because the Sync operation on surrounding switches results in non-edge Designated ports become Discarding, they will start sending Proposals themselves, and the entire logic repeats further on those ports, one step further from the new switch. This is how the Proposal/Agreement wave propagates through the network. However, if this wave propagates up to a link on which there is no root port going to be elected, the Proposals will not be replied to by Agreements, and the wave will be dissipated here, and the entire process of handling the new switch will therefore be gradually finished.

Does this make sense?

Best regards,

Peter

Re: RSTP convergence few questions

Thanks for the clarification Peter. I'm going to study your post when I get home from work.

New Member

Re: RSTP convergence few questions

This is the explain that i needed , thank you , but from my side only one question ..

How surrounding switches know that the bpdu from new switch is inferior bpdu ..

Thanks a lot ...

Cisco Employee

Re: RSTP convergence few questions

Hi Roman,

BPDU can be compared to each other and this comparison tells you that one of these BPDUs is better (superior) than the other (which is inferior).

Comparing BPDUs is a process that takes certain numerical values from these BPDUs in a predefined sequence and compares them to each other. The BPDU containing the smaller value is superior, the second one is inferior. If the values are identical, the next values in the sequence are compared, until the first inequality is found, in which case the BPDU with the smaller value at this step will be superior.

The sequence of compared values is:

  1. Root Bridge ID (consisting of priority, VLAN ID and root bridge MAC address)
  2. Root Path Cost
  3. Sending Bridge ID (consisting of priority, VLAN ID and sending bridge MAC address)
  4. Sending Port ID (consisting of priority and sending port index)
  5. Receiving Port ID (consisting of priority and sending port index; not stored in BPDU)

You start with the first value in this sequence - Root Bridge ID - and compare the BPDUs on this value. If one BPDU contains a smaller value here, it is immediately declared superior. Otherwise, if both BPDUs have the same value of the Root Bridge ID, you proceed to the second value in this list - Root Path Cost - and compare the corresponding values in both BPDUs. If one of them is smaller, it is superior. Otherwise, they are equal, and you proceed with the third step, and so on.

Now, a newly attached switch does not know who the root bridge is, and it considers itself as a root bridge. However, the surrounding switches know who the real root bridge is, and its Root Bridge ID is certainly smaller (because otherwise, the newly attached switch would become the new root). So as soon as the surrounding switches receive BPDUs originated by the new switch, they compare them to their own BPDUs and see immediately using the first item from the list above that the new switch is producing inferior BPDUs to their own.

Best regards,

Peter

New Member

Re: RSTP convergence few questions

Now it's more clearly for me , from your submission is better to understand it as from cisco materials

Re: RSTP convergence few questions

This is because, when a switch first starts up, it believes itself as the root switch. All switches do this by default. If you think about it, they have no way of knowing any better, since they have not heard any BPDUs yet. Of course this all happens very fast. BPDUs will carry cost and BID information within each BPDU. When the surrounding switches receive

the proposal which is just a BPDU (still has cost and BID information) with the Proposal bit set, they examine the BPDU and see that they have a better both to the root, and that BPDU send from the new switch is inferior. Remember it basically compares BPDUs, it says HEY! You have a higher cost than what I currently have on my port.

Re: RSTP convergence few questions

LOL peter, you beat me to it.

Cisco Employee

Re: RSTP convergence few questions

Hi John,

No, not at all. And besides, I am sure that Roman will only benefit from having more viewpoints.

Did the yesterday's debate on details of the RSTP bootup on the new switch make sense to you? Somehow, STP/RSTP do have a certain degree of randomness in them, until the network stabilizes, and it's quite hard to go in details.

Best regards,

Peter

Re: RSTP convergence few questions

Yeah, it cleared up a few things.

From what I can understand, if I throw up a switch in the middle of a network which we will call A and A has connections to B and C for redundancy. The ports from A to B and A to C will be put in Designated Discarding by default, which will then cause the port to be eligible for sending Proposals. A will send a Proposal to B and C. B and C will not accept the proposal because when they look at the information contained in the BPDU with the proposal bit set, it will conclude that both B and C have a better path to the root (in this instance we will say they do), and will each send proposals back to A informing it that B and C have a better path to the root. Once your typical SPA runs it will select a root port, and immediately put it into forwarding. Of course the other link is still blocking via your SYNC process. Otherwise if it wasn't this would causing a switching loop. Is this correct?

And obviously, if A had a better path to the root than B, B would send an Agreement back to A, and elect the port from B to A as it's root port, while still blocking all its non-edge ports. B would then send proposals out all its non-edge p2p links. There by starting your Sync Flood.

Cisco Employee

Re: RSTP convergence few questions

Hi John,

Of course the other link is still blocking via your SYNC process.  Otherwise if it wasn't this would causing a switching loop. Is this  correct?

Yes, it is correct.

And obviously, if A had a better path to the root than B, B would send  an Agreement back to A, and elect the port from B to A as it's root  port, while still blocking all its non-edge ports. B would then send  proposals out all its non-edge p2p links.

Correct.

Best regards,

Peter

New Member

Re: RSTP convergence few questions

Hello, Peter!

Can u clarify next:

Peter Paluch написал(а):

It  will indeed block its non-edge ports but not because of point-to-point  link nature but merely because the Designated Discarding role/state is  the default, initial role/state for a new port on which RSTP has just been  enabled. The same would be also valid for Shared link types.

Peter Paluch написал(а):

Correct. Note that the Proposal is just a BPDU with a particular bit set in the Flags field but otherwise it's just an ordinary BPDU. The Proposal will be sent because the port is in Designated Discarding state, and the Proposal is sent on Designated Discarding and Designated Learning ports - however, they must be on p2p type links. Proposals are not sent on shared link types.

From this i can make assumptions that Shared link after bringing up will start in designated discrading state and will not send proposal bit in outgoing BPDU, but from this we can make conclusion that on such segment (shared) no one switch will send BPDU with proposal bit - so how such segment will converge? By using legasy STP rules - through using timers and gradient algorithm?

Another question - will Shared port participate in proposal-agreement process if it received BPDU with proposal bit set? And how is it possible that on shared segment such BPDU arrived? I think all ports connected to segment has shared type and as you said - didnt send BPDU with proposal bit.

And mine observations - i have segment where all ports shared (two access layer switches connected to remote distribution switch through SDH MUX with ethernet ports but not partisipating in STP) but this segment converge in less than second, so seems it obey to same RSTP rules as p2p ports. So i am totally confused with difference between shared and p2p ports. =(

Regards.

Cisco Employee

Re: RSTP convergence few questions

Hi Alexey,

From this i can make assumptions that Shared link after bringing up will  start in designated discrading state and will not send proposal bit in  outgoing BPDU

Correct.

but from this we can make conclusion that on such segment (shared) no one switch will send BPDU with proposal bit

Correct.

so how such segment will converge? By using legasy STP rules - through using timers and gradient algorithm?

Exactly. Shared segments do not use the Proposal/Agreement mechanism and instead converge using timers.

Another question - will Shared port participoate in proposal-agreement process if it received BPDU with proposal bit set?

No, it should not. A port connected to a shared-type link should always proceed through the Discarding/Learning/Forwarding state using timers.

And how is it possible that on shared segment such BPDU arrived?

Likely a duplex mismatch, resulting in RSTP deducing a wrong type of the link, or misconfiguration.

i have segment where all ports shared (two access layer switches  connected to remote distribution switch through SDH MUX with ethernet  ports but not partisipating in STP) but this segment converge in less  than second, so seems it obey to same RSTP rules as p2p ports

Ports connected to a shared link may theoretically become immediately forwarding if they are identified as Alternate Discarding and the current root port fails. Apart from this, no rapid convergence on shared links should take place. It would be necesssary to see your configuration and show spanning-tree output to see what is going on.

Best regards,

Peter

New Member

Re: RSTP convergence few questions

Ports connected to a shared link may theoretically become immediately forwarding if they are identified as Alternate Discarding and the current root port fails. Apart from this, no rapid convergence on shared links should take place. It would be necesssary to see your configuration and show spanning-tree output to see what is going on.

The case in that both ports on both acess switches is in forwarding state, blocking port located on link between them.

But i found out that it is possible - fast convergence on shared link, in case when all ports threated as full duplex by default - but this situation can lead to temporary loops, cos designated switch will unblock port after first agreement receiving, without awaiting other bridges confirm that all ports put in sync state. But in my case all ports mannualy set to shared link-type, so this is not aplicable to my situation. But i have big doubts now that maybe i really fixed link type after i saw how fast segment converge - will try check behaviour next maintain window and report.

Besides Peter, maybe you can help me with understanding this:

Recently i decide to refresh my knowledges of STP and red Uderstanding RSTP document over and noticed interesting (for me at least) thing -

new to RSTP flags - describing portrole has bits pointed to  Alternate/Backup state of port. Question is - in what circumstances its  possible to receive BPDU with such flag?

And other question - why is Discarding state ommited in the flag? From my opinion here two options for appearing such state:

  • Proposal bit can appear only on port in Designated Discarding state - so to describe this state flag bit for Discarding state required
  • If Alternate/Backup role of port is presented, its seems to be logical that this port role most of time corresponds to Discarding state and BPDU with such role may have flag with bit pointed to Discarding state
Cisco Employee

Re: RSTP convergence few questions

Hello Alexey,

But i found out that it is possible - fast convergence on shared link, in case when all ports threated as full duplex by default

This is rather untypical scenario. A shared link that works on a full duplex is usually caused by a non-STP switch interconnecting a bunch of other switches together. This will cause the other switches to have their link operating in full duplex and leading the STP implementation to a mistaken conclusion that the link is of the point-to-point type.

Please note that the derivation of the link type (p2p/shared) depending on the duplex setting is only a simple heuristic implemented by Cisco. It is absolutely not supported by the STP standard. What Cisco switches do is a simple educated but still naive guess - if the link operates in half duplex then it must be connected to a hub, because a hub is never able to operate in full duplex, and hence the link is shared. Otherwise, if the link operates in full duplex, it is probably directly connected to other switch and that switch is expected to run STP, hence the p2p mode. But the situation when a number of switches is interconnected by a non-STP switch is a non-standard scenario and can not be handled automatically.

There is no guaranteed way of detecting the link type (p2p/shared), and there is no guaranteed way of detecting the port type (edge/non-edge). That is why you have to be very careful about the real physical topology, and configure the ports appropriately.

new to RSTP flags - describing portrole has bits pointed to   Alternate/Backup state of port. Question is - in what circumstances its   possible to receive BPDU with such flag? 

A very good question that has caught me quite unprepared! Clearly, we know that usually ports in Alternate/Backup role do not send BPDUs.

One thing coming to my mind is a feature introduced by Cisco called the Bridge Assurance where all ports send BPDUs, regardless of their role/state, and the BPDUs therefore become a fully fledged Hello mechanism. In this case, it would make sense.

Another use may arise in MSTP when a port may be in a different role/state in different instances. As MSTP uses a single large BPDU to describe all instances, there can be situations in MSTP where opposite ports on the same link both send MSTP BPDUs.

In general, however, I have a feeling that the role flags were added to the RSTP BPDUs primarily for debugging purposes, not necessarily to perform any explicit action. They are being used in recent implementations as a means to prevent unidirectional links (the so-called Dispute mechanism) but as far as the standard goes, there is no much usage described.

And other question - why is Discarding state ommited in the flag?

Perhaps it is because the Learning/Forwarding bits have to be interpreted slightly differently. If you capture RSTP BPDUs, you will see that these BPDUs sent from a  Designated Forwarding port carry both Learning and Forwarding flags set. That would implicate the following interpretation:

  • If a port forwards frames, the Forwarding bit will be set. Otherwise, it will be cleared, signifying either Discarding or Learning states.
  • If a port learns MAC addresses, the Learning bit will be set. Otherwise, it will be cleared. So, having both Learning and Forwarding bits cleared, we have the Discarding state. Having Learning set to 1 and Forwarding clear, we have the Learning state. Having both Learning and Forwarding bits set to 1, we have the Forwarding state. There is no meaning for Learning=0, Forwarding=1.

Proposal bit can appear only on port in Designated Discarding state - so to describe this state flag bit for Discarding state required

Not true - Proposals are set on BPDUs sent from Designated/Discarding and Designated/Learning ports.

If Alternate/Backup role of port is presented, its seems to be logical  that this port role most of time corresponds to Discarding

All the time - not most of the time. An Alternate/Backup port can never be on a way to Forwarding state and hence be in the transitory Learning state.

Best regards,

Peter

1576
Views
28
Helpful
16
Replies
CreatePlease login to create content