STP/RSTP problem

[vipin.b.s]

Hi,

It seems that the normal working of STP/RSTP keeps the ports whose link is not up in forwarding state (role = designated).

When such a port is connected to another port in the forwarding state, a network loop may occur.

Such a loop will be resolved when one of these ports receives a BPDU sent by the other.

But at the time of connection establishment between these ports, if there is some broadcast going on, a broadcast storm may create due to the temporary loop. Consequently BPDUs will collide with the broadcast packets and the ports will not be able to exchange BPDUs and it takes longer time for the network to converge. In the worst case, it will never converge. Please see the attached topology.

In this case:

a) There is a "ping" between PC_A and PC_B. (ping interval: 1 second)

b) PC_C transmits broardcast packets every 1 second.

c) Connection between SW_111(Port1) and SW_444(Port1) is restored.

In certain trails, broadcast storm was created on reconnection and it took longer time for the network to converge.

It took more than 180 seconds for RSTP to converge in certain cases.

If there is no broadcast, such a topology will converge in 0-2 seconds for RSTP and 0-19 seconds for STP.

Approximate reconvergence time was measured by counting the ping "Request timeout" messages.

One solution is to disable the "link-down ports" and enable it on link-up.

But this increases the convergence time by 30s (two forward delay timer expiries after link-up)

How can this problem be solved without affecting the normal convergence time?

Thanks in advance,

Vipin

[Francois Tallet · Accepted solution]

Hi Vipin,

By default, STP puts a port in designated role but *discarding* state at link up. This means that the temporary loop you describe will not occur.

I don't know what you mean by "link-down ports" option, but I have the feeling that you enabled portfast on a port where you should not have it. Portfast is supposed to identify what the IEEE call "edge" ports. An edge port only connects to end stations (from the L2 perspective, a router is an end station for instance). In your case, you are connecting two layer 2 devices together and portfast is not a valid configuration (the CLI must even complain when you enter the command;-))

It is true that the STP convergence time will be 30 seconds in your scenario, but RSTP should be extremely fast here. Make sure that all the ports are seen as point to point by the spanning tree (which should be the case by default if the links are full duplex, else you can configure the link type manually at the interface level).

Hope this helps!

Francois

[vipin.b.s]

Hi Francois,

Even though you slightly misunderstood my problem, I got what I was looking for. Infact I was debugging an STP/RSTP implementation which puts a port in designated forwarding if the corresponding link is not up. So the solution was to keep such ports in disabled state as long as the link is not up and enable it (designated discarding for RSTP/designated blocking for STP) on link up. Initially I thought that, after the integration of this solution, both STP & RSTP will take 30s to converge in the scenario mentioned in the previous post.

I made necessary corrections in the implementation and the test results show that RSTP is extremely fast (converges in less than 1s) as mentioned in your reply.

Thank you!

- Vipin

[Francois Tallet]

Hi Vipin,

What implementation is that? Is it bridge-group based (I don't know much about this one). What you described is what we call portfast;-) So maybe does not have the same name in the implementation you are testing, but it has the same functionality.

In any case, that should not be the default configuration. If this is a Cisco box, we should change this. Let me know.

Regards,

Francois

[vipin.b.s]

Hi Francois,

It is not a Cisco product. Infact it's an 8-port

10/100Mbps plus 3 port Gigabit Ethernet switch based on Marvell 88E6095 switching chip and Samsung s3c4510 management CPU.

Regards,

Vipin

[Francois Tallet]

Thanks for the update Vipin, it comforts me;-)

Regards,

Francois