Behavior of running PVST+ & Rapid-PVST+ simultaneously?

[huangedmc]

Say you have a network w/ 10 switches.

9 of them run Rapid PVST, and one runs the legacy PVST.

Would the entire L2 network fall back to legacy PVST, or only the segment where the one switch that's not yet converted to Rapid?

This Cisco doc says: "

When any RSTP port       receives legacy 802.1D BPDU, it falls back to legacy STP and the inherent fast       convergence benefits of 802.1w are lost when it interacts with legacy bridges."

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a00807b0670.shtml

However, it doesn't really say if the compatibility fall-back applies to just one segment, or the entire network.

Also, what's the best way to migrate from 802.1D to 802.1w?

Is it best to go bottom-up (start from access, distro, then core), or top-down?

I've been doing it bottom-up, but wanted to know if that's appropriate.

thx

Kevin

[glen.grant]

   I'll be looking at this answer too .  I currently have 2 6500's running pvst which will be getting connected to nexus 7000's with vpc etc.  Nexus only runs rapid pvst so how does it fall back to pvst  or what happens when you connect a device running pvst to a Nexus box.  Not sure we could even get the time to convert everything on the 6500's to rapid pvst to match them up . 

[Peter Paluch]

Hello Kevin and Grant,

Would the entire L2 network fall back to legacy PVST, or only the  segment where the one switch that's not yet converted to Rapid?

To my best knowledge, it should apply just to one segment - only the port on the RSTP-enabled switch that connects to an STP switch falls back to STP operation.

Is it best to go bottom-up (start from access, distro, then core), or top-down?

The bottom-up approach seems to be more appropriate to me. I have no strong proof of this approach to be significantly superior to top-down, though - just a feeling at this point.

Best regards,

Peter

[Joseph W. Doherty]

Disclaimer

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.

Liability Disclaimer

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.

Posting

Also believing, like Peter, STP with rapid-STP impacts only the joint segment, I prefer STP root core toward edge conversions.  This to get the rapid-STP benefit to the core first, and to be able to selectively chose what "branches" I convert next.  I.e. I might not convert from core to edge one hop layer at a time, but might choose a partial "tree" from the core.

[huangedmc]

Came across this blog, which provides nice details on testing numbers on migrating from access to core, and from core to access.

Based on this particular topology & scenario, it's better to start from access layer.

http://www.netcraftsmen.net/blogs/entry/migrating-to-rapid-spanning-tree.html