Chapter 6
Troubleshooting
RUGGEDCOM ROS
User Guide
248
Ethernet Ports
Section 6.2
Ethernet Ports
The following describes common problems related to Ethernet ports.
Problem
Solution
A link seems fine when traffic levels are low,
but fails as traffic rates increase OR a link can
be pinged but has problems with FTP/SQL/
HTTP/etc.
A possible cause of intermittent operation is that of a ‘duplex mismatch’. If one end of the
link is fixed to full-duplex and the peer auto-negotiates, the auto-negotiating end falls back
to half-duplex operation.
At lower traffic 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.
The ping command with flood options is a useful tool for testing commissioned links. The
command
ping
192.168.0.1 500 2
can be used to issue 500 pings each separated by
two milliseconds to the next switch. If the link used is of high quality, then no pings should
be lost and the average round trip time should be small.
Links are inaccessible, even when using the
Link Fault Indication (LFI) protection feature.
Make sure LFI is not enabled on the peer as well. If both sides of the link have LFI enabled,
then both sides will withhold link signal generation from each other.
Section 6.3
Spanning Tree
The following describes common problems related to the Spanning Tree Protocol (STP).
Problem
Solution
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.
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 started."
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.
A computer or device is connected to a
switch. After the switch is reset, it takes a
long time for it to come up.
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.
