Re: How is a break/reconfiguration propagated in an RSTP network?



anoop wrote:
> Christopher Nelson wrote:
>
> > My biggest remaining question is what's "less time" or "much faster".
> > The paper says that STP took 30 seconds to a minute or more to recover
> > and that RSTP is faster. I'm seeing 2-3 second recovery when the
> > primary path is broken. Is that expected and acceptable? When I read
> > the description in the document refereneced above, it seems that the
> > network should be able to converge in 10s of milliseconds but I'm not
> > seeing that.
>
> The 10s of msec for recovery is not generally true. It happens only
> for certain failures that are "easy" to repair based on network
> topology -- cases where it is obvious to the bridge experiencing
> failure that the root has not failed and that the probability of causing
> a loop by opening one of its blocked ports is very small. Even for
> these cases the repair time is usually ~100 msec. Further, the
> actual repair time also depends on the quality of the implementation
> and the way a port failure is communicated to the software running
> STP on the switch.
>
> For the kind of failure you have 3-6s sounds reasonable. I suspect
> you would do a bit better if you had sw1 directly connected to sw4
> and repeated the test, but it still won't be on the order of 10s of
> msec.

Thank you for the reassurance but while I accept your answer as being
well-informed and likely to reflect reality, I don't get why the latter
is true. If Sw2 detects loss of link on it's connection to Sw1, the
root. my incomplete understanding of RSTP suggests that the following
will happen in fairly short order:

- In response to the dropped link, Sw2 will immediately tell Sw4, "I'm
think I'm root"

- In response to Sw2's claim to be root, Sw4 will immediately tell Sw2,
"Nope, Sw1 is still reachable via Sw3. You can get there through me."

- At essentially the same time, Sw4 will make the port leading to Sw3
it's root port.

- Upon receipt of the notification from Sw4, Sw2 will make it's
connection to Sw2 a root port and no longer believe it is root.

Where are there 3 seconds worth of processing in there? There are no
timers involved, are there? Isn't that the point of RSTP? And why do
I see that the recovery time changes when I change Hello Time?

Sorry if I'm dense but this is making me crazy.

.



Relevant Pages

  • Re: Hardening a Solaris system.
    ... > I know files that execute with root permissions by normal users (e.g. ... > I've set up a web server, running Apache, so are thinking about what I ... thing to leave enabled in here might be a backup port. ... there are security steps here. ...
    (comp.unix.solaris)
  • Re: Hardening a Solaris system.
    ... > I know files that execute with root permissions by normal users (e.g. ... > I've set up a web server, running Apache, so are thinking about what I ... thing to leave enabled in here might be a backup port. ... there are security steps here. ...
    (comp.security.unix)
  • Re: Safe practices
    ... Assume I'm logged in to my Linux system as a normal user. ... System is stand-alone, non-networked, but connected to internet via ... Someone might try to get to you through a port used for other purposes ... Your 'su root' at your console:- You are in a different thread to the rest ...
    (alt.os.linux)
  • A new model for ports and kernel security?
    ... why do we have this requirement that only root ... made to a low port to be "secure". ... clearly it has outlived its usefulness as a "security" feature. ... So I would like to propose the following improvement to kernel security ...
    (Linux-Kernel)
  • Re: How is a break/reconfiguration propagated in an RSTP network?
    ... > The 10s of msec for recovery is not generally true. ... Flags: Agreement, Forwarding, Learning, Port Role: Designated, ... Root ID: Sw1 ... Bridge ID: Sw2 ...
    (comp.dcom.lans.ethernet)