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?