RPVST or PVST with UplinkFast ??

[martin_tsang]

*** Please note that I support the forum points system :-) ***

Hi All,

Attached to this post is a diagram of the setup. Switch AAA - HHH are 2950-EI, all the other ones with an ugly blob of green are non-cisco trunking devices which dont really need ST because there will be no loop, ever. (cant set as edge because running in Trunk mode)

Two ports have been manually disabled because the previous designer of this network was worried about loops.

I'm having problems deciding on whether to use Rapid PVST or PVST with UplinkFast. Currently the network is running PVST with UplinkFast all all SILVER switches. Wherever there is a "ring", the port is disabled.

Some switches have dual links and it is working fine.

-----------------------------------

Problems with PVST with UplinkFast

-----------------------------------

*** Cisco documentation says that UplinkFast should only be used on Edge Switches.

*** Adds an annoying value of 3000 to the path cost.

-----------------------------------

Problems with RPVST

-----------------------------------

When a link cuts over from Primary to

Secondary between AAA and BBB, most of the GREEN switches in the diagram dropout for "forward-delay" seconds. When using PVST, this doesnt happen at all. In the case of link flaps between AAA and BBB, it wont affect others. There is only one ping drop when the primary link is restored.

--------------------

Conclusion

--------------------

Since there are many of those GREEN switches, PVST seems like a better alternative.

----------------------------------------

Questions - Please provide opinion.

----------------------------------------

1. What is the preferred protocol to use in this scenario?

2. Will UplinkFast create problems when the two ports are unblocked at EEE and DDD?

Thanks heaps!!!

Martin

[leonvd79]

Martin,

Choosing between Rapid Per-VLAN STP or Per-VLAN STP should be based on application requirements. If your application requires fast convergence it is recomended to use Rapid Per-VLAN STP.

I assume the GREEN non-Cisco switches do not support Rapid STP (802.1W) nor Multiple STP (802.1S), which would mean that you'd have a mixed 802.1d and 802.1W environment. This is not recomended.

Since the GREEN switched are single-homed, it would be appropiate to disable STP. The switchport on Catalyst 2950 can auto-detect the STP port-type. Make shure that no BDPUs are received on edge-ports by entering the "spanning-tree bpdu-guard default" command in global configuration.

Portfast, Uplinkfast and Backbonefast are Cisco proprietary enhancements to 802.1d. Which are re-used in Rapid STP, as defined by IEEE 802.1W. These features were designed to speed up reconvergence.

Since a fast reconvergence is dictated by business requirements 802.1W is increasingly popular to meet those recomands in building a robust network.

To answer question 2, I uplinkfast detects indirect link failures, in this case you would enable a switchport which is put into blocking because the rootpath is not shorter than the current.

HTH

Leon

* Please rate posts if you find them helpful.

HTH

Leon

* Please rate posts if you find them helpful.

[martin_tsang]

thanks for the response Leon, however, it didnt have the information I required.

[Francois Tallet · Accepted solution]

Hi Martin,

I recommend Rapid-PVST, with no doubt!

Some comments on the uplink fast. Cisco recommend that you enable uplinkfast on edge switches because these are the switches the most far away from the root, thus the more likely to have some alternate ports. The feature only helps when there is an alternate port on the switch. The tuning of the costs was just introduced to increase the chance of having an alternate port on the switch (preventing it from being root, etc...). The real limitation with uplinkfast is that:

- you only get fast convergence on switches that have an alternate port (I keep repeating myself;-)), and there are not a lot in your network.

- the convergence is dependent on the transmission of dummy multicasts to update the cam entries, which is not scalable.

Anyway, you should get amazingly faster reconvergence time with rapid-spanning tree. The requirement for a fast RSTP network:

- point to point links,

- edge port correctly identified.

During its convergence, RSTP introduces some cuts in the topology. The cut is just temporary because:

- when a designated p2p port is blocked, it quickly negotiate going back to forwarding with its neighbor.

- when a port has not RSTP neighbor, it can be considered as an edge port and will not be blocked during RSTP reconvergence.

The problem you have is that the green boxes should

- or run RSTP

- or be configured as edge port (portfast, as you mentioned).

To meet this requirements, portfast can now be configured on trunk ports (portfast trunk). Configuring this should be the answer to your problem.

Regards,

Francois

[martin_tsang]

"portfast can now be configured on trunk ports (portfast trunk)"

This is a first class response. /me wonders how a CCIE gets this knowledge in the first place. Is it from reading or is it from work experience or from experimenting?

I tried reading as much as I could, but it seems so hard to find information. I guess its just hard starting off as a noob and not having anyone to ask at work.

I tried googling for portfast and trunk links but couldnt find anything!

Once again, thank you very much for that information and your opinion on RSTP. I really really really appreciate it.

[Francois Tallet]

Thanks Martin,

It's just that I've been the DE responsible for STP within Cisco for a while;-) There is indeed very little valuable information on STP available, that's basically why I've started monitoring the forum for STP questions.

Regards,

Francois

[hlow]

Hi Francois,

A previous poster in this topic mentioned mixing 802.1d and 802.1w in the same network is not recommended.

What you are saying seems to disagree with that.

Can you please clarify?

Thanks

Helena

[Francois Tallet]

Hi Helena,

In fact, I would do the same recommendation to not mix STP and RSTP, but not an absolute rule;-)

If you can upgrade your whole network to RSTP, I think it makes sense because:

- RSTP is more efficient that STP in term of convergence speed

- it's simpler to only deal with a single protocol all over the network in order to understand what is happening.

- A bad mix of RSTP and STP bridges can be less efficient that an homogenous STP network in some cases.

However, if you have some switches that cannot be upgraded to RSTP, I have no problem running a mix of STP and RSTP. It's not a configuration error, it's just that you cannot expect RSTP-like convergence time in all the cases in this scenario and you are doing some trade-off.

RSTP may not be worth it if your network cannot be configured to take full advantage of it. For RSTP to provide rapid reconvergence on a switch, its port needs to be either:

- point to point connected to other RSTP switches.

- edge and properly configured with portfast.

If you enable RSTP on a core bridge surrounded by STP neighbors, you may end up with a network even less efficient in term of reconvergence speed than if it was STP only. This is because RSTP can sync a designated port (move it to a designated blocking state), expecting its RSTP neighbor to send back an agreement allowing the designated port to move back to forwarding immediately. If the neighbor is not running RSTP, there will be no agreement and you will block for 30 seconds... In that particular scenario, you'd rather have an STP bridge that would not sync in the first place;-)

So basically, it all depends. If you can upgrade at least your core to RSTP and only have some access switches running STP (with uplinkfast for instance), I think it is worth having a mix of RSTP/STP.

If it's a matter of only updating a minority of switches to RSTP in the core, I don't think it's worth it.

At last a Cisco specific sidenote. If you are running MST, I really recommend getting rid of any PVST switch in the network if possible (rapid-pvst or pvst). When doing MST/PVST interaction, we fall back to STP convergence time (even rapid-pvst interaction on trunk ports, access ports are ok). So the same concerns as for the STP/RSTP interaction apply here. On the top of that, PVST simulation in MST mode is really complex and confusing for many users. Here, it is really worth trying to avoid that if possible (but again, I don't mean it's an error if it is necessary).

Hope this helps,

Francois