MST RSTP Convergence Time

Unanswered Question
Apr 16th, 2008

Hi all!

I have a ring topology with 5 switches running MST Standard with 2 instances. The Aggregation switch is configured within a MST Region, and the others 4 switches belong to another MST Region. I am doing some tests to find out the real convergence time in the event of a link failure. I realize that when a link in the ring goes down, the convergence time is 1-2 seconds, but in some situations (not identify yet), when a link in the ring comes up the convergence time is 30s. The question is:

Can anyone confirm me that if everything is fine in my topology (all the switches are working correcly, the links are point-to-point, there is no erros in the links, the proposal-aggreement mechanism works fine, etc), the convergence time should be 1-2 seconds in the event of any link going up or down ?

I'm sorry for my english (I am from Argentina).

Thanks!

Max

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Francois Tallet Wed, 04/16/2008 - 22:26

Hi Max,

Convergence time should be similar when the link is coming up.

Check:

-1- that all the links in your ring are seen as point-to-point by MST (this is the default if they are full duplex). It seems you have already done that.

-2- check that you have configured portfast on the ports connecting end devices. I would not be surprised if there was such portfast configuration missing on the path you are testing in order to measure the convergence time.

Regards,

Francois

Maximiliano Gus... Thu, 04/17/2008 - 04:31

Francois, thanks for your soon response (as usual). I am doing qinq at the edge ports of two of the switches and portfast is configured there. What I see is that in some situations, when a link comes up it takes 30s to move to the forwarding state. Do you think this issue can be due to any software problem ? It seem to me that in some cases the proposal-aggreement mechanism is not working fine. Anyway, I just wanted to be sure that in this kind of topology the MST protocol works fine and offers 1-2 seconds of convergence if any link connecting the switches in the ring goes down or comes up (assuming that everything is configured correctly like portfast, point-to-point link, etc). I will keep trying to find out what can be the cause of this behavior..

Regards,

Max

Francois Tallet Thu, 04/17/2008 - 10:53

Hi Max,

Yes, if this is a port that is within your ring, the proposal agreement should move the port to forwarding quickly. If it is an edge port (whether it is configured for qinq or not), it should go forwarding immediately (and not sync).

Regards,

Francois

Maximiliano Gus... Thu, 04/17/2008 - 13:47

Thanks Francois!

I will let you know the end of the story..

By the way, do you know about the existence of a feature to protect against a TC storm? I'am using Cisco ME3400 and CISCO 7600 SUP720-3BXL.

Regards,

Max

Francois Tallet Thu, 04/17/2008 - 13:50

Hi Max,

You're talking about limiting the flush right?

No, I don't know of any mechanism. The trick is that it would not be desirable to miss a topology change indication, so it's difficult to decide when you could ignore one. What do you have in mind exactly?

Regards,

Francois

Maximiliano Gus... Thu, 04/17/2008 - 14:19

Hi Francois,

I'am talking about limiting the rate of TCs. For example, if under a strange situation, a storm of BPDUs with the TC flag set is generated by a switch, the CAM will flush in every switch in the network (where the vlans affected are permitted) many times as BPDUs with the TC flag set are received. This will generate a permanent flooding situation during this behaviour that will affect, for example, different services (clients) using the same MetroTag or services (same client) using one MetroTag but in more than two edge ports (point to multipoint L2 transparent service).

I hope you can understand what I want to tell you.

For example, with these feature, you could flush the entire CAM not more than once in 10 sec. Of course, in this case were are assuming that won't be more than one real TC during this period.

Thanks a lot, and againg sorry for my english.

Regards,

Max

Francois Tallet Thu, 04/17/2008 - 14:35

Hi Max,

The problem is that it's difficult to determine when it's time to stop processing or propagating the TC. How do you make the difference between a device that keeps generating TC "by mistake" from a device that does it rightfully? If you just rate limit, you may fail to process a valid TC. This could result in a long loss of connectivity. On the other hand, flooding is not optimal but will not prevent connectivity. That's why it is generally preferred to black holing.

Now, I don't say this kind of feature could not be implemented, but we have nothing in store for that right now.

> Thanks a lot, and againg sorry for my english.

Now, if you had not apologized for your english, I would not have found a single error in your message;-) So rest assured that you can fool a French guy into thinking you're a native English speaker!

Regards,

Francois

Actions

This Discussion