Siemens RUGGEDCOM ROX II User Manual page 797

RUGGEDCOM ROX II
CLI User Guide
Problem
Unable to connect or disconnect some
switch ports, and multicast goes everywhere.
Is IGMP broken?
Section 19.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
IGMP is not broken. This may in fact be proper switch behavior.
When the switch detects a change in the network topology through RSTP, it acts to avoid loss
of multicast traffic. If configured to do so, it starts forwarding all multicast traffic to all ports
that are not RSTP Edge ports (because they may potentially link to routers). This may result in
some undesired flooding of multicast traffic, which will stop after a few minutes. 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.
The network becomes unstable
started.
Chapter 19
Troubleshooting
751