Help: Stp, rpvst, portfast

jamster2004

Hey i am just a little bit confused here. RPVST is supposed to cut down on the the convergence time of switches whenever there is a change in the topology. how much time would be saved here with only RPVST enabled as compared to enabling rpvst along with portfast? i am really curious as to how portfast work along with rpvst.

veritas_libertas

The way I understand it is that RSTP is simply STP with Portfast, Backbonefast, and Uplinkfast all rolled into one.

Someone please correct me if I'm wrong.

Zartanasaurus

veritas_libertas wrote: »

The way I understand it is that RSTP is simply STP with Portfast, Backbonefast, and Uplinkfast all rolled into one.

Someone please correct me if I'm wrong.

Topology Change process is completely different.
Dead timer calculated differently.
New port types, states and link-types.
Rapid convergence.
BPDU propagation is different.

veritas_libertas

Thanks for correcting me. I didn't realize how greatly different it was. I figured that beyond the convergence time and port state changes it wasn't that different.

MickQ

Backbonefast and Uplinkfast are basically included in RSTP.
Portfast isn't as it still has stuff relating to TCNs.

Timers are quite different, and the states are kinda related, but more common sense and less "wasteful" in RSTP.

mapletune

If i recall correctly, portfast is an STP enhancement implemented by Cisco. Otherwise with STP, access switchports still need to wait 15 seconds in listening and 15 seconds in learning (default time) before moving into forwarding.

RSTP forwards frames to edge ports instantly, effectively placing all access ports into "portfast" by default.

thus, back to OP question:

how much time would be saved here with only RPVST enabled as compared to enabling rpvst along with portfast? i am really curious as to how portfast work along with rpvst.

I'd have to say none. They are the same.

zrockstar

RSTP Edge ports (access ports) go directly into forwarding state, that is the similarity to Portfast. I don't even know if you can enable Portfast on RSTP, because it already is built in. The difference with RSTP and the reason it is considered "Rapid" is because STP will wait 20 seconds after not receiving a BPDU before it triggers a topology change. STP then has to do into listening and learning for 15 seconds each, making the total topology change convergence 50 seconds. RSTP will trigger a topology change any time a non Edge port goes into the forwarding state, or immediately after 3 BPDUs have not been received (6 seconds) then bring up a backup port to restore the tree.

MickQ

Portfast is NOT built into RSTP. Backbone and uplinkfast are.

One particular thing to remember about portfast is that it disables the sending of TCNs. TCNs tell the switches to hit their maxAge timers on the CAM table.
The timers aren't fixed at the default, so it's worth remembering what the states relate to, more so than only the default timers.

BPDU guard is also recommended to be used with RSTP.

Here's some more info.

Zartanasaurus

zrockstar wrote: »

RSTP Edge ports (access ports) go directly into forwarding state, that is the similarity to Portfast. I don't even know if you can enable Portfast on RSTP, because it already is built in. The difference with RSTP and the reason it is considered "Rapid" is because STP will wait 20 seconds after not receiving a BPDU before it triggers a topology change. STP then has to do into listening and learning for 15 seconds each, making the total topology change convergence 50 seconds. RSTP will trigger a topology change any time a non Edge port goes into the forwarding state, or immediately after 3 BPDUs have not been received (6 seconds) then bring up a backup port to restore the tree.

RSTP has support for portfast in the form of edge ports, but it's not enabled by default. One of the things that makes the process rapid (in addition to the faster dead timer) is the proposal/agreement exchange between two switches. They can quickly negotiate which port is going to be the DP and start forwarding instead of going through a longer process. Since an end device won't participate in the proposal/agreement process, and the port isn't configured as an edge port (portfast), the switch falls back to standard listening-learning-forwarding process for that port.