The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Depends on the topology. Often ranges from some fraction of second to a couple of seconds.
exactly how much time will be taken for STP convergence if i reboot primary switch ?
This is impossible to say but at least some estimations can be done.
In case of a sudden loss of a participating bridge, RSTP ages out unconfirmed BPDUs after 3x Hello interval, i.e. after 6 seconds with default setting. This 6 second delay is the minimum time for RSTP to detect a sudden loss of a participating bridge if there are no further topological changes present (such as ports going down). The RSTP will need afterwards to react appropriately - elect a new root bridge, properly determine and negotiate the roles of other ports. The process of electing a new root bridge may take at worst Hello interval seconds for each "stratum of switches" successively departing from the new switch, so in the worst case, the time until all switches know about the new root switch may take Network diameter x Hello interval seconds.
The process of Proposal/Agreement negotiations is very fast. We can safely assume it to take no longer than 0.5 second for a single link, and this process will need to occur at most (Network diameter - 1) seconds.
So the very pessimistic estimation is that after the root bridge is restarted, the network will need 3 x Hello interval + Network diameter x Hello interval + 0.5 x (Network diameter - 1) seconds to reconverge.
Of course, the process can be much faster. If a root bridge is restarted, its ports go down. If another switch detects its own root port went down and it has no Alternate ports to replace it, it starts considering itself as the new root switch right away. The 3 x Hello interval thus shortens to, say, tens of milliseconds. Sending of BPDUs in case of re-root events can be immediate, not observing the Hello interval, in which case the discovery of the new root switch is again just a matter of hundreds of milliseconds, seconds at worst. And the Proposal/Agreement process is very fast, again deeply below 0.5 seconds I took as a very conservative estimate - in reality, it is down to tens of milliseconds. So with a well-designed network and well implemented and behaved RSTP implementations in switches, the RSTP reaction can be below 1 second - but this is a guarantee that simply can not be given in general because as you can see, there are many things based on the topology that have an influence, and also, it depends on how the RSTP is actually implemented in the switches' operating systems and you can not influence this.
after switch comes online how much time it will again take to root bridge?
The pessimistic estimation is that it takes Network diameter x Hello interval + 0.5 x (Network diameter - 1) seconds for the network to learn about the new root switch and to adapt to the new topology.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.