Spanning Tree - Siemens RUGGEDCOM ROX II User Manual

RUGGEDCOM ROX II
CLI User Guide
Problem
Section 6.4

Spanning Tree

The following describes common problems related to the Spanning Tree Protocol (STP).
Problem
The network locks up when a new port is
connected and the port status LEDs are
flashing rapidly.
Occasionally, the ports seem to experience
significant flooding for a brief period of time.
A switch displays a strange behavior where
the root port hops back and forth between
two switch ports and never settles down.
A computer or device is connected to a
switch. After the switch is reset, it takes a
long time for it to come up.
When the switch is tested by deliberately
breaking a link, it takes a long time before
devices beyond the switch can be polled.
Spanning Tree
Solution
However, it guarantees that all devices interested in the traffic will keep receiving it without
interruption.
The same behavior will be observed when the switch resets or when IGMP Snooping is
being disabled for the VLAN.
Solution
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. For more information refer to
when a specific application is
Another possible cause of intermittent operation is that of an auto-negotiation mismatch.
If one end of the link is fixed to full-duplex mode 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.
Is it possible that the RSTP edge setting for this port is set to false? If Edge is set to 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 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.
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 multi-point 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
The network becomes unstable
started.
Chapter 6
Troubleshooting
625