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

RSTP Proposal/Agreement Process

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: RSTP Proposal/Agreement Process

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

6 REPLIES
Cisco Employee

RSTP Proposal/Agreement Process

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

Cisco Employee

RSTP Proposal/Agreement Process

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

Cisco Employee

RSTP Proposal/Agreement Process

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

Cisco Employee

Re: RSTP Proposal/Agreement Process

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

New Member

Re: RSTP Proposal/Agreement Process

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

Cisco Employee

Re: RSTP Proposal/Agreement Process

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

4155
Views
15
Helpful
6
Replies
CreatePlease to create content