Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

RAPID STP configuration

RSTP will be configured on ten 2950 switches connected to two 6500 core switches. Only CLI command I found about RSTP is:

switch(config)#spanning-tree mode rapid-pvst

is that all i need? no need to configure edge ports?

and is RSTP a sub-second process?

tx in advance.

1 ACCEPTED SOLUTION

Accepted Solutions

Re: RAPID STP configuration

Yes you need to configure portfast on access ports. RSTP uses a sync mechanism that allows it to converge independently of any timer (it beats backbonefast and uplinkfast in terms or performance... these features are irrelevant in RSTP). This mechanism however blocks ports temporarily during reconvergence. Edge ports that are not correctly identify could then suffer some temporary loss of connectivity.

You can simply enable portfast on all the access ports. If you have lots of access ports, which must be the case on your access switches, you can also enable portfast by default on all the ports and explicitly disable it on your uplinks.

On your 10 access switches, enter the global configuration: spanning-tree portfast default

Then on the interface connecting to other bridges (the 6500 or the neighboring access switches) configure: spanning-tree portfast disable

Regards,

Francois

9 REPLIES
Purple

Re: RAPID STP configuration

I believe that is all that is needed , but all switches in the domain must be setup for rspt otherwise it reverts to pvst. Don't know about subsecond but its usually within a couple of seconds as opposed to 50 for normal pvst.

Purple

Re: RAPID STP configuration

Hi,

That one command is all you need. Typically you will get a convergence time of around 2-3 seconds with 802.1w.. however, in a properly designed network, convergence times around a few hundred milliseconds is also possible.

Hope that helps - pls rate posts that are helpful

Paresh

Re: RAPID STP configuration

That's all it takes to configure Rapid-PVST (RSTP). However, RSTP will only be efficient in an "appropriate" network where:

- links are point-to-point (slow convergence on shared segments)

- edge ports are correctly identifies, i.e. portfast is configured on all the ports that are not leading to a L2 device.

- no interaction with STP is necessary: STP-like convergence time when interacting with STP.

This is generally not a big deal in modern networks... it's generally just a matter of configuring portfast where necessary.

Community Member

Re: RAPID STP configuration

Please see the attached file.

on this topology, access switches(total ten) and core switches are considered point-to-point.

- so all has to be done is; executing the "switch(config)#spanning-tree mode rapid-pvst

" command on all 10 access switches and two core switches would do the job ?

- for ports connected to end users and server (edge ports) do i need to configure portfast for RSTP ?

Tx a lot in advance

Community Member

Re: RAPID STP configuration

its clear now. The UplinkFast, BackboneFast, and cross-stack UplinkFast features are not supported with the RSTP.

But portfast is supported

Silver

Re: RAPID STP configuration

UplinkFast and BackboneFast was Cisco's proprietary way of "fixing-up" traditional STP for faster convergence.

The intelligence of UplinkFast and BackboneFast is built in to the RSTP protocol natively. You are not loosing these features by using RTSP, you just dont need to configure them anymore.

Re: RAPID STP configuration

Yes you need to configure portfast on access ports. RSTP uses a sync mechanism that allows it to converge independently of any timer (it beats backbonefast and uplinkfast in terms or performance... these features are irrelevant in RSTP). This mechanism however blocks ports temporarily during reconvergence. Edge ports that are not correctly identify could then suffer some temporary loss of connectivity.

You can simply enable portfast on all the access ports. If you have lots of access ports, which must be the case on your access switches, you can also enable portfast by default on all the ports and explicitly disable it on your uplinks.

On your 10 access switches, enter the global configuration: spanning-tree portfast default

Then on the interface connecting to other bridges (the 6500 or the neighboring access switches) configure: spanning-tree portfast disable

Regards,

Francois

Community Member

Re: RAPID STP configuration

thank you man it helped a lot

one last question;

what if there were ten unmanaged access switches instead of ten 2950s? Would RSTP work in this case?

unmanaged switches do not support RSTP/STP. But still 6500 with RSTP running on it can rapidly prevent the loop cant it?

Re: RAPID STP configuration

I assume that your unmanaged switches are nice guys and don't eat up BPDUs (I've seen some doing that!!). So basically, they look like hubs to the STP.

If the diagram is exactly as what you showed earlier, you are running a little risk, and this independently of whether you are running STP or RSTP - I mean that if you are currently running STP, you already have this potential problem;-). The problem is that you have a link between two access switches and this link is entirely invisible to the STP. Suppose that this link goes away. As a result, after (slow) STP reconvergence, both ports on the 6500s are designated forwarding. Now, when the link between the two access switches come back up, it becomes immediately forwarding. As a result, you have a temporary bridging loop until the 6500 ports hear of their neighbor. Bridging loops are really not desirable in L2 domains, even temporary ones. That's just a risk you're taking, the situation should stabilize.

If your access switches don't run STP but are simply directly connected redundantly to the two 6500, this should be fine.

Now, as far as reconvergence time...

When an uplink fails, you will only have slow convergence because the blocked port on the cat6500 have no neighbor running RSTP to answer its proposals. So 2xforward-delay (30 seconds by default) will be necessary for it to go forwarding.

When the uplink comes back up, you will currently wait another 2xforward-delay before it can become forwarding. This is because our current implementation does not send back agreement on backup or alternate ports. This will be changed in an upcoming release. This behavior is already available in the latest MST implementation, if you want to go this way (MST would make sense in your network).

Regards,

Francois

361
Views
0
Helpful
9
Replies
CreatePlease to create content