I have started going through the network where I just started to see what needs to be done to get it as close as possible to Cisco Best Practice. In the process of doing this, I found that a switch other than the core switch in the data center is the spanning tree root.
Most of the switches (mostly 650x, a few 3750's) are all direct connected to the core except for one switch which is two hops out from the core. I am probably a month out (possibly more) from upgrading the sup engines in all the 6509's from the Sup720's they now run on to the Sup2T's. From researching this, the command I will need to run on the core is spanning-tree vlan x root. Should I use that command or spanning-tree vlan x priority followed by an increment of 4096 instead ? I would think that the root command would be the simplest. Wasnt sure which was the best option.
What I cant get a feel for is the amount of time it will take to get this straightened out. I know that I will need to run this command for each vlan. My guess at this point is that this will probably take a minute or so per vlan to fix.
At my main office where I am dealing with this, I have 4 6509's, 1 6506 and 6 3750 switches. Of the 4 6509's, one of them is the one that will be the root for spanning tree for all vlan's when I am done.
Would appreciate any suggestions on this as I need to put a plan together for my boss so that we can get this approved by change control. I am expecting a minor outage during the recalculation for each vlan that I will be working with based on past experience.
Also, the switches are setup for the default of PVST. Should I consider using Rapid-PVST or something else ?
In general, in 802.1D STP or Cisco PVST/PVST+, the upper time estimate on the STP reconvergence is 50 seconds after the last change to the STP settings.
Using the spanning-tree vlan X root primary command should usually be safe unless the current root switch is already at the priority of 4096, in which case the command will refuse to run and will not be applied. I personally prefer using a numeric priority directly, however, that necessitates knowing the current root's priority (visible in the show span vlan X command) and decreasing the new root's priority by 4096 or its multiple.
I would personally also vouch for running RSTP or RPVST/RPVST+. If configured properly, its convergence should be well under 1 second, however, the time estimate in RSTP is more difficult to determine (up to 30 seconds but that would indicate a serious misconfiguration). Two things to be very carefully verified before deploying RSTP are:
Links between switches should be of point-to-point nature, i.e. no hubs or non-STP-compliant switches inbetween. The point-to-point links should be running in full duplex mode. If these conditions are met, CIsco switches will consider the links to be working in point-to-point mode and will be able to perform rapid operations on them. You should verify using the show span command output that the links are identified as p2p links (even if you still run legacy STP).
Ports towards end stations should be configured as PortFast ports, otherwise, they may get blocked for 30 seconds in case of a topology change detected inside a network. There is no automatic discovery possible - the ports must be configured as PortFast ports manually.
In general, any recent network should run RSTP. There is no reason to keep the old slow STP.
If you are using many VLANs, I would also recommend considering deploying MSTP to decrease the load on switches incurred by runninglots of RSTP instances. MSTP builds on top of RSTP and has all the advantages of rapid convergence as with RSTP.
Thanks for all the info. I have been mostly on the Security side of things for several years, so I am a bit rusty. I have my CCNP Security and have started working on CCNP R/S to help fill in the blanks on my knowledge.
From what you wrote, it sounds like I have several things to work on.
1) Since all my switches currently have "spanning-tree mode pvst" in their configuration, I probably should go with "spanning-tree mode rapid-pvst" on all switches to help reduce the convergence time. Should I go to the switches on the edge first and then do it on the core at the last ? Since my network has less than 20 vlans, rapid-pvst should be sufficient I would hope.
2) I am reviewing all my switches and the root bridge is 32768. The other switches are showing value higher than that. I read about your preference to use the priority value instead of the root command. Going on that, should I look at hard coding a spanning-tree value on all switches ? I would think 4096 for my root, 8192 for the switches that are directly downstream from the root and then 12288 for the switches that are directly downstream of the primary downstream switches ? At this point, I dont have any switch that is more than one hop out from the core, just trying plan for what might happen.
Also, what would you think as to the level of disruption on the network when I make these changes ? Being conservative, I probably should do this during a maintanence window on the weekend. I am a couple of months away from upgrading all my 6500 chassis from Sup720's to Sup 2T's, so I am trying to get some of the housecleanings tasks like this done before I start with the major changes such as implementing the N5k/N2k's that will be coming.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...