RSTP proposal agreement process

EdTheLad

Ok i havent time to test this so i decided to ask here, i wish others who are studying ccie would do the same as its a good way to share info.

1) Connecting two switches back to back, the ports default to designated discard state, in this state they transmit bpdu's with the proposal bit set in the bpdu.They will
stay in this state until a bpdu is received from a neighboring switch.Ok if this is the case , that means if you connect and end device you must ensure to enable portfast
otherwise the port will always stay in a discard state and never pass traffic.

2) I have a hub and spoke arrangement, Switch A is the hub connecting to two spokes B and C. The proposal agreement session is complete and both B and C saw A as the root so placed there nonEdge ports in discarding state and the ports conected to A in forwarding state.Now i connect B and C together, both ports start in designated discarding state, send bpdu's with the proposal bit set, B has the lower sender BID so it has the superior bpdu, so as the synch process goes this should block all nonEdge ports, so the port to A i.e. the root port would be blocked.C would then do the proposal agreement between itself and A, A would win and C would block its port to B.As you can see a vicious circle.So whats the exact steps? Is the root port blocked during the synch process or not?

DW [banned]

Thanks

EdTheLad

I have read and understood this document but it doesnt answer my question, i understand 802.1d very well and i know all the extras like uplinkfast bankbone fast etc.802.1W however has its differences.The second part of my question is regarding the proposal agreement handshake not just monitoring received bpdu for the superior and electing a designated bridge as is done in 802.1d.
It surprises me that you never seem to be able to answer any tech queries, anyway i'll just have to sim it up later.

DW [banned]

Again

DW [banned]

Thanks

DW [banned]

Thanks

EdTheLad

DarbyWeaver wrote:

EdTheLad wrote:

Ok if this is the case , that means if you connect and end device you must ensure to enable portfast otherwise the port will always stay in a discard state and never pass traffic.



Can you tell me where you read this one and how you came to this conclusion?

Did you read this part?

Yes, i read that part.

From the doc you provided.
Proposal/Agreement Sequence
When a port is selected by the STA to become a designated port, 802.1D still waits twice <forward delay> seconds (2x15 by default) before it transitions it to the forwarding state. In RSTP, this condition corresponds to a port with a designated role but a blocking state. These diagrams illustrate how fast transition is achieved step-by-step. Suppose a new link is created between the root and Switch A. Both ports on this link are put in a designated blocking state until they receive a BPDU from their counterpart.

Both ports stay in a designated blocking state until they receive a bpdu from there counterpart.Check the diagram this explanation is regarding connecting two switches back to back.Image one of the switches is actually a host, now the switch doesnt receive a bpdu so it stays in designated blocking state.So as you can see the explanation isnt so clear cut, if the host is connected to the switch via a full duplex ptp link will it stay blocked if i dont enable portfast.

DW [banned]

Thanks

DW [banned]

Thanks

DW [banned]

Thanks

DW [banned]

Thanks

EdTheLad

The problem is i cant find a concise explanation of rstp, i've got 802.1d down to a T but rapid is a different story.It gets very confusing when you start mixing half duplex and full duplex ports.I've tried to read the ieee standard but it jumps all over the place,give me an rfc any day.
Anyway like everything else this is gonna break my heart for the next few days until it jumps out and hits me.

DW [banned]

Thanks

DW [banned]

Thanks

EdTheLad

First part tested, i configured a routers eth as full duplex and switchport as full duplex.The switchport comes up as designated blocked, it sends out the bpdu's with the proposal bit marked every 2 seconds.After the forwarding time it transitions to learning and again transitions to forwarding.So basically it still operates just as 802.1d. Cisco's explanation failed to mention these important details.

Stay tuned..

DW [banned]

Thanks

EdTheLad

Second problem solved, a port in designated discard state will send bpdu's with the proposal bit sent.In the senario i depicted Switch A was root.
So both B and C have root ports to A. As soon as i connect B and C together they must exchange BPDUs with the proposal bit set.
SwitchB has the lower bridge id so its port maintains the designated state, SwitchC will see the superior bpdus comming from B and change its port to the alternate state as it already has a direct path to root.
Switch B will continue to send proposals but it never gets an answer from C as C is not in discard state.No rapid transition will occur so the port on SwitchB will have to wait the standard 2 x forwarding.