cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7667
Views
14
Helpful
11
Replies

MSTP / RSTP convergence

cisco_lad2004
Level 5
Level 5

Hi All

I am looking at issues with convergence on ring of 3550 / 3750.

What is the limit of switches that can be put on a ring topology ? I am not sure but my issues seems to be related to number of trunks, each time I add a trunk convergence times increases.

Any thoughts....before I segment the ring.

As a side mote, looking after this issues has cost me the nickname of Frodo Baggins.

TIA

Cisco Lad

1 Accepted Solution

Accepted Solutions

Hi Sam,

The proposal-agreement mechanism that makes RSTP and MST fast only works on point-to-point links.

By default, we derive the "type" (i.e. p2p vs shared) of the port from the duplex. Unless you are afraid that the negotiation of the duplex ends up in half-duplex, there is no real reason to hardcode the link type.

The link type interface command is available because you can obviously still have a point-to-point half duplex port.

Regards,

Francois

View solution in original post

11 Replies 11

johansens
Level 4
Level 4

Hi there Frodo ;),

The 'maximum' diameter which is normally supported is 7. This means looking at a 'worstcase' scenario, a packet traversing from one switch to another should have a maximum of 7 hops..

Check this page for info on "Understanding and Tuning Spanning Tree Protocol Timers":

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml

Did it help?

The STP timers are conservative. You can tune them automatically using the "spanning-tree root" macro.

The best would be to move to RSTP or MST, where you can go far beyond...

Regards,

Francois

m.mcconnell
Level 1
Level 1

Frodo, you must destroy the ring. You will get more stability from a physical star topology without the ever increasing reconvergence times. STP max diameter is 7 switches with default timers.

I have been liking the rapid pvst mode if your switches are new enough to run it.

-Mark

cisco_lad2004
Level 5
Level 5

Thank you, Warriors of Rohan :-)

I am actually running MSTP/RSTP with unacceptable convergence issues. Based on these documents:

http://www.cisco.com/warp/public/473/147.pdf

http://www.cisco.com/warp/public/473/122.pdf

I cannot see why we have issues, and I dare not temper with timers as this is a Metro Ring carrying traffic for the large corporates and state bodies. Bottom line, the ring must be desytoyed. In fact, I am thinking of terminating my Vlans and Dot1Q tunnels in colocated routers and then route packets in the ring, then no MSTP is needed. A stat topology woul dbe great, but it requires more ports and fibre.

Thanks for all ur comments,

Mr Sam (it is actually my name)

When you say that the convergence time depends on the number of bridges in the ring, could you be a little bit more specific about the exact value of the delay. Is it of the order of the seconds or of the order of the several forward_delay (15 seconds).

Tuning the timers does not help optimizing the convergence time in a correctly configured RSTP/MST network (when I mean correctly configured, I mean a network that is optimized for MST/RSTP, i.e. with point to point links and no interaction with legacy STP).

What I'm trying to determine is whether you have a problem or you are just hitting the limitation of the platforms you are running.

Regards,

Francois

Hi Francois

It is around 30-40seconds for 16 switches on a ring topology. Mailnly 3750 and 2 6509 acting as root for MSTP. My understanding so far is that, in failure scenario 3 times hello has to expire before a bridge decalares its Root port dead, then it syncs its designated port with next switch, and when a port goes to forwarding state, BPDUs with TC set floods the ring and each switch receiving them has to flush its MAC.

So far I am not sure if the whole flood/flush process takes (hello X Number of switches) and this case teh convergence depends on number of switches as well as number of Trunks/designated ports.

Once again, thanks for ur comments !

Sam

Hi Sam,

This is definitely too long for this kind of setup. However, you'll need to explain a little bit more how you measure the reconvergence time (you are pinging between two hosts and unplug a cable in the ring etc...)

MST detects a failure using 3xhello_time only if there is no hardware indication of a link going down. This is rather unusual unless you are using some repeaters or media converters between your switches. When a root port physically goes down, reconvergence starts immediately. In theory, the whole reconvergence should be entirely independent of any timer in an appropriate network, which means that the bottleneck will be the efficiency of our platforms. I expect your network to reconverge in the order of the second (1-3 seconds let's say).

Please, could you check that all the links between your switches are seen as point-to-point by the MST and that there is no STP switch in your ring.

When you lose connectivity for 30-40 seconds, can you identify which port is blocking (well, it's likely to be the port that was blocking during the stable condition and that is somehow slowly going to forwarding). Give some show span mst for this switch.

Regards,

Francois

Hi Francois

Yes all likns are P2P, I have few as P2P Bound PVST, some edge P2P but the ones that concerns me a bit are P2p Pre-STD-Rx reflecting what customet switch is transmitting, I do not have this configured on my port, not sure it would make a difference.

My switches are 3550/3560 and 3750 plus 2 6509 acting as root for each MST.

Th eoutage is seen when we add a new switch, as a result we are unable to access any switch for 30-40 seconds, so hard to troubleshoot. I am planning a debug/log session in few nights.

Many Thanks

Sam

Hi Sam,

Ok, so at least there are things to do. The ports that are in "Bound PVST" are not running MST but plain old slow legacy PVST. That would not be a big deal if it was some access switches connected to your ring, but in your particular case, this is the root port. Even when doing interaction between PVST and MST, we suggest that the root be located on the side of the MST region (for performance reasons). Here, the root is obviously on the PVST side.

Don't be too concerned about the "Pre-STD-Rx" flag. We recently released a new version of MST that is fully IEEE compliant (our initial release was proprietary because it was delivered before the MST standard was out). The switch that is displaying this "Pre-STD-Rx" flag is running this IEEE standard version and has detected a pre-standard neighbor. As a result, it automatically start sending pre-standard BPDUs on this port. The detection is not 100% reliable, that's why we display this flag to encourage network administrator to hardcode the neighbor type as pre-standard on the interface. To put it short, to get rid of the message: -1- configure "spanning-tree mst pre-standard" on the interface -2- or upgrade the neighbor to the latest release. -1- is supposed to be a temporary solution before -2- is possible.

So in the end, please make sure that all the switches in the ring are running MST. You will not get fast convergence if your netork is only partly running MST.

Some port may also be running PVST because they used to be connected to a PVST neighbor that has been later converted to MST. You can do a shut/no shut on the link or a "clear spann detected-protocol" on both sides to fix that.

Let me know what you find out!

Regards,

Francois

Hey Francois

This is really good info.

There is few things that I have to do to eliminate potential bottlenecks. Also discovered 2 P2P switches on the ring exchanging legacy BPDUs. They are both configured to run MSTP.

I have schedulded a maintenance winndow and look forward to make few changes and see a better convergence.

Is there any point in hardcoding link points, though they are negotiated and end up P2P ?

Regards

Sam

Hi Sam,

The proposal-agreement mechanism that makes RSTP and MST fast only works on point-to-point links.

By default, we derive the "type" (i.e. p2p vs shared) of the port from the duplex. Unless you are afraid that the negotiation of the duplex ends up in half-duplex, there is no real reason to hardcode the link type.

The link type interface command is available because you can obviously still have a point-to-point half duplex port.

Regards,

Francois

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: