STP implementation

david-flores · ‎02-20-2008

Ok, I know there are many previous posts regarding STP, but could not find any that were exactly like my configuration, so here goes.

We have 2 6500's with 720's at the core, and another 6500 with a sup1a in another bldg, all with redundant links. We have 20 vlans. I was thinking about implementing Rapid PVSTP+, but my 3500XL switches don't support it. Can I run RPVST plus on the 6500's, and STP on the 3500's?, or should I just stick with PVST. The redundant links are important, but the faster convergence is not that critical. Please advise.

Thanks.

lamav · ‎02-20-2008

David:

From my own experience and in my opinion, I would not mix STP with RSTP. This is also against Cisco best practices for implementing STP.

Is it possible to replace the 3500s with 3750s and then run RSTP?

The faster convergenece time for RSTP is substantial -- up to 50 seconds (15 seconds each for the fwd delay times for Listening anD learning states, as well as 20 seconds for the max age timer).

Here are some very helpful guidelines for implementing STP:

1. Use RPVST+ (802.1W) unless the BackboneFast and Uplinkfast features are not recommended in a particular topology (see 6 & 7 below).

2. Do not change the max-age or forward delay timers, as that can adversely affect stability. Network diameter should not exceed 7 hops.

3. Keep user traffic off the management vlan.

4. Do not overdesign redundancy. Too many blocked ports are a potential disaster waiting to happen.

5. Be deterministic in the deployment of STP. Rig the root bridge elections by setting the priority and then document all root ports, designated ports and blocking ports to create a baseline document for normal network conditions.

6. Do not enable Uplink Fast on access switches that have more than 2 uplinks.

7. Enable BackboneFast on all switches running STP only if they can all support BackboneFast, too.

8. Enable Loopguard and UDLD aggressive (Unidirectional Link Detection) globally if the switch allows this. Otherwise, do it on the individual interfaces, including EtherChannels.

9. Enable PortFast on access ports and, if it is a Cisco switch, issue the interface level switchport host command to optimize the auto-negotiation feature of the access port.

10. Enable BPDU Guard on all access ports that are configured for PortFast.

HTH

PLEASE rate post if you found this helpful.

Thanks

Victor

Francois Tallet · ‎02-20-2008

That's going to be a trade off.

You can configure your core with RSTP and edge with STP. You will still be able to use uplinkfast at the edge and get fast convergence when the uplink of an access bridge fails.

When you get a failure in the core, RSTP will fix this very quickly and restore connectivity in the core in a matter of a second (vs up to 50 seconds with regular STP). Now, here's the catch. When there is an RSTP reconvergence, it is possible for all the ports to be temporarily blocked (synced). That's no big deal with RSTP neighbors, because you have immediate negotiation and the sync is just temporary. Now, when an RSTP bridge is connected to an STP bridge, the RSTP proposal agreement mechanism cannot work. Synced ports then need 30 seconds to go forwarding.

All this to say is that, if you have a reconvergence in the RSTP core, all your STP bridges will be disconnected from the core for 30 seconds. So if all your access bridges are running STP, it's probably not worth running RSTP on the core (what's the point of reconverging quickly the core if no access bridge can reach it?). If some access bridges can run RSTP, or if connectivity within the core is your absolute priority, then the mix RSTP/STP might make sense.

As very often, it's not a black and white answer. The recommendation is just covering the most common scenario, and here, I would not be surprised if it applied to you;-)

Regards,

Francois

david-flores · ‎02-20-2008

Ok, thanks guys for the responses, I thought I would provide a diagram to help illustrate what is going on. I know we can run RPVST on the 6500's with 720, and the 3560's but not on the other equipment. However, would it be ok to run it on these switches only, for the faster convergence, and regualar STP on the 6500 with the sup1 and on the 3500's? I just want to make sure that I am not mixing and matching RSTP/STP when Cisco might not recommend it. I was under the impression that RSTP is backwards compatible, but maybe not? Thanks for your help.

Francois Tallet · ‎02-20-2008

Same kind of answer. Yes you can, but it will not be better for everybody. If you run RSTP on the 3560 and the sup720 you have half of your network running RSTP. To summarize the new behavior:

-1- a failure in the STP part (sup1a + XL bridge) will recover just as before.

-2- a failure in the RSTP part will:

.2a) be repaired very fast in the RSTP network. Meaning that the devices connected directly to the RSTP will probably enjoy sub-second reconvergence.

.2b) however, you will have a split between the RSTP part and the STP part for 30 seconds (the ports on the sup720 leading to the sup1 might block for 30 seconds).

It's up to you to determine if you are happy with the consequence;-)

I don't think it's worth it. Assuming that you root and backup root are on the sup720. You can make a channel between them. Then you can run uplinkfast on the sup1 (well, actually I'm not sure uplinkfast is fully supported on the 6500 in IOS) and on all the access switches. This way, you'll get fast convergence with a full STP network. No need for RSTP yet;-)

Regards,

Francois