RuggedCom RS400 manual Troubleshooting

Spanning Tree

5.6 Troubleshooting

Problem One

When I connect a new port the network locks up. The port status LEDs are flashing madly.

Occasionally, the network seems to experience a lot of flooding. All the ports seem to experience significant traffic. The problem lasts a few seconds and then goes away.

One of my switches displays a strange behavior where the root port hops back and forth between two switch ports and never settles down.

Is it possible that one of the switches in the network or one of the ports on a switch in the network has STP disabled and accidentally connects to another switch? If this has occurred then a traffic loop has been formed.

If the problem appears to be transient in nature, it is possible that ports that are part of the spanning tree have been configured as edge ports. After the link layers have come up on edge ports, STP will directly transition them (perhaps improperly) to the forwarding state. If an RSTP configuration message is then received the port will be returned to blocking. A traffic loop may be formed for the length of time the port was in forwarding.

If one of the switches appears to flip the root from one port to another the problem may be one of traffic prioritization (See problem five).

Another possible cause of intermittent operation is that of an auto-negotiation mismatch. If one end of the link is fixed to full duplex and the peer auto-negotiates, the auto-negotiating end will fall back to half-duplex operation. At lower traffic the volumes the link may display few if any errors. As the traffic volume rises, the fixed negotiation side will begin to experience dropped packets while the auto-negotiating side will experience collisions. Ultimately, as traffic loads approach 100% the link will become entirely unusable. At this point RSTP will not be able to transmit configuration messages over the link and the spanning tree topology will break down. If an alternate trunk exists RSTP will activate it in the place of the congested port. Since activation of the alternate port often relieves the congested port of its traffic, the congested port will once again become reliable. RSTP will promptly enter it back into service, beginning the cycle once again. The root port will flip back and forth between two ports on the switch.

Problem Two

My PC/IED/Device is connected to your switch. After I reset the switch, it takes a long time before it comes up.

Is it possible that the RSTP edge setting for this port is set to false? If edge is set false the bridge will make the port go through two forward delay times before the port can send or receive frames. If edge is set to true the bridge will transition the port directly to forwarding upon link up.

Another possible explanation is that some links in the network run half-duplex. RSTP uses a peer-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.

ROS™ v3.5 166 RS400