• The Collision Domain
• Incompatible Ethernet Jabber
• Auto-negotiation Priorities And Alternatives
• Incompatible Cabling Specifications

The Collision Domain

The single biggest change in network design in Fast Ethernet is the smaller collision domain. Technically, the size of a collision domain in all flavors of Ethernet is exactly the same - 256 bits. On the wire, ten times as many 100Mbps bits can occupy the same space as an equal number of 10Mbps bits, so the collision domain in 100Mbps Ethernet can be only physically one tenth the size of a 10Mbps collision domain.

Effectively this means that whereas up to four hubs can legally be cascaded in 10Base-T between any two stations, only one (or two) hubs can be used in a single segment in 100BASE-T without going through an interconnect device that provides link segmentation; such as a store-and-forward bridge, switch or bridge, or a router. A separate section of the Compendium discusses INTERCONNECT DEVICES in detail. If you see signs of corruption on your network that correspond to propagation delay, check to make sure that you're not cascading too many hubs.

You can make some generalizations regarding the structure of corrupted data frames (as discussed in the 10 Mbps Ethernet FRAME CORRUPTION section) but remember that these corruption patterns may be quite misleading, since you have a hub or switch in the network.

Note that many hub vendors sell stackable hubs. Hubs in a single stack connected via a common backplane are usually considered to be a single hub in terms of propagation delay, but multiple stacks cascaded externally via 100BASE-TX, 100BASE-T4, or 100BASE-FX could definitely cause problems. These 100BASE standards are discussed in the INTRODUCTION to this Fast Ethernet section.

Incompatible Ethernet Jabber

Another potential problem in 100Mbps Ethernet is the use of RJ-45 jacks for more than one flavor of Ethernet. Since 100BASE-TX and 100BASE-T4 both use RJ-45 jacks, as do 10Base-T and many other network technologies, the IEEE 802.3 specified an auto-negotiation protocol to allow stations to figure out the networking technology to use.

Unfortunately, they made its implementation optional. If you're using equipment that does not implement IEEE-spec auto-negotiation, the incompatible Ethernet signals could prevent one of your stations from connecting to your network, or even simulate "jabber" by constantly transmitting a TX idle stream and bringing down the network.

The possibility for this jabber is uncertain, considering that the flavors of Ethernet use different signal formats in transmission. Even if data is not exchanged, it is still possible that incompatible Ethernet flavors could assume that they have a proper connection. Ethernets using RJ-45 connections to a hub use a Link Test Pulse to verify link integrity. This pulse is the same in all flavors of Ethernet if auto-negotiation is not used. The auto-negotiation protocol itself uses a modified form of these pulses to negotiate a common Ethernet implementation.

If Ethernet incompatibility jabber were to occur between 100BASE-TX and another flavor of Ethernet, the results could be catastrophic, as 100BASE-TX transmits a continuous idle signal between frames. Although transparent to 100BASE-TX, this idle signal would completely busy out a 10Base-T or 100BASE-T4 segment. On the other hand, the 802.3 specifies that a Fast Ethernet repeater should implement jabber control, automatically partitioning off any port that is streaming information for more than 40000 to 75000 bits. If the repeater were to partition off the "jabbering" port, the symptom would be reduced to inability to connect the 100BASE-TX station to the network.

Auto-Negotiation Priorities And Alternatives

If the station and repeater both support 100BASE-TX and 100BASE-T4 and 802.3 auto-negotiation, the link will autonegotiate to 100BASE-T4 instead of 100BASE-TX. Since 100BASE-TX requires Category 5 cabling but 100BASE-T4 requires only Category 3, 100BASE-T4 is assumed to be a better default.

If the cabling is known to be UTP-5, then it is probably more efficient to turn off auto-negotiation and use 100BASE-TX wherever possible. 100BASE-T4 requires more overhead than TX because it multiplexes and demultiplexes the data stream over three wire pairs. There is also significantly less overhead in translating between 100BASE-TX and 100BASE-FX than between 100BASE-T4, as TX and FX both use 4B5B encoding instead of T4's 8B6T. 100BASE-TX and 100BASE-FX also leave open the possibility of Full Duplex communication, although full duplex is not yet part of the 802.3 spec.

On the other hand, 100BASE-TX sends an idle signal whenever it is not transmitting data. The 802.3 spec implies that it may very well be preferable to use 100BASE-T4 for battery-powered operation, since the card would only be transmitting when there is actual information to be moved.

Incompatible Cabling Specifications

One final problem with the advent of Fast Ethernet is the different cabling specifications. In classic Ethernet it was difficult to mistake 10Base-2 for 10Base-5. With Fast Ethernet, special care must be taken to verify that the entire connection between station and concentrator either supports TX's 31.25MHz signal or maintains T4's four pairs with proper twist. There are a number of good cable testers and pair scanners available to assist you in determining this for your network.

We will intentionally avoid a detailed discussion of exactly what goes on at each of these layers here. Some of the layers' functions, such as 8B6T encoding, Fan-out and NRZI signaling are labeled and will be discussed in this essay.

In 10Mbps Ethernet, the data is handed directly from the MAC layer to the PMA (Physical Medium Attachment) sublayer and onto the wire. The Reconciliation, PCS and PMD sublayers do not exist in 10Mbps Ethernet.

• Cabling
• Incompatible Implementations
• Repeaters In Fast Ethernet
• Replacement Of Illegal Byte
• Codes Data Translation
• Error Handling And Partitioning

Cabling

There are two methods of running Fast Ethernet over UTP and one method of running it over fibre.

IMPLEMENTATION           CABLE TYPE                NUMBER OF PAIRS

100BASE-TX                   Category 5                              2

100BASE-T4                   Category 3 or 5                      4

100BASE-FX                        Fiber                       (Not Applicable)

Category 3 cabling is not rated to carry the fast signaling of 100BASE-TX, so 100BASE-T4 must be used. 100BASE-T4 may also be used on Category 5 cabling, but 100BASE-TX is probably a better choice.

Incompatible Implementations

Fast Ethernet brings a new urgency to an old problem. Many network technologies use RJ-45 connectors. In the past, it was usually not difficult to figure out whether a jack was Ethernet or token ring: even at a site where both were in use they seldom were found in the same vicinity, so the network administrator could make an "educated guess". Today, with Fast and classic Ethernet interspersed and 10/100 cards common, some mechanism is needed to allow quick identification of the signal that is running across the wire.

Autonegotiation works by having each end of the connection send a series of pulses down the wire to the other end. These pulses are the same signals used in 10Base-T to test link integrity and cause the link indicator light to turn on. If a station receives a single pulse, referred to as a Normal Link Pulse (NLP), it recognizes that the other end is only capable of 10Base-T.

If autonegotiation is being used, a station will transmit a series of these pulses spaced closely together, referred to as a Fast Link Pulse (FLP). An FLP consists of 17 "clocking" pulses interspersed with up to 16 "signal" pulses to form a 16-bit code word. If a signal pulse occurs between two clocking pulses, that bit is a one. Absence of a signal pulse is a zero.

By comparing the 16-bit code words received in the FLP, a station and hub will agree on what implementation of Ethernet to use. The 16-bit code word describes what implementations of Ethernet are supported. Both station and hub will compare what it supports to what the other end supports, then choose which implementation to use for that link according to following priorities, defined by IEEE 802.3 clause 28B.3:

100BASE-TX full duplex

100BASE-T4

100BASE-TX 1

10BASE-T full duplex

10BASE-T

If the station supports 100BASE-T4, 100BASE-TX, and 10BASE-T and the hub supports full duplex 100BASE-TX, single-duplex 100BASE-TX, and 10BASE-T, they will each discover that the Ethernet implementations they have in common are 100BASE-TX and 10BASE-T. Since 100BASE-TX is defined to have a higher priority that 10BASE-T, the station and hub will use 100BASE-TX. This decision takes place independently on each side of the link, but since each side uses the same decision-making process and priorities, the same decision is reached on each end. Because each end of the connection agrees on what implementation of Ethernet is being used, the potential problem of incompatible signaling is averted.

Repeaters In Fast Ethernet

In Fast Ethernet the number of repeaters allowed per network segment is only 1 or 2. Whether one or two repeaters may be used is determined by what class of repeater will be used on the segment. Two classes of Fast Ethernet repeater are defined, Class I and Class II. Only one Class I repeater can be used in a single collision domain. Two Class II repeaters are allowed in a single collision domain, with up to a 5 metre inter-repeater link between them. The only technical difference between Class I and Class II repeaters is that Class II repeaters are faster than Class I repeaters. This allows Class I repeaters to provide other services besides simple repeating, such as translating between 100BASE-TX and 100BASE-T4. Class II repeaters are primarily used to link two hubs supporting only a single implementation of Fast Ethernet.

However, with the trade-off in fewer repeaters comes greater intelligence in each repeater. In addition to implementing the functionality of 10Mbps repeaters, 100Mbps repeaters are responsible for the following:

Replacement Of Illegal Byte

Unlike classic Ethernet, Fast Ethernet does not send a straightforward representation of the actual bits across the physical layer. A different representation of the information is sent instead. As a result, there are possible patterns on the wire which are not defined for use in Fast Ethernet. If a repeater detects an illegal pattern on the wire, it may replace that pattern (and every remaining pattern in the frame) with a special symbol identifying that the frame is corrupt.

Codes Data Translation

For repeaters that implement more than one implementation of Ethernet, the repeater will change the data encoding to be appropriate to the outgoing ports. 100BASE-T4 and 100BASE-TX use very different representations when sending data across a network. A Class I repeater which implements both 100BASE-TX and 100BASE-T4 needs to ensure that the signal going across the wire is the appropriate representation for the Ethernet implementation.

Error Handling and Partitioning

A Fast Ethernet repeater will monitor the state of each port in order to protect the network from any faults that might interrupt the flow of information.

If 60 consecutive collisions are detected from any particular port, the repeater will partition that port: it will stop forwarding information from that port to the rest of the network, but will still continue to repeat all frames from the network to the port. If the station on that port has broken so that it no longer is obeying the rules of CSMA/CD, then it needs to be separated from the network to allow traffic to flow.

However, it is possible that there could be 60 consecutive collisions on an extremely busy segment, so the repeater still forwards information to that port. If the repeater detects between 450 and 560 bits of information from that port without a collision occurring, the repeater will re-activate that port. A legal frame is received from the partitioned port, so we know that the hardware is working.

If between 40000 and 75000 consecutive bits are received from a port, the device at the other end of that cable is assumed to be "jabbering", sending an endless stream of bits, so the output from the port is cut off from the rest of the network. Such a "jabbering" device could prevent any traffic from flowing on a network, since there would never be a break for the other stations to transmit. If the station stops "jabbering", then the repeater will once again activate the port.

In 100BASE-TX and 100BASE-FX, a repeater will further monitor traffic to ensure that only frames with a valid preamble are passed. If two consecutive "false carrier events" occur, or a "false carrier event" lasts for 450-500 bits, the repeater will declare that link to be "unstable" and stop sending information to that port. As a result, faulty links are isolated from the rest of the network, resulting in improved overall network reliability. The link will be reactivated if between 24814 and 37586 bit-times have passed without any information having been received, or if a valid carrier is received after between 64 and 86 bit-times of idle have occurred.

Here are some aspects of 100Mbps implementation that should be considered:

• Implementing Switching
• Eliminating Bottlenecks
• Expand The Topology Outwards and Downwards
  

Implementing Switching

Implement switching in high-traffic areas to concentrate the bottlenecks on the network. Since Fast Ethernet provides higher throughput of bits, it makes sense to figure out which network connections need the most relief. Which segments consistently attempt to pump the most bytes? Which segments consistently demonstrate the highest average percent bandwidth usage according to your protocol analyzer?

Installing switches will help you figure out which network segments are moving the most information due to the effect switches have on your network. Installing switches is like moving from traffic lights to limited-access highways. The idea works extremely well in isolating cross-town traffic, e.g. peer-to-peer networking, but doesn't necessarily help when all of the traffic slows down at particular locations, e.g. an enterprise-wide server or the network Internet firewall. Because there are other ways of isolating network bottlenecks, implementing switches is primarily useful when installing 10/100 switches in preparation for 100Mbps Ethernet.

Installing switches also gives the added benefit of segmenting collision domains. In classic Ethernet, there can be up to four hubs or repeaters between any two stations, but in Fast Ethernet that number is only one or two. Installing switches in place of repeaters spares you having to segment your network at a later point, allowing the cost of the transition to be spread over a longer period of time.

Eliminating Bottlenecks

Once bottlenecks have been identified, upgrade those network connections to 100 Mbps. The primary difficulty in this step is verifying that the existing cabling will be sufficient for Fast Ethernet. On UTP, the cable either needs to meet Category 5 specifications or have four pairs with proper twist maintained on Category 3. If you're planning on using 100BASE-TX, your wiring closet will also need to be certified for a higher speed. There are many devices available such as wire pair scanners, which will make this job much easier.

Installing the initial Fast Ethernet connections is much easier if the switches installed earlier are 10/100, capable of operating at either classic Ethernet speeds or Fast Ethernet speeds. If the switches installed were only 10Mbps switches, they could be used as "hand-me-downs," replacing hubs in segments where users require more bandwidth.

Expand The Topology Outwards and Downwards

Gradually work the Fast Ethernet out into the rest of the network, as far out and down as desired. Note that the price of 10/100 cards is not substantially higher than that of 10Mbps cards, so it may be a wise idea to plan ahead by installing 10/100 cards when installing new machines.

If there comes a point in the future when 100Mbps Ethernet needs to be implemented on that machine, all that will need to be changed is the connection on the other end. On the other hand, upgrading a machine from a 10Mbps card to a 100Mbps card will require reconfiguring the user's machine, installing a new driver, etc. A short-term expenditure can greatly offset the cost in man-hours and down-time later on.

The problem with hubs is the number of hubs allowed in a single collision domain. Classic Ethernet allows hubs to be cascaded up to four deep between any two stations. In Fast Ethernet, the number of hubs allowed in a collision domain is drastically reduced - to a single hub. Sometimes it may be possible to have more than one hub in a collision domain, but it will probably be easier in the long term to design a Fast Ethernet network assuming that only one hub is allowed.

What the IEEE 802.3 spec does not explicitly state is that this limitation only applies to shared 100BASE-T, not to switched 100BASE-T. Since switches act like bridges in defining a separate collision domain, installing Fast Ethernet switches will allow you to work around the single-hub problem. Even if it is not necessary to deliver dedicated switched Fast Ethernet to each desktop, Fast Ethernet hubs can be connected to switches. Connecting a number of repeaters to a switch will provide shared Fast Ethernet and allow you to maintain the size of your network.

Below is a 3D diagram of the frame, let's have a look at it and try to analyse it:

The Data Link Header

Offset 0-5: The Destination Address

• The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.
• The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter, and are specific to the vendor.
• The Destination Address format is identical in all implementations of Ethernet.

Offset 6-11: The Source Address

• The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.
• The Source Address format is identical in all implementations of Ethernet.

Offset 12-13: Length

• Bytes 13 and 14 of an Ethernet frame contain the length of the data in the frame frame, not including the preamble, 32 bit CRC, DLC addresses, or the Length field itself. An Ethernet frame can be no shorter than 64 bytes total length, and no longer than 1518 bytes total length.

 User Data And Frame Check Sequence (FCS)

Data: 46-1500 Bytes

• Following the Data Link header are 46 to 1500 bytes of data. In all Novell frames, the user data begins with an IPX (Novell's network layer protocol) header. The IPX header contains as its first two bytes an optional checksum, with the value FFFF signifying that the checksum is not used. By convention, the checksum is always turned off, and the FFFF that occurs 3 bytes after the end of the source address is how device drivers differentiate Novell frames from 802.3 frames, which look identical until the first byte following the length field.

FCS: Last 4 Bytes

• The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.

Final Note on Novell's Ethernet Frame Format

"A Novell client can only use one frame format for NetWare"

This is a true statement that needs some clarification to be fully understood.

It should be noted that Novell workstations are capable of using any of the four Ethernet frame types mentioned in the Ethernet Frame section, based on the LOAD and BIND settings in the NET.CFG file. A Novell client will use the list of frame formats in NET.CFG to attempt to locate a file server (or a Netware Directory Server for the VLM shell). The client starts at the top of the list of frame types in NET.CFG and broadcasts a 'Find Nearest Server' message. If no file server answers (or Directory Services server in a VLM client) then the client tries the next frame format. When a server finally does answer then the client will use the successful frame format from then on, until the client is rebooted.

As a result, you should remember that a Novell client will ultimately use only one of the four frame formats; it cannot actually use multiple formats for NetWare at the same time. The format it selects will be based on its initial attempt to locate a server. This behavior is restricted to the frame format used by NCP and SPX - if the client is also running a TCP/IP stack then the IP protocol can be configured to use any other frame format (typically Version II Ethernet).

This completes our anaylsis of the Novell proprietary frame format.

Back to Ethernet Frame Formats Section

The SNAP Frame Format consists of a normal 802.3 Data Link Header followed by a normal 802.2 LLC Header and then a 5-byte SNAP field, followed by the normal user data and FCS.

You can see the above mentioned headers in the 3D diagram of the frame below:

The Data Link Header

 Offset 0-5: The Destination Address

• The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.
• The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter and are specific to the vendor.
• The Destination Address format is identical in all implementations of Ethernet.

Offset 6-11: The Source Address

• The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.
• The Source Address format is identical in all implementations of Ethernet.

Offset 12-13: Length

• Bytes 13 and 14 of an Ethernet frame contain the length of the data in the frame, not including the preamble, 32 bit CRC, DLC addresses, or the Length field itself. An Ethernet frame can be no shorter than 64 bytes total length and no longer than 1518 bytes total length.

The 802.2 Logical Link Control (LLC) Header

Following the Datalink Header is the Logical Link Control (LLC) Header, which is described in the IEEE 802.2 Specification. The purpose of the LLC header is to provide a "hole in the ceiling" of the Datalink Layer. By specifying into which memory buffer the adapter places the data frame, the LLC header allows the upper layers to know where to find the data.

Offset 15: The Destination Service Access Point (DSAP)

• The Destination Service Access Point or DSAP, is a 1 byte field that simply acts as a pointer to a memory buffer in the receiving station. It tells the receiving network interface card in which buffer to put this information. This functionality is crucial in situations where users are running multiple protocol stacks, etc...

Offset 16: The Source Service Access Point (SSAP)

• The Source Service Access Point or SSAP is analogous to the DSAP and specifies the Source of the sending process.

• In order to specify that this is a SNAP frame, the SSAP is set to AA hex.

Offset 17: The Control Byte

• Following the SAPs is a one byte control field that specifies the type of LLC frame that this is.

The Sub-Network Access Protocol (SNAP) Header

Offset 18-20: The Vendor Code

• The first 3 bytes of the SNAP header is the vendor code, generally the same as the first three bytes of the source address although it is sometimes set to zero.

Offset 21-22: The Local Code

• Following the Vendor Code is a 2 byte field that typically contains an Ethertype for the frame. This is where the backwards compatibility with Version II Ethernet is implemented.

User Data And Frame Check Sequence (FCS)

Data: 38-1492 Bytes

• Following the 802.2 header are 38 to 1492 bytes of data, generally consisting of upper layer headers such as TCP/IP or IPX and then the actual user data.

FCS: Last 4 Bytes

• The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.

This completes our anaylsis of the IEEE 802.3 SNAP frame format.

Back to Ethernet Frame Formats Section

Let's now have a closer look at the Ethernet II frame format:

The Data Link Header

Offset 0-5: The Destination Address

• The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.

• The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter and are specific to the vendor. See the MAC Address page for more information.

• The Destination Address format is identical in all implementations of Ethernet.

Offset 6-11: The Source Address

• The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.

• The Source Address format is identical in all implementations of Ethernet.

Offset 12-13: The Ethertype

• Following the Source Address is a 2 byte field called the Ethertype. The Ethertype is analogous to the SAPs in the 802.3 frame in that it specifies the memory buffer in which to place this frame.

An interesting question arises when one considers the 802.3 and Version II frame formats: Both formats specify a 2 byte field following the source address (an Ethertype in Version II, and a Length field in 802.3) -- So how does a driver know which format it is seeing, if it is configured to support both Ethernet frames?

The answer is actually quite simple. All Ethertypes have a value greater than 05DC hex, or 1500 decimal. Since the maximum frame size in Ethernet is 1518 bytes, there is no point in overlapping between Ethertypes and lengths. If the field that follows the Source Address is greater than O5DC hex, the frame is a Version II, otherwise it is something else (either 802.3, 802.3 SNAP or Novell Proprietary).

User Data and FCS

Data: 46-1500 Bytes

• Following the Ethertype are 46 to 1500 bytes of data, generally consisting of upper layer headers such as TCP/IP or IPX and then the actual user data.

FCS: Last 4 Bytes

• The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.
  

This completes our anaylsis of the Ethernet II frame.

Back to Ethernet Frame Formats Section

The Diagram below analyses the Ethernet 802.3 Frame:

The Data Link Header

Offset 0-5: The Destination Address

• The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.
• The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter and are specific to the vendor.
• The Destination Address format is identical in all implementations of Ethernet.

Offset 6-11: The Source Address

• The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.
• The Source Address format is identical in all implementations of Ethernet.

Offset 12-13: Length

• Bytes 13 and 14 of an Ethernet frame contain the length of the data in the frame frame, not including the preamble, 32 bit CRC, DLC addresses, or the Length field itself. An Ethernet frame can be no shorter than 64 bytes total length, and no longer than 1518 bytes total length.

The 802.2 Logical Link Control (LLC) Header

Following the Datalink Header is the Logical Link Control Header (LLC), which is described in the IEEE 802.2 Specification. The purpose of the LLC header is to provide a "hole in the ceiling" of the Datalink Layer. By specifying into which memory buffer the adapter places the data frame, the LLC header allows the upper layers to know where to find the data.

Offset 15: The Destination Service Access Point (DSAP)

• The Destination Service Access Point (DSAP), is a 1 byte field that simply acts as a pointer to a memory buffer in the receiving station. It tells the receiving network interface card in which buffer to put this information. This functionality is crucial in situations where users are running multiple protocol stacks, etc...

Offset 16: The Source Service Access Point (SSAP)

• The Source Service Access Point (SSAP) is analogous to the DSAP and specifies the Source of the sending process.

Offset 17: The Control Byte

• Following the SAPs is a one byte control field that specifies the type of LLC frame that this is.
  
  

User Data And The Frame Check Sequence (FCS)

Data: 43-1497 Bytes

• Following the 802.2 header are 43 to 1497 bytes of data, generally consisting of upper layer headers such as TCP/IP or IPX and then the actual user data.

FCS: Last 4 Bytes

• The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.

This completes our anaylsis of the Ethernet 802.3 frame.

Back to Ethernet Frame Formats Section

The circuitry on the adapter card then takes the frame and converts it into an electrical signal. The voltage transitions in the transmitted bit stream are in accordance to the format called Manchester Signal Encoding. Manchester encoding describes how a binary ONE and ZERO are to be represented electrically. Manchester encoding is used in all 10 Megabit per second Ethernets; for example, 10BASE2 Thin Ethernet, 10BASE5 Thick Ethernet and 10BASE-T Twisted-Pair Ethernet.

Here we see an example of the signal transitions used to encode the hexadecimal value "0E", which converts to "00001110" in binary:

Notice that there is a consistent transition in the middle of each bit-time. Sometimes this transition is from low-to-high and sometimes it's from high-to-low. This is the clock transition. The receiving adapter circuitry 'locks on' to this constant signal transition and, thereby, identifies the timing to determine the beginning and end of each bit.

To represent a binary ONE, the first half of the bit-time is a low voltage; the second half of a bit is always the opposite of the first half, that's how the clock transition is created. To represent a binary ZERO, the first half of the bit-time is a high voltage. You see that sometimes there is an additional transition at the beginning of a bit-time (not drawn in in the diagram above) where the signal is pulled either up or down in preparation for the next bit.

Consider what happens if an external electromagnetic field interferes with the Manchester bit encoding. This external field could be the result of an electric motor, radio transmission or other source of interference. You should be able to see that if the Manchester signal is disrupted the bits will be destroyed - because the clock signal will be disrupted.

It would not be reasonably possible for electrical interference to change a binary ONE into a binary ZERO. Since each bit is symmetrical (second half is always opposite the first half) the result of electrical noise would be the destruction of the bit, not a change in bit value.

Smaller Interframe Spacing

The sole reason for the 9.6 microsecond interframe gap is to allow the station that last transmitted to cycle its circuitry from transmit mode to receive mode. Without the interframe gap, it is possible that a station would miss a frame that was destined for it because it had not yet cycled back into receive mode.

There is, however, an interesting sidebar to this discussion and that is that most Ethernet cards in today's market are capable of switching from transmit to receive in much less time than 9.6 microseconds. This is an example of what can happen when 1970's specifications are applied to 1990's technology. In fact, some adapter manufacturers are designing their cards with a smaller interframe spacing, thereby achieving higher data transfer rates than their competitors.

The problem arises when cards with a smaller interframe spacing are mixed on a network with cards that meet the specifications. In this case, there is a potential for lost data.

The moral of the story is that a network administrator needs to know what is going on in his or her network and be aware that not all vendors will stick to the specs. Contact your vendors and find out what they're doing differently -- it'll pay off!

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:

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

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

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.

Electrical Noise

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.

Hardware Malfunctions

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:

• 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.

Troubleshooting Flowchart

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 yes:

1. Make sure you haven't exceeded the specifications of your cable (maximum cable length, maximum repeaters in between nodes, etc)

2. 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.

2. Are the corrupt frames very short, and consistently the same length?

If yes:

1. 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.

2. 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.

3. Are the frames random in length, all cut off cleanly with no signs of bit streaming or other hardware malfunction?

If yes:

1. 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 to the wiring closet and every time the dentist took an X-ray the network would go down!

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.

Propagation Delay

Before we discuss frame size and cable length, an understanding of signal propagation in copper media is necessary. Electrical signals in a copper wire travel at approximately 2/3 the speed of light. This is referred to as the propagation speed of the signal. Since we know that Ethernet operates at 10Mbps or 10,000,000 bits per second, we can determine that the length of wire that one bit occupies is approximately equal to 20 metres or 60 feet via the following maths:

• speed of light in a vacuum = 300,000,000 metres/second
• speed of electricity in a copper cable = 200,000,000 metres/second
• (200,000,000 m/s) / (10,000,000 bits / s) = 20 metres per bit

We can further determine that a minimum size Ethernet frame consisting of 64 bytes or 512 bits will occupy 10,240 metres of cable.

The Relationship

The only time that an Ethernet controller can detect collisions on the wire is when it is in the transmit mode. When an Ethernet NIC has finished transmitting and switches to receive mode, the only thing it listens for is the 64 bit preamble that signals the start of a data frame. The minimum frame size in Ethernet is specified such that, based on the speed of propagation of electrical signals in copper media, an Ethernet card is guaranteed to remain in transmit mode and therefore detecting collisions long enough for a collision to propagate back to it from the farthest point on the wire from it.

Take, for example, a length of 10BASE5 thick Ethernet cabling exactly 500 meters long (the maximum that the spec allows) with two stations, Station A and Station B, attached to the farthest ends of it.

If Station A begins to transmit, it will have transmitted 25 bits by the time the signal reaches Station B, 500 meters away. If Station B begins to transmit at the last possible instant before Station A's signal reaches it, the collision will reach Station A 25 bit-times later (the time it takes for the signal on the wire to travel one bit-length -- 20 metres in copper cable). Station A will have transmitted only 50 bits when the collision reaches it -- nowhere near the 512 bit boundary for an early collision.

Upon closer examination, however, a peculiarity arises. If a normal collision happens before the 512 bit boundary, Station A would have to be over 5000 metres away from Station B before a late collision occurred. Examine the maths for yourself: 512 bits times 20 metres/bit = 10,240 metres. That's 256 bits or approximately 5000 metres for the signal to propagate from Station A to Station B and 5000 metres for the collision event to propagate back to and be detected by Station A. It seems like a late collision would never occur with a maximum cable length of only 500 meters. What is the reason for the overhead?

The reason for the overhead is twofold. First of all, while the maximum possible cable segment length in Ethernet is 500 metres, it is possible to extend that length with up to 4 repeaters before the IEEE 802.3 spec is violated. This means that the signal may have to travel through as much as 2500 metres of cable to reach Station B, or 5000 metres of cable round trip. The second and final reason for the overhead lies solely in the carefulness of Ethernet's inventors. Generally the spec is twice as strict as it needs to be, allowing ample room for errors.

Herein lies one of the greatest strengths and weaknesses of Ethernet. It is a strength in that if you need to, you can probably get away with violating the specs -- an extra length of cable here, an extra repeater there and your network continues to run normally. It is a weakness in that while you can get away with violating the specs, there is a very fine line between a network that is violating the specs and is running and a network that is violating the specs and is crippled by late collisions and you never know which extra bit of wire or extra repeater is going to cross the line.

Despite this dire warning, there are some general rules for violating specs:

• If your vendor tells you you can violate the spec and you're not mixing vendors, it's probably ok. If you mix vendors, obey the strictest vendor.
• If something is wrong with your network and you know that it violates the spec in places, those places should be the first ones you check. Try segmenting the network with a bridge and see which side of the bridge the problems are on.

In this discussion we will refer to the same network described in the discussion of early collisions, but with one modification: In this network, the network administrator has violated the maximum cable length (500 meters for 10BASE5 thick ethernet, 185 meters for 10BASE2 thin ethernet) by either adding too many repeaters in between Stations A and B or by laying too much wire between them.

The following is an outline of a late collision event caused by out of spec. cabling:

Station A, detecting that the wire has been idle for 9.6 microseconds, begins to transmit its data frame, beginning with the 64 bit preamble. Station A transmits 256 bits of its frame. If the cabling were in spec and Station B began to transmit, causing a collision, even if Stations A and B were on the farthest ends of the wire from each other the collision would be detected by station A before it could transmit its 512th bit. (Stage 1)

Station A continues to transmit bits, and meanwhile, down at the other end of the wire, just before the electrical signal reaches Station B, Station B detects idle wire for 9.6 microseconds and begins to transmit. (Stage 2)

A minute amount of time later, a collision occurs. (Stage 3) Station B, being extremely close to the collision, detects it first and begins transmitting a 32 bit jam signal.

The collision begins to propagate down the wire towards Station A (Stage 4), followed by the 32 Bit Jam signal generated from Station B.

But because the cabling was out of spec. by the time it gets to Station A, Station A has already finished transmitting and is no longer listening for collisions! (Stage 5) Station A is completely unaware that a collision has occurred!

The reason that late collisions are a problem is that once the NIC misses the fact that a collision has occurred, recovery and retransmission are left to the upper layers and recovery time goes up drastically. While a NIC will typically recover and retransmit a frame in 2-3 milliseconds, it typically takes anywhere from 10 to 100 times that long for upper layers.

The other major cause of late collisions is a malfunctioning NIC. If a NIC malfunctions in such a manner that it is unable to detect that another station is talking, late (and early) collisions will occur.

An early collision is any collision that occurs before 512 bits of the frame have been put onto the wire.

The following is an outline of a normal or "early" collision event:

Station A, detecting that the wire has been idle for 9.6 microseconds, begins to transmit its data frame, beginning with the 64 bit preamble. While Station A is transmitting, it is also listening for abnormal voltage on the wire -- a signal that a collision has occurred. (Stage 1)

Some period of time later, but before the signal from Station A has had time to propagate down the wire to Station B, Station B also detects that the wire has been idle for 9.6 microseconds and begins to transmit its data frame beginning with the 64 bit preamble. Station B is also listening for a collision on the wire. (Stage 2)

At some point on the wire in between Station A and Station B the electrical signals overlap, creating a point of abnormal voltage. As the signals continue to propagate, this abnormal voltage travels down the wire towards both Station A and Station B. (Stage 3)

Whichever station is closest to the physical point on the wire where the two signals overlapped will detect the collision first. For the sake of this discussion, we will say that Station A detects the collision first. (Stage 4)

Station A, detecting the abnormal voltage on the wire and realizing that a collision has occurred, immediately stops transmitting data and transmits a 32 bit "jam" onto the wire. (Stage 5)

The 32bit jam consists of any combination of values that is not a valid CRC for the frame that was just interrupted by the collision. Most Ethernet cards today just send 32 ones and know that there is only a 1/(2^32) chance that that will be the checksum -- pretty good odds. The purpose of the 32 bit jam is to fully propagate the wire with voltage, preventing anybody else from talking.

Station A will then implement an algorithm known as the Truncated Binary Exponential Backoff Algorithm, which determines how long it will wait before it attempts to retransmit the frame that was just interrupted. The interrupted frame is referred to as a Runt.

Next, Station B will detect the collision. Station B will also send a 32 bit jam and implement the Truncated Binary Exponential Backoff Algorithm. (Stage 6)

Early collisions occur regularly in a normally operating Ethernet network. There is no hardware malfunction or misbehaving station -- it just so happens that two NICs start to talk at the same time. Generally, after the talkers implement the backoff algorithm which is specially designed to not have both NICs attempt to talk at the same time again, both talkers will successfully put their frame onto the wire. It typically takes no longer than 2-3 milliseconds for a station to recover from a collision and successfully retransmit its frame.

A collision is an event that happens on an Ethernet network when two stations simultaneously "talk" on the wire. Collisions are a normal part of life in an Ethernet network and under most circumstances should not be considered a problem.

Even thought alot of people know that collisions do happen on a network, what they don't know is that there are two different type of collisions ! Yes, thats right, two different type of collissions, one is the Early Collisions and the other, Late Collisions .

We will have a look at two collision examples (one of each) in the next couple of pages, and these examples have been carefully selected to help you understand the difference between the two types of collisions. Also, we are going to have a look at the events leading up to and immediately following a collision.

You can use the menu to get to the next pages or simply click on the links below :

• Early Ethernet Collisions
• Late Ethernet Collisions

A more elegant term for "who gets to talk" is to refer to the "media access method", which, in this case, would be "CSMA/CD".

Carrier Sense means that before a station will "talk" onto an Ethernet wire, it will listen for the "carrier" that is present when another station is talking. If another station is talking, this station will wait until there is no carrier present.

Multiple Access refers to the fact that when a station is done transmitting it is allowed to immediately make another access to the medium (a 'multiple' access). This is as opposed to a Token-Ring network where a station is required to perform other tasks inbetween accessing the medium (like releasing a token or sometimes releasing a management frame).

Collision Detection refers to the ability of an Ethernet adapter to detect the resulting "collision" of electrical signals and react appropriately. In a normally operating Ethernet network, it will sometimes occur that two stations simultaneously detect no carrier and begin to talk. In this case the two electrical signals will interfere with each other and result in a collision; an event which is detected by the Collision Detection circuitry in the transmitting network interface cards.

The process of CSMA/CD is implemented slightly differently in a twisted pair (as opposed to a coaxial) Ethernet network.

Back to Ethernet Protocol section