cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2874
Views
0
Helpful
9
Replies

Changing from PVST to Rapid-PVST

RonaldNutter
Level 1
Level 1

As a part of a major network cleanup/standardization project I have been working on for several weeks, I am now looking at spanning-tree and trying to get my company into line with Cisco Best Practice.  I currently have 3 switches in the data center that are spanning-tree root for different vlans.  Before I changing vlan priorities in spanning-tree, I feel that I should change from PVST that everything is on now to Rapid-PVST.  To minimize the momentary network disruptions from making the change, should I do the edge switches first and do the switches in the data center at the last ?

Related to this process is something that I want to do probably after the PVST to Rapid-PVST change.  I am going to manually set the vlan priorities for each vlan on the main core switch.  Assuming I set the vlan priority for each vlan on my main core switch (6509) to 4096, should I set the switch I want to be the backup to 8192 for each vlan and then set the edge switches to something like  12288 to keep them from getting up in the spanning-tree hierarchy  and for general principle to leave nothing to chance ?

Ron

1 Accepted Solution

Accepted Solutions

JohnTylerPearce
Level 7
Level 7

1st Question) I converted our entire switched network from PVST+ to RPVST+. The way I did it way, to do the edge switches first and then I did our distribution and core switches. I didn't have any problems personally. Now, someone may have a lot more experience doing this than I do, but that worked for me. Obviously I could do this in a maintenance window. Also, I would read up on some PVST to RPVST documentation.

2nd Question) I would have one switch to be my root switch for all vlans unless there is a need elsewhere. Then I would pick which switch you want to be the secondary root switch, and adjust the priorities. I wouldn't worry about setting any priorities on the access switches. Depending on where an outage happens, depending on your topology, It can be extrememly hard to tell which switch will be the root switch during an outage. Once again that depends on your topology. If an outage occurs between your distribution switch and your access switches, it's not really a HUGE deal if one of them becoms the root switch for a little while depending on a few things.

Remember, the whole purpose of the root switch, is it's the top of the tree for spanning tree, then all the indvidual links (tree branches) go out from there, and STP creates a loop free path between all switches in the switched network. Also, just because you will always have a root switch, that doesn't mean data actually has to go through the root switch to get to it's destination. The root switches soul purpose in life is just to create a loop free path, and also to send out BPDUs to all other switches (IEEE 802.1d), when you run 802.1w all switches send bpdus to each other including the root switch obviously.

Hope that helped.

View solution in original post

9 Replies 9

Already reading that.  Looking for what has been done "in the real world"  I have been burned by some docs and doing my due diligance to see what others have done.

Ron

JohnTylerPearce
Level 7
Level 7

1st Question) I converted our entire switched network from PVST+ to RPVST+. The way I did it way, to do the edge switches first and then I did our distribution and core switches. I didn't have any problems personally. Now, someone may have a lot more experience doing this than I do, but that worked for me. Obviously I could do this in a maintenance window. Also, I would read up on some PVST to RPVST documentation.

2nd Question) I would have one switch to be my root switch for all vlans unless there is a need elsewhere. Then I would pick which switch you want to be the secondary root switch, and adjust the priorities. I wouldn't worry about setting any priorities on the access switches. Depending on where an outage happens, depending on your topology, It can be extrememly hard to tell which switch will be the root switch during an outage. Once again that depends on your topology. If an outage occurs between your distribution switch and your access switches, it's not really a HUGE deal if one of them becoms the root switch for a little while depending on a few things.

Remember, the whole purpose of the root switch, is it's the top of the tree for spanning tree, then all the indvidual links (tree branches) go out from there, and STP creates a loop free path between all switches in the switched network. Also, just because you will always have a root switch, that doesn't mean data actually has to go through the root switch to get to it's destination. The root switches soul purpose in life is just to create a loop free path, and also to send out BPDUs to all other switches (IEEE 802.1d), when you run 802.1w all switches send bpdus to each other including the root switch obviously.

Hope that helped.

John:

Thanks.  That gets me started.  Starting with the access switches and moving my way back into the core is what I felt would be the safe way to go.

When you changed each switch, do you happen to remember how long before the switch was reachable on the network ?

Will plan on setting the root vlan priority on the core switch only.

The network is mostly a star configuration with only a couple of switches being connected to more than one switch, so I would hope that the reconvergence during the change would be fairly minimal.

This has been an involved process. When I took over this network, I ran into vtp configuration mismatches, inconsistent NTP configuration, use of vlan 1 as the native vlan, no vlan pruning in place, and some spanning tree issues to deal with.  Trying to get things in a stable mode so that I can start moving to Nexus switches for the server farm in a couple of months.

Ron

Haha.. Kinda sounds like the network I ran into. As far as downtime goes, I noticed a few seconds, each time I changed the mode. But once again, just look at your topology, and figure out what may or may not happen, make sure all switches can convert to RPVST+, and do this during a maintenance window. I would suggest doing the priorities first and then changing spanning tree. You're doing almost exactly the same thing I do, just don't worry about configuring priorities on the access switches.   The guy before me, had setup some switches for our DMZ/VM network (two 2960s) hah, but the funny thing is, he setup a 2 port etherchannel between the switches, thinking traffic would get there faster that way. Now, what he didn't realize was, is that actually introduces a loop (not a problem since spanning tree is running), but it blocked the ports, so basically the etherchannel was useless. Plus, the devics that were communicating had to go to the default gateway anyway, since they were on different networks.

John:

When I issue the spanning-tree vlan priority command on the switch that is already spanning-tree root for a vlan that I am running the comand for, should it be a hitless change since all i am doing is changing the priority from 32769 to 4096 ?

Ron

No, because when you change the cost, spanning tree will have to recalculate. I've done this before on a live network, but it was for a vlan that was basically useless and really not in production. Personally, I would wait for a maintenance window. If someone is transfering some huge files etc etc and the connection goes down for a few seconds (maybe), they might get pissed. Better safe than sorry, or Better employed and going out on friday night, then unemployed and eating ramen.

Wanted to give you a final followup on this.  Was finally able to get a maintenance window to make the changes this morning.

When entering the spanning tree priority lines in my core 6509, I noticed at most a second or two "blink" for those vlan's that werent already root on this 6509.

Changing from PVST to Rapid-PVST went just as smoothly.  The wost blink that I noticed was 1 second while the management vlan lost it connection and then reacquired after the changing to spanning-tree.  The other 6509's didnt show anything in the logs about the change.  Only the 3750's seemed to notice/complain about the change.  I had one 3750 that is across the street from my data center that connects via a 100 MB fiber connection and it blinked for 2 seconds.

Thanks for all the help.

The same thing happend to me Nutter. The blink is around 1 to 2 seconds at most. STP Convergence is going on when this happens.

Review Cisco Networking products for a $25 gift card