Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
Articles and Tips: article
Corporate Integration Manager
Systems Engineering Division
RICHARD JONES
Development Manager
ODI LAN Driver Development Team
NetWare Systems Group
01 Sep 1993
Novell has changed the default frame type for all Ethernet LAN drivers from IEEE 802.3 "raw" to IEEE 802.2. This AppNote provides some background information on Ethernet frame types, explains why the default change was made, and offers some suggestions for migrating to the IEEE 802.2 frame type in NetWare 4.x, 3.x, and 2.x environments. This information will be of interest to anyone who receives new NetWare LAN drivers and plans to use them to update previous drivers on a Novell network.
Related AppNotes Nov 92 "Communications Basics and Open Data-Link Interface Technology"
- Introduction
- A Brief History of Frame Types
- NetWare's Support of Multiple Protocols
- Issues with Switching to 802.2
- Guidelines for Migrating Frame Types
- Conclusion
Introduction
Recently, Novell changed the default frame type for all Ethernet LAN drivers from IEEE 802.3 "raw" to IEEE 802.2. The ramifications of this change are important for network designers, installers, and administrators to understand, especially as networks move increasingly toward multivendor, mixed-protocol environments. By selecting this new default frame type, Novell is taking steps to more easily accommodate packet checksumming, advanced security features, protocol independence, and other emerging technologies. However, the intent of this change is not to limit anyone's choice of frame type. With ODI LAN drivers, customers still have the freedom to choose the frame type(s) that best fit their computing environment.
This AppNote provides some background information on Ethernet frame types for those who are unfamiliar with them. It then explains why the default change was made and offers some suggestions for migrating to the IEEE 802.2 frame type in NetWare 4.x, 3.x, and 2.x environments. This information is targeted toward anyone who receives new NetWare LAN drivers and plans to use them to update previous drivers on a Novell network.
A Brief History of Frame Types
Most computer networks require that information transmitted between two stations be divided into blocks called packets or frames. For these packets to be sent successfully to other devices on the network, certain protocol and routing information must be added to the data. In addition, the way this information is arranged inside the packet must conform to a specific format.
In Ethernet, Token-Ring, and other network protocols, media-specific headers define the way data frames (packets) are organized so that they can be sent and received on the wire. The difference between frame type definitions is similar in concept to the differences in the way mail is addressed in different countries. For example, in the United States, a five-digit ZIP code must be included at the end of the address. Canada requires a postal code grouped in two sets of three characters each. Other countries have their own specific rules. International mail cannot be delivered to the correct destination unless: (1) the addressing rules are followed; and (2) mail handling personnel are trained to read and interpret the different addressing schemes.
Similarly, packets cannot be delivered unless the data is packaged as specified by the network protocol and the routing station is able to interpret the information in the media header. When a network device receives a packet, it needs some way of knowing which "translator" to hand it up to so the data can be delivered to the appropriate destination.
Being able to identify a packet's protocol is important in a mixed network environment where different types of computers (running DOS/Windows, Macintosh, Unix, IBM terminal emulation, and so on) communicate using different protocols (IPX/SPX, AppleTalk, TCP/IP, SNA, and so forth). In many cases, routers are used to interconnect these disparate environments. As packets come in to a router, it must figure out what to do with them: route them as IPX packets or as another protocol's packet.
Data Packet (Frame) Standards
The IEEE (Institute of Electrical and Electronic Engineers) is an international professional society that issues LAN technology standards. Some of the LAN standards developed by the IEEE include:
|
IEEE 802.5 |
A physical layerstandard that defines the token-passing accessmethod on a ring topology |
|
IEEE 802.4 |
A physical layerstandard that defines the token-passing accessmethod on a bus topology |
|
IEEE 802.3 |
A physical layerstandard that defines the CSMA/CD accessmethod on a bus topology |
|
IEEE 802.2 |
A data link layerstandard used with 802.3, 802.4, and 802.5 |
In NetWare, frame types are an issue only for Ethernet networks, those that use the CSMA/CD (Carrier Sense Multiple Access with Collision Detection) media access method on a bus topology. On Token-Ring and other networks, IPX/SPX has always used the IEEE 802.2 frame format. Over the years, several frame types have been defined for Ethernet:
Ethernet II
IEEE 802.3 "raw"
IEEE 802.3 with 802.2
IEEE 802.3 with 802.2 SNAP
These frame types are discussed in more detail below, along with a little of the history of how they were developed.
Ethernet II. In the early days of computer networks, Digital, Intel, and Xerox got together and specified a networking standard that they called Ethernet. This standard included the definition of a data-link-level access method and a packet format which shared the Ethernet name. (Today it is often called Ethernet II to reflect its second revision. For clarity, we'll refer to it as Ethernet II in this AppNote.)
The Ethernet II standard specified that a header be added to the data before sending it on the network medium. The frame format follows the rules to access a network using the CSMA/CD access method. Figure 1 illustrates the fields defined for Ethernet II data packets.
Figure 1: Ethernet II frame definition.
A preamble (not shown) is used to synchronize the receiving stations and to indicate that data is about to begin.
The destination address and source address fields contain the local node addresses of the sender and intended receiver, respectively. This has turned out to be the standard way of handling remote addresses on a network. IEEE uses destination and source address fields for all of their standards. Even emerging technologies such as Asynchronous Transfer Mode (ATM) will support this type of addressing.
The frame type field indicates which upper-layer protocol (such as NetWare's IPX/SPX or the Internet's IP) should be used to interpret the information in the data portion of the packet. The values for this type field were defined and managed by Xerox. For example, Novell was assigned the hexadecimal value 8137 for IPX/SPX.
The data part of the packet contains the protocol header and the actual information being transmitted. The minimum size of an Ethernet packet is 64 bytes. If there is not enough data to fill the packet, a pad field is added to make the packet size equal to the minimum.
The frame check sequence (FCS) field is used to check the integrity of the packet. Before placing a packet out on the wire, the sending node takes all the bytes within the packet (excluding the preamble and the FCS field itself), performs a mathematical calculation called a cyclical redundancy check, and places the result at the end of the packet. When the packet arrives at the destination, the receiving station performs the same mathematical calculation and should receive the same result. If not, it assumes something has been corrupted and discards the packet. This is known as bit-level error checking.
IEEE 802.3. Eventually, both the Ethernet media and packet format were pursued by the standards committees of the IEEE. Working from the original Digital-Intel-Xerox specification, IEEE proposed its own Ethernet standard which they called 802.3 (named after the committee that worked on it).
The IEEE 802.3 frame format is almost identical to the Ethernet II format. The only difference is that a length field is used in place of the type field, as shown in Figure 2. This field indicates the length of the data portion of the 802.3 packet. (The maximum length value for Ethernet/802.3 frames is 1518 decimal.)
Figure 2: IEEE 802.3 frame definition.
You might wonder how a router can tell if it's receiving an Ethernet II frame or an 802.3 frame. As it turns out, the assigned values for the Ethernet II type field are always greater than 1500 decimal. Since the maximum frame size for Ethernet is 1518 bytes, the length field will always contain a value less than that. This is the only way for routers to tell the difference between the two frame types.
Without a protocol type field, however, it is impossible to determine what protocol to use for interpreting the encapsulated data in an 802.3 frame. If more than one upper-layer protocol exists on the network, the packet may be incorrectly routed.
IEEE 802.3 with 802.2. The information necessary to properly route 802.3 packets is provided in the IEEE 802.2 standard, which wasn't fully developed until quite some time after the 802.3 standard. The 802.2 header envelopes the data before it is encapsulated within an IEEE 802.3 header. Because the 802.2 fields comprise the Logical Link Control (LLC) layer, the framed data is sometimes referred to as the Logical Link Control Protocol Data Unit (L-PDU). For brevity, we'll refer to the standard IEEE 802.2 data-link layer header enclosed by an IEEE 802.3 physical layer frame as the "IEEE 802.2" frame type.
The IEEE 802.2 frame format adds several fields to the header: a destination service access point (DSAP), a source service access point (SSAP), and a control field, as shown in Figure 3.
Figure 3: IEEE 802.2 frame definition.
A service access point denotes the point of service the packet is intended for, or what upper-layer protocol is supposed to use the data. Both the DSAP and the SSAP fields contain values that identify the upper-layer protocol type of the packet. For example, NetWare IPX/SPX packets will contain the hexadecimal value E0 in the DSAP and SSAP fields.
The control field is used by certain protocols for administrative purposes. Currently, NetWare's IPX/SPX protocols do not use this field other than to set its value to 03, which denotes 802.2 unnumbered format.
When a receiving station receives an IEEE 802.2 packet, it can determine that it is an 802.3 frame with an 802.2 header inside of it. It can then determine the protocol type from the information in the DSAP and SSAP fields.
IEEE 802.2 with SNAP. After the 802.2 frame was defined, there was some concern that the one-byte DSAP and SSAP fields were not adequate for the number of protocols that might eventually need to be identified. One might think that 256 is more than enough, but a lot of the possible values were reserved from the beginning.
In response to pressure from Apple Computer and the TCP/IP community, another frame standard was defined for both Ethernet and Token-Ring. It was called the subnetwork access protocol (SNAP). This frame type adds a five-byte protocol identification field at the end of the 802.2 header, as shown in Figure 4. This is where the protocol is identified.
Figure 4: IEEE 802.2 SNAP frame definition.
To distinguish an IEEE 802.2 SNAP packet, the value of the DSAP and SSAP fields in the 802.2 header are both set to AA. If a router finds AA in the DSAP and SSAP fields, it knows this is a SNAP-based packet and it should look for the protocol type in the protocol identification field.
Identifying the Incoming Protocol
In computer networks that incorporate multiple protocol stacks, a field for specifying upper-layer protocols must exist in the header information. Figure 5 indicates which field is used for this purpose in Ethernet II, IEEE 802.2, and IEEE 802.2 SNAP frames.
Figure 5: Fields used to identify the incoming protocol.
As mentioned previously, Digital's Ethernet II frame type uses a frame type field in place of the length field in the 802.3 header to specify the protocol type. The other two frame types contain fields set aside specifically for identifying the protocol.
When Novell initially implemented its IPX/SPX protocols on Ethernet, IEEE had not fully developed the 802.2 standard. For this reason, we used the 802.3 frame specification without the 802.2 header. But the 802.3 standard wasn't meant to be used all by itself; it was meant to be combined with the 802.2 Logical Link Control information. Thus the IEEE 802.3 frame used without 802.2 was nicknamed the 802.3 "raw" frame type. Novell's IPX is the only protocol that uses the 802.3 raw frame type.
To accommodate additional protocols on a network, Novell decided to use the first two bytes in the data portion of the packet, the IPX checksum field, to identify an 802.3 raw frame using the IPX/SPX protocol. All LAN drivers would use the value 0xFFFF in these two bytes to designate the packet as 802.3 raw, as shown in Figure 6.
Figure 6: Novell's Ethernet_802.3 "raw" packet always has the value 0xFFFF in the checksum field of the IPX header.
Notice that NetWare's IPX header is located at the beginning of the data portion of the 802.3 raw packet. Thus the IPX header always begins with FF-FF. The IPX header also contains information such as the destination and source network, node, and socket addresses.
To identify a packet as 802.3 raw in a mixed environment, receiving stations must first determine whether the value in the length field is less than 1518 bytes (to distinguish it from an Ethernet II frame type). If so, they check the value of the next two bytes. If it is FF-FF, they know it is an IPX packet because FF-FF isn't currently used in 802.2 DSAP and SSAP fields. This process is illustrated in Figure 7.
Figure 7: Identifying an 802.3 raw (IPX) packet.
NetWare's Support of Multiple Protocols
As NetWare started being installed in multiplatform environments and Novell began to develop products that supported protocols in addition to IPX, it became apparent that support for other frame types would be necessary. NetWare 2.1x users may remember using the ECONFIG utility to change the frame type for Ethernet LAN drivers.
Open Data-Link Interface (ODI)
To overcome the limitations of the 802.3 raw frame type and provide support for other environments, Novell developed a new LAN driver specification called the Open Data-Link Interface (ODI). Starting with the release of NetWare 386 3.0 in 1989, Novell has included ODI LAN drivers to provide support for multiple frame types on the same network adapter.
The ODI specification allows a workstation to use any desired frame types supported by the LAN adapter. NetWare servers using ODI drivers can accommodate multiple frame types on the same physical network. (For a more complete discussion on ODI, see "Communication Basics and Open Data-Link Interface Technology" in the November 1992 NetWare Application Notes.)
ODI supports all four Ethernet frame types. They are listed below along with the frame type names defined by Novell and used within the NET.CFG and AUTOEXEC.NCF configuration files:
|
IEEE 802.3 raw IEEE 802.3 with 802.2 IEEE 802.2 with SNAP EthernetII |
(Ethernet_802.3) (Ethernet_802.2) (Ethernet_SNAP) (Ethernet_II) |
ODI also supports many server and workstation platforms:
NetWare 3.x and 4.x
DOS
Windows and Windows NT
OS/2 1,x, 2.0, and 2.1
UnixWare
Note that NetWare 2.x is not supported by ODI. To maintain compatibility with the installed base of NetWare 2.x, the default frame type for ODI LAN drivers remained 802.3 raw. But ODI gave network supervisors the capability to choose the best frame type for their environment. Even so, most Novell customers that have implemented ODI stuck with the 802.3 raw frame type.
New NetWare Default Frame Type
For all new NetWare 3.x and 4.x LAN drivers shipped on or after April 15, 1993, the default frame type is now IEEE 802.3 with 802.2 (Ethernet_802.2). Novell made this change for a number of reasons:
Standards-based operation.
802.3 raw is not recognized by the IEEE as a standard. The IEEE recognizes only 802.3 with 802.2 and 802.2 SNAP frame types. Most vendors are moving quickly to adhere to standards because most government agencies require compliance with IEEE and ISO standards. Because Novell's 802.3 raw headers do not comply, NetWare on Ethernet has not been widely implemented by government agencies. NetWare does use 802.2 frame types on Token-Ring networks, making it IEEE and ISO compliant. As a result, many government agencies have installed Token-Ringnet works.
Support for large multivendor environments.
Many large installations have connections with minicomputers and mainframes, most of which are not compatible with 802.3 raw frame formats. For example, Digital hosts do not support 802.3 raw packets. This was the reason Novell provided the ECONFIG utility to add Ethernet II support into the drivers for NetWare 2.x networks.
IPX checksumming.
The introduction of technologies such as NetWare SFT III, packet signing (phase II and above for high-level security), and other advanced security features require the use of IPX checksumming in NetWare. Since workstations, servers, and routers rely on the IPX checksum field to identify 802.3 raw IPX packets (in the past, this field has always been set to FFFF), IPX checksumming cannot be used with 802.3 raw packets. Therefore, another Ethernet frame type must be used to support checksumming.
OSI 802.2 diagnostics.
Certain OSI 802.2 diagnostic packets use an 802.2 header with DSAP and SSAP values of FF-FF. But placing 0xFFFF as the first two bytes after the 802.3 header makes the packet look identical to an 802.3 raw packet. Thus 802.3 raw and 802.2 diagnostic packets cannot coexist on the same network.
MAC layer bridging.
Bridging Ethernet to Token-Ring (which is all 802.2 compliant) is problematic withraw 802.3 packets. The bridge cannot perform this function, so most manufacturers have created specialized bridges to handle it. In most cases, bridges were designed to convert from 802.3 raw frames to 802.5 with 802.2 frames. But these bridges had to maintain a table of all the stations using 802.3 raw so that when a packet was received from the Token-Ring side, it was forwarded as 802.3 raw and not 802.3 with 802.2 to those stations. To get around this, some customers have installed an IPX router to handle the 802.3 raw IPX packets, and then they bridge the rest. Others require users to use ODI drivers and switch to 802.2 and remove all raw 802.3 IPX frames from the system. Switching to IEEE 802.2 will allow Ethernet and Token-Ring networks to communicate without requiring an IPX router.
Coupled with the default frame type change for Ethernet drivers is the move away from dedicated or "linked" DOS IPX workstation drivers. Dedicated DOS IPX workstation drivers are no longer supported by Novell (except for IPX.OBJ if an adapter only has a dedicated DOS IPX driver available). Novell is providing utilities to assist in the upgrade from these drivers to DOS ODI drivers.
Issues with Switching to 802.2
It is important to emphasize that by selecting a new default frame type, Novell is not implying that IEEE 802.2 is the best frame type to use in all situations, nor are we attempting to limit your choice of frame type. ODI LAN drivers allow you the freedom to choose the best frame type for your particular environment.
Given that Novell's official stance on recommended frame type is to remain neutral, here are some guidelines to help you decide which is best for your environment:
We strongly suggest that users move away from the 802.3 raw frame type, since it is not a standard and cannot support IPX checksumming.
Ethernet II has not been standardized by any internationally recognized standards organization. This should deter large multivendor installations from implementing this frame type as a new strategy.
The 802.2 frame type has been standardized by IEEE, ANSI (American National Standards Institute), and ISO (International Standards Organization). The IEEE 802.2 frame type provides all of the features necessary to properly run NetWare. Most notably, it allows for IPX checksumming. 802.2 is now Novell's default for all Ethernet, Token-Ring, and FDDI drivers. Consequently, if you standardize on 802.2 and subsequently receive a new driver from NetWire or from a board vendor, the network administrator does not have to worry about modifying NET.CFG files at workstations or specifying a frame type when loading the driver at the server. This frame type is the simplest and most trouble-free choice in most situations.
The SNAP frame type has been widely implemented. In fact, it is the solution for both TCP/IP and AppleTalk on Token-Ring networks. However, it isn't a good reason to select SNAP frames for IPX/SPX simply because you are also supporting IP and AppleTalk with SNAP. Since there is effectively no interaction between the IPX, IP, and AppleTalk protocols, you can run the latter two on SNAP and IPX on some other frame type with no problem. Also, if you choose SNAP, your network administrators will have to remember to explicitly specify the frame type whenever they load a driver. This could become a continuing problem for administrators and users alike.
The remainder of this AppNote assumes that you are standardizing on IEEE 802.2 frames and describes how to migrate Ethernet networks from 802.3 raw to the 802.2 frame format. It gives examples and the information necessary for you to understand what is happening and how to manage the transition.
The full impact of the switch to the 802.2 default frame type may not be immediately apparent. If you receive an Ethernet LAN driver today that is set up for 802.2 as the default and upgrade your existing driver that uses 802.3 raw, you need to pay attention. The potential problems can range from "File server not found" errors to malfunctioning routers.
Don't be alarmed, however. You do not have to change all workstations, routers, and servers all at once. In fact, you can determine the rate of migration. Where possible, Novell has automated the process with installation utilities.
There are three main issues to be aware of when migrating from 802.3 raw to 802.2 frame types:
Both sides of the network communication (file server and workstation) must support 802.2 frames.
All intermediate routers must be able to support 802.2 frames(this is true only if checksumming will be used).
Support for both 802.3 and 802.2 frame types is sometimes necessary during the migration period.
Example 1
As an example, Figure 8 shows a typical 802.3-only NetWare network in which all stations use 802.3 raw frames.
Figure 8: Typical NetWare network with only the 802.3 raw frame type in use.
Now suppose you bring in a new workstation driver with 802.2 as the default frame type, and load it on WS1. In essence, this workstation is now communicating on a different "network." As shown in Figure 9, WS1 can no longer communicate with server FS1. In fact, upon bootup it will receive a "File server not found" message.
Figure 9: When only WS1 is upgraded to a new 802.2 driver, it can't communicate with server FS1 anymore.
The solution in NetWare 3.x and 4.x environments is to configure IPX at the server to communicate with both 802.3 raw and IEEE 802.2 frame types, as shown in Figure 10. All that is necessary to support this communication is the additional loading of the 802.2 frame type on the server's network adapter. (We'll describe how to do this later in this AppNote.)
Figure 10: After configuring FS1 for both 802.3 and 802.2 frames, WS1 can successfully communicate with it.
Example 2
Now suppose we introduce another server on the network that doesn't support multiple frame types (for example, a NetWare 2.x server). As shown in Figure 11, WS1 (which has an 802.2 default driver) can communicate with FS2 with FS1 acting as an intermediate "router." The 802.2 packets are going to come in to FS1 on network AA and be routed right back out of the same network adapter to FS2 via network BB.
At first glance, there doesn't seem to be much of an issue here. You've got connectivity-the workstations and servers are all communicating with each other. However, WS1 is causing twice the amount of Routing Information Protocol (RIP) and Service Advertising Protocol (SAP) traffic that is necessary to communicate with FS2. For organizations that are nearing the maximum throughput on the network, this solution could present a problem.
Figure 11: WS1 can also communicate with the NetWare 2.x server, with FS1 acting as a "router" between 802.3 and 802.2.
About the only other option is to upgrade all the drivers to 802.2 at once. In most cases, setting up your servers to support both 802.3 and 802.2 while you gradually migrate the workstations is the better approach. However, it is recommended that you migrate as expediciously as possible. True, you will essentially have two separate networks on the same wire for a while. But you still have the flexibility to continue running 802.3 for as long as is necessary.
Configuring Frame Types with ODI
For DOS/Windows workstations, the frame type is configured in the NET.CFG file. For NetWare 3.x and 4.x servers, the frame type is configured when the LAN driver is loaded, either at the command line or in the AUTOEXEC.NCF file.
Note: The NetWare Requester for OS/2 has always been based on ODI since it was first released with OS/2 1.0. The same Ethernet frame default change is also occurring with most of the OS/2 ODI drivers included with NetWare 4.x. (Some third-party OS/2 drivers will still default to 802.3 raw, but you can select 802.2.)
Configuring Workstations. For workstations using ODI LAN drivers that default to 802.3 raw frames, you need to edit the NET.CFG file to specify the 802.2 frame type. The following line should be added under the [Link Driver DriverName]section of NET.CFG:
FRAME = ETHERNET_802.2
Be sure to indent this line in the NET.CFG file. The syntax is not case sensitive.
Once this change is made, the workstation will not be able to "see" or attach to any servers that do not have the 802.2 frame type enabled.
Workstations cannot run two frame types with the same protocol stack. For example, IPX can be bound to either IEEE 802.2 or 802.3 raw, but not both.
ODI does allow the use of different frame types for different protocol stacks. Here is an example NET.CFG file for a workstation containing an NE2000 network adapter and using both IPX and IP protocols.
NET.CFG
Link Driver NE2000 Int 5 Port 360 Frame = Ethernet_802.2 Frame = Ethernet_SNAP Protocol IPX E0 Ethernet_802.2 Protocol IP 800 Ethernet_SNAP Protocol IPX Bind #1 Protocol IP Bind #2
Configuring NetWare 3.x and 4.x Servers. With NetWare 3.x and 4.x servers, you configure the driver when it is loaded. This could be at the command line, in the AUTOEXEC.NCF file, or through the INSTALL.NLM.
Here are some example LOAD and BIND commands for enabling a server's NE2000 adapter to use both 802.2 and 802.2 SNAP frame types:
Load NE2000 Frame=Ethernet_802.2 Name=8022 Int=5 Port=360 Load NE2000 Frame=Ethernet_SNAP Name=SNAP Int=5 Port=360 BIND IPX 8022 NET=01030014 BIND IP SNAP
Note: INETCFG is new utility from Novell that you can use to match all drivers and protocols without having to rely on command line entry. Contact your Novell reseller for more information.
Guidelines for Migrating Frame Types
The following sections give specific guidelines for migrating from 802.3 raw to 802.2 frame types in various NetWare environments. For more information on exact procedures, refer to your NetWare manuals.
NetWare 4.x Server Installation
The NetWare 4.x server installation utility will install both Ethernet raw 802.3 and IEEE 802.2 frame types as defaults and bind the IPX protocol stack to each. Both frame types will be represented as logical IPX networks. The IPX router (internal to the OS) will route packets between the two logical networks. This means that each frame type will require its own unique IPX network address.
If NetWare 4.x is installed on a new machine that is attached to an existing network, the installation utility will try to determine the network's address. NetWare 4.x sends out a request to any IPX servers or routers on the network and queries what the network address is on that given wire and frame type. If a response is received, NetWare 4.x will use the network address it found to load the IPX protocol stack, and will not prompt you for an IPX network address. If no response is received, NetWare 4.x will prompt you to specify an IPX network address.
The NetWare 4.x installation utility will install both frame types only for Ethernet network device drivers. If you want to install only one default frame type, you can specify the frame type during installation.
Because NetWare 4.x installs both 802.3 raw and 802.2 frame types for Ethernet at the server, both existing 802.3 and newer 802.2 Ethernet workstation drivers can coexist on the same physical network. The only overhead in using both frame definitions on the same network is that NetWare's SAP and RIP traffic is doubled on the wire. After you migrate the workstations to the 802.2 frame type, you can remove the 802.3 frame definitions at the server.
Installing NetWare 4.x ODI Workstation Drivers
The default frame type for Ethernet ODI workstation drivers shipped with NetWare 4.x is IEEE 802.2. To change the frame type, you must include an entry in the NET.CFG file (see "Configuring Workstations" above).
Multiple frame types can be loaded, but each additional frame type loaded will consume about 120 bytes of workstation memory. Furthermore, the IPXODI workstation protocol stack can be bound to only one frame type at a given time. It does not have a built-in routing function.
The workstation installation utility will prompt you for the desired Ethernet frame type (802.2 is the default) and will install the ODI drivers as well as create a NET.CFG file, even if defaults are selected. You can then select any one or a combination of frame types from the installation utility.
You should install the workstations with 802.2 as the default frame type, ensuring that the workstations are connected to the same physical network, such as a NetWare 4.x or NetWare 3.1x file server with the 802.2 frame type for Ethernet loaded and bound to IPX.
Only DOS ODI workstation drivers are included with NetWare 4.x. Older dedicated DOS IPX drivers (which required linking with the WSGEN or SHGEN utility) are being phased out. A supplemental workstation diskette with dedicated DOS IPX and the WSGEN utility will be available from Novell (not included with third-party drivers). If at all possible, you should use DOS ODI drivers, which are available for all commonly used network adapters.
To help you upgrade DOS workstations from dedicated IPX drivers to DOS ODI drivers, Novell is supplying the WSUPGRD utility, which will simultaneously upgrade workstations that are similarly configured. You can execute the WSUPGRD utility from the system login script. WSUPGRD will scan the dedicated IPX.COM file on the workstation, determine which driver was linked with the SHGEN or WSGEN utility, and discover what hardware options were selected. It will reference an installation file you created to select the appropriate ODI driver and install the following:
The ODI driver and the Link Support Layer (LSL)
IPXODI protocol stack
An appropriate NET.CFG file
You can configure or define each of these components. See the DOS ODI Workstation manual (NetWare 3.11) or NetWare Workstation for DOS and Windows manual (NetWare 4.0) for details.
Migrating from NetWare 3.11 to 4.x
How you upgrade your NetWare 3.11 server depends largely upon how you installed that server. If, during the installation process, you selected "Create AUTOEXEC.NCF" after loading and binding network drivers, the AUTOEXEC.NCF file will include an entry specifying the 802.3 raw frame type. If you upgrade to NetWare 4.x without using its installation utility, drivers will load with the 802.3 raw frame type. If you use the 4.x install utility to upgrade a 3.1x server (the recommended upgrade path), both the 802.3 and 802.2 frame types will be installed.
If you selected another frame type (such as Ethernet II) when you installed the NetWare 3.1x server and 802.3 raw is not specified in the AUTOEXEC.NCF file, the 4.x install utility will not add the 802.2 frame type. The network will be installed with the frame type you chose for the NetWare 3.1x server.
If the AUTOEXEC.NCF file was not created by the NetWare 3.1x install utility and the "FRAME=" command line option was not specified in the AUTOEXEC.NCF file, the 4.x install utility will display a warning message.
Mixed NetWare 3.x and 4.x Networks
For internetworks that include both NetWare 3.1x and 4.x servers, you can change the frame type in one of two ways:
First, the NetWare 4.x server can route 802.2 packets for the 4.x workstations and route 802.3 raw packets for the 3.1x servers. Then, one by one, the NetWare 3.1x servers can be converted to 802.2 by changing "FRAME=Ethernet_802.3" to "FRAME=Ethernet_802.2" in the AUTOEXEC.NCF file. In this way, any remaining 802.3 raw workstations can access the converted NetWare 3.1x servers by routing through the 4.x servers.
A second method (possibly easier) would be to add the 802.2 frame type with the existing 802.3 raw frame to the NetWare 3.1x servers. You can make this change at your convenience by adding a line to the AUTOEXEC.NCF file in the NetWare 3.1x servers. Remember that you must bind IPX to the added frame type and specify a network address for the logical network. After all the workstations have been upgraded to 802.2, you can remove the 802.3 raw frame types from the servers.
NetWare 3.11 Environments
This section is for those who currently have a strictly NetWare 3.11 network and want to standardize on 802.2 frames. Changing to the IEEE 802.2 frame type can be done easily and gradually if desired.
The first step is to add the additional frame type to the existing configuration.
The following example assumes that the server is up and running and that it contains an NE2000 adapter. You should substitute the appropriate LAN driver for your configuration.
At the server console prompt, type "LOAD NE2000 <Enter<". The server will load another instance of the NE2000.LAN driver and ask if you want to add another frame type for a previously loaded board.
Answer "Yes" to the prompt. The server will display the hardware configuration for all currently loaded NE2000 drivers. For example:
1. NE2000 using I/O port 300h to 31Fh, Interrupt 3h.
Select the desired LAN adapter (or type "1" if there is only one.) The server will display the supported frame types:
1. Ethernet_II2. Ethernet_802.23. Ethernet_SNAP
Select "Ethernet_802.2" to add the new frame type to the LAN board already loaded in the server.
The next step is to bind IPX to the board and specify a network address. The network address must be unique.
Type "BIND IPX TO NE2000 <Enter<". The server will display a list of boards using the NE2000 driver:
Several boards are using the NE2000 driver 1. NE2000 using I/O port 300h to 31Fh, Interrupt 3hFrame type: Ethernet_802.3 2. NE2000 using I/O port 300h to 31Fh, Interrupt 3hFrame type: Ethernet_802.2
Select the one that has the 802.2 frame type ("2" in this example).
The server will prompt you to enter a network address. Type an eight-digit hexadecimal number that is different from the 802.3 raw network address (for example, 1EEE8022).
The 802.2 frame type can be auto-loaded whenever the server is brought up by adding the following commands to the AUTOEXEC.NCF file:
load NE2000 int=5 port=300 frame=Ethernet_802.2 bind IPX to NE2000 net=1EEE8022
After one NetWare 3.11 server has enabled 802.3 raw and IEEE 802.2 frame types, all workstations using 802.2 frames will attach to that server. The workstation's packets can then be routed to the 802.3 raw network address. The end result is that 802.2 workstations can "see" and login to all servers on the network.
Until all servers are 802.2-enabled, all 802.2 workstations must route communications through an 802.2 network (server) to communicate with an 802.3 raw network.
Once all workstations have been migrated to 802.2 frame types, the 802.3 raw frame type support can be removed from the server. To do this, simply do not load the NE2000.LAN driver without specifying FRAME=ETHERNET_802.2.
NetWare 2.2 Environments
NetWare 2.2 servers should only be converted for compatibility with NetWare 3.x servers in a mixed 2.x/3.x environment. If you plan to upgrade your NetWare 2.2 servers to 3.x or 4.x, compatibility should be maintained by routing to the 802.3 raw frame type in one or more NetWare 3.x or 4.x servers and leaving the 2.2 server alone until it is upgraded.
NetWare 2.2 does not easily support protocols other than IPXC which is one reason the ODI architecture is used in later Novell products. After NetWare 2.15 (which supported Apple Macintosh computers), nearly all NetWare 2.2 Ethernet network drivers have supported the AppleTalk Phase II protocol. To support 802.2 on the IPX protocol in NetWare 2.2 servers, you must use Ethernet drivers that support AppleTalk Phase II.
You can support 802.2 on NetWare 2.2 by linking a virtual 802.2 driver into the system. This requires regeneration of the NET$OS.EXE file. This will allow both 802.3 raw and 802.2 frame types to exist on one physical network. However, the virtual 802.2 driver requires one of the four network driver positions in the 2.2 OS. Since 802.3 raw and 802.2 on the same network board represent two different logical networks, you must install a maximum of three physical Ethernet network boards if they must all support the two frame types.
Note: The Macintosh AppleTalk Phase II VAPs for NetWare 2.2 can coexist with the 802.2 virtual driver. Due to other limitations of the 2.x architecture, 802.2 packets must be limited in size to 512 bytes and the virtual 802.2 drivers will only work with 2.2 servers.
Third-Party Routers
Be aware that some third-party routers do not support 802.2 frames on Ethernet. This is an important consideration in deciding when and how to migrate your network to 802.2 frames. Many of these vendors plan to provide 802.2 support through new software or firmware releases. Contact your router vendor for more information.
Conclusion
In an effort to pave the way for emerging technologies and to remove the limitations of the Ethernet 802.3 raw frame type for IPX, Novell has taken three steps:
The default frame type for new Ethernet LAN drivers has been changed from 802.3 raw to IEEE 802.2. (The default for Token-Ring and FDDI drivers is already 802.2.)
Only DOS ODI workstation drivers are included with NetWare 4.x and releases of NetWare 3.x after 3.11. Dedicated DOS IPX workstations drivers have been phased out.
To help those upgrading to NetWare 4.x, the 4.x server installation utility loads both 802.3 raw and 802.2 frame types as the default for Ethernet networks.
Since both frame types can coexist on the same physical Ethernet network, you can decide when and how to change the frame type. Ethernet networks need not be migrated to IEEE 802.2, although migration is strongly recommended because it will make network management easier today and in the future.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.