Ethernet has been around for so long, and is now so widely used, that a complete overview would easily fill its own book. The goal here is to stay concise and to convey only key points to clear up areas that are known to cause confusion.
The philosopher George Santayana one stated, “Those who do not remember their past are condemned to repeat their mistakes.” It is to him that we dedicate this section. Well, him and everyone else who fell prey to buying into now-obsolete market failures such as ATM, Token Ring, FDDI, Token Bus, ARCnet, TCNS, or SMDS. All sought to solve the needs of high-speed communications over a shared medium, and all are now only footnotes in history—a history that is penned by the victorious Ethernet.
Ethernet v2 is a de facto standard first published by the Digital, Intel, and Xerox vendor alliance. It was based on a prototype satellite communications network called ALOHAnet. When Bob Metcalf later adapted the technology to run over coaxial cable in the early 1970s, the term Ether was used to pay homage to its original use of electromagnetic radiation through the vacuum of space, whereby the alleged media was the mythical luminiferous ether, a substance that the ancient Greeks believed conducted the planets through their orbits.
When used for minicomputers, LANs were a novelty. Enter the IBM PC in the early 1980s, and suddenly LANs are a hot commodity. The official standards bodies could not stand by and watch a vendor consortium do all the work. As a result, the IEEE 802 committee was formed to standardize LANs. The committee initially met in February 1980, hence the 80-2 Committee.
What was Ethernet became IEEE 802.3, which then branched off into various medium-specific standards such as 10Base-5, 10Base-2, 10Base-T, 100Base-T, 1000Base-TX, and so on. In the IEEE terminology, the number represents the bit rate, the term Base indicates the baseband (digital) signaling (there is a 10Broad36 spec for analog use over cable), and the last value identifies a medium, either indirectly via maximum segment length or by type. For example, the “5” in 10Base-5 means 500-meter cable length, which in turn indicates a thick coaxial cable medium, whereas the “T” in 10Base-T stands for UTP.
Despite the blessing by an official standards body, the irony is that the most common usage of Ethernet is, in fact, actually Ethernet v2 and not 802.3. The next section details the differences so that you can speak the truth when describing your network.
According to the OSI model, LANs operate at Layer 1 and Layer 2. Hence, they are considered a Link-layer technology. In addition, a LAN’s Link layer is broken into two parts, or sublayers: the Media Access Control (MAC) and Logical Link Control (LLC) components.
The goal here was noble. LANs should be able to provide a common service and interface to the upper layer (the Network layer), regardless of the fact that each LAN technology has a unique MAC sublayer that functions to provide orderly access to the shared medium. This makes some sense, in that a collision is unique to Ethernet LANs, so why should the IP layer know or care at all about one, as the same IP is also run over Frame Relay, which is a collision-free technology.
In contrast, Ethernet specifies only a MAC layer, as shown in Figure 1-3.
Although there is a notable difference in the MAC layer, given that Ethernet uses a Type code and 802.3 redefines the field as a Length value, the real answer to the proverbial question of Ethernet or 802.3 lies in the absence, or presence, of the Length field and 802.2/LLC. If the frame has a Type field, it’s Ethernet, plain and simple.
No magic is needed to differentiate between these two frame types because Type codes are selected to not conflict with valid IEEE Length values. Thus, any value less than 0×0600 is interpreted as a Length, and a value greater than 0×05DC is seen as an EtherType. In case you are doing the conversion, 0×05DC in hex symbolizes 1,500 bytes in decimal. The need to preserve this compatibility with Ethernet is one reason the IEEE 802.3 standard was never updated to support jumbo frames, which are frames larger than 1,500 bytes.
An Ethernet frame identifies the upper layer protocol using an EtherType, where the value 0×0800 indicates IP. Because there is no length indication padding, which is needed for Ethernet as the smallest amount of user data that can be sent is 46 bytes, it has to be performed by the upper layers.
This interlayer dependency, though long since accommodated by IP stacks, was seen as an egregious violation of the principle of layer independence. As such, the IEEE opted for a Length field at the MAC layer. This meant the MAC layer could now do its own padding, which is cool and all, but there was still a need to identify what the heck was in the frame. Enter LLC, which, from a practical perspective, pretty much functions to replicate Type code functionality, except now using three bytes rather than two, and you get to use fancy-sounding terms such as Service Access Point (SAP), which in the end simply identifies the upper layer. Note that another form of LLC is defined, LLC type 2, that provides a connection-oriented, reliable traffic exchange à la the connection-oriented balanced exchange procedures defined in Link Access Procedure, Balanced (LAPB). LAPB is used at Layer 2 of the X.25 model; in LANs, LLC type 2 uses a Set Asynchronous Balanced Mode Extended (SABME) initiation command to set up extended mode (modulus 128) sequencing, however. This LLC mode was used only in Token Ring/Bus networks, and then typically only for protocols such as the Systems Network Architecture (SNA) protocol. Need we say more? A third type of LLC, type 3, was never implemented. It provided a connectionless mode with acknowledgments.
We already stated that IP is the Network layer protocol of choice in the modern world. Yes, there are standards that define how an IP datagram can be encapsulated in Ethernet, 802.3/LLC, or 802.3 with LLC, combined with the official standards-supported method of escape back to the use of an EtherType via the Subnetwork Access layer Protocol (SNAP), which, as indicated, accommodates the use of the original EtherType codes, except now conveniently buried within a SNAP header, which itself is embedded within an LLC header. Talk about wheels within wheels....
Although this is good to know, it must be stressed that Juniper Networks switching and routing gear running JUNOS supports only Ethernet-based encapsulations for IP. JUNOS is known to interoperate with all networking gear of consequence, and is found in most large IP networks and in the backbones of virtually all Tier 1 service providers. It would seem that lack of support for IP over IEEE 802.3 is not an issue for anyone, and this is the point that is made. Ironically, the only thing that uses 802.3 encapsulation in JUNOS is Intermediate System to Intermediate System Level 1 (IS-IS), which is an OSI-based routing protocol that was originally intended to support OSI’s CLNS routing. The irony is that for most JUNOS gear, actual CLNS routing is not supported; IS-IS is used to build, and this is the rub, IP routing tables! I’m not sure why, but I can’t help but smirk as I write this, being both an IP bigot and not myopic enough to fail to see the bold IP writing on the wall, so to speak.
These days the practical truth is that IEEE 802.3 defines updates to the Physical layer standards and capabilities, and IP makes use of the faster speeds while choosing the relative comfort of an Ethernet-based frame; the fiber-optic medium or wire cares not one bit about the Type or Length field, so all is well. Unless you are specifically discussing LLC and the use of SAP, or MAC layer padding, the two terms are pretty much interchangeable, and are often used that way. This near synonymous nature is what often leads to confusion about the true differences, however.
There are many physical varieties of Ethernet, but generally speaking they all share the same MAC frame format and protocol. This is one of Ethernet’s greatest strengths. Its specification was based on bit times, not rates, making it easy to ramp up the speed (typically by an order of magnitude), while leaving the rest untouched.
It is worth noting here that the MAC we refer to is the entire Media Access Control layer of networking. A MAC address, which we all know and love, is merely a portion of this. All media have both PHY (physical) and MAC characteristics. The Ethernet MAC defines frame structure as well as the CSMA/CD shared media access procedure.
There are a few MAC characteristics that bear some extra attention, so let’s get cracking.
In its original form, Ethernet was based on a shared (not switched as is now the norm) medium and the use of a single baseband bit rate. This meant that only one node could actively use the cable at any time. Rather than bother with passing tokens or other shenanigans, Ethernet’s inventors opted for an opportunistic-based MAC called Carrier Sense Multiple Access with Collision Detection, or CSMA/CD. Sounds fancy, but humans do this all the time. We, after all, also share a medium and emit sound energy in the same band, which means there really should be only one person speaking at any time for maximum productivity.
In CSMA/CD, a station that wants to speak first listens to sense whether another station is active. If so, it waits. This is the Carrier Sense part. As quiet for one is quiet for all, there is nothing to prevent multiple stations from seizing the opportunity (a case of carpe medium, to use yet another pun), and this would be the Multiple Access part. When this occurs all the messages are corrupted, so the stations involved should detect the collision so that they can start an exponentially increasing back-off timer and try again later.
The Ethernet MAC algorithm can be summarized as “It’s nice to share, and if you have something to say don’t wait for an invitation; if at first you don’t succeed, try and try again, 16 consecutive times, and then give up,” as there is likely a cable fault (unterminated) that is causing the station’s own energy to reflect back (as a standing wave), which in turn activates the collision detection circuitry at every transmission attempt.
The shift away from shared coax, to a hub-and-spoke (star-based) topology that was based on twisted pair, was a monumental point for Ethernet. Although no one could have imagined it at the time, advances in technology would shift these multiport repeaters into a bridging or switching role. Unlike a repeater, both of these devices terminate collision domains. Because a UTP link can have only two stations (P-to-P), and because of a separate transit and receive pair (or frequency), there was no reason to run HD anymore.
This is significant, because in addition to doubling potential throughput by allowing simultaneous send and receive this also eliminated the potential for collisions.
The ability to use preexisting UTP, a medium originally intended for analog telephone use at 20 KHz, to build a high-performance and highly survivable LAN was too much for the market to resist. Not having to deal with buying and installing coaxial cable was advantage enough. However, the shift to P-to-P links also eliminated the single point of failure associated with shared media. In theory, one cable break with Thick Ethernet, or one jabbering station that won’t shut up, could bring down the entire LAN. Now the repeater or switch port simply partitions to isolate the malfunctioning link/node to prevent such network-wide disruption.
The shift from a bus to a star topology was followed closely by a bump in speed from 10 Mbps to 100 Mbps via the 100Base-TX standard. Ethernet has been the dominant LAN ever since, and is now, for all intents and practical purposes, the only LAN the world appears to need, or want, for that matter.
One part of the MAC layer specification is the shared media access method; the other is the frame structure. An important part of the MAC frame is the MAC address. Ethernet LANs use a 48-bit-long MAC address that is non-hierarchical or flat. Figure 1-4 details the structure of a MAC address. The Most Significant Byte (MSB) of the MAC address is sent first and is the high-order address octet.
The MAC address contains flags to indicate whether it’s a group (multicast) or an individual (unicast) address, and whether the address is universally administered (via the IEEE) or is a locally assigned value. The broadcast address is a special form of multicast that uses all 1s to indicate it is intended for every station on the LAN.
The network interface card (NIC) or Ethernet port’s burned-in address (BIA) is presumed to be globally unique by virtue of a managed vendor-ID space. Vendors apply for one or more blocks of MAC addresses, as identified by the first 24 bits, and are then responsible for distributing MAC chips with unique addresses using the remaining 24 bits.
The address space is said to be flat in that all 48 bits are needed to identify a station. There is no concept of information hiding or aggregation of multiple MACs into a single super MAC. A switch must know and learn (which means store) the complete 48-bit MAC address for every active station in the LAN. This is a significant point, as it impacts scalability. There is a reason that the worldwide Internet is not based on Layer 2 switching. No switch on Earth could learn and store a 48-bit address for every one of the more than 1.8 billion machines projected to form the Internet of 2010! (Source: http://www.clickz.com/stats/web_worldwide.)
In contrast, routers operate at Layer 3, where the addresses that are used support hierarchical structuring. This allows a router to summarize (or hide) information, which in turn allows it to scale far beyond the scope of any Layer 2 device. Consider the common case of a single default route, which summarizes every possible IP address (more than 4 billion are possible) into a single table entry. A core router must be able to reach every host on the planet without relying on a default route. IP address hierarchy currently permits this feat with a table that contains only about 280,000 entries as this is written. Far better efficiency could be had if IP addresses were originally allocated in a manner that better accommodates summarization—a mistake that will, ostensibly, not be repeated with IPv6 address allocation.
Ethernet technologies continue to evolve as speeds ramp up and new functionality, such as OAM, continues to breathe life into this venerable workhorse. Table 1-1 summarizes the characteristics of widely used Ethernet Physical layer standards.
Table 1-1. Key Ethernet standards
Standard | Speed/mode | Topology | Medium | Segment length | Comments |
|---|---|---|---|---|---|
10Base-5 DIX 1980, 802.3 1983 | 10 Mbps/HD | Bus | Thick coax, RG-8/U | 500 m | The original, vampire taps and all |
10Base-2 802.3A 1985 | 10 Mbps/HD | Bus | Thin coax, RG-58 | 185 m | Bye-bye taps, hello BNC T connectors |
FOIRL 802.3D 1987 | 10 Mbps/FD | Star | Two fibers | 1,000 m | The beginning of star-wired buses; P-to-P allows FD |
10Base-T 802.3I 1990 | 10 Mbps/FD | Star | Two pairs Category 3 UTP or better | 100 m | No more coax or expensive fiber media; the beginning of the end for other LANs |
10Base-FL 802.3J, 1993 | 10 Mbps/FD | Star | Two multimode (MM) fibers, 62.5/125 μm | 2,000 m | Updated FOIRL specification |
100Base-TX 802.3U, 1995 | 100 Mbps/FD | Star | Two pairs Category 5 UTP or better | 100 m | So much for FDDI and its expensive optics |
100Base-T4, 802.3U, 1995 | 100 Mbps/HD | Star | Four pairs Category 3 UTP or better | 100 m | Uses eight wires, allows use of installed CAT-3 for 100 Mbps |
100Base-T2, 802.3Y, 1997 | 100 Mbps/FD | Star | Two pairs Category 3 UTP or better | 100 m | So much for 100Base-T4; same speed on half as many wires and FD |
1000Base-LX, 802.3Z, 1998 | 1,000 Mbps (GE)/FD | Star | Two single-mode (SM) fibers, 10 μm Two MM fibers, 62.5/125 μm | 5 KM/5,000 M
550 m | The first Gigabit Ethernet (GE) flavor |
1000Base-SX, 802.3Z, 1998 | 1,000 Mbps (GE)/FD | Star | Two MM fibers, 62.5/125 μm, 50/100 μm | 220 m 550 m | A popular fiber flavor with wide deployment |
1000Base-LH (SX) (non-standard) | 1,000 Mbps (GE) | Star | Two SM fibers, 10 μm | 10–70 km | Non-standard flavor of 1000Base-LX with better optics |
1000Base-T, 802.3AB, 1999 | 1,000 Mbps (GE)/FD | Star | Four pairs Category 5 UTP or better | 100 m | GE over UTP copper, albeit using all eight wires with echo cancellation for FD |
10GBase-R, 802.AE, 2002 | 10 Gbps (10 GE)/FD | Star | LR, SM 9/125 μm SR, MM 62.5/125 μm | 10 km 26 m | First 10 GE over fiber, both long and short reach |
10GBase-T, 802.3AN, 2006 | 10 Gbps (10 GE)/FD | Star | Four pairs UTP | 55–100 m | Had to happen; 10 GE on UTP, needs CAT-6a for max distance |
Note that the wide variety of Physical layer media options for Gigabit Ethernet (GE) has resulted in the concept of Small Form-factor Pluggable (SFP) optics. The optics name is somewhat of a misnomer here, as copper-based SFPs are also available. Note that 10 GE SFPs are called XFPs, and provide the same function.
Although none too cheap, the ability to mix and match switch or NIC ports to the physical layer du jour by simply inserting the desired module is a big advantage. XFP support is especially important with 10 GE, given that there are at least 10 different Physical layer standards specified! The original version of this technology was referred to as a GE Interface Converter (GBIC). The newer SFPs have been further reduced in size and are sometimes called mini GBICs.
Currently the IEEE is working on standards for the next Ethernet speed overhaul, specifically 40GbE and 100GbE.
Table 1-1 makes it clear that there is no shortage of Ethernet flavors to choose from. With so many options, finding the set of mutual capabilities that yields the highest performance between any two pairs of nodes can be daunting. Automatic selection of the best level of compatibility is the motivation behind auto-negotiation.
The current best practice is to use auto-negotiation rather than to hardcode parameters. Over the years, the standards have matured enough to work reliably, and manually setting these parameters has been found to be error-prone. Figure 1-5 shows the operating mode priority, which always selects the best mode that is mutually supported, as well as a table showing the outcome for various combinations of Ethernet auto-negotiation pairings.
The key takeaway is that pairing one end set for auto-negotiation with another end that is hardcoded is almost always a bad thing. The result is often a duplex mismatch, which can be a very nasty thing, as in many cases the result is significantly diminished performance that may not be detected and therefore will be allowed to remain in place, causing long-term service degradation. The issue is that the HD end senses the remote end’s FD operation as a collision, resulting in needless back-offs and retransmission attempts.
Auto-negotiation has been defined in several IEEE standards, and is optional for most flavors of Ethernet. The protocol was updated and made mandatory for 1000Base-T as part of the GE 802.3a specification. Auto-negotiation is mandatory for normal 1000Base-T operation due to the need to determine the Master/Slave timing role for each end’s Physical layer; this function is unique to 1000Base-T, and is determined during the auto-negotiation process.
Ethernet won the LAN battle. Today when the three-letter acronym (TLA) LAN is used, you can bet it regards some flavor of that tireless workhorse known as Ethernet. Although there was a time when a LAN switch needed to support Ethernet and Token Ring/FDDI ports, that time has passed. Yes, it has passed much like the proverbial token, on into that great sunset that awaits all mortal beings, be they LAN, WAN, or (hu)MAN (pun intended).
Juniper Networks’ EX switches are Ethernet-based. The information in the next section prepares the reader for upcoming deployment labs, which by matter of modern practicality are strictly Ethernet-based.
Get JUNOS Enterprise Switching now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
