Hello Stephane,
Can somebody confirm me that each time a root is lost within a
spanning-tree domain, the negotiation starts all over and every
switches pretend that it is the root until each on root is identify
while Rapid Spanning-Tree switch keeps track of the different root
value of each switches and does not pretend to be the root if it has no
chance of becoming one.
Actually, I cannot confirm this.
I think that many people like to see the STP operation divided into three nice stages taking place in the entire network - first, the root switch is elected, second, the root ports are identified, third, the designated ports are identified and all other ports are put into the Blocking/Discarding state. This may be illustrative but it does not correspond to how the STP operates. The main difference is that this description assumes the entire process to be synchronized all over the switched domain while in real life, these three steps take place individually and independently on each switch with every single BPDU received.
In other words, every time a BPDU is received on a port, the switch running legacy 802.1D performs roughly the following evaluation:
- Is the received BPDU identical to the best stored on the port in the last max_age seconds? If yes then just reset the timer and end the evaluation.
- Is the received BPDU inferior to the best stored on the port in the last max_age seconds? If yes then ignore it and end the evaluation.
- If we reached this step then the BPDU must be superior to the best stored on the port in the last max_age seconds. Using this BPDU,
- If this BPDU is superior to the BPDU received on the current root port in the last max_age seconds, this port becomes the new root port. All other ports shall be moved to the Listening state and renegotiate their new state in the new spanning tree topology using this same algorithm.
- If this BPDU is inferior to the BPDU received on the current root port in the last max_age seconds then the root port remains stable, however, the receiving port clearly must be put into the Blocking state because it is not the best port on the segment anymore.
Of course, optimizations to this basic algorithm can be done but this is how I perceive the elementary working of 802.1D.
In RSTP, there is an important change to the step 2: even if the received BPDU is inferior to the one stored on the port, it will be accepted if it comes from the designated or root bridge connected to that port, and the switch continues the reevaluation. This modification is to allow rapid acceptance of information sent from the current designated/root switch whose RSTP parameters have worsened for any reason. See the following document for slightly more information about this:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#inferior
Note that this document actually talks about a switch running RSTP erroneously believing itself to be a new root, and a non-root switch actually correcting its idea.
It is true that in RSTP, each switch sends BPDUs on its own and does not wait for the root switch to generate a BPDU so that it can be relayed. The BPDUs thus become more similar to the Hello packets used in many Layer3 protocols (though they are not bidirectional until the so-called Bridge Assurance functionality is configured that treats the BPDUs as real Hello packets sent from each and every port including Alternate and Blocking ports). Thanks to this, an outage can be detected more quickly and precisely because if a BPDU is not received then it is clear that the problem is between these two particular neighbors, not somewhere in the network between the root switch and this switch. But apart from that, there are no further important differences as far as I am concerned (of course, not talking about Proposal/Agreement but this is not about election of port roles).
You wrote that the "RSTP keeps track of different root value of each switches" - I am not sure what you meant by it. Can you perhaps clarify?
Best regards,
Peter
