[c-nsp] Rapid and classic Spanning Tree Interoperation/Migration

[David J. Hughes]

On 04/06/2005, at 7:14 AM, Matt Buford wrote:

> It works ok for a short migration, but it isn't something I would 
> recommend
> running longer than you have to.
>
> The big catch is that (as I understand it) a topology change on RSTP 
> (link
> change on a non-edge port) resets the spanning tree state of all 
> non-edge
> ports.  I can't remember anymore if this was only on the same switch, 
> or
> network-wide.  When speaking to other RSTP devices, it reconverges 
> almost
> instantly.  When speaking to an original STP speaker, you have the 
> whole
> listen/learn delay to sit through before communication is 
> reestablished.

I may be wrong but I thought that the RSTP link change only impacted 
upon RSTP non-edge ports on the same device.  STP devices "below" that 
switch in the tree shouldn't be impacted upon because a TCN doesn't 
have any impact upon the topology of the receiving device.  You'd have 
to actually flap the link or block root BPDUs until the timers expired 
to get the STP instance on the downstream switch to recalc.  Or am I 
missing something that is about to cause me grief in our mixed RSTP / 
STP environment?

Regardless of the protocol, portfast is your friend anyway ;-)


David
...