RSTP alternate port behavior

[Alexey Stytsenko]

Good day, folks.

In Petr Lapukhov document "understanding-stp-and-rstp-convergence" in section where considered convergense process  in case of root bridge failure

(see pic.1 and notice that bridge X and bridge Y have best priorities in corresponded side and will be elected as temporary bridge, btw X has better BID than Y)

                                             Pic. 1

there is a possible pace of developments:

If the bridge “A” hears about “X” before it hears about “Y”, it will invalidate 
cached information about “R” and reach an agreement with “X” about new 
root bridge. At the moment when inferior information from “Y” reaches “A”, 
the latter will properly synchronize with “Y”, and a new root bridge will be 
elected. The extra synchronization time required to wipe out old root 
bridge “R” information is no longer required, as this information is never 
propagated to “Y”. 

I cant get why "A" should invalidate cached information about “R”, if it has ALTN port and didnt hear on it any iferior information from "Y"? In my understanding when “A” hears about “X” it should make re-root operation (cos it still thinks that "R" alive on it ALTN port) - change it ROOT port to previoulsy ALTN and start sync process downside to "X" bridge propagading that it have path to "R".

Only after inferior information from “Y” reaches “A”, it will try to propagate this information again downside to "X" bridge. "X" will reject this and start anounce himself as the root and propagation wave will bounce back to "Y". After this topology will become converged.

So the question - who is right here? I bet on Petr Lapukhov but want clarifications. I cant get why bridge can accept inferior information still having ALTN port to previous root bridge.

[paulstone80]

Hi Alexey,

I just read this document and this is what I understand to happen.

Bridge A invalidates the information about R because X has declared itself root.

Bridge A will no longer receive information from R because R has failed, therefore it can not be considered the root bridge.

Due to the time it takes for RSTP information to propagate through the clouds, bridge A only hears root election information from X, so it believes X is root.

It takes time for the root information from Y to propagate to A, and by the time A receives the root election information from Y, it already believes X is root.

Does that answer your question?

HTH

Paul



****Please rate useful posts****

[Alexey Stytsenko]

Does that answer your question? 

Ofcourse no. You just paraphrase what adduced in quotation in initial post.

Question is - why "Bridge A invalidates the information about R because X has declared itself root"? It have alive ALTN port where no information about "R" failure yet arrived and should unblock it instead of invalidating information about "R".

[paulstone80]

Bridge A only has an ALTN port whilst it continues to hear Hello-BPDUs from the root bridge.

If A doesn't hear any Hello-BPDUs for the max-age time it assumes the root is no longer reachable on that port.

HTH

Paul



****Please rate useful posts****

[Alexey Stytsenko]

From where you derive information that max-age timer passed? I think information about direct failure will propagate to bridge A much fuster than max-age expires. It rather logic and no mention of inderect failure in Peters article.

If A doesn't hear any Hello-BPDUs for the max-age time it assumes

RSTP has different mechanics than IEEE STP - BPDUs not relayed but generated every hello-interval by every bridge. So 'A'  will hear BPDU but message-age will grow untill get max-age and then previous learned information will be invalidated.

[Aninda Chatterjee]

Hi Alexey,

That is how RSTP is designed. It is meant to accept inferior BPDUs (unlike 802.1D which will discard them till max age expires and the BPDU ages out) and invalidate the previously cached information for that port.

Please see the section "Accepts inferior BPDUs" in the following document:

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

So, in this situation, when the root port of A receives inferior BPDUs from X, it immediately accepts it and ages out previously known root bridge information, because of which it cannot unblock its alternate port and move it to root forwarding - that port is essentially not an alternate port anymore since the root has changed. It then tries to sync this information downstream and so on.

This design does make convergence faster since we are not waiting for stale BPDU information to age out anymore, however, in certain situations (with the topology like the one above and the special race condition described), it can cause some unwanted delay too.

Cheers,

Aninda

[Alexey Stytsenko]

That is how RSTP is designed. It is meant to accept inferior BPDUs (unlike 802.1D which will discard them till max age expires and the BPDU ages out) and invalidate the previously cached information for that port.

Good day.

Let me qoute link you adduced:

The       IEEE 802.1w committee decided to incorporate a similar mechanism into RSTP.       When a bridge receives inferior information from its designated or root bridge,       it immediately accepts it and replaces the one previously stored. 

Thats treated to port level - it accept and replace BPDU for port but this dont mean that  it will choose new root having alive ports to old one (and better one as well). Here quoutations from Understanding and Configuring Backbone Fast on Catalyst Switches:

A bridge stores the value of the BPDU on a port sent by the       current designated bridge. 

When S receives this new BPDU from B, it realizes it is inferior to             the one it had stored for port P and ignores it.

S has now checked all its non-designated ports, and it still has             connectivity to the root. It can then age out immediately the information             stored on port P. P transitions to listening and starts to send BPDUs. At that             stage, you have already saved max_age seconds, and the standard Spanning-Tree             Algorithm (STA) applies then.

So when we talk that "RSTP  accept inferior BPDUs" it meaned that RSTP have natively enabled behaviour to immideatly accept and replace inferior BPDU for port based on it assurance that every topology change will be explicitly syncronized all over the network. This doesn`t mean that it will accept Root in inferior bpdu as new root bridge. Indeed it will imediately responce with its own proposal with old root, if it still believe it alive. And in our case Bridge "A" must still believe that root "R" still accesible on it ALTN port leaded to bridge B, cos "it don`t heard about Y on it ALTN port yet".

What a matter having ALTN ports if any inferrior BPDU received on root port? If consider following picture,

By your logic "A" must accept BPDU coming from "X" and start propagate it to "Y" despite that roor "R" still alive:

[Aninda Chatterjee]

Good day to you too, my friend.

There is a distinction in this situation and other situations, which arises from how switches react to direct and indirect failures. Let's say the link between A and X (or the cloud) goes down. A loses its root port and it will transition its alternate port to root forwarding. In the event that A does not receive BPDUs on its root port for 3xHellos, again, it will think that it has lost its best path to the root and transitions its alternate port to root forwarding.

However, in this situation, the switch receiving inferior BPDUs on its root port itself, which clearly indicates that something has gone wrong upstream which is why it accepts this information and attempts to sync it downstream.

In your last example, we have an indirect failure. When X loses its root port because of that failure, it assumes itself to be the root and sends that information back down to A. A accepts it and tries to sync that with Y. Y realizes that the R is still alive and active, and sends that information back to A.

At this stage A moves the alternate blocking port to root forwarding.

Now suppose that the link between A and X fails. This would cause an immediate transition of the alternate port to root forwarding.

[Alexey Stytsenko]

Good day.

Tnx for your clarifications, i higly appreciate it. I think we will find truth in few more steps.

But before lets make few more adjustments

However, in this situation, the switch receiving inferior BPDUs on its root port itself, which clearly indicates that something has gone wrong upstream which is why it accepts this information and attempts to sync it downstream. 

ALTN port do not lead do downstream - it lead to upstream as well, only designated ports lead to downstream.

So you conclusion that appearing inferior BPDU on root port "clearly indicates that something has gone wrong upstream" is not correct. ALTN port  (candidate root per se) as well upstream port but receive a worse information that root.

[Aninda Chatterjee]

I'm sorry, I did not mean to imply that an alternate port does not lead to the root.

When A gets the inferior BPDUs from X, do you think that it should ignore it? If so, for how long? 802.1D here has a good check implemented via BackboneFast which sends out RLQs to verify if the root is still active or not.

However, RSTP does not follow the same mechanism. While we can say that RSTP has the 'uplinkfast and backbone fast mechanisms inbuilt', this is not 100% true. The behavior is inbuilt, however the exact same process that uplinkfast and backbone fast use to achieve their goal is different from what RSTP does.

With RSTP, when A receives the inferior BPDUs from X, it wll accept it and try and sync this information with Y. Because Y is still receiving BPDUs from R (because of which it knows the root is still active and its root port is still valid), it will just send this information back to A, and A can now adjust accordingly. This is just how RSTP was built to bring about faster convergence times.

Regards,

Aninda

[Alexey Stytsenko]

When A gets the inferior BPDUs from X, do you think that it should ignore it? 

No. I dont think so.

When A gets inferior BPDU from X - it will immediate age out previous learned BPDU from R and replace it with X BPDU. This is the one of core operations of RSTP - you send me link to it in your first message in this discussion.

 802.1D here has a good check implemented via BackboneFast which sends out RLQs to verify if the root is still active or not.

But RSTP (802.1D - 2004) is aware that root alive because of it core function - explicitly syncronize changes to root all over the network. There are some possible effects in such awareness your already red in Petr Lapukhov article.

With RSTP, when A receives the inferior BPDUs from X, it wll accept it and try and sync this information with Y. Because Y is still receiving BPDUs from R (because of which it knows the root is still active and its root port is still valid), it will just send this information back to A, and A can now adjust accordingly. This is just how RSTP was built to bring about faster convergence times.

The brige (A) receiving timely BPDU from it legal (true one) root (R) on it upstream (ALTN) port suddenly swear to other root (X) based on iformation received in inferior BPDU, and tried to negotiate it with neigboring bridges (Y) This is seems like not STP alorithm but as script for new "Game of Thrones" series - s401 "Betray the ROOT" 

Cannot find such behaviour described in any Cisco doc. I will try to simulate such conditions and using Wireshark analyze whats going on. Will post result here then.

[Aninda Chatterjee]

But RSTP (802.1D - 2004) is aware that root alive because of it core function - explicitly syncronize changes to root all over the network. There are some possible effects in such awareness your already red in Petr Lapukhov article.

Yes, this is exactly what is happening in this situation as well. Switch A attempts to sync this new information downstream (I say downstream because it assumes X is the root and Y thus becomes downstream to A).

The brige (A) receiving timely BPDU from it legal (true one) root (R) on it upstream (ALTN) port suddenly swear to other root (X) based on iformation received in inferior BPDU, and tried to negotiate it with neigboring bridges (Y) This is seems like not STP alorithm but as script for new "Game of Thrones" series - s401 "Betray the ROOT"  

I particularly enjoyed your Game of Thrones comment That would make for a very interesting episode

The thing to understand here is that this is a very specific and rare race condition. If switch A receives the the superior BPDU from from switch Y, it will naturally understand that the better root is through Y and moves its previously alternate port to root forwarding. But in that small time period where it receives that inferior BPDU from X, it will accept it and attempt to sync that with Y.

So let's say A receives the inferior BPDU from X. If the BPDU from Y then reaches A (before the sync process could be started), A knows that the better root is through Y. If the BPDU is not received in time, A will send a proposal to Y and Y simply responds with a counter proposal and again, A knows the better root is through Y. All of this happens very quickly and both situations result in A moving its previously alternate port to root forwarding.