RSTP Proposal/Agreement Process

[JohnTylerPearce]

I just wanted to verify that my understanding of this process is correct.

SWA<=====>SWB   (SWA has the lower BID)

SWA is powered on first.

SWA will send its superior BPDU to SWB, whos port starts in the discarding state. SWB comes to the conclusion that

the port to SWA from SWB is the root port, and sends an agreement back to SWA. This starts the Sync process, where

all non-edge ports are blocked. The communication from the link between SWA and SWB are now in their correct port roles.

Then the process happens again on SWB to SWC if one exists.

[InayathUlla Sharieff]

John,

your explanation is Quite on the way

Here is the best example with video you can see how this happens:

http://www.youtube.com/watch?v=Pbv2wLQ2xyY

The "SYNC" means that all non-edge Designated ports have been put into Discarding state. These ports by definition send Proposals (each Designated Discarding or Designated Learning port sends Proposals). If their Proposal is not replied to (and no superior BPDU is received in these ports), they will gradually proceed from Discarding to Listening to Forwarding. After reaching the Forwarding state, the Proposal bit will cease to be set.

HTH

Regards

Inaayath

[Peter Paluch]

Hello Inayath,

That video is a screen recording of the CCNA Exploration 3 curriculum. However, the particular animation is wrong, and I have submitted a ticket to the team that maintains the curriculum regarding that animation in 2009. Although it was accepted after a couple of iterations, it never got implemented. To explain what is wrong with that animation, I am copying from my original ticket here:

1.) The proposal/agreement process between S4 and S2 should take place  in the opposite direction. Presently, the S2 is shown to send a proposal  to the S4 and S4 is shown to reply with an agreement. This is incorrect.  A proposal may be sent only by a Designated port in the Discarding or  Learning state, as described in the Cisco document "Understanding Rapid  Spanning Tree Protocol" at

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

which says:

"When  a designated port is in a discarding or learning state (and only in  this case), it sets the proposal bit on the BPDUs it sends out."

On  the link between S4 and S2, the S4's Fa0/2 is the Designated port while  the S2's Fa0/2 is the Root port so the S2 is not allowed to send  proposals on that link. Thus, the correct sequence of events is that the  S4 sends a proposal to the S2 and it replies with an agreement to S4  after it blocks all its non-edge ports.

2.) The  proposal/agreement process between S2 and S3 will not take place at all,  as opposed to the animation. It is true that S2 may send a proposal to  S3. However, both S3 and S2 already have a different Root port elected  and the arrival of the BPDU from either side will not change that  selection. This means that the link between S2 and S3 must be blocked,  otherwise a loop would be formed transiting these two switches. A  proposal/agreement process, on the other hand, is used to put a link  into a forwarding state rapidly. Therefore, even if either S2 or S3  sends a proposal to its neighbor, no agreement may be sent because the  link between S2 and S3 must remain blocked.

The real sequence of events would be:

- S2 may send a proposal to S3

- S3 may send a proposal to S2

-  After mutual exchange of BPDUs eventually containing proposals, each  switch will be aware of the fact that the link must remain blocked, as  the root port on either switch is not changed. Therefore, after  exchanging the BPDUs on the link between S2 and S3, it will immediately  be clear which port is the Designated and which is the Alternate port on  that link. The Alternate port will cease sending BPDUs and will remain  in Discarding state while the Designated port will slowly transition  from Discarding to Learning to Forwarding state. However, no agreement  at all will be sent from either switch, and no other non-edge ports will  be blocked as a result of receiving a proposal.

Best regards,

Peter

[InayathUlla Sharieff]

Thanks Peter,

Yes you are correct I overlooked at the video again yes they need to change a bit on that animation video as you suggested.

Regards

Inayath

[Peter Paluch · Accepted solution]

John,

SWA will send its superior BPDU to SWB, whos port starts in the discarding state. SWB comes to the conclusion that the port to SWA from SWB is the root port, and sends an agreement back to SWA. This starts the Sync process, where all non-edge ports are blocked.

The sequence of steps is not entirely right. Correctly, it should follow this sequence:

(Just to stress a very important fact before going into the sequence of steps, keep in mind that the SWA's port will come up as Designated Discarding, as this is the default port role and state in RSTP. Every Designated Discarding (and Designated Learning) port sends BPDUs with the Proposal bit set. SWB's port will also come up as Designated Discarding and may send Proposals as well but at this point, it is not relevant because after receiving a superior BPDU from SWA, SWB's port role will change to Root.)

1. SWA will send its superior BPDUs from its Designated Discarding port with Proposal bit set to SWB
2. After receiving a superior BPDU, SWB comes to the conclusion that this port is the Root port. SWB will transition this port from Designated Discarding to Root Discarding. Furthermore, as a result of receiving a Proposal on a Root port, SWB will put all non-edge Designated ports into the Discarding state. This is the Sync operation.
3. Only after Sync completes, i.e. all non-edge Designated ports are put into Discarding state, SWB send an Agreement back to SWA and moves the Root Discarding port into Root Forwarding
4. Upon receiving the Agreement from SWB, SWA will move its Designated Discarding port to Designated Forwarding
5. On SWB, ports that have been put into Designated Discarding state as the result of this Sync operation, will start sending Proposals, i.e. the "cut" has moved from between SWA and SWB to beneath SWB

Best regards,

Peter

[sandipmtech]

Hi Peter,

First i want say thanks.

It's great explanation of proposal/agreement. I have one doubt,Is there any scenario in RSTP the port remain stay in Designated discarding state insted of slowly comming into designated forwarding.

e.g     SWA(P4)------------(P5)XXXX

           (P3)

            |

            |

            |   

           (P2)

       SWB(P1)---------------(P6)XXXXX

P6,P2->Designated forwdingstate,P3->Root forwarding.On  P4 port i disabled the BPDUTx and BPDURx.

at this scenario,is there any chance P4 is going into designated disable state forever.

Thanks,

sandipmtech

[Peter Paluch]

Hello,

You are heartily welcome!

Is there any scenario in RSTP the port remain stay in Designated  discarding state insted of slowly comming into designated forwarding

In pure 802.1w RSTP, the only reason for a port to remain in Designated Discarding state is during a so-called Dispute condition: when two or more ports on a common segment consider themselves to be Designated. As this is an illegal situation and often suggests at an uni-directional link condition, the true Designated port (that one which is entitled to be Designated) is put into Discarding state to prevent a loop from occuring. The presence of multiple Designated ports on a common segment is easily detected in RSTP, as its BPDUs carry the role and state of their sending port encoded inside the Flags field.

Apart from this situation, there is no reason in pure 802.1w RSTP for a port to remain Designated Discarding.

P6,P2->Designated forwdingstate,P3->Root forwarding

I am not quite sure where is the root bridge in your topology. This description suggests that it is the XXXXXX switch at the bottom right with the P6 port, and the P1 on SWB should then also be considered a root port.

On  P4 port i disabled the BPDUTx and BPDURx.
at this scenario,is there any chance P4 is going into designated disable state forever

In pure RSTP, no. If, however, you had Cisco Loop Guard activated on the P4 and the port was not Designated before you deactivated the BPDU Tx and Rx, the loss of received BPDUs on this port will cause Loop Guard to put it into Designated Discarding state.

Best regards,

Peter

[EmmanuelEgbewatt09995]

Hello Peter, 

You explanation is awesome. I just have one doubt, is the root bridge elected before the proposal/agreement handshake process? If yes, then why is the proposal BPDU called a SUPERIOR BPDU ?

I know you have explained this previously but to make sure i am on the right track, i have listed how i understood the process below: 

From what I understood, to participate in RSTP convergence, a switch must decide the state of each of its ports and when a RSTP enabled switches are powered on, the non-edge ports remain in designated/blocking or discarding state, correct?

These switches will start to exchange the configuration BPDUs of which the proposal bit is set to one.

Imagine that we have two switches SWA and SWB, and when these switches are powered on, both switches claim to be the root switch of the segment and they will both start exchanging BPDUs. SWA send a configuration BPDU with the proposal bit set to 1, when SWB receives this BPDU and see’s that it is a SUPERIOR BPDU, it considers the port that it receives this BPDU to be a root port, am I correct?

SWB will put all its ports to discarding state and sends its own BPDU proposal to its downstream neighbors, when it receives a responds from its downstream neighbors, it will the transition its root port to forwarding state and send a BPDU agreement to SWA set to 1 and proposal bit set to 0 . SWA ports will transition to forwarding.

I thought this superior BPDU was also to elect a root bridge or to see which device is having the best BID or.. to become the root switch?  If otherwise, what’s the meaning of the Superior BPDU here?

Please could you clarify me on this ?

Thanks in advance

Emmanuel