cables, and so on), and bad network interface
cards. There are several things to watch for in relation to
collisions: - Does the detected collision level track
approximately with the utilization level?
If
changes in utilization and collision levels track together
reasonably closely, then there may simply be too many stations
transmitting on the collision domain, assuming that there is a
collision problem at all. - Are there spikes of detected
collisions that do not follow the utilization level?
If there are spikes of detected collisions that are
significantly different from the general fluctuation in
utilization, then the collisions may often be traced back to a
single source. It may be a bad cable to a single station, a bad
uplink cable on a hub or port on a hub, or a link that is
exposed to external electrical noise. Over time the problem
station may be isolated by monitoring the traffic sources at
the same time as the collision level bursts higher. Note which
station(s) are transmitting at the time when spikes of
collisions are detected. If the problem seems to relate to
transmissions from a single station then troubleshoot that
suspect link. If the problem seems to relate to transmissions
from multiple stations then compare that information against
the functional network diagram to see if there is a common path
between those stations and the rest of the collision domain.
The single station could be an uplink from the collision domain
to a switch, and the functional diagram should reveal that all
of the other stations are beyond that link. One or more
stations set to full duplex within a collision domain will also
cause this sort of collision problem, as well as other errors.
- Are there collisions when there is no apparent
utilization to cause them?
If there are abnormal
numbers of collisions taking place when there is little or no
utilization to cause them, then suspect a noise source near a
cable or hub. Use divide and conquer troubleshooting to isolate
the location of the fault, adding traffic to the network from
the monitoring tool while troubleshooting. This sort of fault
must usually be diagnosed after-hours since portions of the
collision domain will be disconnected from the network during
troubleshooting. - Are there approximately 33 percent or
100 percent collisions?
If the level of collisions
is either 33 percent or 100 percent, there may be a 100 Mbps
station attempting to connect to a 10 Mbps segment. This
collision level results from a station transmitting MLT-3
encoded 100 Mbps signal to the 10 Mbps hub. The 10 Mbps hub
turns on the link state LED and forwards its best
interpretation of the MLT-3 signal as Manchester encoded data.
The 100 Mbps end is not able to establish synchronization, and
thus does not turn on the link state LED or forward any
received traffic to the MAC Layer. The reverse situation does
not result in a problem. If a 10 Mbps station attempts to
insert into a 100 Mbps only hub, then that station will not
achieve MLT-3 synchronization and the hub will not turn on the
link state LED or attempt to interpret and forward the
Manchester encoded signal. To track down the source of
collisions, it is often necessary to have traffic on the
network. Use a traffic generator to add a small amount of
traffic while monitoring. A safely insignificant level of
traffic is 100 frames-per-second, 100-byte frames, which is
still sufficient to sensitize nearby faults and allow them to
be located. Be sure that the destination MAC address for
generated traffic will not affect other parts of the network
while troubleshooting. Using a destination address within the
collision domain will prevent the traffic from crossing bridged
connections and disrupting other users. Do not make up a
non-existent destination MAC address because that will flood to
all parts of the broadcast domain. If the generated level of
traffic is very low, then the destination address could be set
to that of the tool or station generating the traffic without
disrupting its operation. Some media-related problems are
traffic-level dependent. Try gradually raising the traffic
level to more than 50 percent, and at the same time watching
the error and collision levels. Many monitoring tools offer LED
indicators for both, which makes it much easier to vary the
traffic level while watching for resulting errors or elevated
collision levels. Be careful when doing this because it can
easily saturate the network. Solving collision-related problems
can be very tricky because the measurements are largely
dependent upon the observation point. Results may vary between
two observation points separated by only a few feet on the same
cable. Make tests from multiple locations and watch for changes
in the nature of the problem. If collisions get worse in direct
proportion to the level of traffic, if the amount of collisions
approaches 100 percent, or if there is no good traffic at all,
the cable system may have failed. For UTP cable, test the
entire cable path between the hub and the station connection.
Substitute a known-good patch cable before testing, as patch
cables are the most likely source of the problem. For coaxial
cable, try a DC continuity test. About 25 ohms should be seen
if both terminators are present and testing occurs from a BNC T
connection, or 50 ohms if testing from an end. For fiber-optic
cable, check to see if the connections are fully seated and
clean. A loose connection or a dirty connection can result in
the receiver misinterpreting input signals as a result of poor
signal quality, and usually results in other errors in addition
to collisions.
Content 3.4 Identifying
Physical Layer Problems 3.4.6 External
interference One of the most notable causes of
Electromagnetic Interference (EMI) is lightning. When
electrical disturbances occur in the environment they impact
radio and television broadcast signals. This will often result
in crackling and popping sounds in speakers or bright flashes
on the screen. Common occurrences in a building utility system,
such as main power lines near data cables, cabling runs passing
elevator installations, or other features that use electrical
motors, can cause interference as well. Loose connections,
damaged or aging equipment and dusty insulators are a few of
the conditions causing electrical noise from the outside world.
Noise
On any line, even in the absence of a data
signal, random fluctuations of the line voltage and current
will occur. This effect is known as Line Noise Level, or simply
Background Noise. There are three main causes of this noise:
- Cross-talk
- Impulse Noise
- Thermal
Noise, which will not be discussed
Cross-talk – Occurs when a signal on one line is picked
up by adjacent lines as a small noise signal. Particularly
troublesome is Near- End Cross talk (NEXT) caused when a strong
transmitter output signal interferes with a much weaker
incoming receiver signal. Impulse Noise – This noise is
caused by external activity or equipment and generally takes
the form of electrical impulses on the line. These impulses can
cause large signal distortion for their duration and can bring
the entire network down whenever they occur. Proper common-mode
line terminations must be used for the unused Category 5, UTP
cable pairs 4/5 and 7/8. Common-mode termination reduces the
contributions to EMI and susceptibility to common-mode sources.
Wire pairs 4/5 and 7/8 are actively terminated in the RJ-45,
100BASE-TX port circuitry in the FE-TX port adapter.
Content 3.4 Identifying Physical Layer
Problems 3.4.7 Configuration script errors
Many things can be misconfigured on an interface to cause it to
go down. This will cause a loss of connectivity with attached
network segments. Changing the subnet of an interface to a
different one from the directly attached network segment is an
obvious way to shut down their connection, but this is not a
physical layer problem. If a LAN segment has multiple links to