CCNA 1 and 2 Companion Guide, Revised (Cisco Networking Academy Program) part 32 potx

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.. The main Ethernet frame er

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

Preamble 7

SFD 1

Destination 6

Source 6

Length Type 2

FCS 4

Data

46 to 1500

Local Collision Remote Collision Late Collision

64 Octets

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 overover-voltage 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

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

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

Jabberis 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

Long Frame

Along 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

Preamble 7

SFD 1

Destination 6

Source 6

Length Type 2

FCS 4 Data

> 1518 Octets

Preamble 7

SFD 1

Destination 6

Source 6

Length Type 2

FCS 4 Data

< 64 Octets

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

arange error This error also appears when the Length field value is less than the

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 ghostto 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

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)

NLP Pulse

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 reprep-resent 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

Clock Pulses

Data Pulses Coded Data

D0 1

D1 0

D2 0

D3 0

D4 0

D5 1

D6 1

D7 1

D8 1

D9 0

D10 0

D11 0

D12 0

D13 0

D14 0 D15 0

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 testDur-ing 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