RSTP convergence time measure

[ZakinusRSTP]

Hello,

I wanted to measure the time that the connectivity is lost when a link is broken (in millisecond) before RSTP recover the connectivity can sameone tel me how to do that , i tried ping but it's not accurate ?

Thanks.

[Giuseppe Larosa]

Hello ,

you can try to use iperf on two PCs using UDP traffic (TCP supports flow control and retramission) and measuring losses.

To make RSTP to work properly all access ports connecting to end user devices have to be configured as edge ports (spanning-tree portfast in Cisco IOS commands). Not doing this can lead to very slow convergence of RSTP even worse then original STP.

In practice, also a VOIP call between two IP phones can be used if the call stays up and there is no perception of silence or missing words in conversation could be enough to qualify the RSTP convergence.

The support of VOIP calls is one of the reasons that at the beginnging have driven the change to RSTP as STP convergence can be too slow.

Hope to help

Giuseppe

[ZakinusRSTP]

Hello , 

thank's for your answer , i have another question in when case that RSTP took 6 seconds to do the convergence ?

Because in my lab with 8 switchs in ring , when i broke a designated link i have no ping loss (so convergence is less than 2 seconds) , i saw that RSTP need to loose 3 Bpdus (3*2 = seconds) to notice that link is lost ?

Thanks for your help.

[Giuseppe Larosa]

Hello,

RSTP can use the handshake mechanism proposal / agreement and it does not need to wait for timers.

The case when you need to wait for 3 Hello times is for indirect failure. ( A failure on the root port of the upstream switch)

In your case it depends how you emulate the fault if you shut down an interface the other side will have its port going down.

If instead of shutting down you use spanning-tree bpdufilter enable the link will remain up but the designated side is not able to send or receive BPDUs.

WARNING:  you can create a loop if using spanning-tree bpdufilter I would not recommend it in a production network. You can use it in a lab.

Hope to help

Giuseppe

[ZakinusRSTP]

To do the test,I unplug the fiber or rj45 that is in designated state , and i can see the state of port changing to disabled and the alternate link switch to designated state , what is indirect failure ? sorry i did not understand the problem "upstream switch" 

thank's again for your time.

[Giuseppe Larosa]

Hello,

 in RSTP when bridge assurance is NOT used only designated ports speak and non designated ports listen to RSTP BPDUs originated by the root bridge and delivered on other switches.

local switch --RP  DP-> upstream switch --RP-->    <--DP---root bridge

                                                                   <----- direction of BPDUs in normal conditions

IF  there is a fault between the switch where the local root port is connected (this is the upstream switch ) that makes the upstream switch unable to receive BPDUs on any port the upstream switch can only skip to send the Hello configuration BPDU to the local switch.

The local switch has not a direct failure the link is up but it is not receiving BPDUs from the upstream switch on its root port.

In this case the local switch after 6 seconds can try to react and to elect a new root port.

In old STP the switch had to wait 20 seconds (max-age) before reacting to an indirect failure and then going via Listening and Learning state it could require 50 seconds for convergence.

Cisco introduced for classic STP an optimization called backbone fast that allowed to skip the max-age timer.

This optimization is now integral part of standard RSTP.

if you unplug the fibers or RJ 45 cable the link will go down and there is no need to wait for 6 seconds to react.

This why you are not losing a packet in ping tests.

Hope to help

Giuseppe

[Martin L]

hmmm.... research options with debug spanning bpdu or bpdu+
probably do some tests. Waring debug is very noisy !