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 . Remote, and Late 11 02. book Page 27 9 Tuesday, May 20 , 20 03 2: 53 PM 28 0 Chapter 5: Ethernet Fundamentals Local Collision To create a local collision on coax cable (10 BASE2 and 10 BASE5), the signal. station to its link partner. After both stations have interpreted what the other ~ ~ ~ ~ 16 ms (+/- 8 ms) 11 02. book Page 28 6 Tuesday, May 20 , 20 03 2: 53 PM Ethernet Operation 28 7 partner is offering,. are called long frames. 11 02. book Page 28 2 Tuesday, May 20 , 20 03 2: 53 PM Ethernet Operation 28 3 Long Frame A long frame is one that is longer than the maximum legal size and that takes into consideration