The Physical Structure of the Four Ethernet Frame Types -------------------------------------------------------
Here is the physical appearance of the four Ethernet frame types, listed in rough order of creation. I will ignore the purely electronic aspects of the frame, including start bits and Frame Check Sequence. Those are required by the physical hardware and are, consequently, uniform for all four frame types.
Novell Frame Type Designation: Ethernet_802.3 Common name: "Raw" 802.3 Layout:
6 bytes 6 bytes 2 bytes Up to 1500 bytes +-------------+-------------+--------------+------------------------+ | Destination | Source | Total packet | IPX Packet | | MAC Address | MAC Address | length | first two bytes: FF,FF | +-------------+-------------+--------------+------------------------+
Comments: 1. No protocol ID: Can only carry IPX packets. 2. Distinguishable from Ethernet_802.2 only because the first two bytes of all IPX packets carried on Ethernet_802.3 must be all ones, which makes no sense in Ethernet_802.2. 3. The default frame type for NetWare software until NetWare v4.0 was released.
Should You Use Ethernet_802.3? ------------------------------
You probably know by now that since the frame type Ethernet_802.3 does not carry the required 802.2 header, it is not conformant to the official 802.3 specification. You may also have heard about problems on networks using Ethernet_802.3 frames. As a conscientious network adminitrator, this may cause you to worry about using the Ethernet_802.3 frame type on your network. Here are some guidelines for deciding whether to switch away from Ethernet_802.3.
First of all, if you are installing a *new* network, then *don't* use Ethernet_802.3. One thing's for sure: Ethernet_802.3 is obsolete. New networks should use a more current frame type such as Ethernet_II.
So the only real question is whether you should convert an existing Ethernet_802.3 network to some other frame type.
The first observation is that Ethernet_802.3 isn't generally dangerous. The problems that have occurred because of Ethernet_802.3 frames are few and far between, and generally involve older hardware or software. If you haven't already seen any such problems, then you probably never will. So normally there's no risk to keeping Ethernet_802.3 as a existing network's frame type. In particular, if your Ethernet_802.3 is fairly static and you do not plan any major upgrades or additions to it, then you can continue with Ethernet_802.3 indefinitely without concern.
On the other hand, Ethernet_802.3 is an obsolete frame type, as i say. So if you find a convenient opportunity, you may want to switch a network away from it. For example, if you decide to upgrade all of your client nodes from older software to an ODI driver or the VLM client, that might be a good time to also switch to Ethernet_II since you're already making modifications on every node.
One consideration that may be important to you is that IPX packets with checksums cannot be transmitted on Ethernet_802.3 networks. In order to take advantage of the data integrity provided by the IPX checksum feature of the newer NetWare releases, you'll have to upgrade your Ethernet_802.3 networks to Ethernet_II or some other Ethernet frame type.
Note that a single Ethernet can carry both Ethernet_802.3 and Ethernet_II traffic at the same time. Novell software treats the two frame types as entirely different logical networks even though they are being transmitted and received on the same NIC. A NetWare v3.x or v4.x server with its IPX bound to two logical boards running the two frame types will function as an IPX router between the two "networks". (Notice that there *are* two networks, so they need two *different* network numbers.) This allows you to upgrade Ethernet_802.3 nodes one by one to Ethernet_II. The NetWare router will forward packets from one "network" to the other, allowing the upgraded nodes to continue talking to the older nodes and vice versa.
Which Ethernet Frame Type Should You Use for IPX? -------------------------------------------------
One thing we can all agree on: you should *not* use Ethernet_802.3 unless you are connecting an installed network that uses it. Refer to my other note, "Should You Use Ethernet_802.3?", for a complete discussion of Ethernet_802.3. For our purposes here, i assume Ethernet_802.3 isn't being considered.
Novell does not, at least to my knowledge, explicitly recommend any one Ethernet frame type for carrying IPX traffic, although perhaps the default frame type of Ethernet_802.2 on the v4.0 LAN drivers might provide a clue. My PERSONAL recommendation, however, is, "When given a choice, run IPX on Ethernets exclusively with the Ethernet_II frame type."
While there are a couple of technical arguments i can make in support of Ethernet_II, they really aren't important enough to mention. (But i'm always asked what they are, so i'll explain them in a moment.) The real reason i recommend Ethernet_II is that it's the true Ethernet standard. With only a couple of exceptions, every significant protocol uses Ethernet_II instead of either Ethernet_802.2 or Ethernet_SNAP.
[The exceptions? OSI runs on Ethernet_802.2, and the "new" AppleTalk runs on Ethernet_SNAP, although the old AppleTalk runs on Ethernet_II. (I quote "new" because the later version of AppleTalk is actually fairly well established; it's basically just what you'd think of as AppleTalk. Pure "old" AppleTalk networks are rather rare these days.)]
The practical effect of Ethernet being the principle framing standard is that you are often using Ethernet_II framing already for some other protocol. If you're running any other protocol (other than OSI), using Ethernet_802.2 for IPX will mean having one more frame type to worry about on that NIC. For example, if you're using TCP/IP on a NetWare v3.11 server, the Ethernet_II frame type is already loaded for IP. If you also run IPX over Ethernet_II instead of Ethernet_802.2, you won't have to reload the LAN driver for a second frame type.
Another practical consideration is old NetWare software. Pre-ODI clients and 2.x servers can be switched to Ethernet_II framing using an old widely available utility: ECONFIG.EXE. Pre-ODI clients cannot talk Ethernet_802.2. I've heard rumors that some 2.x servers can be configured to use Ethernet_802.2, but i have no idea how that's done or where you get the software components needed to do it.
I rule out Ethernet_SNAP simply because IPX has never been normally run on that frame type. There's no significant technical advantage for IPX between Ethernet_II and Ethernet_SNAP, but Ethernet_II is by far more common of the two, particularly for IPX.
One thing's for certain: no matter which frame type you decide to use, SPECIFY IT in your configuration files. Do *NOT* let the LAN driver use the "default" frame type. The default can change from version to version of the LAN drivers, but you don't want any given node to change its frame type just because a driver was upgraded. To ensure that doesn't happen, tell the LAN driver explicitly which frame type to use, even if you think the frame type you've selected is the default. (This is actually general advice: when configuring *any* software, only allow the software to use default values when you really don't care what the value is. Since the wrong frame type would break communications, you really do care exactly which frame you're using, so specify it.)
p.s. No, i didn't forget. The first minor technical advantage of Ethernet_II is that in it the IPX packet is aligned to the proper word boundary. The poor alignment of Ethernet_802.2 will cause a slight performance penalty in some cases, although i've seen nothing to indicate the performance penalty would ever be significant...or even measurable, for that matter.
The second is that in Ethernet_II, the hex E-type 8137 is officially assigned to IPX by IEEE. The Ethernet_802.2 SAP which IPX uses (hex E0) is *not* officially assigned to IPX. E0 is in the range of SAPs which are reserved for local definition. This means that there's no official restriction against some other network protocol using a SAP of E0, although in practice it is extremely unlikely anyone would ever do such a thing. -dp
I'm often stopped on the street, metaphorically speaking, and asked, "Hey, Don, what *is* it with these Ethernet frame types." I've determined that the inquisitor generally wants the answer to one of four questions, which i list here in rough order of increasing inflamedness:
1. Physically, what do the four Ethernet frame types look like?
2. Politically, where do the four Ethernet frame types come from? (Or, put more simply, "Why are there four?")
3. If Ethernet_802.3 is so Yucky, should I stop using it?
4. Which Ethernet frame type should I use for IPX?
Rather than try to answer all four questions in the same message, I've elected to post five different messages: this introduction, plus one message to answer each of the four questions. For ever after, i hereby appoint Joe Doupnik to see to the posting (or mailing, should the consciousness of the mailing list be raised to the point where posting becomes redundant) of the appropriate answer whenever this question comes up. I also suggest that these answer be added to the FAQ, and i'll make the entire pamphlet available for anonymous FTP on sjf-lwp.sjf.novell.com in odi/eframe.txt.
Or i may just publish it and live in opulence on the royalties.
Some of you might be wondering what prompted me to post my recent (or future, depending on how time runs in your news service) opus on Ethernet frame types. Well, yes, continual nagging by y'all out there had something to do with it, but primarily it was the last major contribution i needed to make to these forums before i dropped off line. A sharp increase in my responsibilities here at Novell make it impossible for me to continue participating in these lists. In fact, i haven't had time to read them for a week or two already. With regret i will be hitting the old unsubscribe key as soon as i've finished posting this last note.
I'm sure y'all'll be able to carry on without me. Rest assured that i'll be busy working under the covers to make sure that Novell continues to supply you with the best products possible. Au revoir.
The Political Origin of the Four Ethernet Frame Types -----------------------------------------------------
Many people want to know why there are four Ethernet frame types. Each one has a story, as i'll explain below.
Where did Ethernet_II come from? --------------------------------
The frame type NetWare software calls Ethernet_II is basically the original Ethernet frame type. There were actually two earlier Ethernet standards before the final one we know today. The first was strictly experimental and ran at 3 megabit. The second was the 10 megabit Ethernet we've come to know and love, but it had a few kinks which were quickly ironed out in the DIX Ethernet standard (named for DEC, Intel, and Xerox, the three companies that developed it). Because of the earlier standard, the "new" one was often refered to as "Ethernet II", although the actual packet formats were the same for both standards. (The DIX standard had slightly different hardware signaling specifications.) These days, the history has been long since forgotten and no hardware has survived from the pre-DIX Ethernet days, so the currrent standard is now commonly known as simply "Ethernet".
Where did Ethernet_802.2 come from? -----------------------------------
With Ethernet happily deployed around the world, some dim bulb decided to have it blessed by a standards body. The body was IEEE. The result was the 802.3 specification. IEEE just couldn't resist changing the Ethernet framing in a pointless, yet significant way. They eliminated the two byte protocol ID (known in Ethernet as the "Ethernet Type" or "E-type") and replaced it with a two byte length. The protocol ID was then carried within the 802.3 packet in an 802.2 header, keeping in accordance with the overall IEEE 802 plan.
The 802.2 header made 802.3 consistent with the other 802 physical layer protocols. This was intended to allow easy use of these datalink layers by the ill-fated OSI protocol suite. Until NetWare v4.0 shipped with Ethernet_802.2 as the default for Ethernet drivers, OSI was the only significant use of the 802.3/802.2 protocol (except for a few uses of the SNAP extension to 802.2, which in Novell drivers is a different frame type: Ethernet_SNAP).
Ethernet_802.2 packets are distinquished from Ethernet packets by having a packet length of 1500 bytes or less. Ethernet protocol IDs are all larger than 1500 decimal.
Where did Ethernet_802.3 come from? -----------------------------------
Ethernet_802.3 came from Novell. At some point in the development of 802.3, someone at Novell got a copy of the 802.3 specification. I wasn't around at the time, so i don't know for sure what happened, but apparently it didn't occur to anyone that a legitimate datalink protocol would simply *have* to carry a network layer protocol identification. (Without a protocol ID, the datalink protocol could only be used for a single protocol, which isn't very practical.)
Anyway, to make a long story short, some Novell engineer implemented 802.3, but *without* the required 802.2 header. (Novell apologists claim that at some point in the early days of 802.3, the 802.2 header wasn't required. I'll believe that the requirement for 802.2 might not have been clearly spelled out at some point, but i cannot believe that anyone on the 802.3 committee thought 802.3 didn't need a protocol descriminator, so i'm sure the intention was always for 802.2 to be required.) Instead of an 802.2 header, in the Ethernet_802.3 frame IPX simply sits right in the 802.3 packet as the only possible protocol.
Now normally you might think that having two protocols, IPX and 802.2, both riding in the same place in the same type of frames would cause a problem. Indeed, there have been isolated cases over the years of nodes expecting 802.2 being confused by arriving IPX packets and vice versa. But by a remarkable stroke of serendipity, IPX packets, which until just recently always started with two bytes of all ones, look ridiculous to properly implemented 802.2 code. (And, on the other hand, 802.2 packets never start with two bytes of all ones, which makes them invalid as IPX packets transmitted in Ethernet_802.3 frames.) This has made the number of problems quite limited, and such bugs in the packet handling code were generally fixed posthaste.
Where did Ethernet_SNAP come from? ----------------------------------
802.2, being three bytes long, makes the network layer packet badly aligned in an 802.3 packet. In addition, only seven bits are available in 802.2 for descriminating between different protocols, so there can only be 128 different protocols on an 802.2 network.
The solution to these problems, driven by the TCP/IP community which -- guess what? -- likes to have its packets aligned and requires several protocols, was SNAP (which stands for something, i just can never remember what), which in Novell LAN drivers is the frame type Ethernet_SNAP. SNAP uses a single 802.2 protocol ID (hex AA) to indicate a SNAP packet. The SNAP packet, carried inside the 802.2 packet, has a five byte header followed by the network layer protocol. The five byte header is simply a five byte protocol ID. The first three bytes of the protocol ID are a Organizational Unit Identifier (or OUI) identifying the authority assigning the protocol ID. The last two bytes are the protocol ID according to that authority.
This sounds a little complicated, but in practice the three byte OUI is always zero and the last two bytes are always the Ethernet Type code assigned to the protocol for use on standard Ethernet. (Well, ok, there is one exception: AppleTalk, for reasons i cannot fathom, uses some other OUI (presumably Apple's), but still uses the Ethernet Type as the last two bytes. The punch line is that AppleTalk's auxilliary protocol, AARP, uses an OUI of zero. Go figure.) In other words, when SNAP is used, it typically ends up being eight extra bytes of datalink header just to get back to the information that's normally carried in the simple Ethernet packet.
Why does IPX run on all four frame types? -----------------------------------------
In article <1993Sep17.190654.13...@novell.com> d...@novell.com (don provan) writes: >I also suggest that these answer be added to the >FAQ, and i'll make the entire pamphlet available for anonymous FTP on >sjf-lwp.sjf.novell.com in odi/eframe.txt.
I'm sure many people will appreciate the effort that has been put into this but if it is going to go into the FAQ I think it ought to be made clear it is a personal view. Apart from one or two purely factual inaccuracies it makes a lot of claims about IEEE vs. DIX which aren't really backed up. A proper list of which protocols actually do use DIX, 802.2 or SNAP would be interesting, but a highly selective one is not, and proves nothing.
In particular there were several users of non-SNAP 802.2 before Novell, apart from OSI. SNA, X.25, MMS, RPL to name but four, as well as low-level protocols like the bridge spanning tree protocol which you may have running on _your_ LAN whether you like it or not. It also dismisses IEEE's technical improvements such as the separation of media-dependent and independent parts. (DIX is unique to Ethernet; 802.2 is exactly the same frame as you get on FDDI and IBM token ring.) Even Novell are using this separation of layers in their new LAN driver architecture. Maybe that will even mean the 802.2 frame processing is more optimised than DIX frames, since the 802.2 module is a more general piece!
I hope others from Novell are still reading this news group. Novell needs to keep in touch with the people in the trenches. Feed back from users is essential for Novell to "to supply you with the best products possible."
In article <1993Sep17.193204.14...@novell.com>, d...@novell.com (don provan) wri tes:
> Some of you might be wondering what prompted me to post my recent (or > future, depending on how time runs in your news service) opus on > Ethernet frame types. Well, yes, continual nagging by y'all out there > had something to do with it, but primarily it was the last major > contribution i needed to make to these forums before i dropped off > line. A sharp increase in my responsibilities here at Novell make it > impossible for me to continue participating in these lists. In fact, > i haven't had time to read them for a week or two already. With > regret i will be hitting the old unsubscribe key as soon as i've > finished posting this last note.
> I'm sure y'all'll be able to carry on without me. Rest assured that > i'll be busy working under the covers to make sure that Novell > continues to supply you with the best products possible. Au revoir.