Ethernet Troubleshooting: Physical Frame Corruption
When troubleshooting your Ethernet network, the first thing to look for is physical frame malfunction. In this essay, we will discuss the different causes of physical frame corruption and the characteristics of each one. It is important to remember that the frame corruption that is being discussed is SPECIFIC TO COAXIAL ETHERNET. Twisted-pair Ethernet implementation will NOT manifest these types of corruption patterns!
This page discusses troubleshooting with reference to the WildPackets EtherPeek NX Analyzer. While the tips here are universal, other Analyzers’ behavior might differ in such a way as to make these tips invalid or unusable.
There are four possible causes of physical frame corruption in an Ethernet Network, each one different in the way it corrupts the frame and is therefore recognizable.
The four causes are:
- Collisions. Caused by out of spec. cabling or faulty hardware.
- Signal Reflections. Caused by un-terminated cables, impedance mismatch, and exceeding the maximum allowable bend radius of the cable.
- Electrical Noise. Caused by nearby power grids, fluorescent lighting, X-ray machines, etc…
- Malfunctioning Hardware. Caused by gremlins, helpful users, natural disasters, etc…
At the end of the discussion there is a Troubleshooting Flowchart to help you identify the cause of frame corruption. It is important to remember that these corruption patterns will only be evident on a coaxial Ethernet (10BASE-2 Thin Ethernet, 10BASE-5 Thick Ethernet). Twisted-Pair Ethernet networks, because each station is connected to a hub or switch, do not manifest these exact corruption patterns.
Collisions are the most easily recognizable of the four causes of physical frame corruption. Generally, when a collision occurs, several bytes of the preamble of the colliding frame will be read into your Analyzer’s buffer before the signal is completely destroyed. You will see these bytes in the hexadecimal decode of the packet as either several bytes of AA’s or several bytes of 55’s at the very end of the frame (Remember, AAh=1010b, 55h=0101b. Depending on where the collision occurred, the preamble could be perceived as either of these).
Because the preamble is only 8 bytes long, ending in 1011, if you see more than 8 bytes of AA or 55, then the corruption was not caused by a collision and more investigation is necessary.
Signal reflections are caused by electrons literally “bouncing” back along the wire. One cause of signal reflection is an un-terminated cable. Electrons travel down the wire until they reach the cable’s end, where, with no resistor to absorb the voltage potential, they reflect back from the open end of the cable.
Another cause of signal reflections is mixing cables with different impedance’s. Impedance can be thought of as the “rate of flow” of the wire. When electrons from the higher impedance wire attempt to travel through the lower impedance wire, some of them can’t make it and are reflected back, destroying the signal.
The final cause of signal reflections is exceeding the maximum allowable bend radius of the cable. When the maximum bend radius is exceeded, the copper media is deformed, causing reflections.
The characteristic of signal reflection is very short frames (typically less than 16-32 bytes), with no preamble in the frame, and with all frames cut short within one or two bytes of the same place in the frame. Once again, this can be determined by viewing the frames in the Hexadecimal Decode view of your analyzer. The Expert in EtherPeek NX will also detect a high number of short or runt frames, as well as a high rate of physical frame corruption.
Physical frame corruption caused by electrical noise is similar in appearance to corruption caused by reflections in that there is no preamble in the frame — the frame just seems to stop short, but is different in that the frames are generally cut off at random lengths.
Frame malfunction caused by hardware malfunctions is potentially the hardest to diagnose because of the large number of ways that hardware can malfunction. Generally, hardware malfunctions will occur either randomly or constantly, but not regularly. The type of frame malfunction is impossible to predict, generally manifesting as random “garbage” in the frame, but some common signs are:
- A stream of ones or zeros. A transceiver has malfunctioned and is “jabbering” on the wire. Most transceivers have jabber detection circuitry that prevents the adapter from transmitting for longer than a certain preset time.
- Gigantic frames (greater than 1500 bytes). Same as above.
Remember: This applies to corruption patterns that would be visible when viewing frames on a COAXIAL Ethernet.
- Is a preamble (less than 8 bytes of AA or 55) visible at the very end of the frame?
- Make sure you haven’t exceeded the specifications of your cable (maximum cable length, maximum repeaters in between nodes, etc)
- Use a “divide and conquer” method to isolate the troublemakers. Separate the network into halves using a bridge and see which side of the bridge the problems occur on. Now separate that half into halves, etc….
If no, go on.
- Are the corrupt frames very short, and consistently the same length?
- Your problem is probably related to signal reflection. First check for un-terminated cables. If the cable is terminated properly, your job becomes a lot harder. If new cable has been installed recently, impedance mismatch is probably the problem. Avoid this problem by buying all your cabling from the same lot (if possible) and buying cabling all at once and putting extra in storage rather than ordering as needed. Finally, check for cable deformation due to bending the cable or placing heavy objects on the cable.
- A Time Domain Reflectometer can really save you some work when diagnosing this type of problem. This device can tell you, probably to the foot, how far down the wire the signal reflection is occurring.
If no, go on.
- Are the frames random in length, all cut off cleanly, with no signs of bit streaming or other hardware malfunction?
- Your problem is probably electrical noise. Use the “divide and conquer method outlined in bullet number 1 to determine where the noise is occurring and then use your intuition. I’ve seen problems as bizarre as a dentist’s X-ray machine being on the other side of the wall that the wiring closet was up against, and every time the dentist would take an X-ray, the network would go down.
If no, go on.
- If you’ve gotten to this point, your problem is probably hardware related. Use the “divide and conquer” method outlined in bullet 1.