|Ethernet Troubleshooting - Physical Frame Corruption|
|Written by Administrator|
|Friday, 27 May 2011 23:58|
When troubleshooting your Ethernet network, the first thing to look for is physical frame corruption. 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 being discussed is SPECIFIC TO COAXIAL ETHERNET. Twisted-pair Ethernet implementation will NOT manifest these types of corruption patterns!
Let's find the problem !
I am going to discusses troubleshooting with reference to the Network General Expert Sniffer Network 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 therefore recognizable.
The four causes are:
At the end of the section 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, where 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 Sniffer'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 AAs or several bytes of 55s 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 impedances. 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 when the maximum allowable bend radius of the cable 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 Sniffer will also probably 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 it is different in that the frames are generally cut off at random lengths.
Frame corruption 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 corruption is impossible to predict, generally manifesting as random "garbage" in the frame, but some common signs are:
REMEMBER: This applies to corruption patterns that would be visible when viewing frames on a COAXIAL Ethernet.
1. Is a preamble (less than 8 bytes of AA or 55) visible at the very end of the frame?
If no, go on.
2. Are the corrupt frames very short, and consistently the same length?
If no, go on.
3. Are the frames random in length, all cut off cleanly with no signs of bit streaming or other hardware malfunction?
If no, go on.
4. If you've arrived at this point, your problem is probably hardware related. Use the "divide and conquer" method outlined in bullet 1.