11-09-2024 09:50 PM - edited 11-09-2024 09:51 PM
Next week our infra is planning to move from PVST mode (currently all switches are in PVST) to RPVST all are cisco switches. Our infra is like this we have 2 core switches both in hsrp protocol and from there 2 distribution switches from there it goes to several access switches. These access switches are of cascaded connection (no stacking) through copper cable. All the vlans are passed in all the switches in infra because we connect differenet end devices in same switches likes ip camera, ipphone, wifi AP, PCs. All of them are in different vlans configured.So my question is before starting this activity what all things I should keep in mind because I dont want to have any network disruption in the live environment (like vlan priority, root port etc). I have only limited knowledge based on STP, loopguard,bpdu etc. Pls help me.
NOTE: All the access switches are cisco 2960 model, Core & distribution switches are 4506 model.
11-09-2024 11:00 PM
Hello @13jobsp90
A careful approach is needed to avoid potential disruptions...
With your infrastructure comprising two core switches in HSRP, two distribution switches, and cascaded access switches connecting various devices across multiple VLANs, there are several critical factors to consider.
First, in a hierarchical network, your core switches should serve as the root bridge for each VLAN to maintain optimal traffic flow and prevent inefficient routing. Since your core switches are running HSRP, ensure the primary core switch is the root for all VLANs, with the secondary core switch configured as the backup. This alignment with HSRP will help ensure traffic flows through the shortest paths. Set spanning-tree priorities on the core switches to establish primary and secondary roots, using lower priorities on the designated primary core switch and slightly higher priorities on the backup core switch.
One of the benefits of RPVST is faster reconvergence, which can also mean that any network instability could propagate quickly !!! To mitigate potential issues, enable Loop Guard on all trunk ports that do not act as the root ports. This will prevent potential network loops if an issue arises with root or designated port roles. In addition, BPDU Guard should be activated on ports connected to end devices, which will ensure that unexpected BPDU packets from devices like IP cameras, phones, or PCs do not interfere with your spanning-tree topology. Considering that you have configured these access ports as spanning-tree portfast...enabling portfast on these edge ports will reduce convergence delays. Ports with portfast configured transition immediately to the forwarding state, allowing devices to connect more quickly. However, BPDU Guard should also be enabled on these edge ports to automatically disable them if a BPDU is detected, which could indicate an accidental loop created by connecting a switch or bridge.
As your network has VLANs configured across multiple devices, ensure consistency across VLAN configurations before beginning the transition. Use commands like `show vlan` and `show spanning-tree vlan` to confirm all VLANs are properly configured across core, distribution, and access switches. For trunk links, manually prune unused VLANs to reduce unnecessary traffic, which will optimize bandwidth across your network.
--
Start by enabling RPVST on the core switches, then the distribution switches, and finally the access switches. Monitor the network for any unexpected blocking or changes in root and designated port roles. By testing each section of the network individually, you can isolate and resolve any issues before fully deploying RPVST.
!!! For a production network, it’s best to make this change during a maintenance window !!!
Once RPVST is active across your switches, keep a close watch on your spanning-tree status for a period to catch any potential issues early. Regularly use `show spanning-tree` commands to check root port status and confirm that all devices are functioning correctly. Having backups of your configurations will be beneficial if a rollback is required...
--
Here are some key commands to support your RPVST transition.
--set Root Priority for Cores
spanning-tree vlan <VLAN_ID> root primary
spanning-tree vlan <VLAN_ID> root secondary
--enable PortFast and BPDU Guard on Access Ports
interface range <port_range>
spanning-tree portfast
spanning-tree bpduguard enable
--enable Loop Guard on Trunks:
interface <interface_id>
spanning-tree guard loop
-verify spaning tree config and status:
show spanning-tree summary
show spanning-tree vlan <VLAN_ID>
11-10-2024 12:43 AM
I have a doubt from my switches I can see some of the vlans around 10 to 20 nos vlans out of 100 vlans are having root bridge to some other access switch i can see, rest all other vlans are core sw1 has the root bridge. So what will happen if I change the edge switch to RPVST from PVST instead of starting from Core switch.
11-10-2024 06:41 AM
I have done this activity before I started off with an edge switch. But immediately after changing to RPVST in cbs 350 some of the vlans got down hence its connected end devices got offline. What must be the possible reasons for this? Since it got down I have to rollback to PVST immediately. Pls help me...
11-10-2024 07:00 AM
Hello
M02@rt37 wrote:
Start by enabling RPVST on the core switches, then the distribution switches, and finally the access switches.
Really! -So right off the bat you create stp convergence throughput the estate - I would say that's not wise tbh, you need to start at the network edge not the core for minimal disruption
11-10-2024 04:08 AM
Likely, a such a conversion CANNOT be done without network interruption.
As to your concern (from earlier separate posts) about, optimal usage of optional STP configuration statements, they are pretty much the same between PVST and rapid-PVST. There are a couple of optional PVST configuration statements that are part of the rapid standard, which will become enabled under rapid, if not already enabled, and which cannot be disabled.
As has been suggested, make this kind of change during a maintenance window which allows for complete network outage.
How large a maintenance window? I would suggest between 3 to 4 hours.
Will the network be down for all that time? Possibly, and hopefully, not, but it allows for configurations changes, both conversion and rollback, verification all working correctly, and some troubleshooting.
If you're inexperienced in whole network changes, and as you admit lack of knowledge about STP, really consider retaining professionally (paid) assistance.
11-10-2024 04:21 AM
I have a doubt from my switches I can see some of the vlans around 10 to 20 nos vlans out of 100 vlans are having root bridge to some other access switch i can see, rest all other vlans are core sw1 has the root bridge. So what will happen if I change the edge switch to RPVST from PVST instead of starting from Core switch..
11-10-2024 05:12 AM - edited 11-10-2024 05:59 AM
Again, PVST and rapid-PVST are supposed to interoperate, how well they do interoperate likely depends on many factors, which I consider irrelevant because there's no good reason to mix them in a permanent environment.
Yes, their interoperability MIGHT make a transition less painful, but I think it much better to plan for a quick bulk conversion.
Trying a soft conversion, I suspect, likely to be more time consuming and more likely that you may be the person to find a new bug using a mixed STP environment.
11-10-2024 04:54 AM
As I mention before there is no issue
R-PVST is compatible with PVST
11-10-2024 05:25 AM
thanku so much? What software are u using? I have a large network infra consisting around 120 switches. So i want to check several things under the simulator. Can u pls tell me how will I add these many switches in simultor ? Is there any option?
11-10-2024 05:37 AM
I use eve-ng
120 SW that alot, I dont think eve-ng support this number.
since we clear that PVST is compatible with R-PVST
the most important points need to check is
1- root bridge
2- STP feature like root guard loop guard and other
please ask as much as you can before apply any command in real network
MHM
11-10-2024 07:07 AM - edited 11-10-2024 07:08 AM
1 doubt will stp makes offline certain vlans. thats what happened for me.
11-10-2024 06:31 AM - edited 11-10-2024 06:35 AM
Hello
Due diligence is an necessity before attempting any spanning-tree migration, You need to understand your own switch topology and how it interconnects.
PVST-RPVST migration needs to be applied on very edge switches first, meaning the only other connection from those edge switches would be an upstream switch(S) like distribution and ideally all stp edge ports set for fast forwarding(portfast)
So for minimal disruption as stated I would suggest to start at the access layers switches, changing them to RPVST working your way upstream towards the core switches changing them last to RPVST
Note: when you change the cores switches, If any FHRP(hsrp,vrrp,glbp) is applied you may see this flap as/when the stp mode is changed but you should not lose end host connectivity.
Pre-change expect to have the below in place:
All stp edge ports enabled for portfast (access switches)
Uplinkfast on access-edge switches
Backbonefast on ALL switches
All switch interconnects manually set to stp link port type point-to-point (excluding any shared ports)
Stp bridge priority's set in a hierarchical manner ( core<distribution<access-layer)
11-10-2024 06:35 AM
"
Pre-change expect to have the below in place:
All stp edge ports enabled for portfast (access switches)
Uplinkfast on access-edge switches
Backbonefast on ALL switches
All switch interconnects manually set to stp link port type point-to-point (excluding any shared ports)
Stp bridge priority's set in a hierarchical manner ( core<distribution<access-layer)"
Can u pls explain these points in detail one by one? Pls.
11-10-2024 08:52 AM
Hello
apologies but if you do not understand what those feature are it would seem you would benefit reviewing spanning-tree as a whole .- here
It should provide you with a good foundation to work from and greatly assist in your migration of spanning-tree
I would definitely recommend NOT to perform any migration unless you at least understand the basics of stp.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide