cables, and so on), and bad network interface cards. There are several things to watch for in relation to collisions: 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. 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. 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. 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 – 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