RuggedCom RS400 用户手册
Spanning Tree
ROS™ v3.5
166
RS400
5.6 Troubleshooting
Problem One
When I connect a new port the network locks up. The port status LEDs are flashing
madly.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.