cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
357
Views
0
Helpful
4
Replies

migrating large enterprise from pvst to rapid-pvst

matthew.k.lee
Level 1
Level 1

So the network that I help support is still believe it or not running 802.1d traditional pvst+ mode. I've proposed migrating the enterprise to rapid mode and will begin some scenario testing soon. I've used the cisco feature navigator to verify that the code each switch platform is running will support rapid-pvst. Devices which for whatever reason do not support rapid mode will be left alone until they are replaced (which will be this year anyway).

My question is, on a network of roughly 7,000 switches, how can i minimize the number of switches that freak out and block all ports. I've thought about scripting a delayed reload in the event a switch drops off the network, but given the scope that seems like a bad idea to me. Also, on sites with large l2 domains, is it recommended to work from the core out, or vice versa?

Thanks

4 Replies 4

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Matthew,

>> n a network of roughly 7,000 switches

this explains why PVST is still in use

:)

In migrating I would start from access layer to core.

Backward compatibility should be supported on a per link basis making the order of migration a question of choices.

So also devices that don't support Rapid can still be used.

Take special care of switch stacks, other users have reported problems in changing STP mode on them.

Of course this cannot be done in one day.

You need to convert one campus at a time.

You can develop your procedures with some lab testings and then you can choice two pilot sites one small and one big to test them.

Hope to help

Giuseppe

Yea, I had planned to pilot a few sites local to HQ in case they take a dive.

What was the issues reported with stacks? We have a ton of 3750's on the network, so i'll be running into that quite often.

Also, is the reasoning behind migrating access layer first out of safety or efficiency? My understanding of bottom up would be that access converts, detects pvst on the uplink, falls back to pvst mode and uses timers to progress lis/lrn/fwd. I guess if you loose an access switch it would hurt less than having a core go down, but the migration would take longer per site, yea? After the procedures are tested, we'll probably ramp up and script out several hundred sites per night. I'll probably lean towards safety, otherwise the NOC would have me for lunch :)

Hi:

Besides Giuseppe's thoughts, i woul dliek to add that you may want to break up this project into small, digestable bites. The first thing you might want to do is breakdown the switched environment into switched distribution blocks.

Then inventory all the switches to see which ones support rapid spanning tree and any other ancillary feature you will want to add, like UDLD aggressive, etc.

Upgrade all IOS as necessary.

take note that if you are running PVST+ with uplink fast and backbone fast, the change to r-PVST+ may not be as intrusive as you think.

Test in a lab as much as you can.

And do ALL work under a maintenance window.

HTH

Victor

Thanks Victor. The project will definitely be broken up, most likely one region of the country per weekend, something like that. Also, in order to minimize risk, we wont be making any software changes, just configuration, and only related to RSTP... the less changes the better - making changes only to STP should make problem isolation easier hopefully.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: