some fundamental questions

Answered Question
May 8th, 2010

Hi All,

I understand how a root bridge is selected - that is the one with the lowest Bridge ID.

But this is easily seen when we know how many switches there are in deployment and what bridge ID each switch has, my question is how does a switch figure it out it is the root bridge?

My understanding is that with 802.1D, once we physically connected all switches together, STP is turned on by default. So all switches start sending BDPUs to their neighbouring switches and claiming themselves as the root bridge, if a neighbouring switch has a lower bridge ID, it will ignore the received BPDU and send its own to the previous sending switch, once the previous sending switches receives the BPDU with a lower bridge ID, it knows instantly it's no longer the root bridge, and starts propagate the superior BPDU to all other neighbouring switches except where the superior BPDU came from.

Is the above description correct? If so, when does the above process arrive at a conclusion? How does the bridge know it is for sure it has the lowest bridge ID? Is it since it no longer receives a even more superior BPDU from any of its nonedge port? Just because it hasn't yet received a more superior BPDU just yet, how does it know it won't? I know one would argue that's the reason for Root Guard, but Root Guard comes in only after a stable topology has formed - Root Bridge is already found, but my question is how does a bridge convinces itself it is the root bridge before a root bridge is already announced? Is there a time constraint that says by a certain time period, if a bridge hasn't received a superior BPDU rather than its own, it is the root bridge? If so, what's the time limit?

My second question is, when we configure RSTP, we configure the switches one at a time. Suppose all switches start as normal STP, when one switch is configured as RSTP, it will send a BPDU to the neighbouring switch to claim itself as the designate switch on that segment. Since the neighbouring switch is still 802.1D, it will not sync, which causes the first switch which has just been configured as RSTP to fall back to 802.1D, is this true?

Once the second switch is configured as RTSP, the sync completes?

If there are three links connected between two switches using RSTP, when a proposal is send out from one port, the receiving port on a neighbouring  needs to block all other ports, and then completes the sync process. And this will happen again when the second and third port send a proposal to the neighbouring  switch again? Does that mean there is going to be a cut off in traffic for three times? Or the answer is it won't, since when the second port sends a proposal, the second port on the neighbouring switch won't block all other ports since it knows this port has to be in blocking? Text book says before a switch agrees to anything, it will put all ports in blocking - I don't know if that means as soon as, or if it won't be blocking, as soon as.

Could experts please explain?

Thanks,

Chris

I have this problem too.
0 votes
Correct Answer by Jon Marshall about 6 years 7 months ago

Peter

Great response, deserves a rating. Good to see you back in the forums again.

Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Peter Paluch Sat, 05/08/2010 - 23:59

Hi Chris,

As to the root bridge election, you are basically correct. Whenever a switch supporting STP is turned on, it considers itself a root switch and so it declares its own Bridge ID (BID) as the Root BID in the BPDUs it sends out. As soon as it receives a BPDU that contains a lower Root BID, it immediately ceases to consider itself a root switch and continues to announce the lower Root BID in its BPDUs. And if later a new BPDU arrives with even lower Root BID, that one will replace the currently stored Root BID.

You have asked when does this process arrive at a conclusion. The answer is that it never does. With each received BPDU, a switch reevaluates all affected STP parameters: whether the Root BID has changed, whether the root port should change, whether the port receiving the BPDU shall remain in its present role/state. In a stable network, all switches will arrive at an apparent STP conclusion after a few iterations of BPDU sending/receiving, however, their evaluation is continuous and never ends.

Your remark about the Root Guard feature is, I believe, not important at this point. The fact is that the Root Guard is configured on a port basis and kicks in every time that port receives a BPDU whose Root BID is even lower than the Root BID of the currently known root switch. There is no waiting for topology to stabilize.

Regarding your questions about RSTP: If a RSTP switch is connected to a 802.1D STP switch, the RSTP will fall back to STP operation on that port. No proposal/agreement process will be attempted. Regarding the proposal/agreement mechanism, it goes as follows: a port sends proposals if and only if it is the designated role and discarding or learning state (note that this requires that the port is superior to its counterpart on the other end of the link). If the other switch determines that the port should go into forwarding state (note that this means that the port will be a new root port), it first puts all its existing non-edge ports into discarding state (the sync) and then signals it via an agreement to the upstream switch. Both switches can then immediately put the ports into forwarding state, and the link has thus rapidly became forwarding. Notice now that as a result of the sync operation, some of the designated ports on the second switch may have been put into discarding state while retaining their designated role. Because a port in designated role and discarding or learning state sends proposals, the proposal/agreement mechanism has effectively now moved "below" the second switch.

If there are three links between two RSTP switches then the root switch (or the switch that is closer to root) will, at the beginning, obviously have its ports in designated role and discarding state, and so it will send proposals on those ports. The second switch will receive three BPDUs with the proposal bit set on its three ports. One of these ports will be elected as a root port, the remaining ports will be put into Alternate Discarding role/state (the Alternate role is a result of simple comparing all received BPDUs to each other, not a direct result of proposal/agreement operation). Upon receiving a proposal on the root port (which is still discarding), the second switch will try to block all non-edge designated ports. As there are none, the work is basically finished, and the switch replies with agreement on its root ports towards the root switch, and the link becomes forwarding. The Alternate Discarding ports have been discarding from the start, and because they are not supposed to transition into forwarding state, they will ignore all proposals and won't respond at all. The root switch will therefore simply slowly proceed from Discarding to Learning to Forwarding states on its remaining two ports towards the second switch.

This is a nice article on Cisco website about the RSTP operation. Give it a look, it was very helpful for me.

Best regards,

Peter

Correct Answer
Jon Marshall Sun, 05/09/2010 - 02:16

Peter

Great response, deserves a rating. Good to see you back in the forums again.

Jon

Peter Paluch Sun, 05/09/2010 - 05:36

Jon,

Thank you so much for your kind words - it is a wonderful feeling to be back here! The semester is closing at my university and I am finally having more time to spend around - and I am really glad to meet all you the great people around here again.

By the way, congratulations on becoming a member of the Hall Of Fame! You absolutely deserve it.

Best regards,

Peter

Chris Zhang Sun, 05/09/2010 - 03:41

Hi Peter, thanks for the response. It is an outstanding answer.

The never-ending re-evaluation part clears my head pretty well.

"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. "

and

"If a designated discarding port does not receive an agreement after it sends a proposal, it slowly transitions to the forwarding state, and falls back to the traditional 802.1D listening-learning sequence. This can occur if the remote bridge does not understand RSTP BPDUs, or if the port of the remote bridge is blocking."

helped a lot too.

Thanks

Chris

Peter Paluch Sun, 05/09/2010 - 05:37

Hello Chris,

You are heartily welcome. I am glad I could be of help.

Best regards,

Peter

Actions

This Discussion

Related Content