RSTP recovery time with Ethernet ring

Question

I am trying to test Rapid Spanning Tree on an Ethernet ring. Most of what I found does not seem to apply to my specific situation, but I am happy to be pointed elsewhere.

Specifically, I have one Ethernet switch. Connected to that switch is a ring of "simple" Ethernet devices, each with 2 ports that do a simple passthrough/forward. So, to attempt an illustration:

    switch
    /    \
 Dev1 -- Dev2

The devices don't send their own RSTP packets. A real network would have 10s of devices in the loop. Before you complain "why would you do that?", this is moderately common in "industrial Ethernet" setups to provide redundancy but at a significant savings in wiring cost.

My problem is, while RSTP is working and the network connects, if I disconnect and reconnect one of the wires at the switch (generally the lower numbered port), it takes 30 seconds (listen+learn) to bring the connection back up. Clearly it is defaulting to the old STP algorithm.

Is this there any way to get the few-second recovery times generally promised by RSTP? Or is this just the way it is with a simple ring?

Answer 1

You need to make sure whether those devices

• really don't send any xSTP BPDUs on their own (verify by packet capturing) - you cannot trust the documentation at all times
• possibly pass through xSTP BPDUs - 802.1D-compliant bridges need to drop these BPDUs but there are many switches around (especially small ones) that do forward BPDUs.

If they really do not participate in xSTP but pass through BPDUs, your tree should reconverge very quickly, so I have some doubts.

If they don't send BPDUs and don't forward them either, your STP scheme is broken and cannot work. However, this would cause the loop to go undetected and cause a broadcast storm, so pretty obviously it's not the case.

I suspect there are different STP schemes at work.

• Classic (and obsolete) STP interoperates with RSTP and MSTP fairly well but slows them down (so that seems likely).
• RSTP and MSTP interoperate perfectly.
• (R)PVST flavors interoperate badly with anything IEEE in most cases, so that should be avoided.
• Something completely different (e.g. probing frames) that isn't documented and that you haven't discovered yet.

Additionally, RSTP is intended for a tree topology with a maximum depth of seven bridges. Assuming the devices participate in STP, the chain length exceeds that maximum and causes convergence problems.

You'd need to reduce the Hello Time (e.g. 1 s) to increase the propagation speed - depending on what those devices actually do, it might help or not.

Alternatively, you could increase the Maximum Age but that causes slower convergence.

Answer 2

If the devices are bridging, and they, themselves, do not support RSTP, then you will not be using RSTP. The STP version used will be the common version supported by all devices. To be able to use RSTP, all the bridges must support RSTP.

Even with RSTP, you will not get recovery times of <1s.

---

Specifically, I have one Ethernet switch. Connected to that switch is a ring of "simple" Ethernet devices, each with 2 ports that do a simple passthrough/forward.

That is a poor practice that should not be tolerated. The point of the devices having two interfaces is that a device can connect to to two different switches.