Ethernet Operation 279
reach Station 1, it also truncates the current transmission and substitutes a 32-bit jam
signal in place of the remainder of the frame being transmitted. Upon sending the 32-bit
jam signal, Station 1 ceases all transmissions.
A jam signal can be composed of any binary data, as long as it does not form a proper
checksum for the portion of the frame already transmitted. The most commonly observed
data pattern for a jam signal is simply a repeating 1, 0, 1, 0 pattern, the same as the
preamble. When viewed by a protocol analyzer, this pattern appears as a repeating
hexadecimal 5 or A sequence. The corrupted, partially transmitted messages often are
referred to as collision fragments and sometimes by the slang term runts. Compared
to late collisions, normal collisions are less than 64 octets in length and, therefore, fail
both the minimum length test and the FCS checksum test.
Types of Collisions
Collisions typically take place when two or more Ethernet stations transmit simulta-
neously within a collision domain. Collisions are reported by event counts by most
diagnostic tools, but they might be reported separately as single collisions or multiple
collisions when a switch or other station is queried with SNMP. A single collision refers
to a collision that was detected while trying to transmit a frame, but, on the next
attempt, the frame was transmitted successfully. Multiple collisions indicate that the
same frame collided repeatedly before being successfully transmitted. This is different
from frames with deferred transmissions because the deferred transmission frame did
not collide. The medium was busy when the station or switch sought to transmit, and
it was required to wait its turn to transmit. Because of repeated collisions of the same
frame, the frame might not be transmitted at all, which would be reported as being
aborted as the result of excessive collisions.
The results of collisions—partial and corrupted frames that are less than 64 octets and
that have an invalid FCS—often are called collision fragments. Some protocol analyzers
and network monitors call these fragments runts, but the term is imprecise.
The main Ethernet frame error types that can be captured through a protocol-analysis
session are local collision, remote collision, and late collision. Figure 5-16 illustrates
those collision types. The sections that follow briefly describe each frame error type.

Figure 5-16 Summary of Collision Types: Local, Remote, and Late
1102.book Page 279 Tuesday, May 20, 2003 2:53 PM
280 Chapter 5: Ethernet Fundamentals
Local Collision
To create a local collision on coax cable (10BASE2 and 10BASE5), the signal travels
down the single cable until it encounters a signal from the other station. The waveforms
then overlap, canceling out some parts of the signal and reinforcing (doubling) other
parts. The doubling of the signal pushes the voltage level of the signal beyond the
allowed maximum. This overvoltage condition is sensed by all of the stations on the
local cable segment as a collision. A special circuit in the NIC monitors for this over-
voltage condition. The overvoltage threshold is around –1.5 volts, as measured on the
coax cable. Figure 5-17 shows a midframe in 10BASE2/10BASE5 collision captured by
a digital storage oscilloscope.
Figure 5-17 10BASE2/10BASE5 Local Collision
In Figure 5-17, the beginning of the waveform represents normal Manchester-encoded
data. A few cycles into the sample, the amplitude of the wave doubles. That is the
beginning of the collision, where the two waveforms overlap. Just before the end of the
sample, the amplitude returns to normal when the first station to detect the collision
quit transmitting, and a jam from the second colliding station still is observed.
On UTP cable (such as 10BASE-T, 100BASE-TX, and 1000BASE-T), a collision is
detected on the local segment only when a station detects a signal on the RX (receive)
pair at the same time it is sending on the TX (transmit) pair. Because the two signals
are on different pairs, there is no characteristic change in the signal, as shown in Fig-
ure 5-17. Collisions are recognized on UTP only when the station is operating in half
duplex. The only functional difference between half- and full-duplex operation in this
regard is whether both transmit and receive pairs are permitted to be used simulta-
neously. If the station is not engaged in transmitting, it cannot detect a local collision.
1102.book Page 280 Tuesday, May 20, 2003 2:53 PM
Ethernet Operation 281
Conversely, a cable fault, such as excessive crosstalk, can cause a station to perceive its

own transmission as a local collision.
Remote Collision
The characteristics of a remote collision are a frame that is less than the minimum
length has an invalid FCS checksum, but does not exhibit the local collision symptom
of overvoltage or simultaneous RX/TX activity. This sort of collision usually results
from collisions that occur on the far side of a repeated connection. A repeater will not
forward an overvoltage state and cannot cause a station to have both the TX and RX
pairs active at the same time. The station would have to be transmitting to have both
pairs active, and that would constitute a local collision. On UTP networks, this is the
most common sort of collision observed. Nearly all monitoring tools that report colli-
sions, such as software protocol analyzers and Remote Monitoring (RMON) probes,
will detect only remote collisions because they are passive listening devices.
Late Collision
No possibility exists for a normal or legal collision after the first 64 octets of data have
been transmitted by the sending station(s). The theoretical maximums for legal net-
work propagation times are exceeded before then. Collisions that occur after the first
64 octets are called late collisions. The most significant difference between late collisions
and collisions that occur before the first 64 octets is that the Ethernet NIC retransmits
a normally collided frame automatically but does not automatically retransmit a frame
that collided late. As far as the NIC is concerned, everything went out fine, and the
upper layers of the protocol stack must deduce that the frame was lost. Other than
retransmission, a station that detects a late collision handles it in exactly the same way
as a normal collision.
In all but one case, the 802.3 standard permits a station to attempt to retransmit a
frame that collided late, but it does not require this. Gigabit Ethernet explicitly denies
late-collided frames from being retransmitted.
A late remote collision takes place after slot time has elapsed and on the far side of a
repeater. However, because the repeater would prevent observation of the local collision
symptoms of an overvoltage state or simultaneous receive/transmit event, monitoring
hardware would have to be present on the distant segment to detect a late collision and

report that information to the monitoring station. You also can infer that a late remote
collision took place somewhere on the other side of a repeater by analyzing the last
few octets of a bad frame for the presence of the pattern normally associated with a
jam signal. Typically, this type of collision would be detected on the local segment simply
as an FCS error.
1102.book Page 281 Tuesday, May 20, 2003 2:53 PM
282 Chapter 5: Ethernet Fundamentals
Ethernet Errors
Why learn about Ethernet errors? Because Ethernet is a dominant LAN technology, an
intimate knowledge of typical errors is invaluable for understanding both the operation
and troubleshooting of Ethernets.
Whereas local and remote collisions are considered to be a normal part of Ethernet
operation, the late collision is considered to be an error. The presence of errors on
Ethernet always suggests that further investigation is warranted. The severity of the
problem indicates the troubleshooting urgency related to the detected error(s). A
handful of errors detected over many minutes or over hours would be a low priority.
Thousands detected over a few minutes suggest that urgent attention is warranted.
Situations that are considered Ethernet errors are as follows:
■ Simultaneous transmission occurring before the slot time has elapsed
(collision or runt)
■ Simultaneous transmission occurring after the slot time has elapsed
(late collision)
■ Excessively or illegally long transmission (jabber, long frame, and range errors)
■ Illegally short transmission (short frame, collision fragment, or runt)
■ Corrupted transmission (FCS error)
■ Insufficient or excessive number of bits transmitted (alignment error)
■ Mismatch of actual and reported number of octets in frame (range error)
■ Unusually long preamble or jam event (ghost or jabber)
Each situation is defined separately. Frames associated with error conditions are fre-
quently, but not always, discarded. Normal collisions are included simply to provide

a more complete list but are not actually considered errors. The sections that follow
briefly describe some of the Ethernet errors.
Jabber
Jabber is defined several places in the 802.3 standard as being a transmission of at least
20,000 to 50,000 bit-times in duration. However, most diagnostic tools report jabber
whenever a detected transmission exceeds the maximum legal frame size—which is
considerably smaller than 20,000 to 50,000 bit-times. This presents a rather fuzzy
definition because the reporting device might or might not consider a 1518-octet frame
with VLAN tagging added to be larger than the legal limit. Also, no indication exists
as to whether jabber has a good or bad FCS. Most references to jabber more properly
are called long frames.
1102.book Page 282 Tuesday, May 20, 2003 2:53 PM
Ethernet Operation 283
Long Frame
A long frame is one that is longer than the maximum legal size and that takes into
consideration whether the frame was tagged. It does not consider whether the frame
had a valid FCS checksum. This error usually is meant when someone says that jabber
was detected on the network. Figure 5-18 illustrates that a long frame is longer than
1518 octets.
Figure 5-18 Long Frame
Jabber and long frames are both in excess of the maximum frame size. Jabber is signif-
icantly larger, however. If the frame is 802.1q tagged, that usually is not counted
toward being illegally large. The IEEE 802.1Q standard defines the operation of virtual
LAN (VLAN) bridges that permit the definition, operation, and administration of VLAN
topologies within a bridged LAN infrastructure. The IEEE’s 802.1Q standard was
developed to address the problem of how to break large networks into smaller parts so
that broadcast and multicast traffic would not grab more bandwidth than necessary.
Short Frame
A short frame is a frame smaller than the minimum legal size of 64 octets, with a good
frame check sequence. Some protocol analyzers and network monitors call these frames

runts, but the term is imprecise. In general, you should not see short frames, although
their presence is no guarantee that the network is failing.
Short frames are formed properly in all but one aspect and have valid FCS checksums;
they are less than the minimum frame size (64 octets), however. Figure 5-19 illustrates
that a short frame is shorter than 64 octets.
Figure 5-19 Short Frame
Runt
The term runt is generally an imprecise slang term that means something less than a
legal frame size. It can refer to short frames with a valid FCS checksums. It usually
1102.book Page 283 Tuesday, May 20, 2003 2:53 PM
284 Chapter 5: Ethernet Fundamentals
refers to collision fragments. The Ethernet standard describes an SNMP management
attribute called a runt that is approximately greater than 74 bit-times but less than the
minimum frame size (64 octets at 10-/100-Mbps speeds, or the minimum half-duplex
transmission event of 517 octets at 1000 Mbps); is not a local collision.
FCS Errors
A received frame with a bad frame check sequence (also referred to as a checksum or
CRC error) is different by at least 1 bit from what was transmitted. In a frame with an
FCS error, the header information is probably correct (the addressing and such), but
the checksum calculated by the receiving station does not match the checksum appended
to the end of the frame by the sending station. Trusting the accuracy of the addressing
in a single frame is probably a bad idea, but if many frames have the same source
address, there is a pretty good chance that the source address is correct.
A high number of FCS errors from a single station usually indicates a faulty NIC or
faulty or corrupted software drivers, or a bad cable connecting that station to the net-
work. If FCS errors are associated with many stations, it generally is traceable to bad
cabling, a faulty version of a NIC driver, a faulty hub port, or induced noise in the
cable system.
FCS errors are reported when at least 1 bit in the transmission is different. When a
new checksum is calculated by the receiving station and compared to the checksum in

the FCS field, the two do not match. The frame then is discarded.
Alignment Error
A message that does not end on an octet boundary is known as an alignment error.
That is, instead of the correct number of binary bits to form complete octet groupings,
some additional bits (less than 8) are left over. Such a frame is truncated to the nearest
octet boundary; if the FCS checksum fails, an alignment error is reported. This often is
caused by bad software drivers or a collision, and frequently is accompanied by a fail-
ure of the FCS checksum. Other causes are characterized by a read and write operation
error, which is caused by software bugs. If an alignment error is not corrected, this can
cause a crash. Usually, the software corrects itself, but this causes a sudden spike in
CPU resources for the router.
Range Error
A frame that has a legal-size value in the Length field but that does not match the
actual number of octets counted in the Data field of the received frame is known as
a range error. This error also appears when the Length field value is less than the
1102.book Page 284 Tuesday, May 20, 2003 2:53 PM
Ethernet Operation 285
minimum legal unpadded size of the Data field. A similar error, Out of Range, is
reported when the value in the Length field indicates a data size that is too large to
be legal.
Ghost
Fluke Networks has coined the term ghost to mean energy (noise) detected on the cable
that appears to be a frame but that lacks a valid SFD. To qualify as a ghost, this “frame”
must be at least 72 octets long (including the preamble); otherwise, it is classified as a
remote collision. Because of the peculiar nature of ghosts, it is important to note that
test results largely are dependent upon where on the segment the measurement is made.
Some types of noise fool nodes on a network segment into thinking they are receiving
a frame. However, the sensed frame never comes, so no data is passed up into the NIC
to be processed. After a while, the sensed transmission ceases and the NIC resumes
sending its own messages. Different network interfaces react differently, and no stan-

dards define how or when an NIC should react to a noisy segment. Repeaters usually
propagate these noise signals into other segments of the collision domain.
The visible symptom of ghosting is a network that is slow for no apparent reason. The
file servers are nearly idle, and network-monitoring equipment shows very low network
utilization, yet users complain that the network is excessively slow or completely down.
The symptom might be geographically limited, with one end of a large/long segment
seeming to operate and the other being slow or completely down.
Ground loops and other wiring problems are usually the cause of ghosting. Ghosts
cause some repeaters to respond as though a frame is being received. Because the
repeater reacts only to an AC voltage riding on the cable, there is no valid frame to
pass on to the other ports. The repeater, however, transmits this energy on to its other
port(s). The retransmitted ghost might appear as a jam pattern or a very long preamble.
Most network-monitoring tools do not recognize the existence of ghosts, for the same
reason that they do not recognize preamble collisions—they rely entirely on what the
chip set tells them. Software-only protocol analyzers, many hardware-based protocol
analyzers and hand-held diagnostic tools, and as most RMON probes do not report
these events.
Ethernet Autonegotiation
As Ethernet grew from 10 to 100 and 1000 Mbps, one goal was to make each technol-
ogy interoperable, even to the point that 10, 100, and 1000 interfaces could be directly
connected. A process called autonegotiation (of speeds and half duplex or full duplex)
was developed. Specifically, at the time that Fast Ethernet was introduced, the standard
1102.book Page 285 Tuesday, May 20, 2003 2:53 PM
286 Chapter 5: Ethernet Fundamentals
included a method of automatically configuring a given interface to match the speed
and capabilities of the link partner. This process defines how two link partners auto-
matically can negotiate a configuration that offers the best common performance level.
It has the additional advantage of involving only the lowest part of the physical layer.
10BASE-T required each station to transmit a link pulse about every 16 milliseconds
whenever the station was not engaged in transmitting a message. Autonegotiation

adopted this signal and renamed it a Normal Link Pulse (NLP). When a series of NLPs
are sent in a group for the purpose of autonegotiation, the group is called a Fast Link
Pulse (FLP) burst. Each FLP burst is sent at the same timing interval as an NLP and is
intended to allow older 10BASE-T devices to operate normally if they receive an FLP
burst. Figure 5-20 illustrates the NLP and FLP timing.
Figure 5-20 NLP Versus FLP Timing
10BASE-T transmits using signaling between +1 and –1 volts, for a 2-volt peak-to-
peak differential signal. NLP signaling uses only the range from 0 to +1 volts. The
duration of a single NLP pulse is 100 ns. Figure 5-21 illustrates two sample NLP pulses.
The left pulse is very sharp and clean, and is from an interface capable of 1000-Mbps
operation. The right pulse is from an older device capable of only 10/100-Mbps opera-
tion, which does not require as precise of a signal.
Figure 5-21 NLP Pulses
Autonegotiation is accomplished by transmitting a burst of 10BASE-T link pulses from
each of the two link partners. The burst communicates the capabilities of the trans-
mitting station to its link partner. After both stations have interpreted what the other
~
~
~
~
16 ms (+/- 8 ms)
1102.book Page 286 Tuesday, May 20, 2003 2:53 PM
Ethernet Operation 287
partner is offering, both switch to the highest-performance common configuration and
establish link at that speed. If anything interrupts communications and the link is lost,
the two link partners first attempt to link again at the last negotiated speed. If that fails,
or if it has been too long since the link was lost, the autonegotiation process starts over.
The link can be lost because of external influences, such as a cable fault, or because
one of the partners issues a reset.
Figure 5-22 shows the actual FLP autonegotiation burst. The FLP burst is made up of

multiple NLP link pulses.
Figure 5-22 FLP Autonegotiation Burst
An FLP burst consists of 33 pulse positions, which represent a 16-bit link code word
that is framed by 17 clocking pulses. Pulses within a burst are separated by 62.5 ms
(±7 ms). Data pulse positions are found between each clocking pulse. If a data pulse is
present, it is interpreted as a binary 1. The absence of a data pulse in the window
between two clocking pulses is interpreted as a binary 0
. As shown in Figure 5-23, the
17 clocking pulses are always present. The 16 data pulses are present only if they rep-
resent binary 1; they are absent if they represent binary 0 in the encoded 16-bit data
word. The pulses interpreted as binary 1s for data are highlighted in gray.
Figure 5-23 Interpretation of Autonegotiation Pulse
When autonegotiation is implemented, additional information can be added using the
concept of pages. Pages are additional bits representing more sophisticated negotiation
and link parameters.
After a device has decoded the link code word offered by its link partner, it acknowledges
receipt of the current word by sending at least three FLP bursts with the Acknowledge
bit set. After both link partners acknowledge the current FLP link code word exchange
in that manner, the link partners either move on to the next page or enable the agreed
1102.book Page 287 Tuesday, May 20, 2003 2:53 PM
288 Chapter 5: Ethernet Fundamentals
configuration and attempt to link accordingly. Link partners can send any number of
next pages following the initial configuration base page and any necessary next pages
that are associated with the base page.
Link Establishment and Full/Half Duplex
Link partners are allowed to skip offering configurations that they are capable of offer-
ing, but are not allowed to include configurations that they are not capable of offering.
This enables the network administrator to force ports to a selected speed and duplex
setting, without disabling autonegotiation.
Autonegotiation is optional for most Ethernet implementations. Gigabit Ethernet

requires its implementation, although the user can disable it. Autonegotiation origi-
nally was defined for UTP implementations of Ethernet. It has been extended to work
with other fiber-optic implementations through the use of /C/ ordered sets in the place
of the FLP bursts.
When an autonegotiating station first attempts to link, it is supposed to enable 10BASET
parts of the front-end chip set to attempt to immediately establish a link. If 10BASET sig-
naling is present and the station supports 10BASET, it attempts to establish a link with-
out negotiating. If either signaling produces a link, or if FLP bursts are received, the
station proceeds with that technology. If a link partner does not offer an FLP burst, but
instead offers NLPs, that device automatically is assumed to be a 10BASET station. Dur-
ing this initial interval of testing for other technologies, the transmit path sends FLP
bursts. The standard does not permit parallel detection of any other technologies.
If a link is established through parallel detection, it is required to be half duplex. Only
two methods of achieving a full-duplex link exist:
■ Through a completed cycle of autonegotiation
■ By administratively forcing both link partners to full duplex
If one link partner is forced to full duplex but the other partner parallel-detects while
attempting to autonegotiate, there is certain to be a duplex mismatch, resulting in col-
lisions and errors on that link. If you force one end, you must force the other. The
exception to this is that 10 Gigabit Ethernet does not support half duplex.
Many vendors implement their hardware in such a way that it cycles through the various
possible states. It transmits FLP bursts to autonegotiate for a while, then it configures
itself for Fast Ethernet and attempts to link for a while, and finally it simply listens for
a while. Some vendors do not offer any transmitted attempt to link until the interface
1102.book Page 288 Tuesday, May 20, 2003 2:53 PM