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

[Matt Buford]

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.

This means touch a RSTP backbone link, and watch every single STP speaker
drop off your network for 30+ seconds.

This also means that it is essential that you always designate edge ports
for things like routers and hosts with the portfast command.  Non-STP
speakers have to sit through the whole listen/learn delay too.

I found this the hard way when I forgot to set portfast for a single server
and also had not set portfast for a tagged link to one of my routers.  My
router kept dropping off the net, and eventually I noticed it happened every
time I rebooted a specific server.  Switching both of them to portfast
solved the issue.

I still have the issue with the boundary point between the main RSTP network
and the small amount of my network that is original STP.  However, I almost
never have RSTP topology changes so it isn't much of an issue and will
hopefully all be gone soon anyway.

----- Original Message ----- 
From: <christian.macnevin at uk.bnpparibas.com>
To: <cisco-nsp at puck.nether.net>
Sent: Friday, June 03, 2005 6:26 AM
Subject: [c-nsp] Rapid and classic Spanning Tree Interoperation/Migration


> Hi,
>
> Has anyone got any good resources or just tips regarding upgrading a
>       network to Rapid Spanning Tree?
>
> I'm aware that it's backwards compatible, meaning that it 'negotiates
> down'
>       to classic spanning tree, and the ports need to be reset manually to
>       force it up to RSTP once all bridging members of the VLAN are
>       talking the new protocol. So if you roll it out segment by segment,
>       you still have a classic network, requiring quite a bit of work to
>       force it into RSTP.
>
>
>
> The other thing which concerns me is that it might be a bit of a big arse
>       to take the network I'm looking at the whole way to RSTP, and I
>       might only be able to do it on specific crucial segments. Is this
>       even practical? Or does it effectively reduce the whole, once again,
>       to a classic implementation?
>
>
>
> Cheers
>
> Christian
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
> **********************************************************************************************
>
> BNP Paribas Private Bank London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Securities Services London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Fund Services UK Limited is authorised and
> regulated by the Financial Services Authority.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>