28. Spanning Tree
ROX™ v2.2 User Guide
330
RuggedBackbone™ RX1500
Another possible explanation is that some links in the network run in half-duplex mode. RSTP uses a
peer-to-peer protocol called Proposal-Agreement to ensure transitioning in the event of a link failure.
This protocol requires full-duplex operation. When RSTP detects a non-full duplex port, it cannot rely
on Proposal-Agreement protocol and must make the port transition the slow (i.e. STP) way. If possible,
configure the port for full-duplex operation. Otherwise, configure the port’s point-to-point setting to true.
Either one will allow the Proposal-Agreement protocol to be used.
Problem Three
When I test your switch by deliberately breaking a link, it takes a long time before I can poll devices
past the switch. I thought RSTP was supposed to be fast. What is happening?
Is it possible that some ports participating in the topology have been configured to STP mode or that the
port’s point-to-point parameter is set to false? STP and multipoint ports converge slowly after failures
occur.
Is it possible that the port has migrated to STP? If the port is connected to the LAN segment by shared
media and STP bridges are connected to that media, then convergence after link failure will be slow.
Delays on the order of tens or hundreds of milliseconds can result in circumstances where the link
broken is the sole link to the root bridge and the secondary root bridge is poorly chosen. The worst of all
possible designs occurs when the secondary root bridge is located at the farthest edge of the network
from the root. In this case, a configuration message will have to propagate out to the edge and then
back in order to reestablish the topology.
Problem Four
My network is composed of a ring of bridges, of which two (connected to each other) are managed and
the rest are unmanaged. Why does the RSTP protocol work quickly when I break a link between the
managed bridges but not in the unmanaged bridge part of the ring?
A properly operating unmanaged bridge is transparent to STP configuration messages. The managed
bridges will exchange configuration messages through the unmanaged bridge part of the ring as if it is
non-existent. When a link in the unmanaged part of the ring fails however, the managed bridges will
only be able to detect the failure through timing out of hello messages. Full connectivity will require
three hello times plus two forwarding times to be restored.
Problem Five
The switch is up and running and working fine. Then I start a certain application and the network
becomes unstable. After I stop the application, the network goes back to running normally.
RSTP sends its configuration messages using the highest possible priority level. If CoS is configured
to allow traffic flows at the highest priority level and these traffic flows burst continuously to 100% of the
line bandwidth, STP may be disrupted. It is therefore advised not to use the highest CoS.
Problem Six
After I bring up a new port, the root moves on to that port, and I don’t want it to. The port that I want
to become root won’t do so.
Is it possible that the port cost is incorrectly programmed or that auto-negotiation derives an undesired
value? Inspect the port and path costs with each port active as root.
Problem Seven
My IED/Controller doesn’t work with your switch.
Certain low CPU bandwidth controllers have been found to behave less than perfectly when they receive
unexpected traffic. Try disabling STP for the port.
