Content

| 3.4 |  | Identifying Physical Layer Problems |
| 3.4.5 |  | Collision based problems – shared media |

Excessive collisions are most often caused by a problem with the physical media, such as missing or incorrect terminators, impedance discontinuities (bad connectors, cable stubs, crushed 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.